Re: [Emailcore] Retrying delivery on post-DATA permanent error status

["Luis E. Muñoz" <[e-mail]>]

On 26 Jul 2022, at 1:15, John C Klensin wrote:

> (Personal opinion, not as editor or anything else because I
> don't remember the original discussion any more).

And I believe I am being late to the party. But thanks!

> The key part of that text is the last part of the sentence:
> "without user review of the message and response and appropriate
> intervention".  Now the question for you is "are you sure those
> are all of the cases".  If, for example, for some messages, and
> automated review would be satisfactory, do you think whatever
> robotic process was involved would constitute "user review".  If
> the answer to either of those questions is "no", then SHOULD is
> appropriate and the question becomes whether there should be an
> explanation in the text about those other possible cases.

I understand and subscribe to your opinion above. Review and manual 
intervention could help turn an undeliverable message into a deliverable 
one. However, I believe such review should be mandatory prior to 
retrying. To this end, I believe a MUST NOT would better convey the 
importance of such review.

Regarding the number of use cases, I am particularly interested in the 
status quo for most ESPs. I believe the semantics of a 5xx status code 
show an inconsistency between what the spec says and what a substantial 
/ vocal group of operators expect it to do. This is my recollection of 
use cases.

* ESPs tend to interpret a 550 response as "I will not try to send this 
same message to this recipient. I however will still try future 
messages".
* Spamtrap operators following M3AAWG guidance expect that after a 
while, ESPs will remove spamtrap addresses from their lists.
* MTA operators applying an IP-based policy block would rather have the 
ESP stop sending email to the same email addresses over and over.

There are other many use cases that complement this list. I don't think 
all of them can be unambiguously handled by the current definition of 
status codes, mainly because response are tied to the specific message 
being processed in the SMTP session. I believe that an additional set of 
extended SMTP result codes (X.Y.Z) expressing policy decisions that 
transcend the current message might be helpful. e.g.: "Your IP address 
has been blocked", "User does not want to receive email from any of your 
mailing lists".

I am aware of the data that shows little adoption of those extended 
results codes—matches my data as well—but I'm optimistic that if 
these codes allowed for a more accurate filtering by the ESPs, market 
forces would drive adoption and improve on the status quo.

> (Now
> slipping my editor hat back on, for this case, I hope not.)

:-)

Best regards

-lem