Subject: [yam] Ambiguities in RFC 5321

From: John Levine <[email-masked]>
Date: 13 Nov 2009 20:07:01 -0000

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.  The semantics of the 554 are utterly
unclear.  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.

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

554 MY NETAPP IS EMITTING SMOKE. SORRY.

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.

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

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Nov 2009 16:01:44 -0500

Get it on the YAM list (really soon -- before the prospectus
goes to the IESG).   I'm personally happy to spend the time to
clarify ambiguities, but don't know how others feel about it.

    john

--On Friday, 13 November, 2009 20:07 +0000 John Levine
<[email-masked]> 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.
> 
> 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.
> 
> b) This server is broken, try others as though you couldn't
> connect to this one.
> 
> c) This server is sort of broken, try others at the same MX
> priority but not lower.
> 
> I don't feel strongly about which is the right interpretation,
> but it would be nice to know how to code my mail clients.
> 
> R's,
> John
> 
> 
> 
> 
> _______________________________________________
> yam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yam

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Nov 2009 12:12:11 -0800

Hi John,
>would be nice to know how to code my mail clients.

I logged this as an issue.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Nov 2009 10:01:08 -0800 (PST)

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

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

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

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

> 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

---

From: "John R Levine" <[email-masked]>
Date: 21 Nov 2009 14:25:12 -0500

> are 220 or 554. Nowhere does it say these are the only possibilities.

Well, OK, if there are other possibilities, their meaning, and indeed 
their very existence, could also stand some clarification.

> (d) 554 No SMTP service here. Fail.

I think we can split hairs about whether it means "no SMTP service at all" 
vs. "no SMTP service for you", although it's easy enough to define so that 
it doesn't matter and the client does the same thing either way.

> mail. That's the entire point of having 554 as a possible connection repsonse.

That's a reasonable interpretation, but I would point out that it's 
sufficiently unclear that the guy who wrote the RFC has interpreted it 
differently.

Like I said, I don't much care which of the possibilities is the correct 
one, but we should document it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: John C Klensin <[email-masked]>
Date: Sat, 21 Nov 2009 15:56:30 -0500

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
<[email-masked]> 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.
> 
> 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.
> 
> 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
>...

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 21 Nov 2009 13:13:59 -0800

John R Levine wrote:
> vs. "no SMTP service for you", although it's easy enough to define so that it
> doesn't matter and the client does the same thing either way.

This leads down the slippery slope of needing to define a long list of 
differential reasons the service does not exist:

Doesn't exist for you
Doesn't exist outside of office hours
Doesn't exist on Tuesdays.
Doesn't exist on Holidays.
Doesn't exist for specific IP Address ranges.
Doesn't exist for hosts associated with .biz domains

etc.

And if the above list seems silly, consider that each one is likely to be of 
intersest -- and even utility -- for some serveroperator and/or some client 
operator.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 21 Nov 2009 16:10:49 -0500

> documentation and the situation.

I don't feel strongly about whether we need a separate 550 status, but I 
do think that if we agree that the correct response to a 554 is to fail 
and not try any alternative MX, it would be a good idea to say so.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 22 Nov 2009 13:41:46 -0500

> differential reasons the service does not exist:

Indeed, which is why I suggested we adjust the wording so it's clear what 
the client is supposed to do, regardless of the reason.  The leading 
candidates appear to be:

a) Total failure, bounce whatever you were planning to deliver

b) Host failure, forget this one but try other MXes

Note that in the original scenario of a host that is getting mail by 
mistake, due to A record fallback, these are equivalent.

Regards,

---

From: Tony Hansen <[email-masked]>
Date: Sun, 22 Nov 2009 22:17:57 -0500

I'd personally expect a 454 error for "Host failure, forget this one but 
try other MXes".

	Tony Hansen
	[email-masked]

John R Levine wrote:
>>> vs. "no SMTP service for you", although it's easy enough to define so 
>>> that it doesn't matter and the client does the same thing either way.
>>
> Indeed, which is why I suggested we adjust the wording so it's clear 
> what the client is supposed to do, regardless of the reason.  The 
> leading candidates appear to be:
>