Message Submission for Mail
draft-ietf-yam-rfc4409bis-03

[Ballot discuss]
The specification says:

    If an incoming message includes a DKIM [DKIM], PGP [RFC4880],
    S/MIME [RFC5751], or other signature, sites SHOULD consider what
    effect message modifications will have on the validity of the
    signature, and MAY use the presence or absence of a signature as
    a criterion when deciding what, if any, modifications to make.

  This text is a warning that there are dragons here, but it does not
  tell the reader anything about the real consequences.  I believe
  that the text ought to be saying that portions of the incoming
  message that are covered by the signature SHOULD NOT be altered.
  The consequences of such alteration should probably be included in
  the security considerations.

[Ballot comment]
I have no objection to the publication of this document, but here are some piddle-nits you might look at in the interest of making the draft so highly polished that you can see your ^H^H^H face in it.

---

idnits says...
  -- The draft header indicates that this document obsoletes RFC4409, but the
    abstract doesn't seem to mention this, which it should.

---

I think you are not supposed to include citations in the Abstract.
On the other hand, it might be nice to include the reference to
[SMTP-MTA] in the first paragraph of Section 1.

---

Maybe the Abstract should mention what type of messages (i.e. mail) the
document handles?

---

Section 2.2 does not need to include
  In examples, "C:" is used to indicate lines sent by the client, and
  "S:" indicates those sent by the server.  Line breaks within a
  command example are for editorial purposes only.

---

Section 3

In the last paragraph of the section there are some lower-case "must".
Please be sure that you don't mean upper case.

Similarly section 8 paragraph 3

[Ballot comment]
WRT to anchor36: Do we expect the RFC editor to ask the IESG before or after the telechat?  I think you could delete it prior to publication.

Appendix B: You could strike 5322 from the list because it's an informative reference.

[Ballot discuss]


The IETF LC (https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=9680&tid=1314107697) did not call out the downrefs to RFC 4954 and 5321.  There is no doubt in my mind that no one will object to these downrefs, but they need to be explicitly called out in the IETF LC.

[Ballot discuss]
The specification says:

    If an incoming message includes a DKIM [DKIM], PGP [RFC4880],
    S/MIME [RFC5751], or other signature, sites SHOULD consider what
    effect message modifications will have on the validity of the
    signature, and MAY use the presence or absence of a signature as
    a criterion when deciding what, if any, modifications to make.

  This text is a warning that there are dragons here, but it does not
  tell the reader anything about the real consequences.  I believe
  that the text ought to be saying that portions of the incoming
  message that are covered by the signature SHOULD NOT be altered.
  The consequences of such alteration should probably be included in
  the security considerations.

[Ballot comment]
Given that start-tls is (as stated) the most common
way to secure the submission channel, perhaps the
mention of IPsec in 3.3 would be better replaced
with a reference to start-tls?

typo in IANA cnosiderations? "The table in Table 1..."
s/table/text/?

IANA has questions about the actions requested by this document.

ACTION 1:

IANA will replace the references to [RFC4409] with references to this
document for the following port number registrations:

submission 587 tcp Submission [RFC-to-be]
submission 587 udp Submission [RFC-to-be]

ACTION 2:

The IANA Considerations section says, "The table in Table 1 has been
corrected (reference for NO-SOLICITING) and extended (ATRN, DELIVERBY,
CONPEM, and CONNEG). The registry should be updated to reflect the
changed and new entries."

However, the reference for NO-SOLICITING is correct in the registry, and
ATRN and DELIVERBY have already been registered. It appears that the
only action required is to register the following SMTP Service
Extensions at
http://www.iana.org/assignments/mail-parameters :

Keywords Description Reference
------------------- ---------------------------------- -----------
CONPERM (?) [RFC4141]
CONNEG (?) [RFC4141]

QUESTIONS:

- Is the name of the registration CONPERM, as in the table, or
CONPEM, as in the IANA Considerations section?

- How should we fill in the "Description" field for these registrations?

- Should we add [RFC1846] as a reference for SIZE, as Table 1 appears to
require?

- Should we add [RFC3463] as a reference for ETRN, as Table 1 appears to
require?

Note: the IANA Considerations section should probably refer to the name
of the registry ("SMTP Service Extensions"). It would also be helpful if
the table included the RFC number for each registration.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Message Submission for Mail) to Full Standard


The IESG has received a request from the Yet Another Mail WG (yam) to
consider the following document:
- 'Message Submission for Mail'
  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
ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be
sent to iesg@ietf.org 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.

.a. The Document Shepherd for draft-ietf-yam-rfc4409bis-02 is S. Moonesamy.
I have personally reviewed this version of the document and I believe that
this version is reading for forwarding to the IESG for publication.

1.b. RFC 4409 was reviewed by participants of the YAM WG and a
pre-evaluation I-D
(draft-ietf-yam-4409bis-submit-pre-evaluation) was generated. This document
incorporates the changes that was identified during the
pre-evaluation of RFC 4409
and during reviews by participants of the YAM WG. I do not have any
concerns about
the depth or breadth of the reviews that have been performed.

1.c. I do not believe that the document needs more review from a particular or
broader perspective as the specification is well-known to many
participants in the
YAM WG and there is already significant implementation and successful
operational
experience.

1.d. I do not have any specific concerns or issues with this
document. I am not
aware of any IPR claims.

1.e. The WG as a whole understands and agrees to the publication of
the document.

1.f. There hasn't been any threat of appeal or any discontent about
the document.

1.g. draft-ietf-yam-rfc4409bis-02 is submitted for publication as
"Full Standard".

1.h. RFC 4956, RFC 5321 and RFC 5322 are downward references. The protocols
that they describe are widely-deployed, interoperable, stable, and successful,
so the references are justified based on RFC 4897.

1.i. There is an IANA considerations section and it is consistent
with the body of
the document. The entry in the SMTP Service Extensions registry for
RFC 4409 should
be updated to reference this document. The reference for Submit (RFC
2476) should be
updated to point to this document. The registry should be updated to
reflect the
changed and new entries in Section 7. The entry in the Service Name
and Transport
Protocol Port Number Registry for port 587 should be updated to point
to this document.

1.j. The document does not contain any ABNF rule.

1.k. Document Announcement draft

Technical Summary

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

Working Group Summary

The YAM WG adopted a two-step approach to move this document to Full Standard.
The first step was a pre-evaluation of the existing specification to identify
changes and non-changes. The second step was to incorporate the changes into
the document and ensure that any implementation that conforms to the Draft
Standard version of the specification remains compliant with this document.
There was no controversy. There is consensus to move the specification to
Full Standard.

Document Quality

The document has a high degree of technical maturity. In the five years since
publication of the Draft Standard and 13 years since publication as Proposed
Standard, the specification has become an integral part of all professional
SMTP software products and is widely supported in Internet Mail operations.
Chris Newman suggested adding Section 5.3 applying shorter timeouts.
John Klensin wrote the text in Section 6.5 which discusses about adjusting
character encodings.

Personnel

S. Moonesamy is the Document Shepherd for this document. Pete Resnick is the
Responsible Area Director.