ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] SMTP Greylisting Retry Hints + PRDR

2019-02-08 13:45:47
Some more thoughts:

What kind of emails have a lot of recipients?  Newsletters and spam.  When the 
spam delivery is postponed, then even
better, as there will be more knowledge about that mail in the DNSBL/DCC later. 
 If the email is a newsletter (MLM),
then its delivery is likely not urgent and the delivery statūs will be handled 
by the MLM or the corresponding
postmasters will do some “accelerations” to deal with the case, when a server 
accepts few RCPTs per try.

My “alternative” delivery mode will impact “Distributed Checksum 
Clearinghouse”, as the same mail will be hit once per
recipient on each transaction, not once per receiving server.

Here comes one more reason against fake temporary rejection: postponing the 
delivery, can evaluate an email as spam for
subsequent recipients, that was not evaluated as spam in the past for other 
recipienst.  (because whether a mail is
evaluated as spam is also a function of the time)

At 07:21 AM 08-02-2019, John R Levine wrote:
How reliably does that work?  If I were writing an MTA I'd think a 
mix of 2xx and 5xx is likely but 2xx and 4xx is unexpected.

If the some RCPTs have enough space in the mailbox they communicate 2xx.  If 
other RCPTs have currently not enough space
for new mails it can answer with 4xx in the same SMTP transaction. 
(https://tools.ietf.org/html/rfc1870 Section 6.4 Per-
recipient rejection based on message size)


So the senders must be concerned with false positives, by hard rejecting 
the email, what I proposed.

Similarly, in my experience, human senders rarely look at bounce 
messages, and if they do, they rarely understand them or know how to 
react. So, rejecting a message (resulting in a bounce message) is at 
least as likely to end up with a message 'mysteriously' disappearing, as 
putting into a quarantine with a regular "quarantined message summary" 
being sent to the recipient.

Not exactly.  Going back to the original example with the cancelled meeting, it 
is not anymore “nobody’s fault”: the
senders can do something once they are notified that RCPTs (permanently) 
rejected a message.  When the message (false
positive) is put in quarantine, meetings are cancelled and it is “nobody’s 
fault”.

On Fri, 2019-02-08 at 13:01 -0500, John Levine wrote:
In article <D50AB431-9FFF-44EE-B0F7-A9F4F282E0D3(_at_)aegee(_dot_)org> you 
write:
Why would an mta-client change the message-id of an email having several 
recipients on each retry?

I've seen it happen, in systems that regenerate the message from a database.


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp