Message Submission
obsoleted by
- rfc-4409 — Message Submission for Mail
Extracted elements (23)
Header rewriting rules must be data-dependent (matching specific configured patterns), not data-independent. Applying rules like 'always delete the first element of a domain name' would be dangerous; only addresses matching specific MSA configuration settings should be altered.
Message modifications (adding Sender, Date, Message-ID, transfer encoding, signing, encrypting, resolving aliases, header rewriting) are appropriate at the MSA but not at downstream MTAs. The paramount rule is to limit modifications to remedies for specific problems with clear solutions, especially for address elements.
Separating message submission from relay allows sites to implement different security policies, authenticated submission for travelers, detect client misconfigurations, and keep MTA and MSA codebases distinct. Modifications that are safe at submission time are harmful when performed by downstream MTAs.
Any references to the DATA command also refer to substitutes for DATA such as the BDAT command used with the CHUNKING extension (RFC 1830). MSAs implementing CHUNKING must apply the same submission rules to BDAT.
Future SMTP extensions should explicitly specify whether they are valid on the submission port (587), as the applicability of extensions differs between relay and submission contexts.
A null return path (MAIL FROM:<>) is permitted and MUST be accepted by the MSA, as MUAs need to generate null return-path messages for disposition notifications and other purposes.
An MSA MUST use response code 554 to reject MAIL FROM, RCPT TO, or DATA commands containing something improper, with enhanced status code 5.6.0 if no more specific code applies.
Except when the MSA cannot determine a valid return path, an MSA instructed to issue a rejection code MAY instead accept the message and subsequently generate a bounce. Immediate rejection is preferred for direct user feedback.
If the MSA cannot determine a return path to the submitting user (from a valid MAIL FROM, valid source IP, or authenticated identity), the MSA SHOULD immediately reject the message with a 550 code to the MAIL FROM command.
Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains, since such expansion is particularly risky.
Pipelining (RFC 2197), Extended Status Codes (RFC 1893), DSN (RFC 1891), and 8-bit MIME (RFC 1652) SHOULD be supported on the submission port.
The ETRN extension (RFC 1985) and 521 reply (RFC 1846) MUST NOT be used on the submission port.
The MSA MAY issue a 550/5.7.1 error to MAIL FROM if the address has insufficient submission rights or is not authorized with the authentication used. The MSA MAY require authentication (530) before accepting submissions.
The MSA MUST ensure that all domains in the envelope are fully-qualified. If the MSA examines or alters the message text (except to add trace header fields), it MUST also ensure all domains in address header fields are fully-qualified.
The MSA MUST ensure that any address it places in a 'Sender' field is in fact a valid mail address.
The MSA SHOULD log message errors, especially apparent misconfigurations of client software, to aid administrators in detecting local configuration problems.
The MSA SHOULD reject messages with illegal syntax in sender or recipient envelope addresses, using reply code 501 for MAIL FROM or RCPT TO with detectably improper addresses.
A Message Submission Agent (MSA) is a process that accepts messages from MUAs on port 587 (or optionally port 25) and either delivers them or relays them to an MTA. It is distinct from an MTA, which accepts messages from MSAs or other MTAs.
Enhanced status codes defined for submission-specific rejections: 5.6.0 (bad content), 5.6.2 (bad domain or address in MAIL FROM/RCPT TO/DATA), 5.7.1 (insufficient submission rights or unauthorized address), and 5.7.0 (site policy violation).
Port 587 is reserved for email message submission. Messages received on this port are defined to be submissions, using the ESMTP protocol with additional restrictions. Sites MAY also use port 25 for submission by designating some hosts as MSAs.
Adding MSA-level signatures or encryption generally requires the MUA-to-MSA connection itself to be secured (e.g., via transport layer security or an SMTP-AUTH mechanism providing session integrity), otherwise the security benefit is undermined.
Authorization methods for submission include authenticated SMTP (SMTP-AUTH), IP address restrictions, secure IP (IPsec), and prior POP authentication. IP restrictions do not support travelers and can be spoofed; POP-before-SMTP has coordination and timing-window vulnerabilities.
Separating submission from relay allows a site to require authentication for submission while rejecting non-local relay, preventing open relay abuse and unsolicited bulk email injection. Failure to require any authorization allows open use of the site's resources and name for spam.