Subject: [yam] Last Call: <draft-ietf-yam-rfc4409bis-02.txt> (Message Submission for Mail) to Full Standard

From: The IESG <[email-masked]>
Date: Thu, 11 Aug 2011 06:37:52 -0700

The IESG has received a request from the Yet Another Mail WG (yam) to
consider the following document:
- 'Message Submission for Mail'
  <draft-ietf-yam-rfc4409bis-02.txt> as a Full Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-08-25. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This memo splits message submission from message relay, allowing each
   service to operate according to its own rules (for security, policy,
   etc.), and specifies what actions are to be taken by a submission
   server.

   Message relay is unaffected, and continues to use SMTP [SMTP-MTA]
   over port 25.

   When conforming to this document, message submission uses the
   protocol specified here, normally over port 587.

   This separation of function offers a number of benefits, including
   the ability to apply specific security or policy requirements.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-yam-rfc4409bis/

Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-yam-rfc4409bis/

No IPR declarations have been submitted directly on this I-D.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 22 Aug 2011 16:45:14 -0700

Hi Alexey,

Thanks for the review.  I am following up on the YAM mailing list.

At 10:49 20-08-2011, Alexey Melnikov wrote:
>One pedantic nit:
>
>8.4.  Transfer Encode
>
>   The MSA MAY apply transfer encoding to the message according to MIME
>   conventions, if needed and not harmful to the MIME type.
>
>Shouldn't this be "media type"?

That text is in RFC 4409.  From what I gathered, the term "MIME type" 
was used previously and "media type" is used nowadays.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Aug 2011 14:26:20 -0700

Hi Mykyta,
At 09:21 17-08-2011, Mykyta Yevstifeyev wrote:
>IANA commented that it should be clear that "the registry" refers to 
>SMTP Service Extensions 
>(http://www.iana.org/assignments/mail-parameters); but the registry 
>there seems to have other format compared to Table 1:

I responded to the IANA comments.  I'll ask the editors to mention 
the name of the registry in the next revision of the draft.

>So how is this table going to be incorporated in the aforementioned registry?

The table is not going to be incorporated in the registry.  The 
information in the "name" field will be used as the description.

For what it is worth, this specification is an old one.  I don't have 
much information about its history to comment on why the registry was 
done in such a way.  IANA Considerations were not formal in those days.

Regards,
S. Moonesamy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Aug 2011 01:20:26 +0200

On 23 August 2011 23:26, S Moonesamy wrote:

> I responded to the IANA comments.  I'll ask the editors to mention the
> name of the registry in the next revision of the draft.

While at it please convince IANA that they can now s/2476/4409bis/ below
the table in the footnote:

| * Submit [RFC2476] only. Not for use with SMTP on port 25.

Somehow this 2476 survived 4409, maybe 4409bis eventually fixes it.  And
if not we can try a "manual registration request" to fix this later when
4409bis got its number.

-Frank

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Aug 2011 16:43:19 -0700

Hi Frank,
>| * Submit [RFC2476] only. Not for use with SMTP on port 25.

There was a note about that in the Document Shepherd write-up.

Regards,
S. Moonesamy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Aug 2011 02:14:48 +0200

> There was a note about that in the Document Shepherd write-up.

The later "IANA has questions" note does not exactly indicate
that they got this "2476" detail, let's see what happens... :-)

---

From: Chris Newman <[email-masked]>
Date: Wed, 24 Aug 2011 15:20:49 -0700

>   <draft-ietf-yam-rfc4409bis-02.txt> as a Full Standard

I have read this draft and support advancing it to Full Standard as written 
or with modifications suggested by others.

My comment on issues raised:

Russ Housley's discuss:

The document is more helpful to implementers if it has an informational 
downward reference to deployed signing technologies such as DKIM and 
multipart/signed (RFC 2480, RFC 1847) so that implementers know to consider 
the impact of message modification on those technologies. Normative 
language on that topic is best avoided so the document would be improved by 
removing the "SHOULD" related to those technologies.

I believe the alternative text that was proposed is fine, but I would also 
be fine with the current text and also with dropping the offending 
paragraph if necessary to advance the specification.

Informative reference to RFC 6186:

As much as I like 6186 and hope it deploys, there is not sufficient 
deployment today to justify a reference from a full standard.

Informative reference to RFC 5068 / BCP 134:

I think an informative reference would be helpful to readers, but if adding 
that reference would cause an approval delay then expedience is more 
important.

SMTP AUTH / STARTTLS:

I have seen SMTP AUTH and STARTTLS work well operationally between multiple 
independent implementations of submission. Problems with those technologies 
related to MTA relay are unrelated to this submission draft and thus need 
no additional text in this draft.

		- Chris

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Aug 2011 18:07:59 -0700

Hi Chris,

Thanks for taking the time to review the document.

At 15:20 24-08-2011, Chris Newman wrote:
>I think an informative reference would be helpful to readers, but if 
>adding that reference would cause an approval delay then expedience 
>is more important.

There was a comment about having such a reference ( 
http://www.ietf.org/mail-archive/web/yam/current/msg00744.html ).

>SMTP AUTH / STARTTLS:
>
>I have seen SMTP AUTH and STARTTLS work well operationally between 
>multiple independent implementations of submission. Problems with 
>those technologies related to MTA relay are unrelated to this 
>submission draft and thus need no additional text in this draft.

The input may be useful to the authors of the relevant specifications.

This is the last Last Call comment.  I'll consider all Last Call 
comments as having been addressed.

Regards,
S. Moonesamy