Re: [yam] Ambiguities in RFC 5321

[Ned Freed <ned.freed at mrochek.com>]

> 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.

> Plausible interpretations include:

> a) This domain has rejected your mail, give up and report the message(s)
> as undeliverable, as though you got the 554 in response to DATA.

> 554 YOU ARE BLACKLISTED. FOAD.

This actually isn't what 554 is supposed to mean (see below). This sort of
argues for the addition of a "I think you smell, FOAD" response. 550 is the
most reasonable code to use for this IMO. Adding this as a possible response to
HELO/EHLO would also make sense.

> b) This server is broken, try others as though you couldn't connect to
> this one.

> 554 MY NETAPP IS EMITTING SMOKE. SORRY.

This isn't a reasonable interpretation - you're using a permanent error (per
the theory of reply codes) to report a temporary server problem. The proper
code to use here is 421, which section 4.3.2 says is allowed as a connection
response.

> c) This server is sort of broken, try others at the same MX priority
> but not lower.

> 554 MY SPOOL DISK IS CURRENTLY FULL. SORRY.

This is no different than (b), and once again the proper code is 421.

And you're misssing the correct meaning (d), which is what RFC 5321 actually
associates with the 554 code:

(d) 554 No SMTP service here. Fail.

> I don't feel strongly about which is the right interpretation, but it
> would be nice to know how to code my mail clients.

The case 554 is intended to deal with is that of a system that doesn't run an
email server but is nevertheless having email sent to it.

The usual reason this happens is someone constructs a bogus email address by
putting some random local part in front of a domain name that points to, say, a
router. THe router will of course either refuse the connection or blackhole it.
Either way the email waits in some queue somewhere until it times out. So 554
was invented as a means to say "no SMTP service here", which allows the email
to be bounced immediately.

It is of course a very narrow use-case, because such misdirected mail is 
rarely done in sufficient volume to warrant running a stub server that returns
such a status.

It follows, however, that the right thing for the client to do is bounce the
mail. That's the entire point of having 554 as a possible connection repsonse.

Now, I suppose you can argue that there's an even narower case, where an MX is
misconfigured to point at a system running such a stub server. But the chances
of this happening are so low that I think catering to it by trying a different
MX is a waste of time.

In summary, I would support a small clarification to section 3.1 to state
succiinctly that 554 means "no SMTP service here". I would also support
addition of 550 as a possible response to connections or EHLO/HELO. That said,
several of the  assertions you've made here do not stand up to inspection and
I would not support rewriting 3.1 as you appear to be suggesting.

				Ned