[Top] [All Lists]

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

2019-02-08 11:51:14
Hello Paul,

dynamic message-id for the same messsage means broken 
double-delivery-suppression anyway, when the message is delivered to the same 
mailbox many times over different paths.  Perhaps specifying that the 
message-id must be kept upon retrying after 421/451 in the next SMTP RFC 
edition will help.

As I acknowledged, any approach has drawbacks and at the end one has to weight 
the drawbacks.  I do not offer a panacea and in my case for a mail with many 
recipients, most recipients share the mail-rejection-policy.  So the delays 
appear only for the few others.

In long term PRDR will help, in middle term interpreting a terminating 
"retry=00:00:00" in the RCPT TO: reply for reusing the TCP connection will be 
an improvement.

If senders cannot read mails generated after RCPT TO 421/451 about delays, they 
will likely not be able to read fully-formatted pleasant boince messsages.


On February 8, 2019 6:19:28 PM GMT+01:00, Paul Smith 
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
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
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
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
being delivered to some recipients and not others (because of
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,
putting into a quarantine with a regular "quarantined message summary" 
being sent to the recipient.

ietf-smtp mailing list

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