HTTP/2 302 date: Mon, 14 Jul 2025 09:11:47 GMT content-type: text/html content-length: 143 location: https://get.ietf.org/implementation-report/report-rfc2476.txt cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 expires: Thu, 01 Jan 1970 00:00:01 GMT vary: Accept-Encoding server: cloudflare cf-ray: 95efe50bd940c181-BLR alt-svc: h3=":443"; ma=86400 HTTP/2 200 date: Mon, 14 Jul 2025 09:11:48 GMT content-type: text/plain etag: W/"032affd18febdf0fbceb4402f56d6f93" vary: Accept-Encoding server: cloudflare cf-ray: 95efe50c2caac7d4-BLR content-encoding: gzip alt-svc: h3=":443"; ma=86400 The authors of RFC 2476 and draft-gellens-submit-bis are requesting that Message Submission be promoted to Draft Standard. Message Submission Interoperability Report Randall Gellens (Qualcomm) January 19, 2005 Version 1.0 Message Submission as specified by RFC 2476 has seen widespread deployment. Many email servers now support Message Submission, and many clients comply with it. Note that draft-gellens-submit-bis has one substantive change from RFC 2476: use of SMTP AUTH is now mandatory. Interworking Report: The servers known to support Message Submission are known to work with multiple clients, including when such clients are configured to use port 587 for message submission. Detailed Implementation Report: Port 587: Many email servers now support listening on port 587, including sendmail , EIMS 3.2.5 , Sun Java System Messaging Server , PMDF , and Isode M-Switch 10.6 . Most email clients allow the user to configure a port along with a server name (e.g., "mail.example.com:587") or have a separate port configuration. This includes Eudora, Mulberry, Pegasus, Apple Mail, Outlook, and many others. The Eudora auto-configure feature can be used to configure Eudora's settings, causing it to use port 587. SMTP AUTH: All of the email servers known to support port 587 also support SMTP AUTH. Several ship with a default configuration that enables listening on port 587 and also requires SMTP AUTH on port 587. (All known implementations include support for the CRAM-MD5 mechanism; of the five servers sampled for this report, four support TLS, and three support PLAIN under TLS.) A large number of email clients support SMTP AUTH (including CRAM-MD5). This includes Eudora, Mulberry, Apple Mail. ----------------------------------------------------------------------- 3.2: If 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. Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT in itself be cause for rejecting a message. EIMS: Not reported. Sendmail: Complies. Sun: Not reported. M-Switch: Complies. PMDF: Not reported. Mandatory MSA Actions: 4.1. General Submission Rejection Code Unless covered by a more precise response code, response code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA command that contains something improper. Enhanced status code 5.6.0 is to be used if no other code is more specific. EIMS: Complies. Sendmail: Complies. Sun: Complies. M-Switch: Not reported. PMDF: Not reported. 4.2. Ensure All Domains are Fully-Qualified The MSA MUST ensure that all domains in the envelope are fully-qualified. If the MSA examines or alters the message text in way, except to add trace header fields [SMTP-MTA], it MUST ensure that all domains in address header fields are fully-qualified. Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA command which contains improper domain references. EIMS: Complies: Has an option to reject or accept unqualified domains in MAIL FROM and RCPT TO, and a second option for headers; if accept, it qualifies them before delivering or routing forward the message. Sendmail: Complies: Adds qualification by default; can be overriden by configuration. Sun: Complies: Default is to accept unqualified domains but take whatevr steps are necessary to fully qualify them. The various defaults for this are configurable. Additionally, can be easily configured to flatly reject unqualified MAIL FROM or RCPT TO arguments. PMDF: Complies: Same as Sun. M-Switch: Complies: can be configured to fully qualify header fields and automatically makes domains in the envelope fully qualified (i.e., behavior for MAIL FROM/RCPT TO is the same as for EIMS). Header fields that can't be fully qualified are left alone (otherwise too much mail is rejected and people get upset). Invalid domains in MAIL FROM can be rejected with 5xx response code, unless the error is temporary (e.g., DNS lookup timeout) in which case a 4xx response code is used. 4.3. Require Authentication The MSA MUST issue an error response to the MAIL FROM 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). Reply code 530 [SMTP-AUTH] is used for this purpose. EIMS: Complies: With EIMS 3.2.5 and later, there is an extra setting for "Require AUTH on Submit", which if turned on, will refuse MAIL FROM commands with a 530 5.7.1 response if AUTH has not been successfully used. This setting is on by default for new installations. Sendmail: Complies: Doesn't currently require SMTP AUTH on port 587 by default. However, it can be configured to require AUTH on any nparticular port, including 587. Sun: Complies: Requires AUTH on port 587 by default. Isode M-Switch: Not fully reported: Returns: '530 5.5.1 Must authenticate before starting a transaction' if authentication is required; not reported if M-Switch *requires* authentication on port 587 by default or if it can be configured to do so; also not reported if this is independent of the port 25 configuration. Recommended MSA Actions: 5.1. Enforce Address Syntax An MSA SHOULD reject messages with illegal syntax in a sender or recipient envelope address. EIMS: Does not reject messages with illegal syntax in envelope. Sendmail: Does not reject illegal syntax per se, but does reject domains which do not exist, such as illegal ones (e.g., "@$"). M-Switch: Checks for local addresses and has some checks for illegal addresses. If the MSA examines or alters the message text in way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields. EIMS: Can use filter to examine and reject, but does not now do so. Sendmail: Tries to fix the addresses using heuristics; it only rejects for extreme breakage. Sun: By default, attempts to fix envelope reicpient and header addresses. Envelope recipient addresses will be rejected if fixup fails. It is also possible to configure so that bogus recipient addresses are simply rejected. Similar fixups are done on headers, however, if fixups fail the header can either be left alone or removed. (Various steps can then be taken if this results in an illegal header.) Header fixups can also be disabled, although doing so tends to cause a lot more problems than it solves. PMDF: Same as for Sun. M-Switch: Always accepts message first and does all validation after acknowledging the DATA command. Not reported if M-Switch then rejects or bounces messages with illegal address syntax in the address header fields. 5.2. Log Errors The MSA SHOULD log message errors, especially apparent misconfigurations of client software. EIMS: Complies. Sendmail: Complies. Sun: Complies: Recent versiosn of SJSMS log stuff like bad SMTP commands, valid SMTP commands with bad parameters, addresses found to be invalid, and so on and so forth. PMDF: Complies. M-Switch: Complies. Optional MSA Actions: 6.1. Enforce Submission Rights The MSA MAY issue an error response to the MAIL FROM 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). EIMS: If the "Require AUTH on Submit" setting is turned on in EIMS, the client will only ever get a 530 5.7.1 response to MAIL FROM commands when AUTH has not been successfully used. EIMS does not have any specific per user submission or relay permissions, the closest thing is the "Login Enabled" setting for the user, which will cause AUTH to fail if turned off. Sendmail: If configured to require AUTH, rejects attempts to submit without authenticating. Uses 550 5.7.0 instead of 550 5.7.1. Sun: If configured to require AUTH, rejects attempts to submit without authenticating. M-Switch: can be configured to reject attempts to relay. M-Switch can also have closed groups, so it can restrict whether certain addresses are allowed to post. If the MAIL FROM address is local to the MTA, it checks if the address exists and can reject it with "501 5.1.8" (Unknown local user). Addresses from invalid domains (e.g., DNS lookup fails) can be rejected as well (this is configurable). 6.2. Enforce Permissions The MSA MAY issue an error response to the RCPT TO command if inconsistent with the permissions given to the user (if the session has been authenticated). EIMS: If the "Require AUTH on Submit" setting is turned on in EIMS, the client will only ever get a 530 5.7.1 response to MAIL FROM commands when AUTH has not been successfully used. EIMS does not have any specific per user submission or relay permissions, the closest thing is the "Login Enabled" setting for the user, which will cause AUTH to fail if turned off. Sendmail: Not configured by default to do this; the configuration can be customized to do so by the administrator using sendmail rulesets. Therefore, the administrator decides the SMTP reply and enhanced status code. Sun: SJSMS uses "550 5.7.1 Relaying not allowed: doof@example.org" by default. The extended code and message text are configurable. PMDF: Sas a default similar to Sun's and is similarly configurable. M-Switch: uses "550 5.1.1". 6.3. Check Message Data The 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, or seems inconsistent with permissions given to the user (if known), or violates site policy in some way. EIMS: By default does not do any checking of data; filters that might do this would apply to both port 25 and 587. Sendmail: By default does not do this. Filters can be attached to sendmail using Milter and those filters can reject the message given in the DATA phase. If the filter doesn't supply an SMTP reply code and enhanced status code, sendmail uses "550 5.7.1 Command rejected". Sun: Yes, does all this. PMDF: Yes, does all this. M-Switch: Can be configured to reject messages with no Message-Id and/or Date headers. Can also check the size of the message before the DATA command is enforced. Per-user message context checks can be performed after the message is accepted. 6.4 Support for the Postmaster Address If 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 [SMTP-MTA]), in one or more domains, as compared to requirements enforced for other addresses. EIMS: Doesn't do anything different for postmaster addresses as far as permissions, but does treat 'postmaster' specially for unqualified addresses (that is, it accepts 'postmaster' even when rejecting unqualified addresses). Sendmail: If the user writes custom rulesets for degrees of authentication, they would need to provide for their own exclusions. In the case of requiring authentication on the MSA port (item 4.3 above), the MAIL FROM command is rejected if the user hasn't authenticated; thus can't allow for a postmaster recipient as it won't get to the RCPT TO stage. Sun: Can be configured to do this, but does not do so by default. PMDF: Can be configured to do this, but does not do so by default. M-Switch: The postmaster address is not special, but M-Switch can be configured to use special authorization rules when sending to the postmaster address. SMTP Extensions: Specification: Keyword Name Submission Reference ---------- --------------------- ---------- ------------------ PIPELINING Pipelining SHOULD [PIPELINING] ENHANCEDSTATUSCODES Enhanced Status Codes SHOULD [CODES-EXTENSION] ETRN Extended Turn MUST NOT [ETRN] ... Extended Codes SHOULD [SMTP-CODES] DSN Delivery Status Notification SHOULD [DSN] SIZE Message size MAY [SIZE] ... 521 reply code MUST NOT [521REPLY] CHECKPOINT Checkpoint/Restart MAY [Checkpoint] BINARYMIME Binary MIME MAY [CHUNKING] CHUNKING Chunking MAY [CHUNKING] 8BITMIME Use 8-bit data SHOULD [8BITMIME] AUTH Authentication MUST [SMTP-AUTH] STARTTLS Start TLS MAY [Start-TLS] EIMS: PIPELINING yes ENHANCEDSTATUSCODES yes ETRN not on 587 (yes on 25) DSN *no* SIZE yes CHECKPOINT no BINARYMIME yes 8BITMIME yes AUTH yes STARTTLS no Sendmail: PIPELINING yes ENHANCEDSTATUSCODES yes ETRN not on 587 (yes on 25) DSN yes SIZE yes CHECKPOINT no BINARYMIME no 8BITMIME yes AUTH yes STARTTLS yes Sun: PIPELINING yes ENHANCEDSTATUSCODES yes ETRN not on 587 (yes on 25) DSN yes SIZE yes CHECKPOINT no BINARYMIME no 8BITMIME yes AUTH yes STARTTLS yes PMDF: PIPELINING yes ENHANCEDSTATUSCODES yes ETRN not on 587 (yes on 25) DSN yes SIZE yes CHECKPOINT no BINARYMIME no 8BITMIME yes AUTH yes STARTTLS yes Isode M-Switch: PIPELINING yes ENHANCEDSTATUSCODES yes ETRN no DSN yes SIZE yes CHECKPOINT no BINARYMIME no 8BITMIME yes AUTH yes STARTTLS no