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.
Regards
Дилян
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
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp