doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc4409.txt b/doc/rfc/rfc4409.txt
new file mode 100644
index 0000000..ad5b00e
--- /dev/null
+++ b/doc/rfc/rfc4409.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                         R. Gellens
+Request for Comments: 4409                                      QUALCOMM
+Obsoletes: 2476                                               J. Klensin
+Category: Standards Track                                     April 2006
+
+
+                       Message Submission for Mail
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+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 and final delivery are unaffected, and continue 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 1]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Document Information ............................................4
+      2.1. Definitions of Terms Used in This Memo .....................4
+      2.2. Conventions Used in This Document ..........................5
+   3. Message Submission ..............................................5
+      3.1. Submission Identification ..................................5
+      3.2. Message Rejection and Bouncing .............................5
+      3.3. Authorized Submission ......................................6
+   4. Mandatory Actions ...............................................7
+      4.1. General Submission Rejection Code ..........................7
+      4.2. Ensure All Domains Are Fully-Qualified .....................7
+      4.3. Require Authentication .....................................8
+   5. Recommended Actions .............................................8
+      5.1. Enforce Address Syntax .....................................8
+      5.2. Log Errors .................................................8
+   6. Optional Actions ................................................9
+      6.1. Enforce Submission Rights ..................................9
+      6.2. Enforce Permissions ........................................9
+      6.3. Check Message Data .........................................9
+      6.4. Support for the Postmaster Address .........................9
+   7. Interaction with SMTP Extensions ...............................10
+   8. Message Modifications ..........................................11
+      8.1. Add 'Sender' ..............................................11
+      8.2. Add 'Date' ................................................11
+      8.3. Add 'Message-ID' ..........................................11
+      8.4. Transfer Encode ...........................................11
+      8.5. Sign the Message ..........................................11
+      8.6. Encrypt the Message .......................................12
+      8.7. Resolve Aliases ...........................................12
+      8.8. Header Rewriting ..........................................12
+   9. Security Considerations ........................................12
+   10. IANA Considerations ...........................................13
+   11. Acknowledgements ..............................................13
+   12. Normative References ..........................................14
+   13. Informative References ........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 2]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+1.  Introduction
+
+   SMTP 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 [MESSAGE-FORMAT], and later 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.
+
+   Separating messages into submissions and transfers allows developers
+   and network administrators to more easily do the following:
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 3]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+   *   Implement security policies and guard against unauthorized mail
+       relaying or injection of unsolicited bulk mail
+
+   *   Implement authenticated submission, including off-site submission
+       by authorized users such as travelers
+
+   *   Separate the relevant software code differences, thereby making
+       each code base more straightforward and allowing for different
+       programs for relay and submission
+
+   *   Detect configuration problems with a site's mail clients
+
+   *   Provide a basis for adding enhanced submission services in the
+       future
+
+   This memo describes a low-cost, deterministic means for messages to
+   be identified as submissions, and 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 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 either delivers
+   them or acts as an SMTP client to relay them to another MTA.
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 4]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+   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 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
+
+   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.
+
+   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, ESMTP], 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
+   configure their MSA to reject all message submissions that do not
+   come from authorized users, with authorization based either on
+   authenticated identity or the submitting endpoint being within a
+   protected IP environment.
+
+
+
+Gellens & Klensin           Standards Track                     [Page 5]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+   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.
+
+   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 do not allow
+   for travelers and similar situations, and can be easily spoofed
+   unless all transport paths between the MUA and MSA are trustworthy.
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 6]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+   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
+   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.
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 7]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+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.
+
+   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 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.
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 8]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+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, or 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
+   [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.
+
+
+
+
+Gellens & Klensin           Standards Track                     [Page 9]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+7.  Interaction with SMTP Extensions
+
+   The following table lists the current standards-track and
+   Experimental SMTP extensions.  Listed are the EHLO keyword, name, an
+   indication as to the use of the extension on the submit port, and a
+   reference:
+
+Keyword        Name                        Submission  Reference
+----------     --------------------------  ----------  ----------------
+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 Notification  SHOULD    [DSN]
+SIZE           Message size                  MAY       [SIZE]
+ ...           521 reply code                MUST NOT  [521REPLY]
+CHECKPOINT     Checkpoint/Restart            MAY       [CHECKPOINT]
+BINARYMIME     Binary MIME                   MAY       [CHUNKING]
+CHUNKING       Chunking                      MAY       [CHUNKING]
+8BITMIME       Use 8-bit data                SHOULD    [8BITMIME]
+AUTH           Authentication                MUST      [SMTP-AUTH]
+STARTTLS       Start TLS                     MAY       [Start-TLS]
+NO-SOLICITING  Notification of no soliciting MAY       [Msg-Track]
+MTRK           Message Tracking              MAY       [Msg-Track]
+
+   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
+   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.
+
+   Any references to the DATA command in this memo also refer to any
+   substitutes for DATA, such as the BDAT command used with [CHUNKING].
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 10]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+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].
+
+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.
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 11]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+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.
+
+8.7.  Resolve Aliases
+
+   The MSA MAY resolve aliases (CNAME records) for domain names, in the
+   SMTP envelope and optionally in address fields of the header, subject
+   to local policy.
+
+   NOTE:  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 which 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 left-most 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.
+
+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 use of additional security mechanisms for one or both.  It
+   can do this in a way which is simpler, both technically and
+
+
+
+Gellens & Klensin           Standards Track                    [Page 12]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+   administratively.  This increases the likelihood that policies will
+   be applied correctly.
+
+   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 registration for port 587 has been updated to refer to this memo
+   rather than RFC 2476.
+
+11.  Acknowledgements
+
+   Nathaniel Borenstein and Barry Leiba were instrumental in the
+   development of this update to RFC 2476.
+
+   The original memo (RFC 2476) was developed in part based on comments
+   and discussions which took place on and off the IETF-Submit 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 13]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+12.  Normative References
+
+   [ESMTP]           Klensin, J., Freed, N., Rose, M., Stefferud, E.,
+                     and D. Crocker, "SMTP Service Extensions", STD 10,
+                     RFC 1869, November 1995.
+
+   [KEYWORDS]        Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SMTP-MTA]        Postel, J., "Simple Mail Transfer Protocol", STD
+                     10, RFC 821, August 1982.
+
+                     Partridge, C., "Mail routing and the domain
+                     system", STD 10, RFC 974, January 1986.
+
+                     Braden, R., "Requirements for Internet Hosts -
+                     Application and Support", STD 3, RFC 1123, October
+                     1989.
+
+                     Klensin, J., "Simple Mail Transfer Protocol", RFC
+                     2821, April 2001.
+
+13.  Informative References
+
+   [521REPLY]        Durand, A. and F. Dupont, "SMTP 521 Reply Code",
+                     RFC 1846, September 1995.
+
+   [8BITMIME]        Klensin, J., Freed, N., Rose, M., Stefferud, E.,
+                     and D. Crocker, "SMTP Service Extension for 8bit-
+                     MIMEtransport", RFC 1652, July 1994.
+
+   [CHECKPOINT]      Crocker, D., Freed, N., and A. Cargille, "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.
+
+   [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.
+
+
+
+Gellens & Klensin           Standards Track                    [Page 14]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+   [IMAP4]           Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                     VERSION 4rev1", RFC 3501, March 2003.
+
+   [IPSEC]           Kent, S. and R. Atkinson, "Security Architecture
+                     for the Internet Protocol", RFC 2401, November
+                     1998.
+
+   [MESSAGE-FORMAT]  Crocker, D., "Standard for the format of ARPA
+                     Internet text messages", STD 11, RFC 822, August
+                     1982.
+
+                     Braden, R., "Requirements for Internet Hosts -
+                     Application and Support", STD 3, RFC 1123, October
+                     1989.
+
+                     Resnick, P., "Internet Message Format", RFC 2822,
+                     April 2001.
+
+   [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.
+
+   [SIZE]            Klensin, J., Freed, N., and K. Moore, "SMTP Service
+                     Extension for Message Size Declaration", STD 10,
+                     RFC 1870, November 1995.
+
+   [SMTP-AUTH]       Myers, J., "SMTP Service Extension for
+                     Authentication", RFC 2554, March 1999.
+
+   [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 15]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+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
+
+   EMail: john+ietf@jck.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 16]
+
+RFC 4409              Message Submission for Mail             April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Gellens & Klensin           Standards Track                    [Page 17]
+