Hello,
if rejecting after CRLF.CRLF is better than bouncing, what about
discussing draft-hall-prdr-00 and doing it more normative?
There have been several drafts over the years describing similar proposals. I
think this is the best of the bunch, mostly because it goes just far enough and
doesn't get into other things like trying to return entire DSNs in the SMTP
response stream.
I never understood why the interest level in this was so low. Anyone who has an
LMTP client can implement this pretty easily - the semantics are very similar.
THe server can be more difficult, but even so it's not that bad.
That said, this is unlikely to reduce blowback spam unless you required that
everyone implement it in order to send email, which of course we cannot do.
Consider: If the sender is legitimate, then a partial-success/partial-failure
scenario is a nonissue because the DSN is also legitimate.
If, OTOH, the sender isn't legitimate, then there's no incentive for them to
implement this - spammers can only benefit from blowback, and therefore have
no incentive to go out of their way to stop it.
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?
Simple: Post an update and see if there's any interest in moving it to
proposed. I would cetainly support it.
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.
But we do care in the case of false positive.
> 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.
Exactly - while PRDR will have little if any effect on existing blowback
issues, it adds to our handling options in the false positive case.
Ned