Re: Processing after the end of DATA
2010-08-11 12:25:41
Hello,
if rejecting after CRLF.CRLF is better than bouncing, what about
discussing draft-hall-prdr-00 and doing it more normative?
For an email with two recipients, the first one of who wants to receive
the mail and the second -- not, there is currently no option but to say
250 OK after CRLF.CRLF and send later DSN. With the idea described in
draft-hall-prdr-00, it is possible to avoid the currently unavoidable
DSN. Any suggestion, how this draft can be revived?
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).
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."?
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.
Със здраве
Дилян
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Processing after the end of DATA, (continued)
- Re: Processing after the end of DATA, SM
- Re: Processing after the end of DATA, Nathaniel Borenstein
- Re: Processing after the end of DATA, David MacQuigg
- Re: Processing after the end of DATA, Carl S. Gutekunst
- Re: Processing after the end of DATA, David MacQuigg
- Re: Processing after the end of DATA, John Levine
- Re: Processing after the end of DATA, David MacQuigg
- Re: Processing after the end of DATA,
Дилян Палаузов <=
- Re: Processing after the end of DATA, David MacQuigg
- Re: per user post-data rejects, Processing after the end of DATA, Дилян Палаузов
- Re: per user post-data rejects, Processing after the end of DATA, David MacQuigg
- Re: per user post-data rejects, Processing after the end of DATA, Дилян Палаузов
- Re: Processing after the end of DATA, ned+ietf-smtp
- Re: per user post-data rejects, Processing after the end of DATA, John Levine
- Re: per user post-data rejects, Processing after the end of DATA, ned+ietf-smtp
- Re: per user post-data rejects, Processing after the end of DATA, Dave CROCKER
- Re: per user post-data rejects, Processing after the end of DATA, Carl S. Gutekunst
- Re: per user post-data rejects, Processing after the end of DATA, ned+ietf-smtp
|
|
|