RFC 5321 Draft Standard Transport

Simple Mail Transfer Protocol

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submissi

Status
Draft Standard. A maturity level the IETF retired in 2011. Documents that had reached it kept the label, so it still appears on current work such as RFC 5321.
Published
October 2008
Authors
J. Klensin
Read it
rfc-editor.org · errata · DOI

Replaces RFC 772: Mail Transfer Protocol, RFC 780: Mail Transfer Protocol, RFC 788: Simple Mail Transfer Protocol, RFC 821: Simple Mail Transfer Protocol, RFC 974: Mail routing and the domain system, RFC 1425: SMTP Service Extensions, RFC 1651: SMTP Service Extensions, RFC 1869: SMTP Service Extensions, RFC 2821: Simple Mail Transfer Protocol.

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. 177 must, 128 should, 55 may.

2.1 Basic Structure

  • SHOULDIn many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409 [18]) rather than SMTP.
  • MUSTIn either case, once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8, below).

2.2.1 Background

  • MUSTContemporary SMTP implementations MUST support the basic extension mechanisms.
  • MUSTFor instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO.
  • MUST(However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO must be identified for interoperability purposes, this document discusses only EHLO.

2.2.2 Definition and Registration of Extensions

  • MUST NOTKeywords beginning with "X" MUST NOT be used in a registered service extension.
  • MUSTConversely, keyword values presented in the EHLO response that do not begin with "X" MUST correspond to a Standard, Standards-Track, or IESG-approved Experimental SMTP service extension registered with IANA.
  • MUST NOTA conforming server MUST NOT offer non-"X"-prefixed keyword values that are not described in a registered extension.

2.2.3 Special Issues with Extensions

  • MAYIn particular, if an extension implies that the delivery path normally supports special features of that extension, and an intermediate SMTP system finds a next hop that does not support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host.
  • SHOULDIf this strategy is employed, the timeout to fall back to an unextended format (if one is available) SHOULD be less than the normal timeout for bouncing as undeliverable (e.g., if normal timeout is three days, the requeue timeout before attempting to transmit the mail without the extension might be one day).

2.3.4 Host

  • SHOULD NOTHosts are known by names (see the next section); they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2.

2.3.5 Domain Names

  • MUST NOTLocal aliases MUST NOT appear in any SMTP transaction.
  • MUST NOTLocal nicknames or unqualified names MUST NOT be used.
  • MUSTo The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.
  • MUSTo The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used.

2.3.8 Lines

  • MUST NOTConforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator.
  • MAYLimits MAY be imposed on line lengths by servers (see Section 4).
  • MUST NOTSMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.

2.3.11 Mailbox and Address

  • MUSToptimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

2.4 General Syntax Principles and Transaction Model

  • MAYThat is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning.
  • MUSTThe local-part of a mailbox MUST BE treated as case sensitive.
  • MUSTTherefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts.
  • MAYImplementations MAY wish to employ this encoding to accommodate those servers.
  • MUST NOTAn originating SMTP client that has not successfully negotiated an appropriate extension with a particular server (see the next paragraph) MUST NOT transmit messages with information in the high-order bit of octets.
  • MAYIf such messages are transmitted in violation of this rule, receiving SMTP servers MAY clear the high- order bit or reject the message as invalid.
  • SHOULDIn general, a relay SMTP SHOULD assume that the message content it has received is valid and, assuming that the envelope permits doing so, relay it without inspecting that content.
  • MAYDelivery SMTP systems MAY reject such messages, or return them as undeliverable, rather than deliver them.
  • SHOULDReceiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies.
  • MAY8-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension, RFC 1652 [22].
  • SHOULD8BITMIME SHOULD be supported by SMTP servers.
  • MUST NOTHowever, it MUST NOT be construed as authorization to transmit unrestricted 8-bit material, nor does 8BITMIME authorize transmission of any envelope material in other than ASCII.
  • MUST NOT8BITMIME MUST NOT be requested by senders for material with the high bit on that is not in MIME format with an appropriate content-transfer encoding; servers MAY reject such messages.

3.1 Session Initiation

  • MAYSMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems.
  • MAYImplementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns.
  • MAYThe SMTP protocol allows a server to formally reject a mail session while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220.
  • MUSTA server taking this approach MUST still wait for the client to send a QUIT (see Section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with "503 bad sequence of commands".
  • SHOULDSince an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system.

3.2 Client Initiation

  • MAYOlder SMTP systems that are unable to support service extensions, and contemporary clients that do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO.
  • MUST NOTServers MUST NOT return the extended EHLO- style response to a HELO command.
  • SHOULDFor a particular connection attempt, if the server returns a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO.

3.3 Mail Transactions

  • MUSTIf the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later).
  • MAYIn those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined.
  • SHOULD NOTHistorically, the <reverse-path> was permitted to contain more than just a mailbox; however, contemporary systems SHOULD NOT use source routing (see Appendix C).
  • SHOULD NOTHistorically, the <forward-path> was permitted to contain a source routing list of hosts and the destination mailbox; however, contemporary SMTP clients SHOULD NOT utilize source routes (see Appendix C).
  • MUSTServers MUST be prepared to encounter a list of source routes in the forward-path, but they SHOULD ignore the routes or MAY decline to support the relaying they imply.
  • MAYSimilarly, servers MAY decline to accept mail that is destined for other hosts or systems.
  • MUST NOTConsequently, restricted- capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site.
  • MUSTIf a RCPT command appears without a previous MAIL command, the server MUST return a 503 "Bad sequence of commands" response.
  • MAYIf there was no MAIL, or no RCPT, command, or all such commands were rejected, the server MAY return a "command out of sequence" (503) or "no valid recipients" (554) reply in response to the DATA command.
  • MUST NOTIf one of those replies (or any other 5yz reply) is received, the client MUST NOT send the message data; more generally, message data MUST NOT be sent unless a 354 reply is received.
  • SHOULDThese servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in Section 6 and, in particular, in Section 6.1.
  • SHOULD NOTServer SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body.
  • MUST NOTIn particular, they MUST NOT reject messages in which the numbers of Resent-header fields do not match or Resent-to appears without Resent-from and/or Resent-date.
  • MUSTMail transaction commands MUST be used in the order discussed above.

3.4 Forwarding for Address Correction or Updating

  • MAYo Servers MAY forward messages when they are aware of an address change.
  • MAYWhen they do so, they MAY either provide address-updating information with a 251 code, or may forward "silently" and return a 250 code.
  • MUST NOTHowever, if a 251 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user.
  • MAYo Servers MAY reject messages or return them as non-deliverable when they cannot be delivered precisely as addressed.
  • MAYWhen they do so, they MAY either provide address-updating information with a 551 code, or may reject the message as undeliverable with a 550 code and no address-specific information.
  • MUST NOTHowever, if a 551 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user.
  • SHOULDSMTP server implementations that support the 251 and/or 551 reply codes SHOULD provide configuration mechanisms so that sites that conclude that they would undesirably disclose information can disable or restrict their use.

3.5.1 Overview

  • SHOULDImplementations SHOULD support VRFY and EXPN (however, see Section 3.5.2 and Section 7.3).
  • MAYIf a normal (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user.
  • MUSTIt MUST be in either of the following forms:
  • MAYWhen a name that is the argument to VRFY could identify more than one mailbox, the server MAY either note the ambiguity or identify the alternatives.
  • MAYFor the EXPN command, the string identifies a mailing list, and the successful (i.e., 250) multiline response MAY include the full name of the users and MUST give the mailboxes on the mailing list.
  • MAYIf a request is made to apply VRFY to a mailing list, a positive response MAY be given if a message so addressed would be delivered to everyone on the list, otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, not a user" or "252 Unable to verify members of mailing list").
  • MAYIf a request is made to expand a user name, the server MAY return a
  • MAYpositive response consisting of a list containing one name, or an error MAY be reported (e.g., "550 That is a user name, not a mailing list").
  • MUSTAn implementation of the VRFY or EXPN commands MUST include at least recognition of local mailboxes as "user names".
  • SHOULDHowever, since current Internet practice often results in a single host handling mail for multiple domains, hosts, especially hosts that provide this functionality, SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY also choose to recognize other strings as "user names".
  • SHOULDSimilarly, historical variations in what is returned by these commands are such that the response SHOULD be interpreted very carefully, if at all, and SHOULD generally only be used for diagnostic purposes.

3.5.2 VRFY Normal Response

  • MUSTWhen normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply MUST include the <Mailbox> name using a "<local-part@domain>" construction, where "domain" is a fully- qualified domain name.
  • MAYIn circumstances exceptional enough to justify violating the intent of this specification, free-form text MAY be returned.
  • SHOULDand people, addresses SHOULD appear in pointed brackets.
  • MUSTWhen addresses, rather than free-form debugging information, are returned, EXPN and VRFY MUST return only valid domain addresses that are usable in SMTP RCPT commands.
  • MUSTConsequently, if an address implies delivery to a program or other system, the mailbox name used to reach that target MUST be given.
  • MUST NOTPaths (explicit source routes) MUST NOT be returned by VRFY or EXPN.
  • SHOULDServer implementations SHOULD support both VRFY and EXPN.
  • MAYFor security reasons, implementations MAY provide local installations a way to disable either or both of these commands through configuration options or the equivalent (see Section 7.3).
  • MUSTSince they were both optional in RFC 821, but VRFY was made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be listed as a service extension in an EHLO response.
  • MAYVRFY MAY be listed as a convenience but, since support for it is required, SMTP clients are not required to check for its presence on the extension list before using it.

3.5.3 Meaning of VRFY or EXPN Success Response

  • MUST NOTA server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address.
  • MUST NOTIn particular, a server MUST NOT return 250 if all it has done is to verify that the syntax given is valid.
  • SHOULDIn that case, 502 (Command not implemented) or 500 (Syntax error, command unrecognized) SHOULD be returned.
  • SHOULDIn these situations, reply code 252 SHOULD be returned.
  • SHOULDImplementations generally SHOULD be more aggressive about address verification in the case of VRFY than in the case of RCPT, even if it takes a little longer to do so.

3.5.4 Semantics and Applications of EXPN

  • SHOULD NOTThe propagation of aliasing systems with mail on the Internet for hosts (typically with MX and CNAME DNS records), for mailboxes (various types of local host aliases), and in various proxying arrangements has made it nearly impossible for these strategies to work consistently, and mail systems SHOULD NOT attempt them.

3.6.1 Source Routes and Relaying

  • SHOULD NOTSMTP clients SHOULD NOT generate explicit source routes except under unusual circumstances.
  • MAYSMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes.
  • MAYWhen route information is encountered, SMTP servers MAY ignore the route information and simply send to the final destination specified as the last element in the route and SHOULD do so.
  • MUST NOTThis is one of several reasons why SMTP clients MUST NOT generate invalid source routes or depend on serial resolution of names.

3.6.2 Mail eXchange Records and Relaying

  • SHOULDrelay mail to a particular address for policy reasons, a 550 response SHOULD be returned.
  • MAYA server MAY attempt to verify the return path before using its address for delivery notifications, but methods of doing so are not defined here nor is any particular method recommended at this time.

3.6.3 Message Submission Servers as Relays

  • MUSTIf an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path).
  • SHOULDFormats specified for non-delivery reports by other standards (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if possible.
  • MUST NOTOf course, SMTP servers MUST NOT send notification messages about problems transporting notification messages.
  • MUSTWhen such a message is transmitted, the reverse-path MUST be set to null (see
  • MUST NOTAs discussed in Section 6.4, a relay SMTP has no need to inspect or act upon the header section or body of the message data and MUST NOT do so except to add its own "Received:" header field (Section 4.4) and, optionally, to attempt to detect looping in the mail system (see Section 6.3).

3.7.1 Header Fields in Gatewaying

  • MAYHeader fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries.

3.7.2 Received Lines in Gatewaying

  • MUSTWhen forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header section.
  • MUST NOTAs another consequence of trace header fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace header field and SHOULD be extremely robust in the light of unexpected information or formats in those header fields.
  • SHOULDThe gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies.

3.7.3 Addresses in Gatewaying

  • SHOULDFrom the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in the RFC 822 header section, and all valid RFC 822 messages.
  • MUSTAddresses and header fields generated by gateways MUST conform to applicable standards (including this one and RFC 5322 [4]).

3.7.4 Other Header Fields in Gatewaying

  • MUSTThe gateway MUST ensure that all header fields of a message that it forwards into the Internet mail environment meet the requirements for Internet mail.
  • MUSTIn particular, all addresses in "From:", "To:", "Cc:", etc., header fields MUST be transformed (if necessary) to satisfy the standard header syntax of RFC 5322 [4], MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies.
  • SHOULDThe translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment are delivered to the reverse-path from the SMTP envelope, not to an address in the "From:", "Sender:", or similar header fields of the message.

3.7.5 Envelopes in Gatewaying

  • SHOULDSimilarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment.

3.8 Terminating Sessions and Connections

  • MUST NOTAn SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except:
  • SHOULDAn SMTP server that is forcibly shut down via external means SHOULD attempt to send a line containing a 421 response code to the SMTP client before exiting.
  • SHOULDSMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly.

3.9 Mailing Lists and Aliases

  • SHOULDAn SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery.
  • MUSTWhen a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list.
  • MUSTHowever, in this case, the message header section (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected.
  • SHOULDServers SHOULD simply utilize the addresses on the list; application of heuristics or other matching rules to eliminate some addresses, such as that of the originator, is strongly discouraged.

4.1.1 Command Semantics and Syntax

  • SHOULD(In the interest of improved interoperability, SMTP receivers SHOULD tolerate trailing white space before the terminating <CRLF>.) The syntax of the local part of a mailbox MUST conform to receiver site conventions and the syntax specified in Section 4.1.2.
  • MUST NOTIn the absence of specific extensions offered by the server and accepted by the client, clients MUST NOT send such parameters and servers SHOULD reject commands containing them as having invalid syntax.

4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)

  • SHOULDavailable), the client SHOULD send an address literal (see Section 4.1.3).
  • SHOULD NOTIn the interest of interoperability, it is probably wise for servers to be prepared for this string to occur, but SMTP clients SHOULD NOT send it.
  • SHOULDA client SMTP SHOULD start an SMTP session by issuing the EHLO command.
  • MAYOlder client SMTP systems MAY, as discussed above, use HELO (as specified in RFC 821) instead of EHLO, and servers MUST support the HELO command and reply properly to it.
  • MUSTIn any event, a client MUST issue HELO or EHLO before starting a mail transaction.
  • MUSTAlthough EHLO keywords may be specified in upper, lower, or mixed case, they MUST always be recognized and processed in a case- insensitive manner.
  • MUSTThe EHLO response MUST contain keywords (and associated parameters if required) for all commands not listed as "required" in Section 4.5.1 excepting only private-use commands as described in Section 4.1.5.
  • MAYPrivate-use commands MAY be listed.

4.1.1.3 RECIPIENT (RCPT)

  • SHOULD NOTSending systems SHOULD NOT generate the optional list of hosts known as a source route.
  • MUSTReceiving systems MUST recognize source route syntax but SHOULD strip off the source route specification and utilize the domain name associated with the mailbox as if the source route had not been provided.
  • SHOULDSimilarly, relay hosts SHOULD strip or ignore source routes, and names MUST NOT be copied into the reverse-path.
  • MAYAs provided in Appendix C, xyz.com MAY also choose to relay the message to hosta.int, using the envelope commands
  • MAYSince hosts are not required to relay mail at all, xyz.com MAY also reject the message entirely when the RCPT command is received, using a 550 code (since this is a "policy reason").
  • MUST NOTThe client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response.

4.1.1.4 DATA (DATA)

  • SHOULDThe mail data may contain any of the 128 ASCII character codes, although experience has indicated that use of control characters other than SP, HT, CR, and LF may cause problems and SHOULD be avoided when possible.
  • MUST NOTAn extra <CRLF> MUST NOT be added, as that would cause an empty line to be added to the message.
  • MUSTbody were passed to the originating SMTP-sender with a final "line" that did not end in <CRLF>; in that case, the originating SMTP system MUST either reject the message as invalid or add <CRLF> in order to have the receiving SMTP server recognize the "end of data" condition.
  • MUST NOTThe custom of accepting lines ending only in <LF>, as a concession to non-conforming behavior on the part of some UNIX systems, has proven to cause more interoperability problems than it solves, and SMTP server systems MUST NOT do this, even in the name of improved robustness.
  • MUST NOTIn particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication.
  • MUSTIf the processing is successful, the receiver MUST send an OK reply.
  • MUSTIf the processing fails, the receiver MUST send a failure reply.
  • MUSTErrors that are diagnosed subsequently MUST be reported in a mail message, as discussed in Section 4.4.

4.1.1.5 RESET (RSET)

  • MUSTAny stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared.
  • MUSTThe receiver MUST send a "250 OK" reply to a RSET command with no arguments.
  • MUST NOTAn SMTP server MUST NOT close the connection as the result of receiving a RSET; that action is reserved for QUIT (see Section 4.1.1.10).
  • SHOULDTo preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared.

4.1.1.8 HELP (HELP)

  • MAYThe command MAY take an argument (e.g., any command name) and return more specific information as a response.
  • SHOULDSMTP servers SHOULD support HELP without arguments and MAY support it with arguments.

4.1.1.9 NOOP (NOOP)

  • SHOULDIf a parameter string is specified, servers SHOULD ignore it.

4.1.1.10 QUIT (QUIT)

  • MUSTThis command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel.
  • MUST NOTThe receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error).
  • MUST NOTThe sender MUST NOT intentionally close the transmission channel until it sends a QUIT command, and it SHOULD wait until it receives the reply (even if there was an error response to a previous command).
  • MUSTIf the connection is closed prematurely due to violations of the above or system or network failure, the server MUST cancel any pending transaction, but not undo any previously completed transaction, and generally MUST act as if the command or transaction in progress had received a temporary error (i.e., a 4yz response).

4.1.2 Command Argument Syntax

  • MUSTA-d-l = At-domain *( "," At-domain ) ; Note that this form, the so-called "source ; route", MUST BE accepted, SHOULD NOT be ; generated, and SHOULD be ignored.
  • SHOULDIf this string is an email address, ; i.e., a Mailbox, then the "xtext" syntax [32] ; SHOULD be used.
  • MAYLocal-part = Dot-string / Quoted-string ; MAY be case-sensitive
  • SHOULDWhile the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive.
  • MUSTFor any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent, and the sending system SHOULD transmit the form that uses the minimum quoting possible.
  • MUST NOTSystems MUST NOT define mailboxes in such a way as to require the use in SMTP of non-ASCII characters (octets with the high order bit set
  • MUST NOTThese characters MUST NOT be used in MAIL or RCPT commands or other commands that require mailbox names.
  • MUST NOTTo promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]), characters outside the set of alphabetic characters, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers.
  • MUSTSMTP servers that receive a command in which invalid character codes have been employed, and for which there are no other reasons for rejection, MUST reject that command with a 501 response (this rule, like others, could be overridden by appropriate SMTP extensions).

4.1.3 Address Literals

  • MUSTStandardized-tag = Ldh-str ; Standardized-tag MUST be specified in a ; Standards-Track RFC and registered with IANA

4.1.4 Order of Commands

  • MUSTA session that will contain mail transactions MUST first be initialized by the use of the EHLO command.
  • SHOULDAn SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization.
  • MAYAn EHLO command MAY be issued by a client later in the session.
  • MUSTIf it is issued after the session begins and the EHLO command is acceptable to the SMTP server, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued.
  • MUSTIf the EHLO command is not acceptable to the SMTP server, 501, 500, 502, or 550 failure replies MUST be returned as appropriate.
  • MUSTSMTP server MUST stay in the same state after transmitting these replies that it was in before the EHLO was received.
  • MUSTThe SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5.
  • SHOULDIf this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name.
  • MAYAn SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client.
  • MUST NOTHowever, if the verification fails, the server MUST NOT refuse to accept a message on that basis.
  • SHOULDSMTP servers SHOULD process these normally (that is, not return a 503 code) even if no EHLO command has yet been received; clients SHOULD open a session with EHLO before sending these commands.
  • MUST NOTMAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is already open, i.e., it should be sent only if no mail transaction had been started in the session, or if the previous one successfully concluded with a successful DATA command, or if the previous one was aborted, e.g., with a RSET or new EHLO.
  • MUSTIf the transaction beginning command argument is not acceptable, a 501 failure reply MUST be returned and the SMTP server MUST stay in the same state.
  • MUSTreply MUST be returned and the SMTP server MUST stay in the same state.
  • MUSTThe last command in a session MUST be the QUIT command.
  • SHOULDThe QUIT command SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted.

4.1.5 Private-Use Commands

  • MAYAn extended SMTP server MAY list the feature names associated with these private commands in the response to the EHLO command.
  • MUSTCommands sent or accepted by SMTP systems that do not start with "X" MUST conform to the requirements of Section 2.2.2.

4.2 SMTP Replies

  • MUSTEvery command MUST generate exactly one reply.
  • SHOULDSince, in violation of this specification, the text is sometimes not sent, clients that do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character).
  • SHOULDAn SMTP server SHOULD send only the reply codes listed in this document.
  • SHOULDAn SMTP server SHOULD use the text shown in the examples whenever appropriate.
  • MUSTAn SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable.
  • SHOULDWhenever possible, a receiver- SMTP SHOULD test the first digit (severity indication) of the reply code.
  • MUST NOTThe list of codes that appears below MUST NOT be construed as permanent.
  • MUSTConsequently, a sender-SMTP MUST be prepared to handle codes not specified in this document and MUST do so by interpreting the first digit only.
  • MUST NOTIn the absence of extensions negotiated with the client, SMTP servers MUST NOT send reply codes whose first digits are other than 2, 3, 4,
  • SHOULDClients that receive such out-of-range codes SHOULD normally treat them as fatal errors and terminate the mail transaction.

4.2.1 Reply Code Severities and Theory

  • SHOULDEach reply in this category might have a different time value, but the SMTP client SHOULD try again.
  • SHOULD NOTThe SMTP client SHOULD NOT repeat the exact request (in the same sequence).
  • SHOULDAs noted above, servers SHOULD send the <SP> if subsequent text is not sent, but clients MUST be prepared for it to be omitted.
  • MUSTIn a multiline reply, the reply code on each of the lines MUST be the same.

4.2.4 Reply Code 502

  • SHOULDQuestions have been raised as to when reply code 502 (Command not implemented) SHOULD be returned in preference to other codes.
  • SHOULD502 SHOULD be used when the command is actually recognized by the SMTP server, but not implemented.
  • SHOULDIf the command is not recognized, code 500 SHOULD be returned.
  • MUST NOTExtended SMTP systems MUST NOT list capabilities in response to EHLO for which they will return 502 (or 500) replies.

4.2.5 Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>

  • MUST NOTWhen an SMTP server returns a temporary error status (4yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a subsequent attempt to deliver that message.
  • SHOULDThe user who originated the message SHOULD be able to interpret the return of a transient failure status (by mail message or otherwise) as a non-delivery indication, just as a permanent failure would be interpreted.
  • MUST NOTWhen an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver the message.
  • SHOULDAs with temporary error status codes, the SMTP client retains responsibility for the message, but SHOULD not again attempt delivery to the same server without user review of the message and response and appropriate intervention.

4.3.1 Sequencing Overview

  • MUSTUnless other arrangements are negotiated through service extensions, the sender MUST wait for this response before sending further commands.
  • SHOULDThe sender SHOULD wait for this greeting message before sending any commands.
  • SHOULDThese SHOULD be strictly adhered to.
  • MUSTsubstitute text in the replies, but the meanings and actions implied by the code numbers and by the specific command reply sequence MUST be preserved.

4.3.2 Command-Reply Sequences

  • SHOULDSince some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only.
  • MUST NOTUnless extended using the mechanisms described in Section 2.2, SMTP servers MUST NOT transmit reply codes to an SMTP client that are other than three digits or that do not start in a digit between 2 and 5 inclusive.
  • SHOULDHowever, if the target is more precise granularity in the codes, rather than codes for completely new purposes, the system described in RFC 3463 [25] SHOULD be used in preference to the invention of new codes.
  • SHOULDIn order to provide for future extensions, commands that are specified in this document as not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if arguments are supplied in the absence of EHLO- advertised extensions.

4.4 Trace Information

  • MUSTWhen an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in Section 4.1.1.4.
  • MUSTThis line MUST be structured as follows:
  • MUSTo The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.
  • MAYo The ID clause MAY contain an "@" as suggested in RFC 822, but this is not required.
  • MUSTo If the FOR clause appears, it MUST contain exactly one <path> entry, even when multiple RCPT commands have been given.
  • MUST NOTAn Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section.
  • MUSTSMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.
  • SHOULDSMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type.
  • SHOULDLocal time (with an offset) SHOULD be used rather than UT when feasible.
  • SHOULDIf it is desired to supply a time zone name, it SHOULD be included in a comment.
  • MUSTThis use of return-path is required; mail systems MUST support it.
  • MAYConsequently, any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message.
  • SHOULD NOTA message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field.
  • MUST NOTSMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path header fields are present.
  • MAYSMTP servers making final delivery MAY remove Return- path header fields before adding their own.
  • SHOULDFor this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
  • SHOULDSystems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent.
  • MUSTThe reverse-path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages.
  • SHOULDIn particular: o a gateway from SMTP -> elsewhere SHOULD insert a return-path header field, unless it is known that the "elsewhere" transport also uses Internet domain addresses and maintains the envelope sender address separately.
  • SHOULDo a gateway from elsewhere -> SMTP SHOULD delete any return-path header field present in the message, and either copy that information to the SMTP envelope or combine it with information present in the envelope of the other transport system to construct the reverse-path argument to the MAIL command in the SMTP envelope.
  • MUSTIn such cases, the response to the DATA command MUST be an OK reply.
  • MUSTHowever, the SMTP server MUST compose and send an "undeliverable mail" notification message to the originator of the message.
  • MUSTA single notification listing all of the failed recipients or separate notification messages MUST be sent for each failed recipient.
  • SHOULDFor economy of processing by the sender, the former SHOULD be used when possible.
  • MUSTAll notification messages about undeliverable mail MUST be sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands) and MUST use a null return path as discussed in Section 3.6.
  • MUST NOTStamp = From-domain By-domain Opt-info [CFWS] ";" FWS date-time ; where "date-time" is as defined in RFC 5322 [4] ; but the "obs-" forms, especially two-digit ; years, are prohibited in SMTP and MUST NOT be used.
  • SHOULD NOTSMTP servers SHOULD NOT use unregistered ; names.
  • SHOULD NOTSMTP servers ; SHOULD NOT use unregistered names.
  • SHOULD NOTSMTP servers SHOULD NOT ; use unregistered names.

4.5.1 Minimum Implementation

  • MUSTIn order to make SMTP workable, the following minimum implementation MUST be provided by all receivers.
  • MUSTThe following commands MUST be supported to conform to this specification:
  • MUSTAny system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name.
  • MUSTThe requirement to accept mail for postmaster implies that RCPT commands that specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:<Postmaster>" (with no domain specification), MUST be supported.
  • SHOULDHowever, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages that are not part of such attacks.

4.5.2 Transparency

  • MUSTIf such transformations are necessary, they MUST be reversible, especially if they are applied to mail being relayed.

4.5.3.1 Size Limits and Minimums

  • MUSTEvery implementation MUST be able to receive objects of at least these sizes.
  • SHOULDObjects larger than these sizes SHOULD be avoided when possible.
  • MAYClients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it.

4.5.3.1.7 Message Content

  • MUSTThe maximum total length of a message content (including any message header section as well as the message body) MUST BE at least 64K octets.
  • SHOULDSMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension of RFC 1870 [10], and SMTP client systems that will send large messages SHOULD utilize it when possible.

4.5.3.1.8 Recipients Buffer

  • MUSTThe minimum total number of recipients that MUST be buffered is 100 recipients.
  • MUST NOTThe general principle that relaying SMTP server MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message header fields suggests that messages SHOULD NOT be rejected based on the total number of recipients shown in header fields.
  • MUSTA server that imposes a limit on the number of recipients MUST behave in an orderly fashion, such as rejecting additional addresses over its limit rather than silently discarding addresses previously accepted.
  • SHOULDA client that needs to deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message.

4.5.3.1.10 Too Many Recipients Code

  • SHOULDClients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works.
  • MUSTIf an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above).
  • MAYIf the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5yz response code.

4.5.3.2 Timeouts

  • MUSTAn SMTP client MUST provide a timeout mechanism.
  • MUSTIt MUST use per- command timeouts rather than somehow trying to time the entire mail transaction.
  • SHOULDTimeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code.
  • SHOULDBased on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:

4.5.3.2.7 Server Timeout: 5 Minutes.

  • SHOULDAn SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.

4.5.4 Retry Strategies

  • MUSTAny queuing strategy MUST include timeouts on all activities on a per-command basis.
  • MUST NOTA queuing strategy MUST NOT send error messages in response to error messages under any circumstances.

4.5.4.1 Sending Strategy

  • MUSTIn a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender.
  • MUSTThe sender MUST delay retrying a particular destination after one attempt has failed.
  • SHOULDIn general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.
  • MAYIt MAY be appropriate to set a shorter maximum number of retries for non- delivery notifications and equivalent error messages than for standard messages.
  • MUSTThe parameters to the retry algorithm MUST be configurable.
  • SHOULDA client SHOULD keep a list of hosts it cannot reach and corresponding connection timeouts, rather than just retrying queued mail items.
  • SHOULDAt the same time, SMTP clients SHOULD use great care in caching negative responses from servers.
  • MUST NOTMore significantly, 5yz responses to the MAIL command MUST NOT be cached.
  • SHOULDWhen a mail message is to be delivered to multiple recipients, and the SMTP server to which a copy of the message is to be sent is the same for multiple recipients, then only one copy of the message SHOULD be transmitted.
  • SHOULDThat is, the SMTP client SHOULD use the command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA.
  • MAYHowever, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed.
  • SHOULDThis efficiency feature SHOULD be implemented.
  • MAYSimilarly, to achieve timely delivery, the SMTP client MAY support multiple concurrent outgoing mail transactions.

4.5.4.2 Receiving Strategy

  • SHOULDThe SMTP server SHOULD attempt to keep a pending listen on the SMTP port (specified by IANA as port 25) at all times.
  • MAYSome limit MAY be imposed, but servers that cannot handle more than one SMTP transaction at a time are not in conformance with the intent of this specification.

4.5.5 Messages with a Null Reverse-Path

  • SHOULDAll other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path.
  • SHOULD NOTIn particular, such systems SHOULD NOT reply to messages with a null reverse-path, and they SHOULD NOT add a non-null reverse-path, or change a null reverse-path to a non-null one, to such messages when forwarding.

5.1 Locating the Target Host

  • MUSTOnce an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name (RFC 1035 [2]).
  • SHOULD NOTDue to a history of problems, SMTP servers used for initial submission of messages SHOULD NOT make such inferences (Message Submission Servers [18] have somewhat more flexibility) and intermediate (relay) SMTP servers MUST NOT make them.
  • MUSTIf a non-existent domain error is returned, this situation MUST be reported as an error.
  • MUSTIf a temporary error is returned, the message MUST be queued and retried later (see Section 4.5.4.1).
  • MUSTIf MX records are present, but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error.
  • MUST NOTIf one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present.
  • MUSTIf MX records are present, but none of them are usable, this situation MUST be reported as an error.
  • MUSTWhen a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.
  • MUSTThat domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed.
  • MUSTTo provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds.
  • MAYHowever, there MAY also be a configurable limit on the number of alternate addresses that can be tried.
  • SHOULDIn any case, the SMTP client SHOULD try at least two addresses.
  • MUSTMX records contain a preference indication that MUST be used in sorting if more than one such record appears (see below).
  • MUSTIf there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.
  • MUSTIt is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and the SMTP sender MUST try them in the order presented.
  • MAYIf an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment.
  • MUSTIf it determines that it should relay the message without rewriting the address, it MUST sort the MX records to determine candidates for
  • MUSTThe relay host MUST then inspect the list for any of the names or addresses by which it might be known in mail transactions.
  • MUSTIf a matching record is found, all records at that preference level and higher-numbered ones MUST be discarded from consideration.
  • MUSTIf there are no records left at that point, it is an error condition, and the message MUST be returned as undeliverable.
  • SHOULDIf records do remain, they SHOULD be tried, best preference first, as described above.

6.1 Reliable Delivery and Replies by Email

  • MUST NOTIt MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage.
  • MUSTIf there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message.
  • MUSTThis notification MUST be sent using a null ("<>") reverse-path in the envelope.
  • MUSTThe recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line).
  • MUST NOTif this address is null ("<>"), the receiver-SMTP MUST NOT send a notification.
  • MUSTIf the address is an explicit source route, it MUST be stripped down to its final hop.
  • MUSTThe notification message MUST be sent using:
  • MUSTTo avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final <CRLF>.<CRLF> end of data indicator.

6.2 Unwanted, Unsolicited, and "Attack" Messages

  • SHOULDReliably determining that a return address is invalid can be a difficult and time-consuming process, especially if the putative sending system is not directly accessible or does not fully and accurately support VRFY and, even if a "drop messages with invalid return addresses" policy is adopted, it SHOULD be applied only when there is near-certainty that the return addresses are, in fact, invalid.
  • SHOULD NOTConversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered.

6.3 Loop Detection

  • SHOULDSMTP servers using this technique SHOULD use a large rejection threshold, normally at least 100 Received entries.
  • MUSTWhatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops.

6.4 Compensating for Irregularities

  • MAYThe following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting (message submission) protocol:
  • MUST NOTThese changes MUST NOT be applied by an SMTP server that provides an intermediate relay function.
  • SHOULDIn all cases, documentation SHOULD be provided in trace header fields and/or header field comments for actions performed by the servers.

7.2 "Blind" Copies

  • SHOULD NOTEspecially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the header section, either as part of trace header fields or as informational or private- extension header fields.
  • MAYSince this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command.
  • SHOULD NOTReceiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the header section of the message for delivery.
  • SHOULD NOTThe popular "Apparently-to" header field is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.

7.3 VRFY, EXPN, and Security

  • MUST NOTAs a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified.
  • MUSTIf a site disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification.
  • SHOULDImplementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.

7.5 Information Disclosure in Announcements

  • SHOULDSites are encouraged to evaluate the tradeoff with that issue in mind; implementations SHOULD minimally provide for making type and version information available in some way to other network hosts.

7.9 Scope of Operation of SMTP Servers

  • SHOULDSome sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering.
  • SHOULDWhen mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.

8 IANA Considerations

  • MUSTIn addition, if additional trace header fields (i.e., in addition to Return-path and Received) are ever created, those trace fields MUST be added to the IANA registry established by BCP 90 (RFC 3864) [11] for use with RFC 5322 [4].

10.2 Informative References

  • SHOULDHowever, if the envelope is not supplied, SMTP commands SHOULD be generated as follows:
  • SHOULDEach recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery).
  • SHOULDAny BCC header fields SHOULD then be removed from the header section.
  • SHOULDOnce this process is completed, the remaining header fields SHOULD be checked to verify that at least one TO, CC, or BCC header field remains.
  • SHOULDIf none do, then a BCC header field with no additional information SHOULD be inserted as specified in [4].
  • SHOULDThe return address in the MAIL command SHOULD, if possible, be derived from the system's identity for the submitting (local) user, and the "From:" header field otherwise.
  • SHOULDIf there is a system identity available, it SHOULD also be copied to the Sender header field if it is different from the address in the From header field.
  • SHOULD(Any Sender header field that was already there SHOULD be removed.) Systems may provide a way for submitters to override the envelope return address, but may want to restrict its use to privileged users.
  • MUST NOTA submission protocol based on Standard RFC 822 information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment.
  • SHOULD NOTThe first host in the <reverse-path> was historically the host sending the MAIL command; today, source routes SHOULD NOT appear in the reverse-path.
  • SHOULDHowever, in general, the <forward-path> SHOULD contain only a mailbox and domain name, relying on the domain name system to supply routing information if required.
  • MUSTThe use of source routes is deprecated (see Appendix F.2); while servers MUST be prepared to receive and handle them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT transmit them and this section is included in the current specification only to provide context.
  • MUSTFor relay purposes, the forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully- qualified domain names.
  • MUSTA server that is reached by means of a source route (e.g., its domain name appears first in the list in the forward-path) MUST remove its domain name from any forward-paths in which that domain name appears before forwarding the message and MAY remove all other source routing information.
  • SHOULD NOTThe reverse-path SHOULD NOT be updated by servers conforming to this specification.
  • MUST NOTConversely, SMTP servers MUST NOT derive final message routing information from message header fields.
  • MUSTIf, contrary to the recommendations here, a relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment to which it is relaying the mail rather than that of the transport environment from which the mail came (if they are different).
  • SHOULDThis is another reason why servers needing to return a message SHOULD ignore the source route entirely and simply use the domain as specified in the Mailbox.
  • SHOULDIn general, gateways between the Internet and other mail systems SHOULD attempt to preserve any layering semantics across the boundaries between the two mail systems involved.
  • SHOULD NOTA few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail.
  • SHOULD NOTIts use is deprecated; SMTP systems SHOULD NOT use it unless the server can authenticate the client.
  • MUSTSMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123.
  • MAYThey MAY, if necessary, ignore the routes and utilize only the target domain in the address.
  • MUSTIf they do utilize the source route, the message MUST be sent to the first domain shown in the address.
  • MUST NOTIn particular, a server MUST NOT guess at shortcuts within the source route.
  • SHOULD NOTClients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors.
  • SHOULDAs discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather than HELO when the server will accept the former.
  • MUSTServers MUST continue to accept and process HELO in order to support older clients.
  • MUST NOTIt is deprecated and MUST NOT be used.
  • MUSTWhen dates are inserted into messages by SMTP clients or servers (e.g., in trace header fields), four-digit years MUST BE used.
  • SHOULD NOTClients SHOULD NOT provide SEND, SAML, or SOML as services.
  • MAYServers MAY implement them.
  • MUSTIf they are implemented by servers, the implementation model specified in RFC 821 MUST be used and the command names MUST be published in the response to the EHLO command.

Every current email RFC