[Top] [All Lists]

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

2019-02-08 11:25:27
On 08/02/2019 16:56, Dilyan Palauzov wrote:

Why would an mta-client change the message-id of an email having several 
recipients on each retry?

I don't know - but I've seen it. Basically, the client generates the Message-ID anew every time it tries to send it. It's not good, and arguably non-compliant, but it happens. With a 'faked-defer-but-delivery-anyway' scheme, the recipient could end up with very many duplicates in that case.

Also, what if the send times-out, and the sender human retries? Or what if there was a mistake and the sender human cancels the send and sends a corrected message to the people who received it, but not to those who "didn't" (but actually did)? So, don't do a 'fake-defer'.

Real defer is fine, but could end up with very long delays if the message is being retried for each recipient in a big list of recipients. If you don't know how long the sender will wait between retries, you could end up with messages with over 20 or so recipients just "randomly" being delivered to some recipients and not others (because of timeouts), for no obvious reason to the sender or recipients.

Probably the best thing would be for the receiving server to be able to instruct the sender to degenerate to an 'only one RCPT TO per message' condition. It'd be inefficient (but possibly less so that an arbitrary mix of defers/rejects/accepts), but at least it'd be reliable, determinate and simpler.

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.


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at

ietf-smtp mailing list

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