rfc2821.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:188k
- The last command in a session MUST be the QUIT command. The QUIT
- command cannot be used at any other time in a session, but 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
- As specified in section 2.2.2, commands starting in "X" may be used
- by bilateral agreement between the client (sending) and server
- (receiving) SMTP agents. An SMTP server that does not recognize such
- a command is expected to reply with "500 Command not recognized". An
- extended SMTP server MAY list the feature names associated with these
- private commands in the response to the EHLO command.
- Commands 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
- Replies to SMTP commands serve to ensure the synchronization of
- requests and actions in the process of mail transfer and to guarantee
- that the SMTP client always knows the state of the SMTP server.
- Every command MUST generate exactly one reply.
- Klensin Standards Track [Page 40]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- The details of the command-reply sequence are described in section
- 4.3.
- An SMTP reply consists of a three digit number (transmitted as three
- numeric characters) followed by some text unless specified otherwise
- in this document. The number is for use by automata to determine
- what state to enter next; the text is for the human user. The three
- digits contain enough encoded information that the SMTP client need
- not examine the text and may either discard it or pass it on to the
- user, as appropriate. Exceptions are as noted elsewhere in this
- document. In particular, the 220, 221, 251, 421, and 551 reply codes
- are associated with message text that must be parsed and interpreted
- by machines. In the general case, the text may be receiver dependent
- and context dependent, so there are likely to be varying texts for
- each reply code. A discussion of the theory of reply codes is given
- in section 4.2.1. Formally, a reply is defined to be the sequence: a
- three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
- reply (as defined in section 4.2.1). Since, in violation of this
- specification, the text is sometimes not sent, clients which do not
- receive it SHOULD be prepared to process the code alone (with or
- without a trailing space character). Only the EHLO, EXPN, and HELP
- commands are expected to result in multiline replies in normal
- circumstances, however, multiline replies are allowed for any
- command.
- In ABNF, server responses are:
- Greeting = "220 " Domain [ SP text ] CRLF
- Reply-line = Reply-code [ SP text ] CRLF
- where "Greeting" appears only in the 220 response that announces that
- the server is opening its part of the connection.
- An SMTP server SHOULD send only the reply codes listed in this
- document. An SMTP server SHOULD use the text shown in the examples
- whenever appropriate.
- An 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. The space (blank) following the reply
- code is considered part of the text. Whenever possible, a receiver-
- SMTP SHOULD test the first digit (severity indication) of the reply
- code.
- Klensin Standards Track [Page 41]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- The list of codes that appears below MUST NOT be construed as
- permanent. While the addition of new codes should be a rare and
- significant activity, with supplemental information in the textual
- part of the response being preferred, new codes may be added as the
- result of new Standards or Standards-track specifications.
- Consequently, a sender-SMTP MUST be prepared to handle codes not
- specified in this document and MUST do so by interpreting the first
- digit only.
- 4.2.1 Reply Code Severities and Theory
- The three digits of the reply each have a special significance. The
- first digit denotes whether the response is good, bad or incomplete.
- An unsophisticated SMTP client, or one that receives an unexpected
- code, will be able to determine its next action (proceed as planned,
- redo, retrench, etc.) by examining this first digit. An SMTP client
- that wants to know approximately what kind of error occurred (e.g.,
- mail system error, command syntax error) may examine the second
- digit. The third digit and any supplemental information that may be
- present is reserved for the finest gradation of information.
- There are five values for the first digit of the reply code:
- 1yz Positive Preliminary reply
- The command has been accepted, but the requested action is being
- held in abeyance, pending confirmation of the information in this
- reply. The SMTP client should send another command specifying
- whether to continue or abort the action. Note: unextended SMTP
- does not have any commands that allow this type of reply, and so
- does not have continue or abort commands.
- 2yz Positive Completion reply
- The requested action has been successfully completed. A new
- request may be initiated.
- 3yz Positive Intermediate reply
- The command has been accepted, but the requested action is being
- held in abeyance, pending receipt of further information. The
- SMTP client should send another command specifying this
- information. This reply is used in command sequence groups (i.e.,
- in DATA).
- 4yz Transient Negative Completion reply
- The command was not accepted, and the requested action did not
- occur. However, the error condition is temporary and the action
- may be requested again. The sender should return to the beginning
- of the command sequence (if any). It is difficult to assign a
- meaning to "transient" when two different sites (receiver- and
- Klensin Standards Track [Page 42]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- sender-SMTP agents) must agree on the interpretation. Each reply
- in this category might have a different time value, but the SMTP
- client is encouraged to try again. A rule of thumb to determine
- whether a reply fits into the 4yz or the 5yz category (see below)
- is that replies are 4yz if they can be successful if repeated
- without any change in command form or in properties of the sender
- or receiver (that is, the command is repeated identically and the
- receiver does not put up a new implementation.)
- 5yz Permanent Negative Completion reply
- The command was not accepted and the requested action did not
- occur. The SMTP client is discouraged from repeating the exact
- request (in the same sequence). Even some "permanent" error
- conditions can be corrected, so the human user may want to direct
- the SMTP client to reinitiate the command sequence by direct
- action at some point in the future (e.g., after the spelling has
- been changed, or the user has altered the account status).
- The second digit encodes responses in specific categories:
- x0z Syntax: These replies refer to syntax errors, syntactically
- correct commands that do not fit any functional category, and
- unimplemented or superfluous commands.
- x1z Information: These are replies to requests for information,
- such as status or help.
- x2z Connections: These are replies referring to the transmission
- channel.
- x3z Unspecified.
- x4z Unspecified.
- x5z Mail system: These replies indicate the status of the receiver
- mail system vis-a-vis the requested transfer or other mail system
- action.
- The third digit gives a finer gradation of meaning in each category
- specified by the second digit. The list of replies illustrates this.
- Each reply text is recommended rather than mandatory, and may even
- change according to the command with which it is associated. On the
- other hand, the reply codes must strictly follow the specifications
- in this section. Receiver implementations should not invent new
- codes for slightly different situations from the ones described here,
- but rather adapt codes already defined.
- Klensin Standards Track [Page 43]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- For example, a command such as NOOP, whose successful execution does
- not offer the SMTP client any new information, will return a 250
- reply. The reply is 502 when the command requests an unimplemented
- non-site-specific action. A refinement of that is the 504 reply for
- a command that is implemented, but that requests an unimplemented
- parameter.
- The reply text may be longer than a single line; in these cases the
- complete text must be marked so the SMTP client knows when it can
- stop reading the reply. This requires a special format to indicate a
- multiple line reply.
- The format for multiline replies requires that every line, except the
- last, begin with the reply code, followed immediately by a hyphen,
- "-" (also known as minus), followed by text. The last line will
- begin with the reply code, followed immediately by <SP>, optionally
- some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
- if subsequent text is not sent, but clients MUST be prepared for it
- to be omitted.
- For example:
- 123-First line
- 123-Second line
- 123-234 text beginning with numbers
- 123 The last line
- In many cases the SMTP client then simply needs to search for a line
- beginning with the reply code followed by <SP> or <CRLF> and ignore
- all preceding lines. In a few cases, there is important data for the
- client in the reply "text". The client will be able to identify
- these cases from the current context.
- 4.2.2 Reply Codes by Function Groups
- 500 Syntax error, command unrecognized
- (This may include errors such as command line too long)
- 501 Syntax error in parameters or arguments
- 502 Command not implemented (see section 4.2.4)
- 503 Bad sequence of commands
- 504 Command parameter not implemented
- 211 System status, or system help reply
- 214 Help message
- (Information on how to use the receiver or the meaning of a
- particular non-standard command; this reply is useful only
- to the human user)
- Klensin Standards Track [Page 44]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 220 <domain> Service ready
- 221 <domain> Service closing transmission channel
- 421 <domain> Service not available, closing transmission channel
- (This may be a reply to any command if the service knows it
- must shut down)
- 250 Requested mail action okay, completed
- 251 User not local; will forward to <forward-path>
- (See section 3.4)
- 252 Cannot VRFY user, but will accept message and attempt
- delivery
- (See section 3.5.3)
- 450 Requested mail action not taken: mailbox unavailable
- (e.g., mailbox busy)
- 550 Requested action not taken: mailbox unavailable
- (e.g., mailbox not found, no access, or command rejected
- for policy reasons)
- 451 Requested action aborted: error in processing
- 551 User not local; please try <forward-path>
- (See section 3.4)
- 452 Requested action not taken: insufficient system storage
- 552 Requested mail action aborted: exceeded storage allocation
- 553 Requested action not taken: mailbox name not allowed
- (e.g., mailbox syntax incorrect)
- 354 Start mail input; end with <CRLF>.<CRLF>
- 554 Transaction failed (Or, in the case of a connection-opening
- response, "No SMTP service here")
- 4.2.3 Reply Codes in Numeric Order
- 211 System status, or system help reply
- 214 Help message
- (Information on how to use the receiver or the meaning of a
- particular non-standard command; this reply is useful only
- to the human user)
- 220 <domain> Service ready
- 221 <domain> Service closing transmission channel
- 250 Requested mail action okay, completed
- 251 User not local; will forward to <forward-path>
- (See section 3.4)
- 252 Cannot VRFY user, but will accept message and attempt
- delivery
- (See section 3.5.3)
- 354 Start mail input; end with <CRLF>.<CRLF>
- Klensin Standards Track [Page 45]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 421 <domain> Service not available, closing transmission channel
- (This may be a reply to any command if the service knows it
- must shut down)
- 450 Requested mail action not taken: mailbox unavailable
- (e.g., mailbox busy)
- 451 Requested action aborted: local error in processing
- 452 Requested action not taken: insufficient system storage
- 500 Syntax error, command unrecognized
- (This may include errors such as command line too long)
- 501 Syntax error in parameters or arguments
- 502 Command not implemented (see section 4.2.4)
- 503 Bad sequence of commands
- 504 Command parameter not implemented
- 550 Requested action not taken: mailbox unavailable
- (e.g., mailbox not found, no access, or command rejected
- for policy reasons)
- 551 User not local; please try <forward-path>
- (See section 3.4)
- 552 Requested mail action aborted: exceeded storage allocation
- 553 Requested action not taken: mailbox name not allowed
- (e.g., mailbox syntax incorrect)
- 554 Transaction failed (Or, in the case of a connection-opening
- response, "No SMTP service here")
- 4.2.4 Reply Code 502
- Questions have been raised as to when reply code 502 (Command not
- implemented) SHOULD be returned in preference to other codes. 502
- SHOULD be used when the command is actually recognized by the SMTP
- server, but not implemented. If the command is not recognized, code
- 500 SHOULD be returned. Extended 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>
- When an SMTP server returns a positive completion status (2yz code)
- after the DATA command is completed with <CRLF>.<CRLF>, it accepts
- responsibility for:
- - delivering the message (if the recipient mailbox exists), or
- - if attempts to deliver the message fail due to transient
- conditions, retrying delivery some reasonable number of times at
- intervals as specified in section 4.5.4.
- Klensin Standards Track [Page 46]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- - if attempts to deliver the message fail due to permanent
- conditions, or if repeated attempts to deliver the message fail
- due to transient conditions, returning appropriate notification to
- the sender of the original message (using the address in the SMTP
- MAIL command).
- When 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 that message. The SMTP client
- retains responsibility for delivery of that message and may either
- return it to the user or requeue it for a subsequent attempt (see
- section 4.5.4.1).
- The 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. I.e., if the client SMTP successfully handles these
- conditions, the user will not receive such a reply.
- When an SMTP server returns a permanent error status (5yz) code after
- the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
- any subsequent attempt to deliver the message. As 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 and intervention of the message.
- 4.3 Sequencing of Commands and Replies
- 4.3.1 Sequencing Overview
- The communication between the sender and receiver is an alternating
- dialogue, controlled by the sender. As such, the sender issues a
- command and the receiver responds with a reply. Unless other
- arrangements are negotiated through service extensions, the sender
- MUST wait for this response before sending further commands.
- One important reply is the connection greeting. Normally, a receiver
- will send a 220 "Service ready" reply when the connection is
- completed. The sender SHOULD wait for this greeting message before
- sending any commands.
- Note: all the greeting-type replies have the official name (the
- fully-qualified primary domain name) of the server host as the first
- word following the reply code. Sometimes the host will have no
- meaningful name. See 4.1.3 for a discussion of alternatives in these
- situations.
- Klensin Standards Track [Page 47]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- For example,
- 220 ISIF.USC.EDU Service ready
- or
- 220 mail.foo.com SuperSMTP v 6.1.2 Service ready
- or
- 220 [10.0.0.1] Clueless host service ready
- The table below lists alternative success and failure replies for
- each command. These SHOULD be strictly adhered to: a receiver may
- substitute text in the replies, but the meaning and action implied by
- the code numbers and by the specific command reply sequence cannot be
- altered.
- 4.3.2 Command-Reply Sequences
- Each command is listed with its usual possible replies. The prefixes
- used before the possible replies are "I" for intermediate, "S" for
- success, and "E" for error. Since 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.
- Unless 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.
- These sequencing rules and, in principle, the codes themselves, can
- be extended or modified by SMTP extensions offered by the server and
- accepted (requested) by the client.
- In addition to the codes listed below, any SMTP command can return
- any of the following codes if the corresponding unusual circumstances
- are encountered:
- 500 For the "command line too long" case or if the command name was
- not recognized. Note that producing a "command not recognized"
- error in response to the required subset of these commands is a
- violation of this specification.
- 501 Syntax error in command or arguments. In 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.
- 421 Service shutting down and closing transmission channel
- Klensin Standards Track [Page 48]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- Specific sequences are:
- CONNECTION ESTABLISHMENT
- S: 220
- E: 554
- EHLO or HELO
- S: 250
- E: 504, 550
- MAIL
- S: 250
- E: 552, 451, 452, 550, 553, 503
- RCPT
- S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
- E: 550, 551, 552, 553, 450, 451, 452, 503, 550
- DATA
- I: 354 -> data -> S: 250
- E: 552, 554, 451, 452
- E: 451, 554, 503
- RSET
- S: 250
- VRFY
- S: 250, 251, 252
- E: 550, 551, 553, 502, 504
- EXPN
- S: 250, 252
- E: 550, 500, 502, 504
- HELP
- S: 211, 214
- E: 502, 504
- NOOP
- S: 250
- QUIT
- S: 221
- 4.4 Trace Information
- When 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.
- This line MUST be structured as follows:
- - The FROM field, 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.
- Klensin Standards Track [Page 49]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- - The ID field MAY contain an "@" as suggested in RFC 822, but this
- is not required.
- - The FOR field MAY contain a list of <path> entries when multiple
- RCPT commands have been given. This may raise some security
- issues and is usually not desirable; see section 7.2.
- An Internet mail program MUST NOT change a Received: line that was
- previously added to the message header. SMTP servers MUST prepend
- Received lines to messages; they MUST NOT change the order of
- existing lines or insert Received lines in any other location.
- As the Internet grows, comparability of Received fields is important
- for detecting problems, especially slow relays. SMTP servers that
- create Received fields SHOULD use explicit offsets in the dates
- (e.g., -0800), rather than time zone names of any type. Local time
- (with an offset) is preferred to UT when feasible. This formulation
- allows slightly more information about local circumstances to be
- specified. If UT is needed, the receiver need merely do some simple
- arithmetic to convert the values. Use of UT loses information about
- the time zone-location of the server. If it is desired to supply a
- time zone name, it SHOULD be included in a comment.
- When the delivery SMTP server makes the "final delivery" of a
- message, it inserts a return-path line at the beginning of the mail
- data. This use of return-path is required; mail systems MUST support
- it. The return-path line preserves the information in the <reverse-
- path> from the MAIL command. Here, final delivery means the message
- has left the SMTP environment. Normally, this would mean it had been
- delivered to the destination user or an associated mail drop, but in
- some cases it may be further processed and transmitted by another
- mail system.
- It is possible for the mailbox in the return path to be different
- from the actual sender's mailbox, for example, if error responses are
- to be delivered to a special error handling mailbox rather than to
- the message sender. When mailing lists are involved, this
- arrangement is common and useful as a means of directing errors to
- the list maintainer rather than the message originator.
- The text above implies that the final mail data will begin with a
- return path line, followed by one or more time stamp lines. These
- lines will be followed by the mail data headers and body [32].
- It is sometimes difficult for an SMTP server to determine whether or
- not it is making final delivery since forwarding or other operations
- may occur after the message is accepted for delivery. Consequently,
- Klensin Standards Track [Page 50]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 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.
- A message-originating SMTP system SHOULD NOT send a message that
- already contains a Return-path header. SMTP servers performing a
- relay function MUST NOT inspect the message data, and especially not
- to the extent needed to determine if Return-path headers are present.
- SMTP servers making final delivery MAY remove Return-path headers
- before adding their own.
- The primary purpose of the Return-path is to designate the address to
- which messages indicating non-delivery or other mail system failures
- are to be sent. For this to be unambiguous, exactly one return path
- SHOULD be present when the message is delivered. Systems 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.
- Historical note: Text in RFC 822 that appears to contradict the use
- of the Return-path header (or the envelope reverse path address from
- the MAIL command) as the destination for error messages is not
- applicable on the Internet. The reverse path address (as copied into
- the Return-path) MUST be used as the target of any mail containing
- delivery error messages.
- In particular:
- - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
- unless it is known that the "elsewhere" transport also uses
- Internet domain addresses and maintains the envelope sender
- address separately.
- - a gateway from elsewhere->SMTP SHOULD delete any return-path
- header 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.
- The server must give special treatment to cases in which the
- processing following the end of mail data indication is only
- partially successful. This could happen if, after accepting several
- recipients and the mail data, the SMTP server finds that the mail
- data could be successfully delivered to some, but not all, of the
- recipients. In such cases, the response to the DATA command MUST be
- an OK reply. However, the SMTP server MUST compose and send an
- "undeliverable mail" notification message to the originator of the
- message.
- Klensin Standards Track [Page 51]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- A single notification listing all of the failed recipients or
- separate notification messages MUST be sent for each failed
- recipient. For economy of processing by the sender, the former is
- preferred when possible. All undeliverable mail notification
- messages are sent using the MAIL command (even if they result from
- processing the obsolete SEND, SOML, or SAML commands) and use a null
- return path as discussed in section 3.7.
- The time stamp line and the return path line are formally defined as
- follows:
- Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
- Time-stamp-line = "Received:" FWS Stamp <CRLF>
- Stamp = From-domain By-domain Opt-info ";" FWS date-time
- ; where "date-time" is as defined in [32]
- ; but the "obs-" forms, especially two-digit
- ; years, are prohibited in SMTP and MUST NOT be used.
- From-domain = "FROM" FWS Extended-Domain CFWS
- By-domain = "BY" FWS Extended-Domain CFWS
- Extended-Domain = Domain /
- ( Domain FWS "(" TCP-info ")" ) /
- ( Address-literal FWS "(" TCP-info ")" )
- TCP-info = Address-literal / ( Domain FWS Address-literal )
- ; Information derived by server from TCP connection
- ; not client EHLO.
- Opt-info = [Via] [With] [ID] [For]
- Via = "VIA" FWS Link CFWS
- With = "WITH" FWS Protocol CFWS
- ID = "ID" FWS String / msg-id CFWS
- For = "FOR" FWS 1*( Path / Mailbox ) CFWS
- Link = "TCP" / Addtl-Link
- Addtl-Link = Atom
- ; Additional standard names for links are registered with the
- ; Internet Assigned Numbers Authority (IANA). "Via" is
- ; primarily of value with non-Internet transports. SMTP
- Klensin Standards Track [Page 52]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- ; servers SHOULD NOT use unregistered names.
- Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
- Attdl-Protocol = Atom
- ; Additional standard names for protocols are registered with the
- ; Internet Assigned Numbers Authority (IANA). SMTP servers
- ; SHOULD NOT use unregistered names.
- 4.5 Additional Implementation Issues
- 4.5.1 Minimum Implementation
- In order to make SMTP workable, the following minimum implementation
- is required for all receivers. The following commands MUST be
- supported to conform to this specification:
- EHLO
- HELO
- MAIL
- RCPT
- DATA
- RSET
- NOOP
- QUIT
- VRFY
- Any system that includes an SMTP server supporting mail relaying or
- delivery MUST support the reserved mailbox "postmaster" as a case-
- insensitive local name. This postmaster address is not strictly
- necessary if the server always returns 554 on connection opening (as
- described in section 3.1). The requirement to accept mail for
- postmaster implies that RCPT commands which 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.
- SMTP systems are expected to make every reasonable effort to accept
- mail directed to Postmaster from any other system on the Internet.
- In extreme cases --such as to contain a denial of service attack or
- other breach of security-- an SMTP server may block mail directed to
- Postmaster. However, such arrangements SHOULD be narrowly tailored
- so as to avoid blocking messages which are not part of such attacks.
- 4.5.2 Transparency
- Without some provision for data transparency, the character sequence
- "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
- In general, users are not aware of such "forbidden" sequences. To
- Klensin Standards Track [Page 53]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- allow all user composed text to be transmitted transparently, the
- following procedures are used:
- - Before sending a line of mail text, the SMTP client checks the
- first character of the line. If it is a period, one additional
- period is inserted at the beginning of the line.
- - When a line of mail text is received by the SMTP server, it checks
- the line. If the line is composed of a single period, it is
- treated as the end of mail indicator. If the first character is a
- period and there are other characters on the line, the first
- character is deleted.
- The mail data may contain any of the 128 ASCII characters. All
- characters are to be delivered to the recipient's mailbox, including
- spaces, vertical and horizontal tabs, and other control characters.
- If the transmission channel provides an 8-bit byte (octet) data
- stream, the 7-bit ASCII codes are transmitted right justified in the
- octets, with the high order bits cleared to zero. See 3.7 for
- special treatment of these conditions in SMTP systems serving a relay
- function.
- In some systems it may be necessary to transform the data as it is
- received and stored. This may be necessary for hosts that use a
- different character set than ASCII as their local character set, that
- store data in records rather than strings, or which use special
- character sequences as delimiters inside mailboxes. If such
- transformations are necessary, they MUST be reversible, especially if
- they are applied to mail being relayed.
- 4.5.3 Sizes and Timeouts
- 4.5.3.1 Size limits and minimums
- There are several objects that have required minimum/maximum sizes.
- Every implementation MUST be able to receive objects of at least
- these sizes. Objects larger than these sizes SHOULD be avoided when
- possible. However, some Internet mail constructs such as encoded
- X.400 addresses [16] will often require larger objects: clients MAY
- attempt to transmit these, but MUST be prepared for a server to
- reject them if they cannot be handled by it. To the maximum extent
- possible, implementation techniques which impose no limits on the
- length of these objects should be used.
- local-part
- The maximum total length of a user name or other local-part is 64
- characters.
- Klensin Standards Track [Page 54]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- domain
- The maximum total length of a domain name or number is 255
- characters.
- path
- The maximum total length of a reverse-path or forward-path is 256
- characters (including the punctuation and element separators).
- command line
- The maximum total length of a command line including the command
- word and the <CRLF> is 512 characters. SMTP extensions may be
- used to increase this limit.
- reply line
- The maximum total length of a reply line including the reply code
- and the <CRLF> is 512 characters. More information may be
- conveyed through multiple-line replies.
- text line
- The maximum total length of a text line including the <CRLF> is
- 1000 characters (not counting the leading dot duplicated for
- transparency). This number may be increased by the use of SMTP
- Service Extensions.
- message content
- The maximum total length of a message content (including any
- message headers as well as the message body) MUST BE at least 64K
- octets. Since the introduction of Internet standards for
- multimedia mail [12], message lengths on the Internet have grown
- dramatically, and message size restrictions should be avoided if
- at all possible. SMTP server systems that must impose
- restrictions SHOULD implement the "SIZE" service extension [18],
- and SMTP client systems that will send large messages SHOULD
- utilize it when possible.
- recipients buffer
- The minimum total number of recipients that must be buffered is
- 100 recipients. Rejection of messages (for excessive recipients)
- with fewer than 100 RCPT commands is a violation of this
- specification. The general principle that relaying SMTP servers
- MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
- tests on message headers suggests that rejecting a message based
- on the total number of recipients shown in header fields is to be
- discouraged. A server which imposes a limit on the number of
- recipients MUST behave in an orderly fashion, such as to reject
- additional addresses over its limit rather than silently
- discarding addresses previously accepted. A client that needs to
- Klensin Standards Track [Page 55]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 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.
- Errors due to exceeding these limits may be reported by using the
- reply codes. Some examples of reply codes are:
- 500 Line too long.
- or
- 501 Path too long
- or
- 452 Too many recipients (see below)
- or
- 552 Too much mail data.
- RFC 821 [30] incorrectly listed the error where an SMTP server
- exhausts its implementation limit on the number of RCPT commands
- ("too many recipients") as having reply code 552. The correct reply
- code for this condition is 452. Clients SHOULD treat a 552 code in
- this case as a temporary, rather than permanent, failure so the logic
- below works.
- When a conforming SMTP server encounters this condition, it has at
- least 100 successful RCPT commands in its recipients buffer. If the
- server is able to accept the message, then at least these 100
- addresses will be removed from the SMTP client's queue. When the
- client attempts retransmission of those addresses which received 452
- responses, at least 100 of these will be able to fit in the SMTP
- server's recipients buffer. Each retransmission attempt which is
- able to deliver anything will be able to dispose of at least 100 of
- these recipients.
- If 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). If the server has a configured site-policy limitation on the
- number of RCPT commands, it MAY instead use a 5XX response code.
- This would be most appropriate if the policy limitation was intended
- to apply if the total recipient count for a particular message body
- were enforced even if that message body was sent in multiple mail
- transactions.
- 4.5.3.2 Timeouts
- An SMTP client MUST provide a timeout mechanism. It MUST use per-
- command timeouts rather than somehow trying to time the entire mail
- transaction. Timeouts SHOULD be easily reconfigurable, preferably
- without recompiling the SMTP code. To implement this, a timer is set
- Klensin Standards Track [Page 56]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- for each SMTP command and for each buffer of the data transfer. The
- latter means that the overall timeout is inherently proportional to
- the size of the message.
- Based on extensive experience with busy mail-relay hosts, the minimum
- per-command timeout values SHOULD be as follows:
- Initial 220 Message: 5 minutes
- An SMTP client process needs to distinguish between a failed TCP
- connection and a delay in receiving the initial 220 greeting
- message. Many SMTP servers accept a TCP connection but delay
- delivery of the 220 message until their system load permits more
- mail to be processed.
- MAIL Command: 5 minutes
- RCPT Command: 5 minutes
- A longer timeout is required if processing of mailing lists and
- aliases is not deferred until after the message was accepted.
- DATA Initiation: 2 minutes
- This is while awaiting the "354 Start Input" reply to a DATA
- command.
- Data Block: 3 minutes
- This is while awaiting the completion of each TCP SEND call
- transmitting a chunk of data.
- DATA Termination: 10 minutes.
- This is while awaiting the "250 OK" reply. When the receiver gets
- the final period terminating the message data, it typically
- performs processing to deliver the message to a user mailbox. A
- spurious timeout at this point would be very wasteful and would
- typically result in delivery of multiple copies of the message,
- since it has been successfully sent and the server has accepted
- responsibility for delivery. See section 6.1 for additional
- discussion.
- An 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
- The common structure of a host SMTP implementation includes user
- mailboxes, one or more areas for queuing messages in transit, and one
- or more daemon processes for sending and receiving mail. The exact
- structure will vary depending on the needs of the users on the host
- Klensin Standards Track [Page 57]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- and the number and size of mailing lists supported by the host. We
- describe several optimizations that have proved helpful, particularly
- for mailers supporting high traffic levels.
- Any queuing strategy MUST include timeouts on all activities on a
- per-command basis. A queuing strategy MUST NOT send error messages
- in response to error messages under any circumstances.
- 4.5.4.1 Sending Strategy
- The general model for an SMTP client is one or more processes that
- periodically attempt to transmit outgoing mail. In 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. A mail queue entry will include not only the
- message itself but also the envelope information.
- The sender MUST delay retrying a particular destination after one
- attempt has failed. In 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.
- Retries continue until the message is transmitted or the sender gives
- up; the give-up time generally needs to be at least 4-5 days. The
- parameters to the retry algorithm MUST be configurable.
- A client SHOULD keep a list of hosts it cannot reach and
- corresponding connection timeouts, rather than just retrying queued
- mail items.
- Experience suggests that failures are typically transient (the target
- system or its connection has crashed), favoring a policy of two
- connection attempts in the first hour the message is in the queue,
- and then backing off to one every two or three hours.
- The SMTP client can shorten the queuing delay in cooperation with the
- SMTP server. For example, if mail is received from a particular
- address, it is likely that mail queued for that host can now be sent.
- Application of this principle may, in many cases, eliminate the
- requirement for an explicit "send queues now" function such as ETRN
- [9].
- The strategy may be further modified as a result of multiple
- addresses per host (see below) to optimize delivery time vs. resource
- usage.
- Klensin Standards Track [Page 58]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- An SMTP client may have a large queue of messages for each
- unavailable destination host. If all of these messages were retried
- in every retry cycle, there would be excessive Internet overhead and
- the sending system would be blocked for a long period. Note that an
- SMTP client can generally determine that a delivery attempt has
- failed only after a timeout of several minutes and even a one-minute
- timeout per connection will result in a very large delay if retries
- are repeated for dozens, or even hundreds, of queued messages to the
- same host.
- At the same time, SMTP clients SHOULD use great care in caching
- negative responses from servers. In an extreme case, if EHLO is
- issued multiple times during the same SMTP connection, different
- answers may be returned by the server. More significantly, 5yz
- responses to the MAIL command MUST NOT be cached.
- When 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. That is, the SMTP client SHOULD use the
- command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the
- sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there
- are very many addresses, a limit on the number of RCPT commands per
- MAIL command MAY be imposed. Implementation of this efficiency
- feature is strongly encouraged.
- Similarly, to achieve timely delivery, the SMTP client MAY support
- multiple concurrent outgoing mail transactions. However, some limit
- may be appropriate to protect the host from devoting all its
- resources to mail.
- 4.5.4.2 Receiving Strategy
- The SMTP server SHOULD attempt to keep a pending listen on the SMTP
- port at all times. This requires the support of multiple incoming
- TCP connections for SMTP. Some 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.
- As discussed above, when the SMTP server receives mail from a
- particular host address, it could activate its own SMTP queuing
- mechanisms to retry any mail pending for that host address.
- 4.5.5 Messages with a null reverse-path
- There are several types of notification messages which are required
- by existing and proposed standards to be sent with a null reverse
- path, namely non-delivery notifications as discussed in section 3.7,
- Klensin Standards Track [Page 59]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- other kinds of Delivery Status Notifications (DSNs) [24], and also
- Message Disposition Notifications (MDNs) [10]. All of these kinds of
- messages are notifications about a previous message, and they are
- sent to the reverse-path of the previous mail message. (If the
- delivery of such a notification message fails, that usually indicates
- a problem with the mail system of the host to which the notification
- message is addressed. For this reason, at some hosts the MTA is set
- up to forward such failed notification messages to someone who is
- able to fix problems with the mail system, e.g., via the postmaster
- alias.)
- All 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 with a valid, non-null reverse-path.
- Implementors of automated email processors should be careful to make
- sure that the various kinds of messages with null reverse-path are
- handled correctly, in particular such systems SHOULD NOT reply to
- messages with null reverse-path.
- 5. Address Resolution and Mail Handling
- Once an SMTP client lexically identifies a domain to which mail will
- be delivered for processing (as described in sections 3.6 and 3.7), a
- DNS lookup MUST be performed to resolve the domain name [22]. The
- names are expected to be fully-qualified domain names (FQDNs):
- mechanisms for inferring FQDNs from partial names or local aliases
- are outside of this specification and, due to a history of problems,
- are generally discouraged. The lookup first attempts to locate an MX
- record associated with the name. If a CNAME record is found instead,
- the resulting name is processed as if it were the initial name. If
- no MX records are found, but an A RR is found, the A RR is treated as
- if it was associated with an implicit MX RR, with a preference of 0,
- pointing to that host. If one or more MX RRs are found for a given
- name, SMTP systems MUST NOT utilize any A 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. If MX records
- are present, but none of them are usable, this situation MUST be
- reported as an error.
- When the lookup succeeds, the mapping can result in a list of
- alternative delivery addresses rather than a single address, because
- of multiple MX records, multihoming, or both. To 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. However, there MAY also be a configurable
- limit on the number of alternate addresses that can be tried. In any
- case, the SMTP client SHOULD try at least two addresses.
- Klensin Standards Track [Page 60]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- Two types of information is used to rank the host addresses: multiple
- MX records, and multihomed hosts.
- Multiple MX records contain a preference indication that MUST be used
- in sorting (see below). Lower numbers are more preferred than higher
- ones. If 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.
- The destination host (perhaps taken from the preferred MX record) may
- be multihomed, in which case the domain name resolver will return a
- list of alternative IP addresses. It is the responsibility of the
- domain name resolver interface to have ordered this list by
- decreasing preference if necessary, and SMTP MUST try them in the
- order presented.
- Although the capability to try multiple alternative addresses is
- required, specific installations may want to limit or disable the use
- of alternative addresses. The question of whether a sender should
- attempt retries using the different addresses of a multihomed host
- has been controversial. The main argument for using the multiple
- addresses is that it maximizes the probability of timely delivery,
- and indeed sometimes the probability of any delivery; the counter-
- argument is that it may result in unnecessary resource use. Note
- that resource use is also strongly determined by the sending strategy
- discussed in section 4.5.4.1.
- If 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. Of course, neither
- of the latter require that the list of MX records be examined
- further.
- If it determines that it should relay the message without rewriting
- the address, it MUST sort the MX records to determine candidates for
- delivery. The records are first ordered by preference, with the
- lowest-numbered records being most preferred. The relay host MUST
- then inspect the list for any of the names or addresses by which it
- might be known in mail transactions. If a matching record is found,
- all records at that preference level and higher-numbered ones MUST be
- discarded from consideration. If there are no records left at that
- point, it is an error condition, and the message MUST be returned as
- undeliverable. If records do remain, they SHOULD be tried, best
- preference first, as described above.
- Klensin Standards Track [Page 61]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 6. Problem Detection and Handling
- 6.1 Reliable Delivery and Replies by Email
- When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
- message in response to DATA), it is accepting responsibility for
- delivering or relaying the message. It must take this responsibility
- seriously. It MUST NOT lose the message for frivolous reasons, such
- as because the host later crashes or because of a predictable
- resource shortage.
- If there is a delivery failure after acceptance of a message, the
- receiver-SMTP MUST formulate and mail a notification message. This
- notification MUST be sent using a null ("<>") reverse path in the
- envelope. The recipient of this notification MUST be the address
- from the envelope return path (or the Return-Path: line). However,
- if this address is null ("<>"), the receiver-SMTP MUST NOT send a
- notification. Obviously, nothing in this section can or should
- prohibit local decisions (i.e., as part of the same system
- environment as the receiver-SMTP) to log or otherwise transmit
- information about null address events locally if that is desired. If
- the address is an explicit source route, it MUST be stripped down to
- its final hop.
- For example, suppose that an error notification must be sent for a
- message that arrived with:
- MAIL FROM:<@a,@b:user@d>
- The notification message MUST be sent using:
- RCPT TO:<user@d>
- Some delivery failures after the message is accepted by SMTP will be
- unavoidable. For example, it may be impossible for the receiving
- SMTP server to validate all the delivery addresses in RCPT command(s)
- due to a "soft" domain system error, because the target is a mailing
- list (see earlier discussion of RCPT), or because the server is
- acting as a relay and has no immediate access to the delivering
- system.
- To 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. See RFC 1047 [28] for
- a discussion of this problem.
- Klensin Standards Track [Page 62]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 6.2 Loop Detection
- Simple counting of the number of "Received:" headers in a message has
- proven to be an effective, although rarely optimal, method of
- detecting loops in mail systems. SMTP servers using this technique
- SHOULD use a large rejection threshold, normally at least 100
- Received entries. Whatever mechanisms are used, servers MUST contain
- provisions for detecting and stopping trivial loops.
- 6.3 Compensating for Irregularities
- Unfortunately, variations, creative interpretations, and outright
- violations of Internet mail protocols do occur; some would suggest
- that they occur quite frequently. The debate as to whether a well-
- behaved SMTP receiver or relay should reject a malformed message,
- attempt to pass it on unchanged, or attempt to repair it to increase
- the odds of successful delivery (or subsequent reply) began almost
- with the dawn of structured network mail and shows no signs of
- abating. Advocates of rejection claim that attempted repairs are
- rarely completely adequate and that rejection of bad messages is the
- only way to get the offending software repaired. Advocates of
- "repair" or "deliver no matter what" argue that users prefer that
- mail go through it if at all possible and that there are significant
- market pressures in that direction. In practice, these market
- pressures may be more important to particular vendors than strict
- conformance to the standards, regardless of the preference of the
- actual developers.
- The problems associated with ill-formed messages were exacerbated by
- the introduction of the split-UA mail reading protocols [3, 26, 5,
- 21]. These protocols have encouraged the use of SMTP as a posting
- protocol, and SMTP servers as relay systems for these client hosts
- (which are often only intermittently connected to the Internet).
- Historically, many of those client machines lacked some of the
- mechanisms and information assumed by SMTP (and indeed, by the mail
- format protocol [7]). Some could not keep adequate track of time;
- others had no concept of time zones; still others could not identify
- their own names or addresses; and, of course, none could satisfy the
- assumptions that underlay RFC 822's conception of authenticated
- addresses.
- In response to these weak SMTP clients, many SMTP systems now
- complete messages that are delivered to them in incomplete or
- incorrect form. This strategy is generally considered appropriate
- when the server can identify or authenticate the client, and there
- are prior agreements between them. By contrast, there is at best
- great concern about fixes applied by a relay or delivery SMTP server
- that has little or no knowledge of the user or client machine.
- Klensin Standards Track [Page 63]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- The 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 protocol:
- - Addition of a message-id field when none appears
- - Addition of a date, time or time zone when none appears
- - Correction of addresses to proper FQDN format
- The less information the server has about the client, the less likely
- these changes are to be correct and the more caution and conservatism
- should be applied when considering whether or not to perform fixes
- and how. These changes MUST NOT be applied by an SMTP server that
- provides an intermediate relay function.
- In all cases, properly-operating clients supplying correct
- information are preferred to corrections by the SMTP server. In all
- cases, documentation of actions performed by the servers (in trace
- fields and/or header comments) is strongly encouraged.
- 7. Security Considerations
- 7.1 Mail Security and Spoofing
- SMTP mail is inherently insecure in that it is feasible for even
- fairly casual users to negotiate directly with receiving and relaying
- SMTP servers and create messages that will trick a naive recipient
- into believing that they came from somewhere else. Constructing such
- a message so that the "spoofed" behavior cannot be detected by an
- expert is somewhat more difficult, but not sufficiently so as to be a
- deterrent to someone who is determined and knowledgeable.
- Consequently, as knowledge of Internet mail increases, so does the
- knowledge that SMTP mail inherently cannot be authenticated, or
- integrity checks provided, at the transport level. Real mail
- security lies only in end-to-end methods involving the message
- bodies, such as those which use digital signatures (see [14] and,
- e.g., PGP [4] or S/MIME [31]).
- Various protocol extensions and configuration options that provide
- authentication at the transport level (e.g., from an SMTP client to
- an SMTP server) improve somewhat on the traditional situation
- described above. However, unless they are accompanied by careful
- handoffs of responsibility in a carefully-designed trust environment,
- they remain inherently weaker than end-to-end mechanisms which use
- digitally signed messages rather than depending on the integrity of
- the transport system.
- Klensin Standards Track [Page 64]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- Efforts to make it more difficult for users to set envelope return
- path and header "From" fields to point to valid addresses other than
- their own are largely misguided: they frustrate legitimate
- applications in which mail is sent by one user on behalf of another
- or in which error (or normal) replies should be directed to a special
- address. (Systems that provide convenient ways for users to alter
- these fields on a per-message basis should attempt to establish a
- primary and permanent mailbox address for the user so that Sender
- fields within the message data can be generated sensibly.)
- This specification does not further address the authentication issues
- associated with SMTP other than to advocate that useful functionality
- not be disabled in the hope of providing some small margin of
- protection against an ignorant user who is trying to fake mail.
- 7.2 "Blind" Copies
- Addresses that do not appear in the message headers may appear in the
- RCPT commands to an SMTP server for a number of reasons. The two
- most common involve the use of a mailing address as a "list exploder"
- (a single address that resolves into multiple addresses) and the
- appearance of "blind copies". Especially 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 headers, either as
- part of trace headers or as informational or private-extension
- headers. Since 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.
- There is no inherent relationship between either "reverse" (from
- MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
- transaction ("envelope") and the addresses in the headers. Receiving
- systems SHOULD NOT attempt to deduce such relationships and use them
- to alter the headers of the message for delivery. The popular
- "Apparently-to" header 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
- As discussed in section 3.5, individual sites may want to disable
- either or both of VRFY or EXPN for security reasons. As a corollary
- to the above, implementations that permit this MUST NOT appear to
- have verified addresses that are not, in fact, verified. If a site
- Klensin Standards Track [Page 65]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 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.
- Returning a 250 reply code with the address listed in the VRFY
- command after having checked it only for syntax violates this rule.
- Of course, an implementation that "supports" VRFY by always returning
- 550 whether or not the address is valid is equally not in
- conformance.
- Within the last few years, the contents of mailing lists have become
- popular as an address information source for so-called "spammers."
- The use of EXPN to "harvest" addresses has increased as list
- administrators have installed protections against inappropriate uses
- of the lists themselves. Implementations SHOULD still provide
- support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
- As authentication mechanisms are introduced into SMTP, some sites may
- choose to make EXPN available only to authenticated requestors.
- 7.4 Information Disclosure in Announcements
- There has been an ongoing debate about the tradeoffs between the
- debugging advantages of announcing server type and version (and,
- sometimes, even server domain name) in the greeting response or in
- response to the HELP command and the disadvantages of exposing
- information that might be useful in a potential hostile attack. The
- utility of the debugging information is beyond doubt. Those who
- argue for making it available point out that it is far better to
- actually secure an SMTP server rather than hope that trying to
- conceal known vulnerabilities by hiding the server's precise identity
- will provide more protection. Sites are encouraged to evaluate the
- tradeoff with that issue in mind; implementations are strongly
- encouraged to minimally provide for making type and version
- information available in some way to other network hosts.
- 7.5 Information Disclosure in Trace Fields
- In some circumstances, such as when mail originates from within a LAN
- whose hosts are not directly on the public Internet, trace
- ("Received") fields produced in conformance with this specification
- may disclose host names and similar information that would not
- normally be available. This ordinarily does not pose a problem, but
- sites with special concerns about name disclosure should be aware of
- it. Also, the optional FOR clause should be supplied with caution or
- not at all when multiple recipients are involved lest it
- inadvertently disclose the identities of "blind copy" recipients to
- others.
- Klensin Standards Track [Page 66]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- 7.6 Information Disclosure in Message Forwarding
- As discussed in section 3.4, use of the 251 or 551 reply codes to
- identify the replacement address associated with a mailbox may
- inadvertently disclose sensitive information. Sites that are
- concerned about those issues should ensure that they select and
- configure servers appropriately.
- 7.7 Scope of Operation of SMTP Servers
- It is a well-established principle that an SMTP server may refuse to
- accept mail for any operational or technical reason that makes sense
- to the site providing the server. However, cooperation among sites
- and installations makes the Internet possible. If sites take
- excessive advantage of the right to reject traffic, the ubiquity of
- email availability (one of the strengths of the Internet) will be
- threatened; considerable care should be taken and balance maintained
- if a site decides to be selective about the traffic it will accept
- and process.
- In recent years, use of the relay function through arbitrary sites
- has been used as part of hostile efforts to hide the actual origins
- of mail. Some 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. When mail
- is rejected for these or other policy reasons, a 550 code SHOULD be
- used in response to EHLO, MAIL, or RCPT as appropriate.
- 8. IANA Considerations
- IANA will maintain three registries in support of this specification.
- The first consists of SMTP service extensions with the associated
- keywords, and, as needed, parameters and verbs. As specified in
- section 2.2.2, no entry may be made in this registry that starts in
- an "X". Entries may be made only for service extensions (and
- associated keywords, parameters, or verbs) that are defined in
- standards-track or experimental RFCs specifically approved by the
- IESG for this purpose.
- The second registry consists of "tags" that identify forms of domain
- literals other than those for IPv4 addresses (specified in RFC 821
- and in this document) and IPv6 addresses (specified in this
- document). Additional literal types require standardization before
- being used; none are anticipated at this time.
- The third, established by RFC 821 and renewed by this specification,
- is a registry of link and protocol identifiers to be used with the
- "via" and "with" subclauses of the time stamp ("Received: header")
- Klensin Standards Track [Page 67]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- described in section 4.4. Link and protocol identifiers in addition
- to those specified in this document may be registered only by
- standardization or by way of an RFC-documented, IESG-approved,
- Experimental protocol extension.
- 9. References
- [1] American National Standards Institute (formerly United States of
- America Standards Institute), X3.4, 1968, "USA Code for
- Information Interchange". ANSI X3.4-1968 has been replaced by
- newer versions with slight modifications, but the 1968 version
- remains definitive for the Internet.
- [2] Braden, R., "Requirements for Internet hosts - application and
- support", STD 3, RFC 1123, October 1989.
- [3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
- Reynolds, "Post Office Protocol - version 2", RFC 937, February
- 1985.
- [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
- Message Format", RFC 2440, November 1998.
- [5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
- 1176, August 1990.
- [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
- 2060, December 1996.
- [7] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", RFC 822, August 1982.
- [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
- [9] De Winter, J., "SMTP Service Extension for Remote Message Queue
- Starting", RFC 1985, August 1996.
- [10] Fajman, R., "An Extensible Message Format for Message
- Disposition Notifications", RFC 2298, March 1998.
- [11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
- RFC 2979, October 2000.
- [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC 2045, December 1996.
- Klensin Standards Track [Page 68]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
- 2920, September 2000.
- [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
- Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
- RFC 1847, October 1995.
- [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
- December 1998.
- [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
- January 1998.
- [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
- [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
- Message Size Declaration", STD 10, RFC 1870, November 1995.
- [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
- "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
- [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
- "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
- 1994.
- [21] Lambert, M., "PCMAIL: A distributed mail system for personal
- computers", RFC 1056, July 1988.
- [22] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
- Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
- [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
- Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
- December 1996.
- [24] Moore, K., "SMTP Service Extension for Delivery Status
- Notifications", RFC 1891, January 1996.
- [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
- Delivery Status Notifications", RFC 1894, January 1996.
- [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
- 53, RFC 1939, May 1996.
- Klensin Standards Track [Page 69]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- [27] Partridge, C., "Mail routing and the domain system", RFC 974,
- January 1986.
- [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
- 1988.
- [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
- Program Protocol Specification", STD 7, RFC 793, September 1981.
- [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
- 1982.
- [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
- 2633, June 1999.
- [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
- 2001.
- [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
- Large and Binary MIME Messages", RFC 1830, August 1995.
- [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
- January 1996.
- 10. Editor's Address
- John C. Klensin
- AT&T Laboratories
- 99 Bedford St
- Boston, MA 02111 USA
- Phone: 617-574-3076
- EMail: klensin@research.att.com
- 11. Acknowledgments
- Many people worked long and hard on the many iterations of this
- document. There was wide-ranging debate in the IETF DRUMS Working
- Group, both on its mailing list and in face to face discussions,
- about many technical issues and the role of a revised standard for
- Internet mail transport, and many contributors helped form the
- wording in this specification. The hundreds of participants in the
- many discussions since RFC 821 was produced are too numerous to
- mention, but they all helped this document become what it is.
- Klensin Standards Track [Page 70]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- APPENDICES
- A. TCP Transport Service
- The TCP connection supports the transmission of 8-bit bytes. The
- SMTP data is 7-bit ASCII characters. Each character is transmitted
- as an 8-bit byte with the high-order bit cleared to zero. Service
- extensions may modify this rule to permit transmission of full 8-bit
- data bytes as part of the message body, but not in SMTP commands or
- responses.
- B. Generating SMTP Commands from RFC 822 Headers
- Some systems use RFC 822 headers (only) in a mail submission
- protocol, or otherwise generate SMTP commands from RFC 822 headers
- when such a message is handed to an MTA from a UA. While the MTA-UA
- protocol is a private matter, not covered by any Internet Standard,
- there are problems with this approach. For example, there have been
- repeated problems with proper handling of "bcc" copies and
- redistribution lists when information that conceptually belongs to a
- mail envelopes is not separated early in processing from header
- information (and kept separate).
- It is recommended that the UA provide its initial ("submission
- client") MTA with an envelope separate from the message itself.
- However, if the envelope is not supplied, SMTP commands SHOULD be
- generated as follows:
- 1. Each 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). This includes any
- addresses listed in a RFC 822 "group". Any BCC fields SHOULD then
- be removed from the headers. Once this process is completed, the
- remaining headers SHOULD be checked to verify that at least one
- To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
- with no additional information SHOULD be inserted as specified in
- [32].
- 2. The 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. If 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. (Any Sender 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. This will not prevent mail forgery, but may
- lessen its incidence; see section 7.1.
- Klensin Standards Track [Page 71]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- When an MTA is being used in this way, it bears responsibility for
- ensuring that the message being transmitted is valid. The mechanisms
- for checking that validity, and for handling (or returning) messages
- that are not valid at the time of arrival, are part of the MUA-MTA
- interface and not covered by this specification.
- A 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. Additional information to construct
- an envelope must come from some source in the other environment,
- whether supplemental headers or the foreign system's envelope.
- Attempts to gateway messages using only their header "to" and "cc"
- fields have repeatedly caused mail loops and other behavior adverse
- to the proper functioning of the Internet mail environment. These
- problems have been especially common when the message originates from
- an Internet mailing list and is distributed into the foreign
- environment using envelope information. When these messages are then
- processed by a header-only remailer, loops back to the Internet
- environment (and the mailing list) are almost inevitable.
- C. Source Routes
- Historically, the <reverse-path> was a reverse source routing list of
- hosts and a source mailbox. The first host in the <reverse-path>
- SHOULD be the host sending the MAIL command. Similarly, the
- <forward-path> may be a source routing lists of hosts and a
- destination mailbox. However, 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. The use of source
- routes is deprecated; while servers MUST be prepared to receive and
- handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
- transmit them and this section was included only to provide context.
- For 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. This form is used to emphasize the
- distinction between an address and a route. The mailbox is an
- absolute address, and the route is information about how to get
- there. The two concepts should not be confused.
- If source routes are used, RFC 821 and the text below should be
- consulted for the mechanisms for constructing and updating the
- forward- and reverse-paths.
- Klensin Standards Track [Page 72]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- The SMTP server transforms the command arguments by moving its own
- identifier (its domain name or that of any domain for which it is
- acting as a mail exchanger), if it appears, from the forward-path to
- the beginning of the reverse-path.
- Notice that the forward-path and reverse-path appear in the SMTP
- commands and replies, but not necessarily in the message. That is,
- there is no need for these paths and especially this syntax to appear
- in the "To:" , "From:", "CC:", etc. fields of the message header.
- Conversely, SMTP servers MUST NOT derive final message delivery
- information from message header fields.
- When the list of hosts is present, it is a "reverse" source route and
- indicates that the mail was relayed through each host on the list
- (the first host in the list was the most recent relay). This list is
- used as a source route to return non-delivery notices to the sender.
- As each 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).
- D. Scenarios
- This section presents complete scenarios of several types of SMTP
- sessions. In the examples, "C:" indicates what is said by the SMTP
- client, and "S:" indicates what is said by the SMTP server.
- D.1 A Typical SMTP Transaction Scenario
- This SMTP example shows mail sent by Smith at host bar.com, to Jones,
- Green, and Brown at host foo.com. Here we assume that host bar.com
- contacts host foo.com directly. The mail is accepted for Jones and
- Brown. Green does not have a mailbox at host foo.com.
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- S: 250 HELP
- C: MAIL FROM:<Smith@bar.com>
- S: 250 OK
- C: RCPT TO:<Jones@foo.com>
- S: 250 OK
- C: RCPT TO:<Green@foo.com>
- S: 550 No such user here
- C: RCPT TO:<Brown@foo.com>
- Klensin Standards Track [Page 73]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Blah blah blah...
- C: ...etc. etc. etc.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
- D.2 Aborted SMTP Transaction Scenario
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- S: 250 HELP
- C: MAIL FROM:<Smith@bar.com>
- S: 250 OK
- C: RCPT TO:<Jones@foo.com>
- S: 250 OK
- C: RCPT TO:<Green@foo.com>
- S: 550 No such user here
- C: RSET
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
- D.3 Relayed Mail Scenario
- Step 1 -- Source Host to Relay Host
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- S: 250 HELP
- C: MAIL FROM:<JQP@bar.com>
- S: 250 OK
- C: RCPT TO:<@foo.com:Jones@XYZ.COM>
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Date: Thu, 21 May 1998 05:33:29 -0700
- Klensin Standards Track [Page 74]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- C: From: John Q. Public <JQP@bar.com>
- C: Subject: The Next Meeting of the Board
- C: To: Jones@xyz.com
- C:
- C: Bill:
- C: The next meeting of the board of directors will be
- C: on Tuesday.
- C: John.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
- Step 2 -- Relay Host to Destination Host
- S: 220 xyz.com Simple Mail Transfer Service Ready
- C: EHLO foo.com
- S: 250 xyz.com is on the air
- C: MAIL FROM:<@foo.com:JQP@bar.com>
- S: 250 OK
- C: RCPT TO:<Jones@XYZ.COM>
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Received: from bar.com by foo.com ; Thu, 21 May 1998
- C: 05:33:29 -0700
- C: Date: Thu, 21 May 1998 05:33:22 -0700
- C: From: John Q. Public <JQP@bar.com>
- C: Subject: The Next Meeting of the Board
- C: To: Jones@xyz.com
- C:
- C: Bill:
- C: The next meeting of the board of directors will be
- C: on Tuesday.
- C: John.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
- D.4 Verifying and Sending Scenario
- S: 220 foo.com Simple Mail Transfer Service Ready
- C: EHLO bar.com
- S: 250-foo.com greets bar.com
- S: 250-8BITMIME
- S: 250-SIZE
- S: 250-DSN
- Klensin Standards Track [Page 75]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- S: 250-VRFY
- S: 250 HELP
- C: VRFY Crispin
- S: 250 Mark Crispin <Admin.MRC@foo.com>
- C: SEND FROM:<EAK@bar.com>
- S: 250 OK
- C: RCPT TO:<Admin.MRC@foo.com>
- S: 250 OK
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: Blah blah blah...
- C: ...etc. etc. etc.
- C: .
- S: 250 OK
- C: QUIT
- S: 221 foo.com Service closing transmission channel
- E. Other Gateway Issues
- In 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. Gateway-
- translation approaches that attempt to take shortcuts by mapping,
- (such as envelope information from one system to the message headers
- or body of another) have generally proven to be inadequate in
- important ways. Systems translating between environments that do not
- support both envelopes and headers and Internet mail must be written
- with the understanding that some information loss is almost
- inevitable.
- F. Deprecated Features of RFC 821
- A few features of RFC 821 have proven to be problematic and SHOULD
- NOT be used in Internet mail.
- F.1 TURN
- This command, described in RFC 821, raises important security issues
- since, in the absence of strong authentication of the host requesting
- that the client and server switch roles, it can easily be used to
- divert mail from its correct destination. Its use is deprecated;
- SMTP systems SHOULD NOT use it unless the server can authenticate the
- client.
- Klensin Standards Track [Page 76]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- F.2 Source Routing
- RFC 821 utilized the concept of explicit source routing to get mail
- from one host to another via a series of relays. The requirement to
- utilize source routes in regular mail traffic was eliminated by the
- introduction of the domain name system "MX" record and the last
- significant justification for them was eliminated by the
- introduction, in RFC 1123, of a clear requirement that addresses
- following an "@" must all be fully-qualified domain names.
- Consequently, the only remaining justifications for the use of source
- routes are support for very old SMTP clients or MUAs and in mail
- system debugging. They can, however, still be useful in the latter
- circumstance and for routing mail around serious, but temporary,
- problems such as problems with the relevant DNS records.
- SMTP servers MUST continue to accept source route syntax as specified
- in the main body of this document and in RFC 1123. They MAY, if
- necessary, ignore the routes and utilize only the target domain in
- the address. If they do utilize the source route, the message MUST
- be sent to the first domain shown in the address. In particular, a
- server MUST NOT guess at shortcuts within the source route.
- Clients SHOULD NOT utilize explicit source routing except under
- unusual circumstances, such as debugging or potentially relaying
- around firewall or mail system configuration errors.
- F.3 HELO
- As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
- HELO when the server will accept the former. Servers must continue
- to accept and process HELO in order to support older clients.
- F.4 #-literals
- RFC 821 provided for specifying an Internet address as a decimal
- integer host number prefixed by a pound sign, "#". In practice, that
- form has been obsolete since the introduction of TCP/IP. It is
- deprecated and MUST NOT be used.
- F.5 Dates and Years
- When dates are inserted into messages by SMTP clients or servers
- (e.g., in trace fields), four-digit years MUST BE used. Two-digit
- years are deprecated; three-digit years were never permitted in the
- Internet mail system.
- Klensin Standards Track [Page 77]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- F.6 Sending versus Mailing
- In addition to specifying a mechanism for delivering messages to
- user's mailboxes, RFC 821 provided additional, optional, commands to
- deliver messages directly to the user's terminal screen. These
- commands (SEND, SAML, SOML) were rarely implemented, and changes in
- workstation technology and the introduction of other protocols may
- have rendered them obsolete even where they are implemented.
- Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
- MAY implement them. If 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.
- Klensin Standards Track [Page 78]
- RFC 2821 Simple Mail Transfer Protocol April 2001
- Full Copyright Statement
- Copyright (C) The Internet Society (2001). All Rights Reserved.
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- Acknowledgement
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
- Klensin Standards Track [Page 79]