Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 18:11:45 +0000

On Sun, Aug 03, 2014 at 11:17:30PM +0000, Viktor Dukhovni wrote:

> > Summary: Ready with nits. 
> 
> I finally read the complete draft, additional suggested changes
> (git diff for the .xml document):

Sadly, though it is very late in the process, I failed to notice
this originally, and must belatedly report a significant issue
noted by Wietse Venema.  The response code for rejecting a recipient
with a nullmx domain and a sender with a nullmx domain are reversed
in the draft.

Since 521 like 221 and 421 leads to connection drop after the reply,
it is only appropriate when the entire envelope will be rejected.
Thus 521 goes with rejection of a nullmx sender domain and 550
with a particular nullmx recipient.

	C: MAIL FROM:<[email-masked]>
	S: 521 5.7.26 Sender address has null MX
	... Server drops connection ...

	C: MAIL FROM:<[email-masked]>
	S: 250 2.0.0 Sender OK
	C: RCPT TO:<[email-masked]>
	S: 250 2.0.0 Recipient OK
	C: RCPT TO:<[email-masked]>
	S: 550 5.1.10 Recipient domain has null MX
	... Transaction continues, sans bad recipient ...

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 2 Sep 2014 14:30:57 -0400

> Since 521 like 221 and 421 leads to connection drop after the reply,

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.

> with a particular nullmx recipient.

No, 550 to reject the MAIL FROM is correct.  See RFC 5321, sec 3.3.  It's 
a policy rejection.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 18:45:38 +0000

On Tue, Sep 02, 2014 at 02:30:57PM -0400, John R Levine wrote:

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

Looking at 1846, it gives a server responding with 521 the choice
of either then dropping the connection or else a mandate to reject
all further commands with 521.  This is wrong, with multi-recipient
mail when only some of the recipients are in the problem domain.

The Postfix SMTP server, drops the connection when its response
code is 521.  So 521 is definitely problematic in the "RCPT TO:"
case.

> No, 550 to reject the MAIL FROM is correct.  See RFC 5321, sec 3.3.  It's a
> policy rejection.

I'm not religious on 521 for "MAIL FROM:".  550 is fine too.

This is a bug report about the "RCPT TO:" 521 code, I thought
perhaps they were switched accidentally.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Sep 2014 14:51:08 -0400

--On Tuesday, September 02, 2014 14:30 -0400 John R Levine
<[email-masked]> wrote:

>> Sadly, though it is very late in the process, I failed to
>> notice this originally, and must belatedly report a
>> significant issue noted by Wietse Venema.  The response code
>> for rejecting a recipient with a nullmx domain and a sender
>> with a nullmx domain are reversed in the draft.
>> 
> 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.

>> it is only appropriate when the entire envelope will be
>> rejected. Thus 521 goes with rejection of a nullmx sender
>> domain and 550 with a particular nullmx recipient.
> 
> No, 550 to reject the MAIL FROM is correct.  See RFC 5321, sec
> 3.3.  It's a policy rejection.

Yes, or 554, see Section 3 of draft-klensin-smtp-521code for
discussion (and, if I got that wrong, this would be a good time
to discuss it).

     john

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 19:36:04 +0000

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

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.

We probably don't need to continue this thread on [email-masked],
perhaps we're done, but if not, please redirect replies to a better
list.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Sep 2014 17:37:30 -0400

--On Tuesday, September 02, 2014 19:36 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>> > replace 1846 is a good one, since it could mention this
>> > other fairly obvious use case.
>> 
> 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
> [email-masked], 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

---

From: "John R Levine" <[email-masked]>
Date: 4 Sep 2014 12:37:50 -0400

> My concern is with sending 521 after RCPT TO.  Sorry for coming
> with this late in the process. I wasn't aware of the nullmx revival.

If you get 521 as a server greeting it means "I'm not a mail server."  If 
you get 521 as a response to RCPT TO it means "That's not a mail domain."

It's hard to imagine a situation where you'd want to retry either.  It is 
true that in the former case the whole session fails, while in the latter 
case the recipient address is invalid, but those don't seem hard to tell 
apart.

We're working on an 1846-bis that explains this more clearly.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Sep 2014 16:46:39 +0000

> you get 521 as a response to RCPT TO it means "That's not a mail domain."

This overloading is unfortunate.  It creates an implementation
challenge on the server side, because at least with Postfix, 421/521
responses can originate in milters, policy services, and access
tables.  In such cases the server interprets this as a "please drop
this client now" signal.

Since nullmx recipient policy might well be implemented in miters
and the like, Postfix has no way to distinguish between this new
proposed code (which seems to not be a "drop" signal) and all
previous uses which are.

Postfix also supports "soft_bounce", which downgrades all 5XX
replies to the corresponding 4XX replies.  However 421 after RCPT
TO does not carry a "That's not a mail domain, but try again later"
meaning.

The choice of 521 here seems rather unfortunate, and based on an
error the experimental RFC 1846.  Please consider 550 or similar.

-- 
	Viktor.

---

From: [email-masked]
Date: Thu, 04 Sep 2014 10:20:29 -0700 (PDT)

> tables.

As they can in our MTA. I fail to see the relevance.

>  In such cases the server interprets this as a "please drop
> this client now" signal.

Huh? Since when does the client send SMTP status codes to the server?

> proposed code (which seems to not be a "drop" signal) and all

If that's really true, then Postfix needs work independent of this issue. It
has always been the case that statuses returned in response to RCPT TO are
recipient-specific, and thus have very different semantics from statuses
returned by MAIL FROM, DATA, BDAT, BURL, the final dot, etc., which apply to
the message as a whole.

And these statuses are in turn distinct from session-level stuff like STARTTLS
and AUTH.

When you get right down to it, SMTP isn't all that simple.

> replies to the corresponding 4XX replies.

The structure of extended status codes guarantees that a 5.x.y shares semantics
with a 4.x.y. But this is not true for regular status codes, because the third
digits of those codes were assigned essentially on a  first-come-first serve
basis. So you have things like 500, 501, 502, 503, 504, and 553 that don't have
a corresponding 4yz code, 551 and 451 have very different  semantics, and the
proper downgrade code for 554 really needs to be 451.

Given this, I'd have to say that once again it's the implementation, not
the proposal, that needs work.

>  However 421 after RCPT

It doesn't carry that meaning anywhere. But again, just because someone
assumed, wrongly, that there's general equivalency between 5yz and 4yz and
added an option in support of that incorrect assumption, doesn't mean we should
cater to it.

> error the experimental RFC 1846.  Please consider 550 or similar.

That's part of the problem: None of the existing codes that can be returned in
response to RCPT TO are right for the job. 550 is a mailbox access error, 552
is a storage allocation error, 553 is an invalid mailbox error, and 555 is a
parameter problem. Out of all these 553 is probably the closest, but it is
still not quite right.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 4 Sep 2014 19:09:42 -0000

>parameter problem. Out of all these 553 is probably the closest, but it is

I share your opinion that anything that breaks is already broken, but
considering how widely used Postfix is, it might well be better
engineering to switch to a 553 code.  Topic already raised in
appsarea.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Thu, 4 Sep 2014 11:34:45 -0400 (EDT)

>From my point of view, it is desirable that 4XY and 5XY reply codes
have consistent semantics, i.e. they differ only in whether or not
the sender is supposed to retry a rejected request.

Until now the Postfix community has relied on this property as part
of a temporary safety net (to avoid missing email, replace 5XY with
4XY; after watching the logs for some time, remove the safety net).

Generally, if 4XY and 5XY reply codes have different semantics
besides do/don't retry, then I expect that will increase the
likelihood of mistakes by MTA operators.

Specifically, if 421 (and 221) terminate a session but 521 does
not, then that complicates life for implementors and MTA operators.

	Wietse

---

From: [email-masked] (Wietse Venema)
Date: Thu, 4 Sep 2014 13:45:27 -0400 (EDT)

John R Levine:
> If you get 521 as a server greeting it means ...

Thanks, there was no need to repeat that another time.  I infer
from your response that you are not concerned about consistency
between 4XY and 5XY SMTP responses, not even when until now all X21
SMTP responses end a session whereas the proposed 521 does not.
And with that, I will leave this discussion.

	Wietse

---

From: [email-masked]
Date: Thu, 04 Sep 2014 16:19:55 -0700 (PDT)

> engineering to switch to a 553 code.  Topic already raised in

That's a fair point. I dislike having to make such accomodations, but the
reality on the ground is what it is, and needs to be considered.

				Ned