Subject: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX

From: John C Klensin <[email-masked]>
Date: Mon, 02 Mar 2015 09:30:25 -0500

Hi.

There was a lot of activity around this in the middle of last
year, largely because of the nullMX draft
(draft-ietf-appsawg-nullmx).  According to the tracker, nullMX
has been sitting in the RFC Editor queue since mid-September, in
part because it contains a normative reference to
draft-klensin-smtp-521code.  I think the assumption was that a
quick Last Call was going to be done on the latter I-D, possibly
through appsawg, but nothing has ever happened.

According to the Secretariat's automatic system,
draft-klensin-smtp-521code-02.txt expires next week.

I'm happy to update and repost it if there is a plan to move it
forward.  Or I can let it expire, thereby either killing the
nullMX draft or requiring that it be reissued with a different
strategy and presumably a new Last Call.

Please advise.

    john

---------- Forwarded Message ----------
Date: Monday, March 02, 2015 04:42 -0800
From: IETF Secretariat <[email-masked]>
To: "John C. Klensin" <[email-masked]>
Subject: Expiration impending:
<draft-klensin-smtp-521code-02.txt>

The following draft will expire soon:

Name:     draft-klensin-smtp-521code
Title:    SMTP 521 and 556 Reply Codes
State:    I-D Exists
Expires:  2015-03-11 (in 1 week, 1 day)

---------- End Forwarded Message ----------

---

From: Ned Freed <[email-masked]>
Date: Mon, 02 Mar 2015 08:00:22 -0800 (PST)

I took a quick look at draft-klensin-smtp-521code-02 and I don't see
anything wrong with it. I suggest moving it forward through
whatever means are most expeditious.

My only two minor comments on the text as it stands are first,
that I believe the RFC editor has a thing about references to
other documents in the abstract, so that may be an issue with
how it's presently worded.

Second, I'm not quite comfortable with the phrase "the preferred message".
Perhaps "a possible messsage" or "an acceptable message"?

				Ned

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Mar 2015 11:17:32 -0500

--On Monday, March 02, 2015 08:00 -0800 Ned Freed
<[email-masked]> wrote:

> I took a quick look at draft-klensin-smtp-521code-02 and I
> don't see anything wrong with it. I suggest moving it forward
> through whatever means are most expeditious.
> 

The rule, as far as I recall, is about actual citations in the
abstract, but will sort that out as/when needed.

> Second, I'm not quite comfortable with the phrase "the
> preferred message". Perhaps "a possible messsage" or "an
> acceptable message"?

I agree with your point and (slightly) prefer the latter, so,
unless someone has a strong preference to the contrary, -03 will
say "an acceptable message".

Alexey, I agree with Ned about "most expeditious" -- I think
this has been discussed and isn't work a lot more time.  If you
or others see taking this up officially in APPSAWG as adding
value, I'm ok with that, but it might be equally or more
efficient to post a heads-up to ietf-smtp and then do a four
week IETF LC.    Completely up to you folks; I did the draft
because it seemed like a quick fix and now just want it out of
my queue.

   john

---

From: "John R Levine" <[email-masked]>
Date: 2 Mar 2015 11:53:55 -0500

> Alexey, I agree with Ned about "most expeditious" -- ...

I'm happy with whatever gets it through quickly.  It seems unlikely that 
anyone would be opposed to it.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 02 Mar 2015 16:56:12 +0000

Hi John,

> because it seemed like a quick fix and now just want it out of
I am fine either way, I think our esteemed ADs need to comment on what 
they prefer.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 02 Mar 2015 11:57:12 -0500

> because it seemed like a quick fix and now just want it out of

+1 to AD-sponsored 4-week IETF LC.

I re-read it and think it's ready for publication.

Minor nit: In section 4, I got lost and had to re-read the 1-sentence 
paragraph several times. I suggest rewriting it slightly:

    When an SMTP server returns a 556 response code after receiving a
    command, such as RCPT, containing a forward-pointing address because
    it has information, as discussed above, that mail is not accepted,
    the SMTP client is, consistent with the SMTP specification, expected
    to handle the response like any other permanent negative completion
    reply to the command.

to something along these lines:

    When an SMTP server returns a 556 response code after receiving a
    command (such as RCPT, which contains a forward-pointing address) because
    it has information (such as discussed above) that the mail will
    not be accepted, the SMTP client is expected
    to handle the response like any other permanent negative completion
    reply to the command. This is consistent with the SMTP specification.

     Tony

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 2 Mar 2015 18:06:07 +0100 (CET)

On Mon, 2 Mar 2015, Alexey Melnikov wrote:

> I am fine either way, I think our esteemed ADs need to comment on what they 
> prefer.

I also agree with Alexey!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: t.petch <[email-masked]>
Date: Mon, 2 Mar 2015 18:28:17 +0000

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Sent: Monday, March 02, 2015 4:17 PM
> abstract, but will sort that out as/when needed.

John

The latest style guide [RFC7322] says s4.3
" the Abstract must not contain citations"
and
"The 556 code was created for [[RFC nullMX]]. "
does look very like a citation.

Perhaps you need an RFC Editor note to the effect that this should be
replaced by the RFC nnnn allocated to the nullMX I-D.  Other RFC have,
at least before the latest style guide, contained RFC numbers.

Or, crib from the Introduction

"The 556 code was created for
   for use when an SMTP client encounters a
   domain that it can
  determine does not support receipt of email."

and leave the Introduction to say more.

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Mar 2015 13:58:54 -0500

--On Monday, March 02, 2015 18:28 +0000 "t.petch"
<[email-masked]> wrote:

>...
>> > My only two minor comments on the text as it stands are
>> > first, that I believe the RFC editor has a thing about
>> > references to other documents in the abstract, so that may
>> > be an issue with how it's presently worded.
>> 
>...

> " the Abstract must not contain citations"

Yes.  That is consistent with what I said above.

> does look very like a citation.

The doubled brackets should have been a hint that it is actually
something else.  The observation that references in this spec
are numbered, rather than symbolic, might be another hint.
The XML contained an Entity definition and reference (not a
citation) that produces that string and a note to the RFC Editor
telling them to change it to reflect the RFC number for that
spec.  

Before someone else points it out, I've had problems with the
RFCNNNN convention that have barely been caught during AUTH48
and prefer to not take that risk.

Since this confused both you and Ned, the Entity definition has
been changed to "RFC-nullMX" without the brackets.
 
> Perhaps you need an RFC Editor note to the effect that this
> should be replaced by the RFC nnnn allocated to the nullMX
> I-D.  Other RFC have, at least before the latest style guide,
> contained RFC numbers.

Putting RFC numbers in the abstract is just about the only way
to conform to the IESG's guidance that strings like "updates RFC
NNNN" appear there.

In the hope of not having to spend more time on this, I've added
an RFC Editor note where people can see it (i.e., not just in
the XML).

>   determine does not support receipt of email."

Unfortunately, that isn't how 556 is defined; it is fairly
specific to situations in which that determination is made
without opening a connection.  If a connection is actually
opened to the destination and then the client determines that
mail is not accepted, different options apply.

Last-minute editorial tuning of this type is dangerous because
the changes can accidentally have substantive side effects.

thanks for the careful reading,
    john

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 02 Mar 2015 21:56:40 +0100

John,

> strategy and presumably a new Last Call.

Two minor nits: first sentence of Abstract: code should be plural:

s/code/codes

and, section 3:

s/Server/server

In section 3:

> One additional case is
>     covered in the next section.

it is not clear for me:

a) to which this case is referring (code 554 or 521)
b) to which section this is referring.

General question:

Excuse me if this has been discussed before, it is not my intention to 
propose significant changes right before publication. What I would like 
to ask is: is there a specific reason that some paragraphs talk about 
'client' and 'server' where other paragraphs talk about 'system' and 
'host'? I know these terms have different meanings, but wouldn't it be 
more consistent to use one 'set' throughout the document as much as 
possible?

If (I repeat: if) there is no specific reason, I'd suggest to use the 
words 'client' and 'server'. Section 3, for example:

>     This specification adds the 521 reply code to the repertoire
>     specified in SMTP, reserving it for use at connection-opening time to
>     indicate that the host does not accept email under any circumstances.
>     It SHOULD be used for dummy SMTP servers whose sole purpose is to
>     notify systems that attempt to open mail connections that the host
>     never accepts mail.  It MAY be used in other situations where the
>     intent is for the host to indicate that it never accepts email.

would then become:

    This specification adds the 521 reply code to the repertoire
    specified in SMTP, reserving it for use at connection-opening time to
    indicate that the server does not accept email under any circumstances.
    It SHOULD be used for dummy SMTP servers whose sole purpose is to
    notify clients that attempt to open mail connections that the server
    never accepts mail.  It MAY be used in other situations where the
    intent is for the server to indicate that it never accepts email.

and the proposed 'acceptable' message for code 521 would become:

"Server does not accept mail"

/rolf