Message Submission for Mail
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 is unaffected, and continues 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 requirement
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 10 must, 13 should, 19 may.
3.1 Submission Identification
- MAYA 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
- MAYMTAs and MSAs MAY implement message rejection rules that rely, in part, on whether the message is a submission or a relay.
- SHOULDIf 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.
- MUST NOTNote that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT, in itself, be cause for rejecting a message.
- MAYExcept 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.
4 Mandatory Actions
- MUSTAn MSA MUST do all of the following:
4.2 Ensure All Domains Are Fully Qualified
- MUSTThe MSA MUST ensure that all domains in the SMTP envelope are fully qualified.
- MUSTIf 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.
- SHOULDLocal 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.
4.3 Require Authentication
- MUSTThe 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).
5 Recommended Actions
- SHOULDThe MSA SHOULD do all of the following.
5.1 Enforce Address Syntax
- SHOULDAn MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address.
- SHOULDIf the MSA examines or alters the message text in any way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.
5.2 Log Errors
- SHOULDThe MSA SHOULD log message errors, especially apparent misconfigurations of client software.
5.3 Apply Shorter Timeouts
- SHOULDSubmission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes.
- MAYWhen the submission server has a close administrative and/or network relationship with the submission client(s) -- e.g., with a webmail interface calling on a tightly bound submission server -- mutual agreement on much shorter timeouts MAY be appropriate.
6 Optional Actions
- MAYThe MSA MAY do any of the following.
6.1 Enforce Submission Rights
- MAYThe 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).
6.2 Enforce Permissions
- MAYThe 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).
6.3 Check Message Data
- MAYThe 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, seems inconsistent with permissions given to the user (if known), or violates site policy in some way.
6.4 Support for the Postmaster Address
- MAYIf 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
6.5 Adjust Character Encodings
- MAYSubject to limits imposed by other protocols and specifications, the MSA MAY convert among character sets or string encodings to improve message usefulness, likelihood of delivery, or conformance with other specifications or recommendations.
- MAYSuch conversions MAY include, when necessary, replacement of addresses whose encoding does not conform to RFC 5321 with ones that do, using information available out of band.
7 Interaction with SMTP Extensions
- SHOULD+--------------------+----------------------+--------+-----------------+ | Keyword | Name |Sub- | Reference | | | |mission | | +--------------------+----------------------+--------+-----------------+ |PIPELINING |Pipelining |SHOULD |[PIPELINING] | |ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD |[CODES-EXTENSION]| |ETRN |Extended Turn |MUST NOT|[ETRN] | | ...
- SHOULD|Extended Codes |SHOULD |[SMTP-CODES] | |DSN |Delivery Status |SHOULD |[DSN] | | | Notification | | | |SIZE |Message size |MAY |[SIZE] | | ...
- SHOULDFuture SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
- SHOULDExtended Status Codes [SMTP-CODES] SHOULD be supported and used according to [CODES-EXTENSION].
- SHOULD[PIPELINING] SHOULD be supported by the MSA.
- MUST[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user and MUST be supported by the MSA.
8 Message Modifications
- MAYSites MAY modify submissions to ensure compliance with standards and site policy.
- MUSTAny message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements permitted by extensions that are supported by the MSA and accepted by the next-hop server.
8.1 Add 'Sender'
- MAYThe 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.
- MUSTThe MSA MUST ensure that any address it places in a 'Sender' field is, in fact, a valid mail address.
8.2 Add 'Date'
- MAYThe 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'
- SHOULDThe MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
8.4 Transfer Encode
- MAYThe 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
- MAYThe MSA MAY (digitally) sign or otherwise add authentication information to the message.
8.6 Encrypt the Message
- MAYThe MSA MAY encrypt the message for transport to reflect organizational policies.
8.7 Resolve Aliases
- MAYThe MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME) records) for domain names, in the SMTP envelope and/or in address fields of the header, subject to local policy.
8.8 Header Rewriting
- MAYThe MSA MAY rewrite local parts and/or domains in the SMTP envelope and, optionally, in address fields of the header, according to local policy.
- MUST NOTThe MSA MUST NOT rewrite a forward-pointing (destination) address in a way that violates the constraints of [SMTP-MTA] on modifications of local-parts.
12.2 Informative References
- MUSTAs part of this, reclassified RFC 4954 to a normative reference (SMTP AUTH is a MUST for RFC 4409 and this specification).