[Top] [All Lists]

Re: Processing after the end of DATA

2010-08-11 14:50:21

Dilyan, We are getting way off topic for this list, so I invite you and anyone else who is interested, to a continuation of this discussion at

Дилян Палаузов wrote:
> On 10.08.2010 20:18, David MacQuigg wrote:
>> My system is too small to draw any conclusions, but my impression is
>> that we are overly-concerned about a very small fraction of the mailflow
>> - those few messages that are legit, but get a false reject from a
>> statistical filter. We really don't care about the proper SMTP response
>> if it is spam. The only advantage I see in running the spam filter
>> before ACCEPT is a few less messages at the bottom of my spam bucket. I
>> wish I had some numbers from a larger system.
> A user might have installed redirect for her incoming mails to another mail provider. The other provider might SMTP reject incoming spam. If there is spam for your user, your server does accept it, then sends it to the other mail provider, and that second server SMTP rejects it, then your server will have to send DSN for that SPAM (provided that you do not want to discard emails). With rejection-preferences similar on both servers, the amount of such DSNs will decrease, when both servers reject after DATA. You have no influence on what other servers do with the spam (smtp rejecting or inserting in spam folders).

We have quite a bit of influence. We insist that our recipients turn off all spam filtering, chain-forwarding, SPF checks, whatever might conflict with our acting as Receiver for their email address. Typically, they will have a private mailbox known only to our Receiver/Forwarder. Failures resulting from SMTP rejects, DSNs, or any other problem at the recipient's mailbox are treated the same as a mailbox being suddenly offline. Incoming mail to that address is rejected until we can resolve the problem with the recipient.

>> Would be nice if SMTP had a 'conditional ACCEPT': "Sorry, your
>> transmitter ID '' cannot be verified, Your message has been
>> routed to the recipient's quarantine." Imagine the effect that would
>> have on all the lame excuses for an invalid or hard-to-verify HELO name.
> What do you want to communicate to the sender with this conditional ACCEPT: "Dear Sender, your suspicious email has arrived. It might be read soon, it might be read late, or it might not be read at all."?

No, the message I suggested had a specific reason for the failure. It should also have a link to a webpage with instructions on how to fix the failure, like what we have now on REJECT messages:

> The problem with the spam folders are the false positives. Many users do check the spam folders/quarantines not that often as their Inbox and with less attention. This might lead to reading a message too late, or even overseeing it. I prefer to immediately notify the sender that her message was not delivered, including in the SMTP response alternative ways to contact the recipient (and spamassassin-evaluation of the mail), rather than let the sender hope that her email was properly delivered, while there is a risk that the recipient oversees that message.

False rejects are indeed the main problem with modern email systems, but this problem isn't solved by rejecting a small fraction of messages with the highest spam scores. There are still plenty of messages, almost all spam, that get a score low enough to be kept in quarantine, and there is always a risk that the recipient will overlook a legitimate message. The only good solution to the false reject problem is to offer senders a way to avoid the statistical filters entirely. That is what a reputation system does. When a message comes from (or any other A-rated domain), it goes straight to our recipient's inbox.

************************************************************     *
* David MacQuigg, PhD    email: macquigg at   *  *
* Research Associate                phone: USA 520-721-4583   *  *  *
* ECE Department, University of Arizona                       *  *  *
*                                 9320 East Mikelyn Lane       * * *
*        Tucson, Arizona 85710          *
************************************************************     *

<Prev in Thread] Current Thread [Next in Thread>