On 17 Sep 2014, at 22:41, <ned+dmarc(_at_)mrochek(_dot_)com>
<ned+dmarc(_at_)mrochek(_dot_)com> wrote:
Hi,
On 09/16/14 05:08, Murray S. Kucherawy wrote:
URL: https://www.rfc-editor.org/rfc/rfc7372.txt
This document registers code points to allow status codes to be
returned to an email client to indicate that a message is being
rejected or deferred specifically because of email authentication
failures.
This document updates RFC 7208, since some of the code points
registered replace the ones recommended for use in that document.
I hope this is not off topic here:
(chair hat on)
It is. I've cc'ed and directed replies to the ietf-smtp list, where this
sort of discussion belongs.
(chair hat off)
RFC 7372 proposes to use a 550 response code for reverse DNS auth
failures, see section 3.3.
Correct.
Reverse DNS checks are usually done early in the connection (like IP
blocks) in the connection establishment stage of the SMTP dialog.
RFC 5321 allows only a 554 error response there, see section 4.3.2.
You're misreading RFC 5321. Nowhere does it say that its lists of possible
responses are exhaustive. So it is perfectly permissible for RFC 7372 to
specify additional possible responses as long as they fit into the overal
theory of reply codes.
It doesn’t say that (well-known) reply codes can be chosen arbitrarily in
whatever SMTP stage as long as they fit some formal schema either.
The publication of an RFC specifying a new code or a new usage of an old code
is hardly arbitrary.
What theory of reply codes? THE theory of reply codes goes back to FTP
conventions and the 70s which were adapted to SMTP and HTTP and
other transfer protocols. 5yz is the well-known code for a permanent
negative
completion, and x5z, the category code, that meant “protocol defined” in FTP
includes “policy defined” in SMTP.
Exactly.
So suggesting code 550 with its semantics is perfectly okay for any SMTP
stage but CONNECT because RFC 5321 and its ancestors fortunately are pretty
clear when discussing reply codes and sequencing.
But that isn’t the point. The question is whether SMTP clients SHOULD also
expect a “policy code” in CONNECT and MAY act accordingly, and how this
is covered by said RFC. My concern aren’t MUAs who might wonder what
colour to select for some doesn’t-work-popup but border MTAs where
semantics and interoperability matters.
If the server returned a 550 error on CONNECT, the client has three options:
(1) Immediately bounce the message, which is what it should do.
(2) In violation of protocol and common sense, treat this as a temporary
error and retry until the message times out.
(3) Something else even more bogus.
So where's the problem? It seems the worst case scenario is that the client
retries unnecessarily and continues to fail to get through until the message
times out. And even this seems very unlikely.
Different from the reply message, the reply
code is not just informal because in the real world, semantics come with
system behaviour. We are fighting the battle of fending off bad reputations
while maintaining ours every day.
Well, if we're going to talk about the real world, do you have any evidence
of clients that misbehave when they receive a 550 response in a banner
as opposed to some other 5yz response? Indeed, do you have evidence of
any client that looks at anything other than the first digit in a banner
response?
I'll also note that if we had wanted to stick to previously specified usage, we
would have been stuck with 554 or 521, both of which carry the semantic of "no
SMTP service here", which to the extent that second and third digit choices
actually matter, seems far more likely to be problematic.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp