--On Tuesday, September 02, 2014 19:36 +0000 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> 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(_at_)ietf(_dot_)org, 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