--On Tuesday, September 02, 2014 19:36 +0000 Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > On Tue, Sep 02, 2014 at 02:51:08PM -0400, John C Klensin wrote: > >> > Only when it's the SMTP greeting. In this case it's not. >> > That suggests that JCK's suggestion to have a new RFC to >> > replace 1846 is a good one, since it could mention this >> > other fairly obvious use case. >> >> See draft-klensin-smtp-521code. If additional text is needed >> there, please suggest some. > > At this point there are already fielded MTAs that reject some > clients with 521 followed by a connection drop at times other > than the greeting banner. While such behaviour need not be > officially blessed, it needs to be tolerated by clients. Victor, at least in my interpretation, the IETF (and earlier) view of email standards is that we should set a norm that, if followed, will yield good interoperability and reliable behavior. That means, among other things, that "several MTAs do this badly" has never been accepted as a sufficient reason to change the standard to match their behavior. The so-called robustness principle is closely associated with that approach although with interpretations that are inconsistent with a long history of its abuse. SMTP has been clear since RFC 821 and very clear since 2821 that sending a code (any code) and immediately dropping the connection is bad behavior. It has been equally clear that an SMTP-Sender can use the second and third digits of the reply code to provide additional information to the user (or equivalent) but that its actual actions are determined strictly by the first digit. The "operational necessity" language in RFC 5321 provides a loophole for special cases, but sending and undocumented 521, immediately closing the connection, and then expecting others to adapt nicely to that behavior is unreasonable... and certainly not a justification for changing the standard to match. > The most typical 521 response code scenario is when the > connecting client is listed by an RBL, but the server > administrator prefers to reject at "RCPT TO" so that the audit > trail includes sufficient envelope information. That is, as John Levine pointed out, a "rejected for policy reasons" response, with the policy reason being "you on a list and I've decided to reject your traffic as a result". RFC 5321 is, IMO, quite clear that policy reasons get 550 or 554 codes. If someone decided to send 521 instead, it is on their heads and, IMO, they deserve no special attention as a result. Because of the first digit rule, they probably won't cause any harm, but neither should it be treated as acceptable. Otherwise, why not just send "5" followed by two randomly-selected digits? > We probably don't need to continue this thread on > ietf@xxxxxxxx, perhaps we're done, but if not, please redirect > replies to a better list. I'm done. If you think further discussion is needed, try the SMTP list. john