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).
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.
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.
Whitelisted or authenticated or per-recipient responses or single
recipient per transaction. 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?
