Message Submission for Mail
Extracted elements (28)
Immediate rejection of messages is preferred over delayed bouncing because it gives the user and MUA direct feedback; delayed bounces require MUAs to maintain a queue and match bounces, a capability many contemporary MUAs lack.
Message completions and modifications (e.g., adding Date, qualifying domains) have been shown to cause harm when performed by downstream MTAs, so they are placed in the submission layer where they can be done safely before the message enters the relay network.
Message modification by the MSA should be limited to remedies for specific problems with clear solutions. Indiscriminately appending a domain to an address that lacks one typically results in more broken addresses, since the unqualified local part must first be verified as valid in the target domain.
Separating message submission (MSA) from message relay (MTA) allows each service to operate under its own security and policy rules. This separation makes it easier to implement authenticated submission, detect client misconfigurations, and prevent open relay abuse, without requiring MTAs to change their relay behavior.
Although port 587 is the designated submission port, a site MAY choose to use port 25 for message submission by designating some hosts as MSAs and others as MTAs, for cases where port 587 is not possible or convenient.
Prior POP authentication (POP-before-SMTP) as an authorization method imposes restrictions on both clients and servers, has a vulnerability window where unauthorized users can submit, and is substantially subject to IP spoofing — making it an unreliable authorization mechanism.
References to the DATA command in this memo also apply to substitutes for DATA such as the BDAT command used with the CHUNKING extension.
A null return path (MAIL FROM:<>) MUST NOT in itself be cause for rejecting a message, as MUAs need to generate null return-path messages for disposition notifications and other purposes.
An MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address, using reply code 501 for MAIL or RCPT commands with detectably improper addresses.
Any message forwarded or delivered by the MSA MUST conform to the requirements of SMTP-MTA and MESSAGE-FORMAT.
ETRN (Extended Turn) and the 521 reply code extension MUST NOT be used on the submission port.
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 permitting single-level domains SHOULD reject rather than expand incomplete multi-level domains (e.g., 'squeaky.sales'), since such expansion is particularly risky.
Port 587 is reserved for email message submission. Messages received on this port are defined to be submissions using ESMTP with additional restrictions or allowances.
SMTP-AUTH MUST be supported by the MSA. PIPELINING and Enhanced Status Codes SHOULD be supported. Future SMTP extensions SHOULD explicitly specify if they are valid on the submission port.
The MSA MAY issue an error response (reply code 550 with enhanced status code 5.7.1) to a MAIL command if the MAIL FROM address appears to have insufficient submission rights or is not authorized with the authentication used.
The MSA MAY permit reduced authentication for mail addressed to 'postmaster' to provide an address of last resort for authorized users to report problems that otherwise prevent them from submitting mail.
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 independently established authentication or authorization (e.g., within a 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, it MUST also ensure all domains in address header fields are fully-qualified. Reply code 554 is used to reject improper domain references.
The MSA MUST ensure that any address it places in a 'Sender' field is a valid mail address.
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 many clients still do not generate Message-ID fields.
The MSA SHOULD log message errors, especially apparent misconfigurations of client software, though limits on logging must be imposed to prevent denial-of-service attacks.
A Message Submission Agent (MSA) is a process that accepts messages from MUAs on port 587, and either delivers them directly or relays them as an SMTP client to an MTA. It operates under submission-specific policies distinct from those of relay MTAs.
The IANA port registration for port 587 has been updated to refer to RFC 4409 rather than RFC 2476, affirming port 587 as the designated message submission port.
Care should be used not to expose more detail about rejection reasons to unauthenticated senders than is needed, since some rejections are related to a site's security policy and revealing details could aid attackers.
If a site fails to require any form of authorization for message submissions, it allows open use of its resources and name, enabling injection of unsolicited bulk email using its facilities. Sites should configure MSAs to require authentication and MTAs to reject RCPT for non-local users.
Unlimited error logging can enable certain forms of denial-of-service attacks; limits must be imposed on the volume of logs generated per client or session.