Re: Processing after the end of DATA

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 
http://groups.google.com/group/registry_internet.
Дилян Палаузов 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 box67.com 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 'yahoo.com' 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:  
http://open-mail.org/3strikes/REJECT.html
> 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 yahoo.com (or any 
other A-rated domain), it goes straight to our recipient's inbox.
************************************************************     *
* David MacQuigg, PhD    email: macquigg at ece.arizona.edu   *  *
* Research Associate                phone: USA 520-721-4583   *  *  *
* ECE Department, University of Arizona                       *  *  *
*                                 9320 East Mikelyn Lane       * * *
* http://purl.net/macquigg        Tucson, Arizona 85710          *
************************************************************     *