Re: [yam] Ambiguities in RFC 5321

[John C Klensin <john-ietf at jck.com>]

John,

FWIW, after reviewing my notes, my server config, and the spec
itself, I agree with Ned.  I now remember why we added the 554
language, and it was precisely to permit a server to say,
authoritatively, "no SMTP service here" rather than requiring
the client to wait for a timeout due to nothing listening on the
port.  The latter situation would introduce precisely the
ambiguity you are concerned about --and actually require
retries-- while 554 was expected to be an unambiguous "go away
-- no service" message, not a conditional one.

One can make pragmatic arguments for a different interpretation
based on the assumption that servers identified by different MX
records for the same domain are hopelessly misconfigured.  But
it seems to me that such arguments, even if/when they are
justified, have no place in the standard itself other than as an
extension of the existing language about operational necessities.

I also agree with Ned, and maybe you, that explicitly
documenting 550 for the set of "I don't like you, go away and
don't come back" -- and maybe, for clarity, adding a 4yz code or
comment about one for "I don't like you today, but, if you come
back tomorrow, I might change my mind-- would clarify both the
documentation and the situation.

Much more generally, the inherited ambiguity from long ago that
was clarified in 2821 notwithstanding, I think it is very
important that we try to reaffirm the principle that 5yz codes
imply that the server knows what it is doing and intends to
deliver a "no, and don't try that again because you will get the
same answer" message.  Any variation on "try again later" or
"try some other system" should get a 4yz code, not a 5yz one.

So much for the guy who wrote the spec... he claims jet lag or
at least temporary stupidity.

best,
    john


--On Saturday, November 21, 2009 10:01 -0800 Ned Freed
<ned.freed at mrochek.com> wrote:

>> In the recent draft, I don't see anything one way or the
>> other about dealing with ambiguities in the existing RFC.
>> While we certainly wouldn't want to change the protocol, it
>> looks to me like there are a few places where we could
>> clarify the language and, if need be, noting implementations
>> have interpreted the language other ways.
> 
>> In Section 3.1, a server can offer two greetings to a new
>> connection, 220 or 554.
> 
> That's not what the section says. Rather, it says that two
> possible responses are 220 or 554. Nowhere does it say these
> are the only possibilities.
> 
>> The semantics of the 554 are utterly unclear.
> 
> I disagree with this assertion. 554 is used "to formally
> reject a mail session while still allowing the initial
> connection". I think that's fairly clear, although I wouldn't
> object to adding the later description of 554 as "no SMTP
> service here" to this section.
>...