Recommendations For Submission of Email and Relaying of Email Between Mail Networks

Scope. This document makes recommendations for the submission of electronic mail messages and the relay of electronic mail messages between mail networks. The goals of these recommendations are as follows:

• Deter unauthorized use of mail networks, especially the unauthorized use of mail networks to send spam and/or propagate viruses,
• Encourage greater uniformity in mail submission across mail networks and mail user agents,
• Encourage the separation of processing of newly submitted mail from the processing of mail relayed from other sources, and
• Encourage traceability (though not necessarily non-repudiation) of non-anonymous mail, while preserving the ability of mail to be anonymous.
• Avoid creating new protocols, new protocol elements, or new protocol features, in these recommendations. New protocols, elements or features may be desirable in the future.

Definitions and Assumptions.

• Readers are expected to be familiar with the SMTP protocol (RFC 821, RFC 2821), the Internet Mail message format (RFC 822, RFC 2822), their respective roles, and terms such as Mail User Agent (MUA) and Mail Transport Agent (MTA) that are well-established and widely used in the field.
• MUST, SHOULD, MUST NOT, SHOULD NOT, RECOMMENDED, etc. are as defined in RFC 2119.
• The originator of a message is the person or other entity who initially acts to request that a message be delivered to one or more recipients. The process of requesting delivery of a message is called submission, and the originator is said to submit messages.
• An SMTP server is an MTA that implements the SMTP protocol and accepts incoming mail (for some set of recipients), by default on port 25, or (by private arrangement) on any port other than 587.
• A Mail Submission Agent (MSA) is an agent that allows an authorized originator to submit messages via the Submission protocol, as defined in RFC 2476 or its successors, on port 587. MSAs are assumed to be MTAs, so language that applies to MSAs also applies to MTAs.
• A MAIL FROM address of a message transmission is the address contained in the MAIL FROM command of a Submission or SMTP session used to submit or relay that message.
• A RCPT TO address of a message transmission is the address contained in the RCPT TO command of a Submission or SMTP session used to submit or relay that message.
• A From address or Reply-To address is any address appearing in a From or Reply-To header field (respectively) of a message.
• A return address of a message is any of the MAIL FROM, From, or Reply-To addresses associated with that message.
• A mail domain is any of: 1. A DNS name used as the domain component of some set of email addresses. 2. The "domain" component of an email address according to the syntax in RFC 2822. 3. The set of email addresses that have a particular "domain" component.
• A Mail Originator Network (MON) is a set of MSAs and MTAs that accept messages on behalf of authorized users, and relay each message to the appropriate MDNs for delivery of the message to its intended recipients.
• A Mail Reception Network (MRN) is a set of MTAs that accept mail on behalf of a set of mail domains and deliver each message to each recipient's message store.
• A Mail Network consists of an MON, an MRN, or both, that provide mail origination and/or delivery service to a set of authorized users.
• A local recipient address of an MRN is a recipient address with a domain component that is one of the domains on whose behalf the MRN is authorized to accept and deliver mail, or a recipient address with a domain literal IP address that is one of the addresses used by the MTA to accept mail.
• A nonlocal recipient address of an MRN is an email address that is not a local recipient address of that MRN.
• An authenticated identity is a string that is used by a user or client to of a service (e.g. an SMTP server or a Submission server) to identify himself or itself to that service via some authentication method. An authenticated identity is not necessarily the same as the user or client's email address, nor does it necessarily conform to email address syntax.

Recommendations for Submission servers.

• Submission servers MUST require authentication before accepting any messages for delivery. A discussion of authentication methods is below.
• Submission servers SHOULD support a variety of authentication methods, to ease transition to new methods when previously-used methods are found defective.
• Submission servers MUST refuse to accept any message for which authentication fails, or if the authenticated originator is not authorized to submit mail to the MON.
• Submission servers SHOULD ensure that mail is traceable to the originator, for a reasonable time, via the ID tag and other information in the Received field supplied by the Submission server.
  Discussion: "traceable" does not mean that the originator's real identity is revealed in the message, but rather, that the message can be associated with the originator's authenticated identity by the MON given information stored in the Received field, as supplemented by other information available to the MON (e.g. log files).
• Submission servers MUST NOT disclose the authenticated identity of the originator of a message (in the Sender, Received, or any other fields, or in the message body, or in any SMTP command) unless that identity also appears in the originator-supplied MAIL FROM field, From header field, or Reply-To header field.
  Discussion: There is inevitable tension between the need for messages to be traceable and the need for originators to have a reasonable expectation of privacy. There are many valid reasons for an originator to send mail via a different mail network than one at which the originator wishes to receive mail. On the other hand, mail messages can do harm. It is desirable for harmful messages to be traceable to their origin, so that the originator can be held responsible and/or the originator's computer fixed. Making messages traceable can also do harm if it deters individuals from sending socially valuable messages out of fear of reprisal, or if such individuals are made to suffer out of reprisal for sending such messages.
  As a practical matter it is generally possible for any authenticated message to be associated with the party who submitted the message, because submissions are generally logged. However, nothing in these recommendations requires a mail network to determine the "real" identities of individuals who are authorized to submit mail. MONs SHOULD employ measures to discourage abuse and/or limit the potential for abuse from all authorized originators, though these measures MAY differ from one originator to another.
• Submission servers MAY disclose the authenticated identity of the originator of a message (in the Sender, Received, or other fields) if that identity already appears in the MAIL FROM, From, or Reply-To fields in the message as submitted by the originator.
  Discussion: If the originator's identity used to authenticate to the Submission server is an email address at which he wishes to receive mail, and he has already disclosed that email address in the message header, it seems unlikely that he wishes to keep that identity a secret. However, recipients and mail networks SHOULD NOT assume that a message which does not contain the originator's email address in the Sender or initial Received field is invalid, both because this might provide a false indication of an invalid message, and because the limitations of Sender and Received fields make it difficult to defend against replay attacks. On balance it might be simpler if Submission servers never disclosed the authenticated identities of originators via Sender or Received fields, whether or not such identities were equivalent to any return address supplied by the originator.
• Submission servers MAY include additional information in the message header to authenticate the originator of the message to the recipient and/or a downstream mail processor if one of the following is true:
  • The authenticated identity of the originator appears in the MAIL FROM, From, or Reply-To fields supplied by the originator, OR
  • The originator has explicitly consented to the provision of such information.
  However it may not be appropriate for recipients or downstream mail processors to use such information to determine the validity of such messages.
  Discussion: The authenticated identity presented at submission time is of little value in determining the validity of a message for several reasons. One is that the authenticated identity may have no obvious relationship with any of the return addresses even if the originator is authorized to send mail using those return addresses. Recipients should therefore not assume that a message is invalid merely because the authenticated identity does not match one or more return addresses. Another reason is that absent some sort of signature on the message header, body, and recipient list it is easy to forge apparently valid messages by using authenticated identities from other messages. A message that contains such a signature might be considered invalid if the signature fails verification; however, a message lacking such a signature cannot be considered invalid without some reliable out-of-band information from the originator that messages from that originator will always be signed.

Recommendations for other forms of message submission. In general, the rules for Submission servers also apply to other forms of message submission where message submission can reliably be distinguished from messages that are relayed from other sources.

Recommendations for SMTP servers.

• Distinguishing submission from relaying. The Submission protocol is a recent addition to the Internet mail protocol suite. Longstanding and still-widespread practice is to use the same SMTP protocol, and sometimes the same servers, for both submission of new mail and relaying of mail already in the MTS. However there are several subtle differences between mail submission and mail relaying:
  • In the case of message submission the mail client (presumably an MUA) is acting directly on behalf of the originator, whereas in the case of relaying the client (presumably an MTA) may have no particular relationship with the originator. Thus (and most importantly for the purpose of this memo) the separation of submission from relaying, coupled with the availability of client authentication, provides an opportunity to deny unauthorized users the ability to submit mail.
  • In the case of message submission the server is presumed to have an explicit arrangement with the message originator and in those cases the server is allowed to modify messages according to certain narrow guidelines established in RFC 2476 and elsewhere.
  • In other circumstances (such as a malformed message) it may also be more appropriate for a SMTP server to reject a newly-submitted message (so as to provide immediate feedback to the originator) when in the case of relaying the server would do less harm to accept the message and relay it to its destination.
  Due to these differences there is growing awareness of a need to treat newly submitted mail differently from relayed mail.
• Because of the traditional dual-use of SMTP, is can be difficult for an SMTP server to reliably determine whether an incoming message is a "submission" of a new message or a "relay" of a message that is already submitted.
• Since treating a message as submission may do harm to the message, for instance by altering it, an SMTP server SHOULD NOT treat a message as a submission merely because it appears to be from a "local" originator or because it specifies one or more "nonlocal" recipients.
• An SMTP server SHOULD treat an incoming message as a submission if the SMTP server exists for only the purpose of mail submission, the server is not listed as an mail exchanger for any of the domains associated with the MRN, and the server is not otherwise advertised as a mail relay.
• An SMTP server MAY use the authenticated identity of the SMTP client to distinguish between mail submission and mail relaying. (In other words, an SMTP server may associate some identities with the submission of new mail and other identities with the relaying of mail.) The mere use of authentication SHOULD NOT be used to distinguish between submitted and relayed mail, because this would discourage authentication between mail relays.
• An SMTP server SHOULD NOT attempt to distinguish submissions from relayed mail based on the source IP address of the client. However, if an SMTP server chooses to accept mail for nonlocal recipient addresses from an unauthenticated client based on the client's source IP address, it MUST be able to reliably determine that the source IP address is associated with a known and authorized user, and it MUST make such mail traceable to that user for a reasonable amount of time using information stored in the Received header field.
  Discussion: Such configurations cause the behavior of mail submission from mobile hosts to succeed or fail depending on the network to which they are connected. A laptop-based MUA which submits mail successfully when connected to its home network (because the SMTP server "trusts" the laptop's "home" IP address) might inexplicably fail to submit mail when connected to another network.
  It is understood that use of source IP address to distinguish between mail submission and relaying is widespread practice in some networks, and that it is difficult and expensive to get users to change the configurations of their mail user agents. Migration to the Submission protocol and dedicated submission servers leads to a more robust configuration for mobile hosts. Note that nothing in this memo forbids use of the destination IP address (sometimes called "virtual hosts") to distinguish between submission and relay traffic routed to the same physical host and protocol engine.
• Whenever an SMTP server treats a message as a submission it MUST adhere to the requirements for Submission servers above. In other cases the SMTP server is assumed to be acting as a mail relay. An SMTP server acting as a relay MUST NOT agree to send mail to a non-local recipient. RCPT commands specifying non-local recipients SHOULD be rejected immediately rather than accepting the message and bouncing it later, or accepting the RCPT command and returning failure in response to a DATA or other message-transfer command.
• An SMTP server acting as a relay MAY treat a RCPT command specifying a non-local recipient as a client implementation error or client configuration error and reject all further commands during that session with suitable error codes.
  Discussion: If a SMTP client attempts to send non-local traffic to an SMTP server that is not acting as a submission server, something is wrong. It may be that the client is misconfigured or poorly implemented, or this may be an attempt to use the SMTP server for unauthorized purposes. It may also be a configuration error on the server side. In any of these cases, early and consistent identification and reporting of the fault seem to be in the best interest of all legitimate parties.

Recommendations for Mail Origination Networks (MONs)
These recommendations apply to MONs that intend to allow their users to submit mail from arbitrary IP networks.

• MONs MUST provide Submission servers that listen on port 587 so that users can use those servers to submit mail.
• In the near term, MONs MAY also provide SMTP servers for the specific purpose of message submission. These servers SHOULD require authentication and MUST NOT accept mail for nonlocal recipients without authentication. These servers MUST NOT be listed as mail exchangers for any domain in DNS that is under control of the MON.
  Discussion: many current MUAs are confusing or difficult to configure to submit mail via Submission servers.
• MONs SHOULD encourage users to configure their MUAs to use Submission servers (rather than SMTP servers) to submit mail.

Recommendations for IP networks.

• IP networks that intend to permit their users to send electronic mail SHOULD NOT block outgoing traffic on port 587.
• This memo takes no position on the blocking of outgoing traffic on port 25.

Recommendations for Mail User Agents (MUAs).
These recommendations were intended to apply to MUAs intended for use with arbitrary MONs.

• MUAs MUST support the ability to use the Submission protocol. Because of the need to continue to support submission via SMTP in the near term, for an effective configuration user interface this should be presented as a choice between the Submission protocol and SMTP, rather than expecting the user to type in port number 587.
• MUAs MUST support STARTTLS and AUTH PLAIN when submitting mail.
• MUAs SHOULD support the ability to authenticate to Submission and SMTP servers using STARTTLS, TLS client certificates, and AUTH EXTERNAL.
• MUAs SHOULD support as many robust authentication methods for mail submission as possible.
• The method of mail submission, and the choice of methods to be used by an MUA to authenticate to a server MUST be user-configurable.
• Until such time as there is a secure way for a MON to indicate to a client which authentication methods are supported and which are not, choice of authentication methods MUST be explicitly configured. An MUA MUST NOT attempt to "negotiate" authentication methods by trial-and-error.
  Discussion: this provides a means by which an attacker can encourage an MUA to use a weaker authentication method.

Authentication methods.

• It is RECOMMENDED that Submission servers, and SMTP servers intended to provide submission services, implement STARTTLS, the SMTP AUTH extension, and the SASL PLAIN authentication method.
• Submission servers MAY support authentication using STARTTLS, TLS client certificates, and the AUTH EXTERNAL authentication method.
• The PLAIN authentication method, or any method requiring transmission of password-equivalent material, MUST NOT be accepted over an unsecured channel. A secured channel is one which provides strong encryption as well as authentication of the server to the client.
• In situations where the identity of the client is reliably associated with a source IP address, and it is reasonably believed that there are no paths by which another party could source packets from that IP address, an MTA MAY be configured to treat the source IP address as an indication of the client's identity.
• Submission servers and SMTP servers intended to provide submission services are encouraged to support additional authentication methods that are believed to be reasonably secure against attack.
• In general it is necessary to frequently re-evaluate authentication methods, strengths, and policies in light of new information about attacks, and to adjust clients and servers accordingly.

Transitions from existing practice. This memo makes recommendations that in some cases are contrary to widespread existing practice. It is understood and acknowledged that such practices are difficult and expensive to change, especially when such changes require that large numbers of client MUAs be upgraded and/or reconfigured. It is not expected that all of the recommendations in this memo will be implemented immediately or in the same time frame. At least for large mail networks, some of them will inherently require a longer transition period than others.

Use of the ID tag in Received fields. The ID portion of the Received field may be used to associate a message with a tag, that references external data that can links a message to the authenticated originator. The ID supplied in the Received field tag should uniquely identify the message submission, and be sufficient to recover information about the message submission from the MONs logs.

Caveats.

• Without a means to reliably associate message contents with a particular submission, and without a mechanism prevent replay attacks, any indication of the originator's identity in the message is nearly useless.
• Even if such means were provided, recipients should not assume that an email address is uniquely or stably associated with a particular person.

Future work for IETF.

• A vendor-independent means of configuring MUAs.
• A means to permit a MRN to supply default configuration information with email addresses.

Acknowledgement. This memo is to some degree derived from Internet-Draft draft-hutzler-spamops-04.html, by Carl Hutzler, Dave Crocker, Pete Resnick, Robert Sanders, and Eric Allman. In particular, the two documents have similar (though not identital) scope and similar structure. This memo resulted from an attempt by this author to request changes to draft-hutzler-spamops-04 and a challenge by one of that document's authors to supply text. Mostly because of that document's loose use of terminology it seemed difficult to supply isolated suggestions for changes, so I decided to write my own document instead.