Message Submission for Mail
obsoletes
- rfc-4409 — Message Submission for Mail
updated by
- rfc-8314 — Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
also
- std-72
Extracted elements (25)
Message modifications that complete or correct submitted messages (adding Date, Message-ID, qualifying domains) are appropriate at the MSA (first-hop submission) but have been shown to cause harm when performed by downstream MTAs. Concentrating these actions at the MSA is a key motivation for the submission/relay split.
Message submission is separated from message relay so that each service can operate under its own rules. Submission servers can enforce authentication, policy, and completeness checks that are inappropriate for relay MTAs, and modifications harmful when performed downstream can be handled at first-hop.
Any references to the DATA command in this specification also refer to substitutes for DATA such as the BDAT command used with the CHUNKING extension, ensuring that both traditional and binary MIME submission paths are covered.
Message modification by the MSA can affect the validity of existing message signatures (DKIM, PGP, S/MIME) and render them invalid, which in turn can affect message handling by downstream filtering engines. MSA operators should carefully consider this before modifying messages.
A null return path (MAIL FROM:<>) is permitted and MUST NOT, in itself, be cause for rejecting a message, as MUAs need to generate null return-path messages for reasons including disposition notifications.
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 supported by the MSA and accepted by the next-hop server.
If an MSA cannot determine a return path to the submitting user (from a valid MAIL FROM, source IP, or authenticated identity), the MSA SHOULD immediately reject the message with a 550 code to the MAIL command.
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.
SMTP-AUTH MUST be supported by the MSA; it allows the MSA to validate authority and determine the identity of the submitting user. The AUTH EHLO keyword is mandatory on the submission port.
Submission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes, reflecting the closer and more predictable relationship between submission clients and servers compared to the public Internet relay environment.
The ETRN extension MUST NOT be used on the submission port. Similarly, the 521 reply code extension and ATRN MUST NOT be used on the submission port.
The MSA MUST, by default, issue an error response (reply code 530) to the MAIL command if the session has not been authenticated using SMTP-AUTH, unless it has already independently established authentication or authorization (e.g., protected subnetwork).
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 adding trace header fields), it MUST also ensure all domains in address header fields are fully qualified. Reply code 554 is used for improper domain references.
The MSA MUST ensure that any address it places in a 'Sender' field is a valid mail address. The MSA MAY add or replace the 'Sender' field if the identity of the sender is known and not given in 'From'.
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.
The MSA SHOULD add or replace the 'Message-ID' field if it is absent or has invalid syntax, as a number of clients still do not generate Message-ID fields.
The MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address (reply code 501), and SHOULD similarly reject messages with illegal address syntax in header address fields if the MSA examines or alters the message text.
A Message Submission Agent (MSA) is a process that conforms to this specification, acting as a submission server to accept messages from MUAs, then either delivering them or relaying them to an MTA as an SMTP client. It is distinct from an MTA, which relays between MTAs.
Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions using ESMTP with the additional restrictions specified herein. A site MAY alternatively designate port 25 hosts as MSAs.
Reply code 554 is the general submission rejection code for MAIL, RCPT, or DATA commands containing something improper. Reply code 530 is used when authentication is required. Reply code 550 with enhanced status code 5.7.1 is used to reject based on insufficient submission rights or user permissions.
Table 1 specifies the applicability of SMTP extensions on the submission port: PIPELINING, ENHANCEDSTATUSCODES, DSN, and 8BITMIME are SHOULD; AUTH is MUST; ETRN, 521 reply code, and ATRN are MUST NOT; SIZE, CHECKPOINT, BINARYMIME, CHUNKING, STARTTLS, NO-SOLICITING, MTRK, DELIVERBY, CONPERM, and CONNEG are MAY.
The 'SMTP Service Extensions' registry has been updated to reflect corrected and new entries from Table 1 (NO-SOLICITING reference corrected; ATRN, DELIVERBY, CONPERM, and CONNEG added). The 'Service Name and Transport Protocol Port Number Registry' entry for port 587 has been updated to point to this document.
IP address restriction for submission authorization does not support travelers and can be spoofed unless all transport paths between MUA and MSA are trustworthy. POP-before-SMTP has a vulnerability window and coordination difficulties. SMTP-AUTH is the preferred authentication mechanism.
Separating submission from relay allows a site to require authentication for submission while rejecting relay of non-local users at the MTA, providing a coherent email security policy. Failure to require any authorization allows open use of the site's resources for injecting unsolicited bulk email.
Unlimited logging of message errors can enable certain forms of denial-of-service attacks; the MSA SHOULD impose limits on such logging.