Re: Return codes, was Updated draft for "SMTP Response for Detected Spam"

On Thu, 31 Mar 2022, John C Klensin wrote:
> Personal opinion: Simplifying "exercises like this" is not
> necessarily a useful goal.  Please note the last two paragraphs
> of Section 2.2.1 of RFC 5321 (and its equivalents in its
> predecessors going back to RFC 1425). ...

Well, the alternative is to squat on return codes and take your chances. 
Be careful what you wish for.

How about a registry with an expert review rule that new codes need to be 
enabled by an extension or else standards track RFC.

> While it might work for, e.g., Comcast->Comcast messages and
> some others (see below), I don't see it working well with the
> model.  Suppose we have a sender at example.net who generates a
> message in an MUA, hands it off to a submission server, ...

Naah.  The people using this will be ESPs, people who send bulk mail for 
commercial clients.  I promise you they'd implement in in the 
aforementioned ten milliseconds.

Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly