doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc6409.txt b/doc/rfc/rfc6409.txt
new file mode 100644
index 0000000..bb56a70
--- /dev/null
+++ b/doc/rfc/rfc6409.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Gellens
+Request for Comments: 6409                         QUALCOMM Incorporated
+STD: 72                                                       J. Klensin
+Obsoletes: 4409                                            November 2011
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                      Message Submission for Mail
+
+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 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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6409.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                    [Page 1]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                    [Page 2]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Document Information ............................................5
+      2.1. Definitions of Terms Used in This Memo .....................5
+      2.2. Conventions Used in This Document ..........................6
+   3. Message Submission ..............................................6
+      3.1. Submission Identification ..................................6
+      3.2. Message Rejection and Bouncing .............................6
+      3.3. Authorized Submission ......................................7
+   4. Mandatory Actions ...............................................8
+      4.1. General Submission Rejection Code ..........................8
+      4.2. Ensure All Domains Are Fully Qualified .....................8
+      4.3. Require Authentication .....................................8
+   5. Recommended Actions .............................................9
+      5.1. Enforce Address Syntax .....................................9
+      5.2. Log Errors .................................................9
+      5.3. Apply Shorter Timeouts .....................................9
+   6. Optional Actions ...............................................10
+      6.1. Enforce Submission Rights .................................10
+      6.2. Enforce Permissions .......................................10
+      6.3. Check Message Data ........................................10
+      6.4. Support for the Postmaster Address ........................10
+      6.5. Adjust Character Encodings ................................11
+   7. Interaction with SMTP Extensions ...............................12
+   8. Message Modifications ..........................................13
+      8.1. Add 'Sender' ..............................................14
+      8.2. Add 'Date' ................................................14
+      8.3. Add 'Message-ID' ..........................................14
+      8.4. Transfer Encode ...........................................14
+      8.5. Sign the Message ..........................................14
+      8.6. Encrypt the Message .......................................14
+      8.7. Resolve Aliases ...........................................15
+      8.8. Header Rewriting ..........................................15
+   9. Security Considerations ........................................15
+   10. IANA Considerations ...........................................16
+   11. Acknowledgments ...............................................16
+   12. References ....................................................17
+      12.1. Normative References .....................................17
+      12.2. Informative References ...................................17
+   Appendix A. Major Changes from RFC 4409 ...........................20
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                    [Page 3]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+1.  Introduction
+
+   SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that
+   is, a means to route (if needed) and deliver finished (complete)
+   messages.
+
+   Message Transfer Agents (MTAs) are not supposed to alter the message
+   text, except to add 'Received', 'Return-Path', and other header
+   fields as required by [SMTP-MTA].  However, SMTP is now also widely
+   used as a message *submission* protocol, that is, a means for Message
+   User Agents (MUAs) to introduce new messages into the MTA routing
+   network.  The process that accepts message submissions from MUAs is
+   termed a "Message Submission Agent" (MSA).
+
+   In order to permit unconstrained communications, SMTP is not often
+   authenticated during message relay.
+
+   Authentication and authorization of initial submissions have become
+   increasingly important, driven by changes in security requirements
+   and rising expectations that submission servers take responsibility
+   for the message traffic they originate.
+
+   For example, due to the prevalence of machines that have worms,
+   viruses, or other malicious software that generate large amounts of
+   spam, many sites now prohibit outbound traffic on the standard SMTP
+   port (port 25), funneling all mail submissions through submission
+   servers.
+
+   In addition to authentication and authorization issues, messages
+   being submitted are, in some cases, finished (complete) messages and,
+   in other cases, are unfinished (incomplete) in one or more aspects.
+   Unfinished messages may need to be completed to ensure they conform
+   to the Message Format specification [MESSAGE-FORMAT] and related
+   requirements.  For example, the message may lack a proper 'Date'
+   header field, and domains might not be fully qualified.  In some
+   cases, the MUA may be unable to generate finished messages (e.g., it
+   might not know its time zone).  Even when submitted messages are
+   complete, local site policy may dictate that the message text be
+   examined or modified in some way, e.g., to conceal local name or
+   address spaces.  Such completions or modifications have been shown to
+   cause harm when performed by downstream MTAs -- that is, MTAs after
+   the first-hop submission MTA -- and are, in general, considered to be
+   outside the province of standardized MTA functionality.
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                    [Page 4]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   Separating messages into submissions and transfers allows developers
+   and network administrators to do the following more easily:
+
+   o  Implement security policies and guard against unauthorized mail
+      relaying or injection of unsolicited bulk mail.
+
+   o  Implement authenticated submission, including off-site submission
+      by authorized users such as travelers.
+
+   o  Separate the relevant software code differences, thereby making
+      each code base more straightforward and allowing for different
+      programs for relay and submission.
+
+   o  Detect configuration problems with a site's mail clients.
+
+   o  Provide a basis for adding enhanced submission services.
+
+   This memo describes a low-cost, deterministic means for messages to
+   be identified as submissions, and it specifies what actions are to be
+   taken by a submission server.
+
+2.  Document Information
+
+2.1.  Definitions of Terms Used in This Memo
+
+   Many of the concepts and terms used in this document are defined in
+   [SMTP-MTA]; familiarity with those documents is assumed here.
+
+   Fully Qualified
+
+   Containing or consisting of a domain that can be globally resolved
+   using the Domain Name Service, that is, not a local alias or partial
+   specification.
+
+   Message Submission Agent (MSA)
+
+   A process that conforms to this specification.  An MSA acts as a
+   submission server to accept messages from MUAs, and it either
+   delivers them or acts as an SMTP client to relay them to an MTA.
+
+   Message Transfer Agent (MTA)
+
+   A process that conforms to [SMTP-MTA].  An MTA acts as an SMTP server
+   to accept messages from an MSA or another MTA, and it either delivers
+   them or acts as an SMTP client to relay them to another MTA.
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                    [Page 5]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   Message User Agent (MUA)
+
+   A process that acts (often on behalf of a user and with a user
+   interface) to compose and submit new messages, and to process
+   delivered messages.
+
+   For delivered messages, the receiving MUA may obtain and process the
+   message according to local conventions or, in what is commonly
+   referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP
+   [IMAP4] is used to access delivered messages, whereas the protocol
+   defined here (or SMTP) is used to submit messages.
+
+2.2.  Conventions Used in This Document
+
+   Examples use the 'example.net' domain.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in [KEYWORDS].
+
+3.  Message Submission
+
+3.1.  Submission Identification
+
+   Port 587 is reserved for email message submission as specified in
+   this document.  Messages received on this port are defined to be
+   submissions.  The protocol used is ESMTP [SMTP-MTA], with additional
+   restrictions or allowances as specified here.
+
+   Although most email clients and servers can be configured to use port
+   587 instead of 25, there are cases where this is not possible or
+   convenient.  A site MAY choose to use port 25 for message submission
+   by designating some hosts to be MSAs and others to be MTAs.
+
+3.2.  Message Rejection and Bouncing
+
+   MTAs and MSAs MAY implement message rejection rules that rely, in
+   part, on whether the message is a submission or a relay.
+
+   For example, some sites might configure their MTAs to reject all RCPT
+   commands for messages that do not reference local users, and they
+   might configure their MSA to reject all message submissions that do
+   not come from authorized users, with authorization based on either
+   the authenticated identity or the submitting endpoint being within a
+   protected IP environment.
+
+   NOTE: It is better to reject a message than to risk sending one that
+   is damaged.  This is especially true for problems that are
+   correctable by the MUA, for example, an invalid 'From' field.
+
+
+
+Gellens & Klensin            Standards Track                    [Page 6]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   If an MSA is not able to determine a return path to the submitting
+   user, from a valid MAIL FROM, a valid source IP address, or based on
+   authenticated identity, then the MSA SHOULD immediately reject the
+   message.  A message can be immediately rejected by returning a 550
+   code to the MAIL command.
+
+   Note that a null return path, that is, MAIL FROM:<>, is permitted and
+   MUST NOT, in itself, be cause for rejecting a message.  (MUAs need to
+   generate null return-path messages for a variety of reasons,
+   including disposition notifications.)
+
+   Except in the case where the MSA is unable to determine a valid
+   return path for the message being submitted, text in this
+   specification that instructs an MSA to issue a rejection code MAY be
+   complied with by accepting the message and subsequently generating a
+   bounce message.  (That is, if the MSA is going to reject a message
+   for any reason except being unable to determine a return path, it can
+   optionally do an immediate rejection or accept the message and then
+   mail a bounce.)
+
+   NOTE: In the normal case of message submission, immediately rejecting
+   the message is preferred, as it gives the user and MUA direct
+   feedback.  To properly handle delayed bounces, the client MUA needs
+   to maintain a queue of messages it has submitted and match bounces to
+   them.  Note that many contemporary MUAs do not have this capability.
+
+3.3.  Authorized Submission
+
+   Numerous methods have been used to ensure that only authorized users
+   are able to submit messages.  These methods include authenticated
+   SMTP, IP address restrictions, secure IP and other tunnels, and prior
+   POP authentication.
+
+   Authenticated SMTP [SMTP-AUTH] has seen widespread deployment.  It
+   allows the MSA to determine an authorization identity for the message
+   submission, one that is not tied to other protocols.
+
+   IP address restrictions are very widely implemented, but they do not
+   allow for travelers and similar situations, and they can be easily
+   spoofed unless all transport paths between the MUA and MSA are
+   trustworthy.
+
+   Secure IP [IPSEC], and other encrypted and authenticated tunneling
+   techniques, can also be used and provide additional benefits of
+   protection against eavesdropping and traffic analysis.
+
+   Requiring a POP [POP3] authentication (from the same IP address)
+   within some amount of time (e.g., 20 minutes) prior to the start of a
+
+
+
+Gellens & Klensin            Standards Track                    [Page 7]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   message submission session has also been used, but this does impose
+   restrictions on clients as well as servers, which may cause
+   difficulties.  Specifically, the client must do a POP authentication
+   before an SMTP submission session, and not all clients are capable
+   and configured for this.  Also, the MSA must coordinate with the POP
+   server, which may be difficult.  There is also a window during which
+   an unauthorized user can submit messages and appear to be a
+   previously authorized user.  Since it is dependent on the MUA's IP
+   addresses, this technique is substantially as subject to IP address
+   spoofing as validation based on known IP addresses alone (see above).
+
+4.  Mandatory Actions
+
+   An MSA MUST do all of the following:
+
+4.1.  General Submission Rejection Code
+
+   Unless covered by a more precise response code, response code 554 is
+   to be used to reject a MAIL, RCPT, or DATA command that contains
+   something improper.
+
+4.2.  Ensure All Domains Are Fully Qualified
+
+   The MSA MUST ensure that all domains in the SMTP envelope are fully
+   qualified.
+
+   If the MSA examines or alters the message text in any way, except to
+   add trace header fields [SMTP-MTA], it MUST ensure that all domains
+   in address header fields are fully qualified.
+
+   Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command
+   that contains improper domain references.
+
+   A frequent local convention is to accept single-level domains (e.g.,
+   'sales') and then to expand the reference by adding the remaining
+   portion of the domain name (e.g., to 'sales.example.net').  Local
+   conventions that permit single-level domains SHOULD reject, rather
+   than expand, incomplete multi-level domains (e.g., 'squeaky.sales'),
+   since such expansion is particularly risky.
+
+4.3.  Require Authentication
+
+   The MSA MUST, by default, issue an error response to the MAIL command
+   if the session has not been authenticated using [SMTP-AUTH], unless
+   it has already independently established authentication or
+   authorization (such as being within a protected subnetwork).
+
+   Section 3.3 discusses authentication mechanisms.
+
+
+
+Gellens & Klensin            Standards Track                    [Page 8]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   Reply code 530 [SMTP-AUTH] is used for this purpose.
+
+5.  Recommended Actions
+
+   The MSA SHOULD do all of the following.
+
+5.1.  Enforce Address Syntax
+
+   An MSA SHOULD reject messages with illegal syntax in a sender or
+   recipient SMTP envelope address.
+
+   If the MSA examines or alters the message text in any way, except to
+   add trace header fields, it SHOULD reject messages with illegal
+   address syntax in address header fields.
+
+   Reply code 501 is to be used to reject a MAIL or RCPT command that
+   contains a detectably improper address.
+
+   When addresses are resolved after submission of the message body,
+   reply code 554 (with a suitable enhanced status code from
+   [SMTP-CODES]) is used after end-of-data, if the message contains
+   invalid addresses in the header.
+
+5.2.  Log Errors
+
+   The MSA SHOULD log message errors, especially apparent
+   misconfigurations of client software.
+
+   It can be very helpful to notify the administrator when problems are
+   detected with local mail clients.  This is another advantage of
+   distinguishing submission from relay: system administrators might be
+   interested in local configuration problems, but not in client
+   problems at other sites.
+
+   Note that it is important to impose limits on such logging to prevent
+   certain forms of denial-of-service (DoS) attacks.
+
+5.3.  Apply Shorter Timeouts
+
+   The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are
+   designed to deal with the many types of situations that can be
+   encountered on the public Internet.  The relationship among clients
+   and servers corresponding to this specification is typically much
+   closer and more predictable.  Submission clients behave differently
+   from relay client in some areas, especially tolerance for timeouts.
+   In practice, message submission clients tend to have short timeouts
+   (perhaps 2-5 minutes for a reply to any command).  Submission servers
+   SHOULD respond to any command (even DATA) in fewer than 2 minutes.
+
+
+
+Gellens & Klensin            Standards Track                    [Page 9]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   When the submission server has a close administrative and/or network
+   relationship with the submission client(s) -- e.g., with a webmail
+   interface calling on a tightly bound submission server -- mutual
+   agreement on much shorter timeouts MAY be appropriate.
+
+6.  Optional Actions
+
+   The MSA MAY do any of the following.
+
+6.1.  Enforce Submission Rights
+
+   The MSA MAY issue an error response to a MAIL command if the address
+   in MAIL FROM appears to have insufficient submission rights or is not
+   authorized with the authentication used (if the session has been
+   authenticated).
+
+   Reply code 550 with an appropriate enhanced status code per
+   [SMTP-CODES], such as 5.7.1, is used for this purpose.
+
+6.2.  Enforce Permissions
+
+   The MSA MAY issue an error response to a RCPT command if inconsistent
+   with the permissions given to the user (if the session has been
+   authenticated).
+
+   Reply code 550 with an appropriate enhanced status code per
+   [SMTP-CODES], such as 5.7.1, is used for this purpose.
+
+6.3.  Check Message Data
+
+   The MSA MAY issue an error response to the DATA command or send a
+   failure result after end-of-data if the submitted message is
+   syntactically invalid, seems inconsistent with permissions given to
+   the user (if known), or violates site policy in some way.
+
+   Reply code 554 is used for syntactic problems in the data.  Reply
+   code 501 is used if the command itself is not syntactically valid.
+   Reply code 550 with an appropriate enhanced status code per
+   [SMTP-CODES] (such as 5.7.1) is used to reject based on the
+   submitting user.  Reply code 550 with an appropriate enhanced status
+   code (such as 5.7.0) is used if the message violates site policy.
+
+6.4.  Support for the Postmaster Address
+
+   If appropriate under local conditions and to facilitate conformance
+   with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit
+   a reduced degree of authentication for mail addressed to the
+   "postmaster" (or one of its alternate spelling forms, see
+
+
+
+Gellens & Klensin            Standards Track                   [Page 10]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   [SMTP-MTA]), in one or more domains, as compared to requirements
+   enforced for other addresses.  Among other benefits, this provides an
+   address of last resort that can be used by authorized users to report
+   problems that otherwise prevent them from submitting mail.
+
+6.5.  Adjust Character Encodings
+
+   Subject to limits imposed by other protocols and specifications, the
+   MSA MAY convert among character sets or string encodings to improve
+   message usefulness, likelihood of delivery, or conformance with other
+   specifications or recommendations.  Such conversions MAY include,
+   when necessary, replacement of addresses whose encoding does not
+   conform to RFC 5321 with ones that do, using information available
+   out of band.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 11]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+7.  Interaction with SMTP Extensions
+
+   The following table lists Standards Track and Experimental SMTP
+   extensions whose documents do not explicitly specify their
+   applicability to this protocol.  Listed are the EHLO keyword, name,
+   an indication as to the use of the extension on the submit port, and
+   a reference.
+
++--------------------+----------------------+--------+-----------------+
+| Keyword            | Name                 |Sub-    | Reference       |
+|                    |                      |mission |                 |
++--------------------+----------------------+--------+-----------------+
+|PIPELINING          |Pipelining            |SHOULD  |[PIPELINING]     |
+|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD  |[CODES-EXTENSION]|
+|ETRN                |Extended Turn         |MUST NOT|[ETRN]           |
+|   ...              |Extended Codes        |SHOULD  |[SMTP-CODES]     |
+|DSN                 |Delivery Status       |SHOULD  |[DSN]            |
+|                    |  Notification        |        |                 |
+|SIZE                |Message size          |MAY     |[SIZE]           |
+|   ...              |521 reply code        |MUST NOT|[REPLY-521]      |
+|CHECKPOINT          |Checkpoint/Restart    |MAY     |[CHECKPOINT]     |
+|BINARYMIME          |Binary MIME           |MAY     |[CHUNKING]       |
+|CHUNKING            |Chunking              |MAY     |[CHUNKING]       |
+|8BITMIME            |Use 8-bit data        |SHOULD  |[RFC6152]        |
+|AUTH                |Authentication        |MUST    |[SMTP-AUTH]      |
+|STARTTLS            |Start TLS             |MAY     |[START-TLS]      |
+|NO-SOLICITING       |Notification of       |MAY     |[RFC3865]        |
+|                    |  no soliciting       |        |                 |
+|MTRK                |Message Tracking      |MAY     |[MSG-TRACK]      |
+|ATRN                |On-Demand Relay       |MUST NOT|[RFC2645]        |
+|DELIVERBY           |Deliver By            |MAY     |[RFC2852]        |
+|CONPERM             |Content Conversion    |MAY     |[RFC4141]        |
+|                    |  Permission          |        |                 |
+|CONNEG              |Content Conversion    |MAY     |[RFC4141]        |
+|                    |  Negotiation         |        |                 |
++--------------------+----------------------+--------+-----------------+
+                             Table 1
+
+   Future SMTP extensions SHOULD explicitly specify if they are valid on
+   the Submission port.
+
+   Some SMTP extensions are especially useful for message submission:
+
+   Extended Status Codes [SMTP-CODES] SHOULD be supported and used
+   according to [CODES-EXTENSION].  This permits the MSA to notify the
+   client of specific configuration or other problems in more detail
+   than the response codes listed in this memo.  Because some rejections
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 12]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   are related to a site's security policy, care should be used not to
+   expose more detail to unauthenticated senders than is needed.
+
+   [PIPELINING] SHOULD be supported by the MSA.
+
+   [SMTP-AUTH] allows the MSA to validate the authority and determine
+   the identity of the submitting user and MUST be supported by the MSA.
+
+   [START-TLS] is the most widely used mechanism, at the time this
+   document was written, that allows the MUA and MSA to protect message
+   submission integrity and privacy.
+
+   Any references to the DATA command in this memo also refer to any
+   substitutes for DATA, such as the BDAT command used with [CHUNKING].
+
+8.  Message Modifications
+
+   Sites MAY modify submissions to ensure compliance with standards and
+   site policy.  This section describes a number of such modifications
+   that are often considered useful.
+
+   NOTE: As a matter of guidance for local decisions to implement
+   message modification, a paramount rule is to limit such actions to
+   remedies for specific problems that have clear solutions.  This is
+   especially true with address elements.  For example, indiscriminately
+   appending a domain to an address or element that lacks one typically
+   results in more broken addresses.  An unqualified address must be
+   verified to be a valid local part in the domain before the domain can
+   be safely added.
+
+   Any message forwarded or delivered by the MSA MUST conform to the
+   requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements
+   permitted by extensions that are supported by the MSA and accepted by
+   the next-hop server.
+
+   Message modification can affect the validity of an existing message
+   signature, such as by DomainKeys Identified Mail (DKIM) [DKIM],
+   Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME)
+   [RFC5751], and can render the signature invalid.  This, in turn, can
+   affect message handling by later receivers, such as filtering engines
+   that consider the presence or absence of a valid signature.
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 13]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+8.1.  Add 'Sender'
+
+   The MSA MAY add or replace the 'Sender' field, if the identity of the
+   sender is known and this is not given in the 'From' field.
+
+   The MSA MUST ensure that any address it places in a 'Sender' field
+   is, in fact, a valid mail address.
+
+8.2.  Add 'Date'
+
+   The MSA MAY add a 'Date' field to the submitted message, if it lacks
+   it, or correct the 'Date' field if it does not conform to
+   [MESSAGE-FORMAT] syntax.
+
+8.3.  Add 'Message-ID'
+
+   The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it,
+   or it is not valid syntax (as defined by [MESSAGE-FORMAT]).  Note
+   that a number of clients still do not generate 'Message-ID' fields.
+
+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.
+
+8.5.  Sign the Message
+
+   The MSA MAY (digitally) sign or otherwise add authentication
+   information to the message.
+
+8.6.  Encrypt the Message
+
+   The MSA MAY encrypt the message for transport to reflect
+   organizational policies.
+
+   NOTE: To be useful, the addition of a signature and/or encryption by
+   the MSA generally implies that the connection between the MUA and MSA
+   must, itself, be secured in some other way, for example, by operating
+   inside of a secure environment, by securing the submission connection
+   at the transport layer, or by using an [SMTP-AUTH] mechanism that
+   provides for session integrity.
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 14]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+8.7.  Resolve Aliases
+
+   The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME)
+   records) for domain names, in the SMTP envelope and/or in address
+   fields of the header, subject to local policy.
+
+   NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in
+   addresses and the session-opening announcement.  As with other SMTP
+   requirements, RFC 5321 effectively prohibits an MSA from forwarding
+   such messages into the public Internet.  Nonetheless, unconditionally
+   resolving aliases could be harmful.  For example, if www.example.net
+   and ftp.example.net are both aliases for mail.example.net, rewriting
+   them could lose useful information.
+
+8.8.  Header Rewriting
+
+   The MSA MAY rewrite local parts and/or domains in the SMTP envelope
+   and, optionally, in address fields of the header, according to local
+   policy.  For example, a site may prefer to rewrite 'JRU' as
+   'J.Random.User' in order to hide login names and/or to rewrite
+   'squeaky.sales.example.net' as 'zyx.example.net' to hide machine
+   names and make it easier to move users.
+
+   However, only addresses, local-parts, or domains that match specific
+   local MSA configuration settings should be altered.  It would be very
+   dangerous for the MSA to apply data-independent rewriting rules, such
+   as always deleting the first element of a domain name.  So, for
+   example, a rule that strips the leftmost element of the domain, if
+   the complete domain matches '*.foo.example.net', would be acceptable.
+
+   The MSA MUST NOT rewrite a forward-pointing (destination) address in
+   a way that violates the constraints of [SMTP-MTA] on modifications of
+   local-parts.  Changes to addressing and encoding, carried out in
+   conjunction with the action of Section 6.5, do not violate this
+   principle if the MSA has sufficient information available to
+   successfully and accurately apply the substitution.
+
+9.  Security Considerations
+
+   Separation of submission and relay of messages allows a site to
+   implement different policies for the two types of services, including
+   requiring the use of additional security mechanisms for one or both.
+   It can do this in a way that is simpler, both technically and
+   administratively.  This increases the likelihood that policies will
+   be applied correctly.
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 15]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   Separation also can aid in tracking and preventing unsolicited bulk
+   email.
+
+   For example, a site could configure its mail servers such that the
+   MSA requires authentication before accepting a message, and the MTA
+   rejects all RCPT commands for non-local users.  This can be an
+   important element in a site's total email security policy.
+
+   If a site fails to require any form of authorization for message
+   submissions (see Section 3.3 for discussion), it is allowing open use
+   of its resources and name; unsolicited bulk email can be injected
+   using its facilities.
+
+   Section 3 includes further discussion of issues with some
+   authentication methods.
+
+   Section 5.2 includes a cautionary note that unlimited logging can
+   enable certain forms of denial-of-service attacks.
+
+10.  IANA Considerations
+
+   The entries in Table 1 have been corrected (reference for NO-
+   SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG).  The
+   "SMTP Service Extensions" registry has been updated to reflect the
+   changed and new entries.  Entries in the registry that do not appear
+   in the table above are correct and should not be altered.
+
+   The entry in the "SMTP Service Extensions" registry for RFC 4409 has
+   been updated to reference this document.  The original reference for
+   Submit (RFC 2476), which should have been corrected earlier, has also
+   been updated to point to this document.
+
+   The entry in the "Service Name and Transport Protocol Port Number
+   Registry" for port 587 has been updated to point to this document.
+
+11.  Acknowledgments
+
+   The preparation and development of the current version of this
+   specification was stimulated by discussions in the IETF YAM and EAI
+   Working Groups.  Dave Crocker, Subramanian Moonesamy, Barry Leiba,
+   John Levine, and others provided text that appeared in this document
+   or versions leading up to it.
+
+   Nathaniel Borenstein and Barry Leiba were instrumental in the
+   development of RFC 4409, the update to RFC 2476.
+
+   The original memo (RFC 2476) was developed, in part, based on
+   comments and discussions that took place on and off the IETF-Submit
+
+
+
+Gellens & Klensin            Standards Track                   [Page 16]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   mailing list.  The help of those who took the time to review that
+   document and make suggestions is appreciated, especially that of Dave
+   Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
+
+   Special thanks to Harald Alvestrand, who got this effort started.
+
+12.  References
+
+12.1.  Normative References
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SMTP-AUTH]  Siemborski, R. and A. Melnikov, "SMTP Service Extension
+                for Authentication", RFC 4954, July 2007.
+
+   [SMTP-MTA]   Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+                October 2008.
+
+12.2.  Informative References
+
+   [CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for
+                Checkpoint/Restart", RFC 1845, September 1995.
+
+   [CHUNKING]   Vaudreuil, G., "SMTP Service Extensions for Transmission
+                of Large and Binary MIME Messages", RFC 3030,
+                December 2000.
+
+   [CODES-EXTENSION]
+                Freed, N., "SMTP Service Extension for Returning
+                Enhanced Error Codes", RFC 2034, October 1996.
+
+   [DKIM]       Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
+                Identified Mail (DKIM) Signatures", RFC 6376,
+                September 2011.
+
+   [DSN]        Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
+                Extension for Delivery Status Notifications (DSNs)",
+                RFC 3461, January 2003.
+
+   [ETRN]       De Winter, J., "SMTP Service Extension for Remote
+                Message Queue Starting", RFC 1985, August 1996.
+
+   [IMAP4]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+                4rev1", RFC 3501, March 2003.
+
+   [IPSEC]      Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+
+
+Gellens & Klensin            Standards Track                   [Page 17]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   [MESSAGE-FORMAT]
+                Resnick, P., Ed., "Internet Message Format", RFC 5322,
+                October 2008.
+
+   [MSG-TRACK]  Allman, E. and T. Hansen, "SMTP Service Extension for
+                Message Tracking", RFC 3885, September 2004.
+
+   [PIPELINING] Freed, N., "SMTP Service Extension for Command
+                Pipelining", STD 60, RFC 2920, September 2000.
+
+   [POP3]       Myers, J. and M. Rose, "Post Office Protocol - Version
+                3", STD 53, RFC 1939, May 1996.
+
+   [REPLY-521]  Durand, A. and F. Dupont, "SMTP 521 Reply Code",
+                RFC 1846, September 1995.
+
+   [RFC2645]    Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with
+                Dynamic IP Addresses", RFC 2645, August 1999.
+
+   [RFC2852]    Newman, D., "Deliver By SMTP Service Extension",
+                RFC 2852, June 2000.
+
+   [RFC3865]    Malamud, C., "A No Soliciting Simple Mail Transfer
+                Protocol (SMTP) Service Extension", RFC 3865,
+                September 2004.
+
+   [RFC4141]    Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
+                Content Conversion", RFC 4141, November 2005.
+
+   [RFC4880]    Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
+                R.  Thayer, "OpenPGP Message Format", RFC 4880,
+                November 2007.
+
+   [RFC5751]    Ramsdell, B. and S. Turner, "Secure/Multipurpose
+                Internet Mail Extensions (S/MIME) Version 3.2 Message
+                Specification", RFC 5751, January 2010.
+
+   [RFC6152]    Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
+                Service Extension for 8-bit MIME Transport", STD 71,
+                RFC 6152, March 2011.
+
+   [SIZE]       Klensin, J., Freed, N., and K. Moore, "SMTP Service
+                Extension for Message Size Declaration", STD 10,
+                RFC 1870, November 1995.
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 18]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+   [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
+                RFC 3463, January 2003.
+
+   [START-TLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP
+                over Transport Layer Security", RFC 3207, February 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 19]
+
+RFC 6409               Message Submission for Mail         November 2011
+
+
+Appendix A.  Major Changes from RFC 4409
+
+   The protocol specified by this document is not substantively
+   different from that of RFC 4409.  However, the present specification
+   contains several clarifications and updates to reflect changes and
+   revisions to other documents subsequent to the publication of RFC
+   4409.  The following specific changes may be of interest to some
+   readers.
+
+   o  Updated several references to reflect more recent versions of the
+      various specifications.  As part of this, reclassified RFC 4954 to
+      a normative reference (SMTP AUTH is a MUST for RFC 4409 and this
+      specification).
+
+   o  Updated the text in Section 7 to reflect the existence and partial
+      population of the registry and the included table (Table 1) to
+      correct one entry and add others.  See Section 10 for more
+      information.
+
+   o  Added new text (Section 5.3) to clarify that Submission Servers
+      should respond quickly.
+
+   o  Added text to make it explicit that character encoding changes are
+      permitted.
+
+   o  Added text to make it clear that modifications to signed messages
+      may cause problems and that they should be carefully considered.
+
+Authors' Addresses
+
+   Randall Gellens
+   QUALCOMM Incorporated
+   5775 Morehouse Drive
+   San Diego, CA  92121-2779
+   USA
+
+   EMail: rg+ietf@qualcomm.com
+
+
+   John C Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA  02140
+   USA
+
+   Phone: +1 617 491 5735
+   EMail: john-ietf@jck.com
+
+
+
+
+
+Gellens & Klensin            Standards Track                   [Page 20]
+