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 [EMAIL PROTECTED]@' 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? -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
