Preliminary Evaluation of RFC 4409 "Message Submission for Mail", for advancement from Draft Standard to Full Standard by the YAM Working Group
draft-ietf-yam-4409bis-submit-pre-evaluation-00

Abstract

This memo is a preliminary evaluation of RFC 4409 "Message Submission for Mail" for advancement from Draft to Full Standard. It has been prepared by the The Yet Another Mail Working Group.

THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE IESG.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 31, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Note to RFC Editor
2.  Preliminary Evaluation
    2.1.  Document
    2.2.  Time in Place
    2.3.  Implementation and Operational Experience
    2.4.  Proposed Changes
    2.5.  Non-Changes
    2.6.  Downward references
    2.7.  IESG Feedback
3.  IANA Considerations
4.  Security Considerations
§  Author's Address

1.  Introduction

A preliminary evaluation has been made of RFC 4409 "Message Submission for Mail" by the Yet Another Mail (YAM) Working Group for advancing it from Draft to Full Standard. The YAM WG requests feedback from the IESG on this decision.

1.1.  Note to RFC Editor

This Internet-Draft is not meant to be published as an RFC. It is written to facilitate processing within the IESG.

2.  Preliminary Evaluation

2.1.  Document

Title:

Message Submission for Mail

Link:

http://tools.ietf.org/html/rfc4409

2.2.  Time in Place

RFC2026:

"A specification shall remain at the Draft Standard level for at least four (4) months, or until at least one IETF meeting has occurred."

Published:

April 2006

2.3.  Implementation and Operational Experience

RFC2026:

"significant implementation and successful operational experience ... characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community."

Confidence level:

Very high.

Message Submission on port 587 has seen significant deployment over the past 8-10 years, becoming widespread in the past 2-3 years. There are several reasons for this, such as decisions by many ISPs and organizations in general to block outbound port 25 (except by their own border MTAs), and consequently to support 587 with authentication, as well as recognition of the need to apply different policies to submission and relay.

2.4.  Proposed Changes

The YAM WG proposes making the following changes in a revision:

Client behavioral differences:

Submission clients behave differently from relay client in some areas, especially tolerance for time-outs. In practice, message submission clients tend to have short time-outs (perhaps 2-5 minutes for a reply to any command) while relay clients are required to have per-command timeouts of as much as 10 minutes). The document should describe this, and perhaps say that submission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes.

Technical errata: NO-SOLICITING

Per http://www.rfc-editor.org/errata_search.php?rfc=4409, the reference for [NO-SOLICITING] is incorrect and needs to be fixed to be RFC 3865.

Technical errata: Additional SMTP extensions

Per request reported at http://www.rfc-editor.org/errata_search.php?rfc=4409, the following RFC extensions which do not themselves specify their validity for Submission should be added to the table in Section 7:

RFC 2645 -- ATRN -- MUST NOT

RFC 2852 -- DELIVERBY -- MAY

RFC 4141 -- CONPERM, CONNEG -- MAY

Note that other subsequently-published extensions, such as UTF8SMTP and BURL, do specify their validity and hence don't need to be included.

Technical errata: References

Per request reported at http://www.rfc-editor.org/errata_search.php?rfc=4409, the [ESMTP] and [SMTP-MTA] references should be updated. Accordingly, [ESMTP]'s STD 10 should refer to RFC 5321-bis instead of both RFC 1869 and RFC 821.

The reference to RFC 974 should be deleted as the relevant material is included in 5321.

Likewise, the reference to STD 3, RFC 1123 should also be deleted from both [SMTP-MTA] and [MESSAGE-FORMAT] as its relevant material is also in RFC 5321.

Updated references:

SMTP AUTH should be RFC 4954 instead of 2554. This is a downref. Note that the current RFC 4409 lists 2554 as an Informative, not Normative reference, even though AUTH is a MUST.

Likewise, IPSec should be RFC 4301.

2.5.  Non-Changes

The YAM WG discussed and chose not to make the following changes:

1. [[[ No non-changes have been proposed (nor discussed) ]]]

2.6.  Downward references

At Full Standard, the following references would be downward references:

SMTP AUTH (RFC 4954)

2.7.  IESG Feedback

The YAM WG requests feedback from the IESG on this decision. In particular:

• Does the IESG believe the proposed changes are suitable during a move from Draft to Full Standard?
• Excluding the previous proposed changes and expected IESG support for technically substantive IETF last call feedback, does the IESG believe any additional changes are critical to advance this document from draft to full standard? If so, please provide sufficient information so the WG can address these issues prior to IETF last call or determine that the document is inappropriate for the YAM WG to process at this time.
• Does the IESG consider the downward references acceptable for a full standard? If not, please cite which specific downward reference or references are problematic and why so the WG can address these issues prior to IETF last call or determine the document is inappropriate for the YAM WG to process at this time.

3.  IANA Considerations

This document contains no IANA actions.

4.  Security Considerations

This document requests IESG feedback and does not raise any security concerns. Security considerations for RFC 4409 have been taken into account during the preliminary evaluation and appear in either Section 2.4 or Section 2.5 of this document.

Author's Address