The envelope contains any number of envelope recipient addresses and at most one return path. The envelope is empty when it contains no addresses.
When the client connects to the server, the envelope is empty.
For example, after the following responses and requests, the envelope contains the return path email@example.com, the recipient address God@heaven.af.mil, and the recipient address firstname.lastname@example.org:
220 heaven.af.mil ESMTP MAIL FROM:<email@example.com> 250 ok RCPT TO:<God@heaven.af.mil> 250 ok RCPT TO:<firstname.lastname@example.org> 550 wrong address, buddy RCPT TO:<email@example.com> 250 ok
A MAIL request has a parameter containing
If the server rejects the MAIL request, the client cannot make any assumptions about the envelope. The envelope could be empty, for example, or it could be the same as it was before the MAIL request. Klensin requires that the envelope be the same, but this is not always true in practice.
Beware that many servers incorrectly reject MAIL requests when the envelope is nonempty. For example, sendmail responds with code 503.
RFC 821 does not permit extra information at the end of a MAIL request. In practice, however, some clients (e.g., at least one version of the Netscape SDK) put extra spaces at the end of MAIL. Furthermore, extensions such as 8BITMIME make use of the extra information.
RFC 821 lets the server use codes 421, 451, 452, 500, 501, or 552 to reject a MAIL request; RFC 1869 also permits code 555. Typical examples:
MAIL FROM:<firstname.lastname@example.org> blah blah blah blah blah 500 line too long MAIL FROM:<email@example.com> garbage 555 garbage not permitted MAIL FROM:>firstname.lastname@example.org< 501 malformatted address MAIL FROM:<email@example.com> 451 timeout
A RCPT request has a parameter containing
RCPT TO:<God@heaven.af.mil> 250 no problem RCPT TO:<firstname.lastname@example.org> 251 okay; will forward your mail to <email@example.com>Today's clients discard the text, whether the code is 250 or 251, so this is not a good way to provide forwarding information. Code 251 is deprecated by Klensin. I use a simple "250 ok" in all cases.
If the server rejects the RCPT request, the envelope is unchanged.
MAIL must be used before RCPT. Servers reject RCPT requests (using code 503) when the envelope is empty.
It is a violation of RFC 821 for the client to send RCPT if the envelope already contains 100 recipient addresses. It is also a violation of RFC 821 for the server to limit its envelope to fewer than 100 recipient addresses. Nevertheless, some servers set much lower limits.
RFC 821 lets the server use codes 421, 450, 451, 452, 500, 501, 503, 550, 551, 552, or 553 to reject a RCPT request; RFC 1869 also permits code 555. Typical examples (out of context):
450 mailbox busy, try again later 452 recipient out of disk space, try again later 452 too many recipients 503 need MAIL before RCPT 550 no such recipient here 551 recipient has moved; try <firstname.lastname@example.org> 553 we don't relay mail to remote addresses
DATA parameters are prohibited. Some servers reject any DATA request with a nonempty parameter.
MAIL and RCPT must be used before DATA. Servers reject DATA requests (using code 503) unless the envelope contains a return path and at least one recipient address.
If the server accepts the DATA request (required code 354), the client sends an encoded message.
If the server accepts the message (required code 250), it is accepting responsibility for delivering the message to each of the recipient addresses in the envelope, or notifying the return path (if it is nonempty) if some deliveries are not made:
MAIL FROM:<God@heaven.af.mil> 250 ok RCPT TO:<email@example.com> 250 ok DATA 354 ok Hi, guys. Just testing our new mail system. . 250 Written safely to disk. #902487694.289148.12219.Many clients save this final 250 response as a receipt; I recommend that the server include enough information that the local system administrator can track down the message in his logs.
If the server accepts the DATA request and the message, the new envelope is empty. (Exception: A server called David reportedly leaves the envelope recipients alone through both DATA and MAIL.) Otherwise the client cannot make any assumptions about the envelope.
RFC 821 lets the server use codes 421, 451, 500, 501, 503, or 554 to reject a DATA request. Typical examples (out of context):
451 unable to set up internal message buffer 503 need RCPT before DATARFC 821 lets the server use codes 451, 452, 552, or 554 to reject a message. Typical examples (out of context):
552 sorry, this message is too large for my disk 554 too many hops, this message is looping