Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

From: Dave Crocker <[email-masked]>
Date: Sat, 02 Aug 2014 06:44:46 -0700

On 7/18/2014 9:03 AM, John Levine wrote:
>>> I don't recall reading this in the document. It's a good point. IM personal
>>> O it's more important than either 4.1, 4.2 and 4.3. Add it, please.
>>
>> I agree with Arnt here. Not having a code for this is an obvious omission,
>> and this is chance to address it.
> 
> Please send text, or at least a three part number.

Shepherd hat:

   I haven't seen any follow-up to John's request, although support for
adding an extended code looks pretty solid.

   It really would help for someone who is strongly in favor of adding
the code to write up the necessary text, to be added to the draft.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Sun, 03 Aug 2014 12:49:32 -0400

> the code to write up the necessary text, to be added to the draft.

Currently, SMTP (RFC5321) current recommends 550 or 553.  Reasons 
explained below, but 554 may be the better match based on documented 
specs.  First some background ........

There has always been a long time resistance (for good reason) towards 
SMTP-based CBV "Call Back Verifiers" methods where a small footprint 
SMTP client is used to verify the validity of the 5321.Mail From 
address a.k.a Return Path or reverse-path at the SMTP transaction level.

The NULL MX can be used as short circuiting method to minimize the CBV 
overhead where it is used. Currently, the CBV is one the highest 
payoff for fraud detection and can be found to be used abeit at the 
smaller scale despite the obvious IETF concerns about it.

Our CBV currently uses a straight forward 550 rejection when the 
return path can not be validated.   Based on 11 years of CBV usage, 
IMO, what would be more important to convey is *WHEN* the NULL MX can 
be performed; at the MAIL FROM state or the RCPT TO state.

Each receiver site has a different rate of 55x user rejections at the 
RCPT TO level.

For our site, since 2003, it can be a consistently high 50-60%.  This 
translates to the 50-60% reduction in DNS MX lookup overhead when any 
DNS-based check can be delayed from MAIL FROM to RCPT TO, and that 
includes the SPF check where this optimization need was first discovered.

However, this idea of delaying the return path check until the 
forwarding address is known was discussed in RFC5321 section 3.3:

    3.3.  Mail Transactions

                                                    Despite the apparent
    scope of this requirement, there are circumstances in which the
    acceptability of the reverse-path may not be determined until one or
    more forward-paths (in RCPT commands) can be examined.  In those
    cases, the server MAY reasonably accept the reverse-path (with a 250
    reply) and then report problems after the forward-paths are received
    and examined.  Normally, failures produce 550 or 553 replies.

In short, this is the closest thing we have to an IETF "sanctioned" 
logistic for checking reverse-path with a recommended response code.

However, according to SMTP, probably 554 is a closer match for a NULL 
MX reason:

SMTP (RFC5321) has the following example definitions for the three codes:

    550  Requested action not taken: mailbox unavailable (e.g., mailbox
         not found, no access, or command rejected for policy reasons)

    553  Requested action not taken: mailbox name not allowed (e.g.,
         mailbox syntax incorrect)

    554  Transaction failed (Or, in the case of a connection-opening
         response, "No SMTP service here")

So probably 554 would be the proper code for a a "No SMTP Service 
Here" NULL MX check operation.

-- 
HLS

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 3 Aug 2014 20:07:15 +0200

I've changed my mind, btw. I haven't changed my mind in principle, but 
since I've said more than once that we obsess too much over minor matters 
of wording, I should restrain myself in such matters. Sorry. I think the 
text as it stands is good enough, and being good enough is what matters.

That said, I'll suggest wording for response codes:

      Code:               X.1.10
      Sample Text:        Recipient address has null MX
      Associated basic status code:  501
      Description:        This status code is returned when the associated
                          address is marked as invalid using a null MX.
      Reference:          [this document]
      Submitter:          [author of this document]
      Change controller:  IESG

      Code:               X.7.26
      Sample Text:        Sender address has null MX
      Associated basic status code:  550
      Description:        This status code is returned when the associated
                          sender address has a null MX, and the SMTP 
receiver
                          is configured to reject mail from such sender 
(e.g.
                          because it could not return a DSN).
      Reference:          [this document]
      Submitter:          [author of this document]
      Change controller:  IESG

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 03 Aug 2014 14:48:29 -0700 (PDT)

>       Code:               X.1.10

I have a mild reference for a X.4.Y code, but it's so mild I'm not going
to bother making a case for it.

>       Associated basic status code:  501

This, OTOH, does need to change. RFC 1846 specifically defined the 521 code for
the "host does not accept mail" case. I see no reason not to use it here.

>                           sender address has a null MX, and the SMTP receiver
>                           is configured to reject mail from such sender (e.g.

This one is hard to classify from a code perspective, but 7 looks as good
as any other choice.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 4 Aug 2014 08:53:36 +0200

> the "host does not accept mail" case. I see no reason not to use it here.

501 was actually a typo (I looked at what 5.1.2 does and misread the table 
I was looking at). I agree that 521 is better.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Aug 2014 05:20:42 -0400

Hi.
Ned's point about the use of code 521 has come up before and the
use of a special code for "does not accept mail" seems, to put
it mildly, obvious.  RFC 1846, published in 1995, has been
widely implemented and ceased being, in any sense, an experiment
15 or 18 years ago. 

Moving 1846 from Experimental to Standards Track seems to me to
be closer to orderly housekeeping than a significant change in
status.

I suggest that, with the exception of being classified as
Experimental today, RFC 1846 meets all of the criteria for a
full standard.  Noting that there are no outstanding errata, it
might even be worthwhile for the IESG to save itself and the
community time and energy by issuing a single Last Call, for
advancement to Proposed Standard now and for automatic
advancement to Internet Standard after the waiting period
expired if no substantive errata appeared in that interval.

In retrospect, I have no idea why we didn't just simply pick 521
up during DRUMS and incorporate it into RFC 2821.

    john

p.s. the use of the generic 550 code for this seems
inappropriate, especially if the whole idea of "null MX" seems
important enough to standardize.

--On Sunday, August 03, 2014 14:48 -0700 Ned Freed
<[email-masked]> wrote:

>>       Description:        This status code is returned when
>>       the associated address is marked as invalid using a
>>                           null MX. Reference:          [this
>>       document]
>>       Description:        This status code is returned when
>>       the associated sender address has a null MX, and the
>>                           SMTP receiver is configured to
>>                           reject mail from such sender (e.g.
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Aug 2014 06:26:46 -0700

> up during DRUMS and incorporate it into RFC 2821.

As I understand it, we can't just reclassify it in-place but would instead
need to publish a new version as a Proposed Standard and then promote it in
the usual way.  The main reason I think that is that this should officially
update RFC 5321.  Is that correct?

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Aug 2014 10:16:13 -0400

> expired if no substantive errata appeared in that interval.

This seems reasonable, and I can use this note to create a
status-change document to make the request.  A couple of points:

1. My reading of RFC 6410, Section 2.2, tells me that there is no
longer a waiting period.  Indeed, this document has waited long
enough, having effectively been PS for years.  I will consult with the
IESG about whether that view is generally held, and whether we can do
one four-week last call to go directly to IS (technically, to PS and
to IS as one dual action), or we think we need two back-to-back last
calls (I think that would be pointless, but some like to dot T's and
cross I's differently).

> update RFC 5321.  Is that correct?

2a. If it does "update" 5321, that's just metadata, and that can be
changed at the same time.  If there are no substantive updates to the
document, there's no reason to publish a revision.

2b. The reason it would "update" 5321, in the RFC-metadata meaning,
would be if it said that all new implementations of SMTP MUST do this.
If it's still an option, it doesn't update 5321.

All that said, we have to decide whether we want to change the
boilerplate, which currently says this:

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.

We might decide that it's weird to have an Internet Standard with that
boilerplate in it.

Barry

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Aug 2014 11:36:37 -0400

--On Monday, August 04, 2014 10:16 -0400 Barry Leiba
<[email-masked]> wrote:

>> full standard.  Noting that there are no outstanding errata,
>> it might even be worthwhile for the IESG to save itself and
>> the community time and energy by issuing a single Last Call,
>> for advancement to Proposed Standard now and for automatic
> 1. My reading of RFC 6410, Section 2.2, tells me that there is
> no longer a waiting period.  Indeed, this document has waited
> long enough, having effectively been PS for years.  I will
> consult with the IESG about whether that view is generally
> held, and whether we can do one four-week last call to go
> directly to IS (technically, to PS and to IS as one dual
> action), or we think we need two back-to-back last calls (I
> think that would be pointless, but some like to dot T's and
> cross I's differently).

When I read it last evening, I thought I saw a continuing
waiting period requirement.   I can no longer find it, and
certainly prefer your interpretation (and any other
interpretation that would avoid obviously pointless steps)
 
> Murray says:
>> As I understand it, we can't just reclassify it in-place but
>> would instead need to publish a new version as a Proposed
>> Standard and then promote it in the usual way.  The main
>> reason I think that is that this should officially update RFC
>> 5321.  Is that correct?
> 
> 2a. If it does "update" 5321, that's just metadata, and that
> can be changed at the same time.  If there are no substantive
> updates to the document, there's no reason to publish a
> revision.
> 
> 2b. The reason it would "update" 5321, in the RFC-metadata
> meaning, would be if it said that all new implementations of
> SMTP MUST do this. If it's still an option, it doesn't update
> 5321.

That is consistent with my interpretation.   More important, the
list of reply codes in 5321 (and 2821 and 821) has never been
considered exclusive.   That was, at least according to Postel
long ago, the reason for the long discussion about code theory
(now in RFC 5321 Section 4.2.1) is there.  The introduction to
Section 4.2 also says 

	"An SMTP server SHOULD send only the reply codes listed
	in this document." 

but also

	"The list of codes that appears below MUST NOT be
	construed as permanent.  While the addition of new codes
	should be a rare and significant activity, with
	supplemental information in the textual part of the
	response being preferred, new codes may be added as the
	result of new Standards or Standards-Track
	specifications."

Those are obviously not completely consistent and I made a note
a few years ago in the editing copy of 5321bis to clarify it.
But I think the intent is still clear -- 5321 need not be
replaced or updated to add a code.

In any event, if 521 has appropriate standardization status by
the time 5321bis appears, it is safe to assume that the code
will be listed and discussed there, presumably obsoleting this
document (another reason I hope to minimize time-wasting
rituals).

>    community.  This memo does not specify an Internet standard
> of any    kind.
> 
> We might decide that it's weird to have an Internet Standard
> with that boilerplate in it.

If that is the decision, I'll take the action to spin up a new
version unless the original authors are inclined to do so.  If
we go to the trouble to generate a new version to fix the
boilerplate, it should almost certainly explicitly update 5321
for hygienic reasons (in part because it would have a later date
then 5321).  I just don't think it is worth spinning up a new
draft (and raising additional questions about fast-tracking the
document into Internet Standard) for the purpose of noting the
addition to the 5321 code list.  Again, this all seems to me to
be a housekeeping activity, not a substantive one.

Please advise.

   john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Aug 2014 08:51:02 -0700

Changed Subject notwithstanding, this sub-thread to the nullmx Last Call
does not appear to contain any comments relevant to last call.

If I've missed a request for specific action, concerning the nullmx
draft, perhaps it could be repeated separately?

d/

---

From: Hector Santos <[email-masked]>
Date: Mon, 4 Aug 2014 12:29:31 -0400

For the record, if we use the concept of "no mail/SMTP service" for this protocol, then rfc5321 already has a 554 description:

Whether it's appropriate or not, this is what people will see and use as the closest "reply code" unless this new null mx spec is specific.  Let's keep in mind that extend reply codes is still OPTIONAL. 

--
Hector Santos
http://www.santronics.com

> On Aug 4, 2014, at 2:53 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> Ned Freed answers me:
> 501 was actually a typo (I looked at what 5.1.2 does and misread the table I was looking at). I agree that 521 is better.
> 
> Arnt
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Aug 2014 12:58:58 -0400

--On Monday, August 04, 2014 08:51 -0700 Dave Crocker
<[email-masked]> wrote:

> Changed Subject notwithstanding, this sub-thread to the nullmx
> Last Call does not appear to contain any comments relevant to
> last call.

The shift in focus is why I made the effort to change the
subject line.  The linkage is that the proposal to use 550 as
the response code for this case was, I assume (perhaps
incorrectly) because the nullmx spec authors did not consider
521 appropriate because of its nominal experimental status.
After reading Ned's note and those of others, I felt it was time
to clear up any further ambiguity by changing the status of RFC
1846.  If anyone involved in nullmx believes that use of 521
requires a normative reference from it to 1846, so be it, but I
have also already explained why I think that is unnecessary.

If there is some part of the above you consider inappropriate,
I'd appreciate an explanation as to why.

> If I've missed a request for specific action, concerning the
> nullmx draft, perhaps it could be repeated separately?

The specific actions, both discussed in Ned's note in the
original thread, were

	* To use the 521 code, not the 550 one.
	
	* An analysis about the subcode situation and a
	suggestion about the code to be used.

I agree with Ned's analysis and did not feel a need to elaborate
on it further.

     john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Aug 2014 10:12:21 -0700

>> Last Call does not appear to contain any comments relevant to
...
>> nullmx draft, perhaps it could be repeated separately?

Ned's suggestion came before the re-labeling of the Subject line.

My query was about the sub-thread with a new Subject line.

I have not seen an action for nullmx requested in that sub-thread, other
than a quick comment agreeing with Ned.  However the sub-thread is about
a separate document.

d/

---

From: "John Levine" <[email-masked]>
Date: 4 Aug 2014 17:24:44 -0000

>draft, perhaps it could be repeated separately?

The suggestion is to change section 4.1 so mail sent to a nullmx'ed
domain gets a 521 rather than 550 rejection (e.g. at submission time.)
That seems reasonable to me.

As I understand it, if Barry can change RFC 1846 to standards track,
I can refer to it without a downref issue.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Aug 2014 10:47:05 -0700

> I can refer to it without a downref issue.

This leads to a decision-three question:

     Is use of the code by the current draft worth making the /possible
and eventual/ change in status of RFC 1846 worth the indeterminate delay
for the current draft?  Is it that important?

d/

---

From: Ned Freed <[email-masked]>
Date: Mon, 04 Aug 2014 11:27:48 -0700 (PDT)

FWIW, I didn't even notice that RFC 1846 was experimental.

I agree with John's assessment that this has been PS or better for years.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Aug 2014 14:34:12 -0400

This seems directly relevant to the Last Call, so I have added
the appropriate string back to the Subject line and copied the
IESG.

--On Monday, August 04, 2014 10:47 -0700 Dave Crocker
<[email-masked]> wrote:

>> The suggestion is to change section 4.1 so mail sent to a
>> nullmx'ed domain gets a 521 rather than 550 rejection (e.g.
>> at submission time.) That seems reasonable to me.
>> 
>> As I understand it, if Barry can change RFC 1846 to standards
>> track, I can refer to it without a downref issue.
> 
> 
>      Is use of the code by the current draft worth making the
> /possible and eventual/ change in status of RFC 1846 worth the
> indeterminate delay for the current draft?  Is it that
> important?

For whatever my opinion is worth:  

(2) Yes, it is that important.   

(2a) I haven't heard anything said so far that points to
"interminable delay" if that comment was meant to reflect some
very long time of indefinite extent.

(2b) It is worth remembering that, if the nullMX draft is simply
documenting and ratifying an existing practice that has been
around for many years (repeatedly given as the main reason that
reviews of some of the associated technical and operational
issues and possible alternate strategies are not in order), then
another several weeks or months should make no difference.

(1) I don't see a necessary downref issue even if nothing is
done.  As discussed in an earlier note, the list of codes in
5321 has never been exhaustive.   Noting my earlier review of
that text (on the apps-discuss list) it would be, IMO,
completely consistent with even a very restrictive
interpretation of the language in 5321 for the present
("nullmx") draft to explicitly update 5321 by adding the code,
using it, and making an informative reference to 1846 for a more
general discussion of the code and the reasoning behind it.
Personally, I think moving 1846 onto the standards track is more
sanitary but, if there is really more urgency about approval of
"nullmx" than I've seen argued (see above) that giving 1846 a
new status can tolerate, than that would be an alternate
approach that accomplishes the same purpose and would not, in
principle, cost additional time.

    john

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Aug 2014 15:26:46 -0400

> for the current draft?  Is it that important?

The delay will be short; we don't have to wait for the status change.
If you add the downref, we just do a pro forma second last call on the
document, asking for comments on the downref.  We never get any.  It
delays the document's entry into the RFC Editor queue by no more than
two weeks.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Aug 2014 15:29:30 -0400

Ned says...
> I agree with John's assessment that this has been PS or better for years.

Excellent.  So, let me ask it this way:

Does anyone object to:

1. Moving RFC 1846 from Experimental to Proposed Standard?

2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)?

If you do, please say why.

If no one objects in the next couple of days, I'll create the
status-change document and start a four-week last call on it, which
will give plenty more time for any objections to surface, should there
be any.

Barry

---

From: Hector Santos <[email-masked]>
Date: Mon, 4 Aug 2014 16:31:21 -0400

I really don't appreciate, at all, this super fast tracking and rubber stamping without the appropriate industry wide (not just who happens to be here) input and interop reports. And how is this related to the null mx or no mail service? 

> On Aug 4, 2014, at 3:29 PM, Barry Leiba <[email-masked]> wrote:
> 
> Ned says...

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 04 Aug 2014 16:44:26 -0400

It's just about a year shy of it's 20th birthday.  Do you have a real concern 
about interoperability or are you just playing process police?

In any case, IETF standards are made by the people who show up, so people who 
happen to be here are who you get.

Scott K

On Monday, August 04, 2014 16:31:21 Hector Santos wrote:
> I really don't appreciate, at all, this super fast tracking and rubber
> stamping without the appropriate industry wide (not just who happens to be
> here) input and interop reports. And how is this related to the null mx or
> no mail service?
> 
> --
> Hector Santos

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 4 Aug 2014 23:01:00 +0200

On Monday, August 4, 2014 10:31:21 PM CEST, Hector Santos wrote:
> I really don't appreciate, at all, this super fast tracking and 
> rubber stamping without the appropriate industry wide (not just 
> who happens to be here) input and interop reports.

Make a suggestion, then. How should an RFC be treated it it's been 
experimental for a decade and a lot?

> And how is this related to the null mx or no mail service?

The nullmx document is to mention 521, which is defined by 1846.

Arnt

---

From: Hector Santos <[email-masked]>
Date: Mon, 4 Aug 2014 17:15:07 -0400

What r u talking about? Do u have a SMTP product in the market place? You don't? Well I do for a few decades now. U have no freaking clue what this mean and if you only deal with only whom "shows up" well, we have a serious problem.  

This "experiment" is unknown.  It's not in any SMTP RFC. 521 is not documented in SMTP.  It's not part of state machine response tables. It's all possible, but see the spec and understand what it means.   Rfc5321 is what's known. Not this other one and just have the 20 years in the archives doesn't mean it's place.  See if it is first.  You don't have any idea what can happen if 521 is issued out there. U need to get reports, at least ask the SMTP vendors out there and the four week rubber stamping is way too short.

> On Aug 4, 2014, at 4:44 PM, Scott Kitterman <[email-masked]> wrote:
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 4 Aug 2014 17:16:33 -0400

By rolling up your sleeves and researching if it's been implemented in a significant across the board way.  Just can't use time as the criteria.

> On Aug 4, 2014, at 5:01 PM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
>> I really don't appreciate, at all, this super fast tracking and rubber stamping without the appropriate industry wide (not just who happens to be here) input and interop reports.
> 
> Make a suggestion, then. How should an RFC be treated it it's been experimental for a decade and a lot?
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 4 Aug 2014 17:49:38 -0400

> The nullmx document is to mention 521, which is defined by 1846.

As mentioned a few times already, the closest empirical field practice to a null mx concept at the receiver level is most likely those systems that have implemented CBV operations.  They do a small footprint SMTP callback. They exist.  Don't underestimate it. 

As one of those implementer for 11 years, interoperating with others who also implemented it, 521 IS NOT was is used -- 55z is.    I'll be happy to explore it for fine tuning specific reply codes for our package,  but I can't tell you if will cause a client problem or if others will barf on it. 

We all know it should not, but we don't know, do we?  We do know 55x or any of the other listed state machine reply codes should be supported for SMTP compliance.  But we just don't know how generically it is handled in a state machine, i.e. 5yz for all permanent transaction failures. It could be fine in package X but we don't know how other packages will handle it.  It could be looking for just those codes listed in rfc5321.

Four weeks is too short and an appropriate experiment report should be completed.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 04 Aug 2014 18:17:19 -0400

I think that sort of argument from authority is out of place on an IETF list.

Will your product have a problem with this?  Give us a yes or no.

My MTA of choice (postfix) has implemented 521 replies since version 2.6 
(released in 2009).  I'm unaware of any issues associated with its use.  One 
of its primary developers is active on the IETF general list, so I'm sure if 
there's any concerns from that end, they'll be expressed during last call.

The IETF doesn't have a magic vendor list to consult.  People who have 
technical concerns should speak up.  I don't think wanting reports written 
qualifies as a technical concern.

Scott K

On Monday, August 04, 2014 17:15:07 Hector Santos wrote:
> What r u talking about? Do u have a SMTP product in the market place? You
> don't? Well I do for a few decades now. U have no freaking clue what this
> mean and if you only deal with only whom "shows up" well, we have a serious
> problem.
> 
> This "experiment" is unknown.  It's not in any SMTP RFC. 521 is not
> documented in SMTP.  It's not part of state machine response tables. It's
> all possible, but see the spec and understand what it means.   Rfc5321 is
> what's known. Not this other one and just have the 20 years in the archives
> doesn't mean it's place.  See if it is first.  You don't have any idea what
> can happen if 521 is issued out there. U need to get reports, at least ask
> the SMTP vendors out there and the four week rubber stamping is way too
> short.
> 
> --
> Hector Santos
> > It's just about a year shy of it's 20th birthday.  Do you have a real
> > concern about interoperability or are you just playing process police?
> > 
> > In any case, IETF standards are made by the people who show up, so people
> > who happen to be here are who you get.
> > 
> > Scott K
> >

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 5 Aug 2014 00:18:03 +0200

On Monday, August 4, 2014 11:15:07 PM CEST, Hector Santos wrote:
> This "experiment" is unknown.

I found five implementations in one minute of grepping, including Postfix, 
so not entirely unknown.

Arnt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Aug 2014 15:44:53 -0700

> mean and if you only deal with only whom "shows up" well, we have a serious

I don't accept the premise that one has to have a product released to have
a valid opinion here.  In any case, the tone of this reply is not
appropriate.  Please take it down a notch.

> the SMTP vendors out there and the four week rubber stamping is way too

Section 4.2 of RFC5321 describes how SMTP clients handle codes in general,
even if it's not one of the explicitly listed codes (see, especially,
Section 4.2.1).  If a client breaks upon seeing 521, it seems to me that
it's missed the guidance of that section.

So by my read, even if 521 has Experimental status, its use by SMTP servers
shouldn't break anything that's been built according to the advice of the
Draft Standard.

I believe that, at best, your question becomes "How many already-broken
clients out there will trip on this if adoption is increased?"  I think
that's a perfectly fine thing to discuss in a four-week Last Call.

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Mon, 04 Aug 2014 17:15:08 -0700 (PDT)

> there's any concerns from that end, they'll be expressed during last call.

FWIW, both Sun/Oracle MTA and PMDF before that have had code in place to handle
a 521 greeting (actually any 5yz code) since at least 1994, if not earlier. I
don't have earlier sources handy right now so I can't say when the support was
added. It's entirely possible it's been there since the SMTP support was first
coded.

The only change I note in the past 20 years was in the handling of MX
hosts returning 521. RFC 1846 clearly states that such hosts MUST NOT
return a 521, which leaves open how to handle this bogosity should it occur.
We used to bounce the message immediately on receipt of such a response,
irrespective of whether or not it was an MX, but around 2000 we changed the
code to try additional MXes should any exist.

I'm afraid I don't recall the circumstances that led to the change, but IMO the
RFC is  right to leave open how implementations should handle this condition.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Aug 2014 23:32:40 -0400

--On Monday, August 04, 2014 17:49 -0400 Hector Santos
<[email-masked]> wrote:

> As mentioned a few times already, the closest empirical field
> practice to a null mx concept at the receiver level is most
> likely those systems that have implemented CBV operations.
> They do a small footprint SMTP callback. They exist.  Don't
> underestimate it. 
> 
> As one of those implementer for 11 years, interoperating with
> others who also implemented it, 521 IS NOT was is used -- 55z
> is.    I'll be happy to explore it for fine tuning specific
> reply codes for our package,  but I can't tell you if will
> cause a client problem or if others will barf on it. 
> 
> We all know it should not, but we don't know, do we?  We do
> know 55x or any of the other listed state machine reply codes
> should be supported for SMTP compliance.  But we just don't
> know how generically it is handled in a state machine, i.e.
> 5yz for all permanent transaction failures. It could be fine
> in package X but we don't know how other packages will handle
> it.  It could be looking for just those codes listed in
> rfc5321.

Hector and others,

As Murray suggested, I think the tone of this needs to be taken
down a notch.  I hope this note can help.

First, the practice of setting up a fake SMTP server that
responds to any connection attempt with a 5yz code with the
intention of saying "go away and don't bother me (permanently)"
goes back to the 80s, long predating nullmx and several
long-dead conventions including the DNS WKS record that was
formally deprecated in RFC 1123 (and, I think, dead in practice
before that).   In an odd way, none of this has much to do with
nullmx -- if that convention is used by the DNS administrator
associated with a particular host and understood by clients, no
attempt will ever be made to make an SMTP connection so whether
there is a stub SMTP server on that host is pretty much
irrelevant.  So is what such a server might do if a connection
is opened to it by a client that doesn't follow the nullmx
convention (or if a client that does follow it doesn't get such
a record.   Maybe that is the point Dave Crocker was trying to
make but it seems to me that the nullmx spec opens itself to
some of this discussion by giving any advice at all about what a
server associated with such a record should do if contacted
anyway.

One thing I didn't remember until you pointed it out in one of
your earlier notes was that RFC 5321 (and 2821) contain explicit
text recommending 554 for (quoting 2821; 5321 uses slightly
different language) "formally reject[ing] a transaction while
still allowing the initial connection".   I don't remember
whether DRUMS discussed 521 and preferred 554 or whether it
really wasn't discussed.  But I'm fairly confident that one can
find implementations out there that use 554 and 521 (different
servers, of course).   I am quire certain that I've seen early
uses of 502, 503, and 550 and even was slightly involved with an
implementation that used 550 30-odd years ago.  There is clearly
some logic in the latter since RFC 821's description of it
includes "no access" in the 550 description (even though its
"Command-Reply Sequences" table lists only 220 and 421 for
connection establishment).

That history is long enough that I don't think your arguments
about needing more experimental trials holds up.   More
important, it has been very clear since at least RFC 1123 that
SMTP clients must be prepared to accept, and act plausibly on,
_any_ reply code that begins with the digits 2, 4, or 5 (and,
after DATA, 3).  That rule was made even more explicit in 2821.
An SMTP cli8ent implementation that gets into trouble with an
unknown code in the appropriate range is so far out of
compliance with SMTP as to not be appropriate to worry about.

With regard to 1846, I think there are only two realistic
choices (of course "don't deal with it for another decade" is a
possibility, but I can't really recommend it.  One is to face
the reality that it is practiced and maybe even that an explicit
code that exists for the sole purpose of saying "no SMTP traffic
accepted here", differentiating that from the 554 cases that
include "not accepting SMTP connections from an address in your
range" is desirable for the reasons 1846 outlines.  If one
believes that, it should be standardized and I/we will face a
slightly tricky wording problem when 5321bis is posted and
considered.  The other is to try to denounce the use of 521,
declare the 1846 experiment a failure, and deprecate that spec.
I don't think the latter is sensible; YMMD.

Finally, remember where this leaves us.  Assuming 521 is adopted
as a code reserved for a "no SMTP service or SMTP traffic
accepted here", a client that knows about it will be able to
report more precisely to the user (or originating MUA) what is
going on than one that gets a 554, which, in turn, conveys more
information than 550.  Any of those three convey more
information -- and are less misleading-- than using 500, 502,
503, or 504.  But, other than better problem reporting, the
client response to any of those codes is exactly the same.  That
is to treat the situation as a fatal error (given the first
digit of "5") and dispose of the message without issuing further
commands (other than QUIT or RSET) or putting it back in the
queue for later retries.

best,
   john

---

From: Pete Resnick <[email-masked]>
Date: Mon, 4 Aug 2014 23:09:50 -0500

> We might decide that it's weird to have an Internet Standard with that

I think you will find that, even if we don't think it weird, the RFC 
Editor will think it terribly weird. I believe they will require a new 
document with a new boilerplate; I seem to remember trying this before 
and them not wanting to advance the document in place.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Aug 2014 21:11:48 -0700

On 8/4/2014 8:32 PM, John C Klensin wrote:
>  So is what such a server might do if a connection

What text in the draft are you referring to?

d/

---

From: t.petch <[email-masked]>
Date: Tue, 5 Aug 2014 18:03:45 +0100

----- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: "Ned Freed" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, August 05, 2014 5:09 AM
> On 8/4/14 9:16 AM, Barry Leiba wrote:
<snip>
> and them not wanting to advance the document in place.

RFC1846 is a fine document for its time but the IETF has changed
what is expected of a Standard RFC somewhat since then and, reading
RFC1846, there is an awful lot more boilerplate that I think may have to
be changed (but I think that we should still do it).

For example, References, Copyright (for older material), Security, the
personal details of the editors, RFC2119 etc; and then there are calls
for IPR claims, contacting the editors, verifying that all the options
listed have interoperable implementations etc  It is a bit like trying
to
upgrade Windows 95 to Windows 7 - easier just to buy an iPhone:-)

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Aug 2014 13:27:39 -0400

Tom (and others),

Having reviewed the document and sensed the way the wind is
blowing, I've generated an XML-based version of the document
with updated references, boilerplate, and some general cleanup.
I've also written the authors or 1846, with a copy to Pete and
Barry, asking how they would like to proceed and will now wait a
reasonable amount of time to hear from them.

The revision-generating process took about a half-hour, far less
time that it would take to debate whether or not it was _really_
necessary on this list.  :-(

As a preview, the draft "Differences from RFC 1846" section now
reads, approximately, 

 o Updated boilerplate and editorial material for a standards
	track document.  As part of this, added new Section 1
	("Introduction") and Section 7 ("Context and other
	Approaches").
 o Removed "experimental" material
 o Updated references and improved ties to RFC 5321.
 o Mentioned the "nullMX" relationship.

Of course, if the 1846 authors take the document over, they may
discard some or all of that material.

    john

--On Tuesday, August 05, 2014 18:03 +0100 "t.petch"
<[email-masked]> wrote:

> Cc: "Ned Freed" <[email-masked]>;
> <[email-masked]>; <[email-masked]>
>> > All that said, we have to decide whether we want to change
>> > the boilerplate, which currently says this:
>> > 
>> >     This memo defines an Experimental Protocol for the
>> >     Internet community.  This memo does not specify an
>> >     Internet standard of
> any
>> >     kind.
>> > 
>> > We might decide that it's weird to have an Internet
>> > Standard with
> that
>> > boilerplate in it.
>> > 
>> 
>> I think you will find that, even if we don't think it weird,
>> the RFC Editor will think it terribly weird. I believe they
>> will require a new document with a new boilerplate; I seem to
>> remember trying this before and them not wanting to advance
>> the document in place.
> 
> RFC1846 is a fine document for its time but the IETF has
> changed what is expected of a Standard RFC somewhat since then
> and, reading RFC1846, there is an awful lot more boilerplate
> that I think may have to be changed (but I think that we
> should still do it).
> 
> For example, References, Copyright (for older material),
> Security, the personal details of the editors, RFC2119 etc;
> and then there are calls for IPR claims, contacting the
> editors, verifying that all the options listed have
> interoperable implementations etc  It is a bit like trying to

---

From: "John Levine" <[email-masked]>
Date: 5 Aug 2014 22:01:31 -0000

>what is expected of a Standard RFC somewhat since then ...

That's true, but we also have a lot of standards from 1995 and earlier
that we use every day.

Unless you think there's something in 1846 that is wrong and needs to
be changed, what interop problem would be be solving by recycling and
adding all the modern goop?  The copyright and other admin problems
are water under the bridge, it's published, nothing's going to change
about it.

R's,
John

PS: On the third hand, I have some sympathy for Klensin's concern that
doing the goop could be faster than deciding not to do it.

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Aug 2014 18:51:35 -0400

--On Tuesday, August 05, 2014 22:01 +0000 John Levine
<[email-masked]> wrote:

>> changed what is expected of a Standard RFC somewhat since
>> then ...
> 
> That's true, but we also have a lot of standards from 1995 and
> earlier that we use every day.
> 
> Unless you think there's something in 1846 that is wrong and
> needs to be changed, what interop problem would be be solving
> by recycling and adding all the modern goop?  The copyright
> and other admin problems are water under the bridge, it's
> published, nothing's going to change about it.

There is, in fairness, a little bit of text there about
experiments (e.g., telling the authors how things worked out) as
well as the traditional "...does not specify an Internet
standard of any kind" status statement.  Like (I assume) you and
Barry, I think that stuff can be blown off by a procedural
reclassification if anything can.  But...

> PS: On the third hand, I have some sympathy for Klensin's
> concern that doing the goop could be faster than deciding not
> to do it.

Based on recent history, I can easily imagine our spending days
and days debating just what conditions an Experimental spec
needs to meet to be moved onto the standards track without a new
document and then days more debating whether this one qualifies.
I can also imagine days or weeks of amateur lawyering about
apparently-contradictory statements, etc.   A 30 minute
investment in a draft that, with signoff from the original
authors, could be ready to go into a four week Last Call late
this week or early next seemed more efficient and less
frustrating and, of course, it would immediately satisfy those
who believe it is really necessary.   I'm not sure I like what
it says about the IETF if that extra ritual is the best answer,
but I think the pragmatic approach is to just do it and debate
the rest later.

The tone of the comment to which you responded just reinforces
that view.

    john

---

From: t.petch <[email-masked]>
Date: Wed, 6 Aug 2014 14:39:55 +0100

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 05, 2014 11:01 PM

John

I have been amazed in recent times at the hostility shown at IETF Last
Call to an I-D that has been extensively reviewed and well regarded in a
WG.  So putting RFC1846 out with its present wording as an exemplar of
an IETF full Standard in 2014 ..  mmm it might sneak out unnoticed by
any other Area or WG but I think it more likely we would generate a DoS
attack on Appsawg.  So, nothing to do with interop or anything
technical, just politics.

Simpler to take the technical content and recast it in modern form; I
reckoned it would take me half a day and thought I might do it on Friday
but no matter, the job has been done better, with a much better chance
of success, than I would have done it.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Wed, 6 Aug 2014 15:05:05 +0100

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: "Ned Freed" <[email-masked]>
Sent: Monday, August 04, 2014 8:29 PM

Barry

A reservation.  Internet Standard requires that all the described
features have been implemented and while '521' is clearly implemented in
plenty of places, are there two implementations of each and every
feature (which is what I have seen called out in other such proposals?)
I would parse RFC1846 into about five separate features, and it is not
clear to me that the implementations all do everything (well, they
don't, but I am uncertain which they do do:-(

Or is RFC6410
   (3) There are no unused features in the specification that greatly
       increase implementation complexity.
woolly enough for us to say that there is nothing of complexity
involved?

Tom Petch

---

From: Ned Freed <[email-masked]>
Date: Wed, 06 Aug 2014 11:31:53 -0700 (PDT)

> woolly enough for us to say that there is nothing of complexity

Rather than speculate, why not take a look at the RFC? It's only 4 pages,
not counting the boilerplate, less than 3.

There are two parts to this, the client part and the server part.

Server first. Writing a stub server that writes a line to a connection and then
closes the connection is not what we call rocket science. We shipped one of
these for years; I think it was around 20 lines of code. The alternate "read a
line, and if it's not QUIT send a line, if it is QUIT send a different line and
close the conenction" is only slightly more difficult.

I really hope there's consensus that the state of network programming is
sufficiently advanced that we don't have to check and evaluate stub server
implementations. If so, that's enough about that.

The rest of this deals with actual SMTP servers and clients.

The other server option is to have an MX that points to a regular SMTP server
that returns a 521, as oppose to some other error, when a sees an address using
a "does not accept mail" domain.

Of course every standards compliant SMTP server in existence is capable of
returning a 5YX error in response to an invalid address. RFC 5321 requires it,
among other things.

As for the client, all you have to do is handle 5YZ errors properly by bouncing
the message. The only even marginally "new" part of this is the possibility of
a 5YZ response to the server greeting, which isn't explicitly called out in RFC
5321 or its predecessors. But any implementor with half a brain will have
figured out this is a possibility even if they never saw this RFC. Indeed, in
most implementations this handling is going to fall out of the generic handler
for SMTP responses. It certainly did so in ours.

There is one optional bit of business the client can do, which is in the event
of misconfiguration where an MX points to a server that returns 521, it may
make more sense to try other MXes than fail the message immediately. Our
server does this, and again, this is trivial because the existing
logic for 4YZ greetings has to do the same thing.

Now, I suppose if you really want to be formal, and assuming you're dealing
with SMTP clients and servers that comply with RFC 5321, the checklist for this
document consists of exactly one item:

(1) Do you handle 5YZ greeting responses either by trying the next MX if
    there is one or by bouncing the message as undeliverable? 

And since we've already had at least two implementors say their implementations
support this, I think we're done.

				Ned