On Sun, Sep 21, 2014 at 7:34 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
If a client in its protocol engine suddenly starts
misbehaving then someone has to hire a better software engineer. Please,
let’s not discuss trivia. Mail systems are more than having a mail
bounced,
deferred, or seeing it delivered happily, since 20 years and more.
But that's what RFC 5321 is about - and your complaint was about the
failure to
use a code listed as an initial greeting response in RFC 5321. RFC 5321 is
a
protocol specification, and aside from defining a few codes for use in
expressing policy failures, it doesn't discuss mail system policy matters
at
all.
Now, you can argue that there should be such a document or documents - and
I'd
probably agree - but there aren't. But doesn't mean you can take RFC 5321
as providing guidance in this regard, because it doesn't.
I would say the overriding prose is in Section 4.3.2, where implementers
are advised to anticipate new codes being registered, or codes not in the
sequences listed later in that section, to appear. To me, that means the
appearance of 550 at CONNECT shouldn't cause anything to blow up even
though it's not explicitly listed. In fact, that prose actually does
explicitly say that only the first digit matters when an implementation
sees a code it didn't expect.
I also note that RFC5248, which created the IANA registry of enhanced
status codes, says the "Associated Reply Code" is the one "usually"
associated with the status code being registered. That does leave some
flexibility.
But as Ned points out, enhanced status codes don't have any meaning at
CONNECT, because their use at that point has not been negotiated, so this
is largely moot.
-MSK
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp