Phil Pennock wrote:
> On 2008-10-06 at 18:13 +0100, Ian Eiloart wrote:
>> What I had in mind was a new SMTP verb which would switch the entire
>> session (all subsequent MAIL commands) into LMTP, but I like the MAIL
>> argument better. I just wish that it was a switch into LMTP, and not
>> something almost, but not quite the same.
>
>> Here, Tony Finch says "this is of dubious utility if the spammers don't
>> also use it...". <http://fanf.livejournal.com/51156.html>.
>>
>> Perhaps, but it does at least allow us to handle non-spam, or even
>> forwarded spam, in a better way. And, don't forget that some spam might
>> actually be sent through well configured servers.
>
> What I've been considering for a couple of weeks now is adding an XLMTP
> extension, but EXDATA works just as well. A MAIL adverb, same general
> design, with the idea that what I'd configure is roughly "you use XLMTP
> or you're a whitelisted sender, else I limit you to one RCPT per
> transaction with 4xx errors for all additional recipients."
>
> (I'll write XLMTP but the same general thing applies to EXDATA and it's
> already out there).
'A journey of a thousand li begins with the first step'
(Confucius)
'..and ends with the last step. Even if it is also the first one'
(Hacker)
In ten years or so, Sam sems to have been the only MTA-maker to actually
*ship* something.
Seesm to me meeting that in-place feature is the 'first step' that most
deserves a 'second' step on the same path.
Anyway - it is the easiest....
>
> The idea being to wait a couple of releases for the XLMTP support to
> get out there and stabilised/bug-fixed, then start turning it on.
> There's no breaking of the protocol and it's a local site policy
> decision as to how aggressively to require it.
IF/AS/WHEN at least one other MTA would adopt XLMTP ...
But until at least two MTA-bulder communities demo interoperability, it
is mere 'intellectual incest' in discussion. And Onanism if shipped.
>
> I mean, seriously -- how many multiple recipient mails do I receive that
> aren't spam? A few from big providers (Gmail, Hotmail); when I hosted a
> family mailing-list, the built-up CC's would add a few more, but using
> list.dnswl.org takes care of those ISPs. Let's see, excluding local
> submission (replying to exim-users and poster), local host (Mailman):
> fgrep '<=' mainlog-* | fgrep -v P=local | fgrep -v H=smtp.spodhuis.org | grep ' for .*@.*@'
> gives 5 mails since the start of July. Two spams, two regular mails
> (sent to both my wife and myself) and one dhcp-announce mail which went
> to multiple mailing-lists, which went to multiple per-recipient
> addresses here.
> Anyone who still has access to an ISP's mail-logs able to do a similar
> analysis and give us a percentage figure? I suspect that you're looking
> at a very small percentage and some very rudimentary logs analysis would
> let you know what to whitelist before turning it on.
hardly an IPS, but from a mainlog not rotated since 13 March 2008:
conducive# grep -c 'R5 ' /var/log/exim/mainlog
2072
'R5 ' appears in the log for the fifth acl in acl_smtp_rcpt:
====
# RCPT_5: IF multiple recipients THEN defer all after first one.
# UNLESS for a domain that uses only per-domain preferences
#
defer
message = \n Limit one recipient at a time. Try again soon!
log_message = R5 $acl_m3 Second Recipient deferred.
!condition = ${if ge{$acl_m0}{2}}
!condition = ${if ge{$acl_m1}{2}}
!condition = ${if eq{$domain}{<redacted>}}
!hosts = <redacted list of those NOT using per-recipient prefs>
condition = $recipients_count
=====
NB: Our most active domain <redacted> does NOT use per-recipient prefs,
so skips this acl, as do several others in the !hosts line.
So far, this has had far less of a negative effect on correspondents
than greylisting deferrals - which can hit *everybody* at least once, if
not several retry times before listing kicks in.
That said, this is a BFBI tool.
I still want EXDATA (or equivalent) as a scalpel.
>
> Whitelisted or authenticated or per-recipient responses or single
> recipient per transaction.
See above. Two exemptions were provided. The first catching tha lion's
share with a singular comparison, vs a 'resource heavier' hostlist
expansion.
> Let's see if I can remember the knobs I
> thought appropriate and which I appear to have neglected to write down
> ...
>
> Main configuration:
> xlmtp_advertise_hosts = * (hostlist)
> -- obvious
> ACL:
> control = xlmtp_required_multircpt
>
> The ACL control is something that could be down with ACL variables and
> counters on RCPT verbs, but that gets fiddly and just a straight control
> would lead to cleaner config. I think that a default of
> no_xlmtp_required_multircpt with someone able to turn it on at the start
> of the connection unless the IP address matches relevant logic and turn
> it off again for authenticated connections is a fair balance. I was
> also thinking of a bool to automatically turn it off whenever the
> "control = submission" control is applies. I can't remember if there
> was something else ... damn, why is *this* the one where I didn't write
> it out before now?
>
> I can probably get around to writing an Exim patch for this.
>
> Feedback before I start mucking around?
>
See above. If the BFBI approach has not caused an Earthquake, anything
more fine-grained should slip into the pool with nary a ripple.
Afterwards? 'it ain't braggin' if you can actually DO it!'
Finding a courier-mta instance to test EXDATA inter-operability should
be dead easy.
Getting a(ny) other-MTA-than-Exim coder to co-implement XLMTP might take
longer... *Much* longer, given that it does not yet exist anywhere..
;-)
Best,
Bill
