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

It appears that John C Klensin  <[email protected]> said:
>Let me add one thing to your suggestions.  While it does not
>appear in the headers, the last sentence of Section 1 of the
>current draft claims that this updates RFC 5321.  I suppose that
>is necessary because it adds a reply code that is not in the
>list that now appears in 5321, following the model of RFC 7504.

This reminds me, why don't we have an IANA registry for SMTP return
codes?  That would greatly simplify exercises like this.

I suggested to Alex that his draft needs to define an extension to let
client MTAs tell servers that they understand 259:

 ehlo cruddy.mail.org
 250-sceptical.server.com
 250-STARTTLS
 250-PIPELINING
 250-ENHANCEDSTATUSCODES
 250 MAYBESPAM

 mail from:<[email protected]> MAYBESPAM
 250 2.1.0 Sender accepted.

 rcpt to:<[email protected]>
 250 2.1.5 Recipient accepted.

 data
 354 Go ahead
 -- blah blah blah --
 .
 259 2.6.8 That smelled pretty bad.


In that case it doesn't update 5321, since it's not changing what SMTP
clients and servers do in the absence of that extension, but it would
be nice to have a registry so the codes don't accidentally overlap.

With respect to 259 vs 559, Comcast is a pretty big mail system. If
they think this could be useful, which they apparently do, I think it
would be a fine idea to try the experiment (which does not need an RFC
since we are still not the Network Police) and then later perhaps
advance the proposal with experience of what it does. Experiments
would be easier if it were possible to reserve the code points without
a lot of overhead.

R's,
John