It appears that John C Klensin <john-ietf(_at_)jck(_dot_)com> 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:<sleazy(_at_)sleazy(_dot_)org> MAYBESPAM
250 2.1.0 Sender accepted.
rcpt to:<victim(_at_)somewhere(_dot_)wtf>
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp