Network Working Group M. Crispin
Request for Comments: 3502 University of Washington
Category: Standards Track March 2003
Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the multiappending extension to the Internet
Message Access Protocol (IMAP) (RFC 3501). This extension provides
substantial performance improvements for IMAP clients which upload
multiple messages at a time to a mailbox on the server.
A server which supports this extension indicates this with a
capability name of "MULTIAPPEND".
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [KEYWORDS].
Introduction
The MULTIAPPEND extension permits uploading of multiple messages with
a single command. When used in conjunction with the [LITERAL+]
extension, the entire upload is accomplished in a single
command/response round trip.
A MULTIAPPEND APPEND operation is atomic; either all messages are
successfully appended, or no messages are appended.
In the base IMAP specification, each message must be appended in a
separate command, and there is no mechanism to "unappend" messages if
an error occurs while appending. Also, some mail stores may require
Crispin Standards Track [Page 1]
RFC 3502 IMAP MULTIAPPEND March 2003
an expensive "open/lock + sync/unlock/close" operation as part of
appending; this can be quite expensive if it must be done on a
per-message basis.
If the server supports both LITERAL+ and pipelining but not
MULTIAPPEND, it may be possible to get some of the performance
advantages of MULTIAPPEND by doing a pipelined "batch" append.
However, it will not work as well as MULTIAPPEND for the following
reasons:
1) Multiple APPEND commands, even as part of a pipelined batch,
are non-atomic by definition. There is no way to revert the
mailbox to the state before the batch append in the event of an
error.
2) It may not be feasible for the server to coalesce pipelined
APPEND operations so as to avoid the "open/lock +
sync/unlock/close" overhead described above. In any case, such
coalescing would be timing dependent and thus potentially
unreliable. In particular, with traditional UNIX mailbox files,
it is assumed that a lock is held only for a single atomic
operation, and many applications disregard any lock that is
older than 5 minutes.
3) If an error occurs, depending upon the nature of the error,
it is possible for additional messages to be appended after the
error. For example, the user wants to append 5 messages, but a
disk quota error occurs with the third message because of its
size. However, the fourth and fifth messages have already been
sent in the pipeline, so the mailbox ends up with the first,
second, fourth, and fifth messages of the batch appended.
6.3.11. APPEND Command
Arguments: mailbox name
one or more messages to upload, specified as:
OPTIONAL flag parenthesized list
OPTIONAL date/time string
message literal
Data: no specific responses for this command
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text,
append cancelled
BAD - command unknown or arguments invalid
Crispin Standards Track [Page 2]
RFC 3502 IMAP MULTIAPPEND March 2003
The APPEND command appends the literal arguments as new messages
to the end of the specified destination mailbox. This argument
SHOULD be in the format of an [RFC-2822] message. 8-bit
characters are permitted in the message. A server implementation
that is unable to preserve 8-bit data properly MUST be able to
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding.
Note: There MAY be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in the
message literal argument to APPEND. The full implications
of doing so MUST be understood and carefully weighed.
If a flag parenthesized list is specified, the flags SHOULD be set
in the resulting message; otherwise, the flag list of the
resulting message is set empty by default.
If a date-time is specified, the internal date SHOULD be set in
the resulting message; otherwise, the internal date of the
resulting message is set to the current date and time by default.
A zero-length message literal argument is an error, and MUST
return a NO. This can be used to cancel the append.
If the append is unsuccessful for any reason (including being
cancelled), the mailbox MUST be restored to its state before the
APPEND attempt; no partial appending is permitted. The server MAY
return an error before processing all the message arguments.
If the destination mailbox does not exist, a server MUST return an
error, and MUST NOT automatically create the mailbox. Unless it
is certain that the destination mailbox can not be created, the
server MUST send the response code "[TRYCREATE]" as the prefix of
the text of the tagged NO response. This gives a hint to the
client that it can attempt a CREATE command and retry the APPEND
if the CREATE is successful.
If the mailbox is currently selected, the normal new message
actions SHOULD occur. Specifically, the server SHOULD notify the
client immediately via an untagged EXISTS response. If the server
does not do so, the client MAY issue a NOOP command (or failing
that, a CHECK command) after one or more APPEND commands.
Crispin Standards Track [Page 3]
RFC 3502 IMAP MULTIAPPEND March 2003
Example: C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar></foobar>
C: Subject: afternoon meeting
C: To: mooch@owatagu.example.net
C: Message-Id: <b27397-0100000></b27397-0100000>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch></mooch>
C: Subject: Re: afternoon meeting
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930></a0434793874930>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred></fred>
C: Subject: hmm...
C: {35403}
S: A005 NO APPEND failed: Disk quota exceeded
Note: The APPEND command is not used for message delivery,
because it does not provide a mechanism to transfer [SMTP]
envelope information.
Modification to IMAP4rev1 Base Protocol Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF].
append = "APPEND" SP mailbox 1*append-message
append-message = [SP flag-list] [SP date-time] SP literal
Crispin Standards Track [Page 4]
RFC 3502 IMAP MULTIAPPEND March 2003
MULTIAPPEND Interaction with UIDPLUS Extension
Servers which support both MULTIAPPEND and [UIDPLUS] will have the
"resp-code-apnd" rule modified as follows:
resp-code-apnd = "APPENDUID" SP nz-number SP set
That is, the APPENDUID response code returns as many UIDs as there
were messages appended in the multiple append. The UIDs returned
should be in the order the articles where appended. The message set
may not contain extraneous UIDs or the symbol "*".
Security Considerations
The MULTIAPPEND extension does not raise any security considerations
that are not present in the base [IMAP] protocol, and these issues
are discussed in [IMAP]. Nevertheless, it is important to remember
that IMAP4rev1 protocol transactions, including electronic mail data,
are sent in the clear over the network unless protection from
snooping is negotiated, either by the use of STARTTLS, privacy
protection is negotiated in the AUTHENTICATE command, or some other
protection mechanism is in effect.
Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet
Mail Extensions) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
Crispin Standards Track [Page 5]
RFC 3502 IMAP MULTIAPPEND March 2003
Informative References
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
[SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
2821, April 2001.
Author's Address
Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Avenue NE
Seattle, WA 98105-4527
Phone: (206) 543-5762
EMail: MRC@CAC.Washington.EDU
Crispin Standards Track [Page 6]
RFC 3502 IMAP MULTIAPPEND March 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Crispin Standards Track [Page 7]
This is good to know about E-Mail in general, Pegasus Mail or Mercury.
Network Working Group S. MaesRequest for Comments: 4550 Oracle
Category: Standards Track A. Melnikov
Isode Ltd.
June 2006
Internet Email to Support Diverse Service Environments
(Lemonade) Profile
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a profile (a set of required extensions,
restrictions, and usage modes) of the IMAP and mail submission
protocols. This profile allows clients (especially those that are
constrained in memory, bandwidth, processing power, or other areas)
to efficiently use IMAP and Submission to access and submit mail.
This includes the ability to forward received mail without needing to
download and upload the mail, to optimize submission, and to
efficiently resynchronize in case of loss of connectivity with the
server.
The Internet Email to Support Diverse Service Environments (Lemonade)
profile relies upon extensions to IMAP and Mail Submission protocols;
specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501)
extensions and the BURL extension to the SUBMIT protocol (RFC 4409).
Maes & Melnikov Standards Track [Page 1]
RFC 4550 Lemonade Profile June 2006
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Forward without Download ........................................3
2.1. Motivations ................................................3
2.2. Message Sending Overview ...................................4
2.3. Traditional Strategy .......................................4
2.4. Step-by-Step Description ...................................5
2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
2.4.2. Message Assembly Using SMTP CHUNKING and
BURL Extensions ....................................10
2.5. Normative Statements Related to Forward without Download ..14
2.6. Security Considerations for "pawn-tickets" ................14
2.7. The fcc Problem ...........................................15
2.8. Registration of $Forwarded IMAP Keyword ...................15
3. Message Submission .............................................15
3.1. Pipelining ................................................16
3.2. DSN Support ...............................................16
3.3. Message Size Declaration ..................................16
3.4. Enhanced Status Code Support ..............................16
3.5. TLS .......................................................16
4. Quick Resynchronization ........................................16
5. Additional IMAP Extensions .....................................17
6. Summary of the Required IMAP and SMTP Extensions ...............17
7. Future work ....................................................18
8. Security Considerations ........................................18
8.1. Confidentiality Protection of Submitted Messages ..........19
8.2. TLS .......................................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Acknowledgements ..............................................21
Maes & Melnikov Standards Track [Page 2]
RFC 4550 Lemonade Profile June 2006
1. Introduction
Lemonade provides enhancements to Internet email to support diverse
service environments.
This document describes the Lemonade profile, which includes:
- "forward without download", which describes exchanges between
Lemonade clients and servers to allow new email messages to be
submitted incorporating content that resides on locations
external to the client.
- Quick mailbox resynchronization using [CONDSTORE].
- Several IMAP and SMTP extensions that save bandwidth and/or
number of round-trips required to send/receive data.
The organization of this document is as follows. Section 2 describes
"forward without download". Section 3 describes additional SMTP
extensions that must be supported by all Lemonade Submission servers.
Section 4 describes IMAP quick resynchronization.
1.1. Conventions Used in This Document
In examples, "M:", "I:", and "S:" indicate lines sent by the client
messaging user agent, IMAP e-mail server, and SMTP submit server,
respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All examples in this document are optimized for Lemonade use and
might not represent examples of proper protocol usage for a general
use Submit/IMAP client. In particular, examples assume that Lemonade
Submit and IMAP servers support all Lemonade extensions described in
this document, so they don't show how to deal with absence of an
extension.
2. Forward without Download
2.1. Motivations
The advent of client/server email using the [RFC3501], [RFC2821], and
[SUBMIT] protocols has changed what formerly were local disk
operations into repetitive network data transmissions.
Maes & Melnikov Standards Track [Page 3]
RFC 4550 Lemonade Profile June 2006
Lemonade "forward without download" makes use of the [BURL] SUBMIT
extension to enable access to external sources during the submission
of a message. In combination with the IMAP [URLAUTH] extension,
inclusion of message parts or even entire messages from the IMAP mail
store is possible with a minimal trust relationship between the IMAP
and SMTP SUBMIT servers.
Lemonade "forward without download" has the advantage of maintaining
one submission protocol, and thus avoids the risk of having multiple
parallel and possibly divergent mechanisms for submission. The
client can use Submit/SMTP [SUBMIT] extensions without these being
added to IMAP. Furthermore, by keeping the details of message
submission in the SMTP SUBMIT server, Lemonade "forward without
download" can work with other message retrieval protocols such as
Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or
whatever else may be designed in the future.
2.2. Message Sending Overview
The act of sending an email message can be thought of as involving
multiple steps: initiation of a new draft, draft editing, message
assembly, and message submission.
Initiation of a new draft and draft editing takes place in the Mail
User Agent (MUA). Frequently, users choose to save more complex
messages on an [RFC3501] server (via the APPEND command with the
\Draft flag) for later recall by the MUA and resumption of the
editing process.
Message assembly is the process of producing a complete message from
the final revision of the draft and external sources. At assembly
time, external data is retrieved and inserted in the message.
Message submission is the process of inserting the assembled message
into the [RFC2821] infrastructure, typically using the [SUBMIT]
protocol.
2.3. Traditional Strategy
Traditionally, messages are initiated, edited, and assembled entirely
within an MUA, although drafts may be saved to an [RFC3501] server
and later retrieved from the server. The completed text is then
transmitted to a Message Submission Agent (MSA) for delivery.
Maes & Melnikov Standards Track [Page 4]
RFC 4550 Lemonade Profile June 2006
There is often no clear boundary between the editing and assembly
process. If a message is forwarded, its content is often retrieved
immediately and inserted into the message text. Similarly, when
external content is inserted or attached, the content is usually
retrieved immediately and made part of the draft.
As a consequence, each save of a draft and subsequent retrieve of the
draft transmits that entire (possibly large) content, as does message
submission.
In the past, this was not much of a problem, because drafts, external
data, and the message submission mechanism were typically located on
the same system as the MUA. The most common problem was running out
of disk quota.
2.4. Step-by-Step Description
The model distinguishes among a Mail User Agent (MUA), an IMAP4Rev1
Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as
illustrated in Figure 1.
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server S) |
+--------------+
Figure 1: Lemonade "forward without download"
Lemonade "forward without download" allows a Messaging User Agent to
compose and forward an e-mail combining fragments that are located in
an IMAP server, without having to download these fragments to the
client.
Maes & Melnikov Standards Track [Page 5]
RFC 4550 Lemonade Profile June 2006
There are two ways to perform "forward without download", based on
where the message assembly takes place. The first uses an extended
APPEND command [CATENATE] to edit a draft message in the message
store and cause the message assembly on the IMAP server. The second
uses a succession of BURL and BDAT commands to submit and assemble
(through concatenation) message data from the client and external
data fetched from the provided URL. The two subsequent sections
provide step-by-step instructions on how "forward without download"
is achieved.
2.4.1. Message Assembly Using IMAP CATENATE Extension
In the [BURL]/[CATENATE] variant of the Lemonade "forward without
download" strategy, messages are initially composed and edited within
an MUA. The [CATENATE] extension to [RFC3501] is then used to create
the messages on the IMAP server by transmitting new text and
assembling them. The [UIDPLUS] IMAP extension is used by the client
in order to learn the Unique Identifier (UID) of the created
messages. Finally, a [URLAUTH] format URL is given to a [SUBMIT]
server for submission using the [BURL] extension.
The flow involved to support such a use case consists of:
M: {to I -- Optional} The client connects to the IMAP server,
optionally starts TLS (if data confidentiality is required),
authenticates, opens a mailbox ("INBOX" in the example below) and
fetches body structures (See [RFC3501]).
Example:
M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
"trip.txt")
"<960723163407.20117h@washington.example.com>"
"Your trip details" "BASE64" 4554 73) "MIXED"))
I: A0051 OK completed
M: {to I} The client invokes CATENATE (See [CATENATE] for details
of the semantics and steps) -- this allows the MUA to create
messages on the IMAP server using new data combined with one or
more message parts already present on the IMAP server.
Note that the example for this step doesn't use the LITERAL+
[LITERAL+] extension. Without LITERAL+, the new message is
constructed using 3 round-trips. If LITERAL+ is used, the new
message can be constructed using one round-trip.
Maes & Melnikov Standards Track [Page 6]
RFC 4550 Lemonade Profile June 2006
M: A0052 APPEND Sent FLAGS (\Seen $MDNSent)
CATENATE (TEXT {475}
I: + Ready for literal data
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar></bar>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
M: URL "/INBOX;UIDVALIDITY=385759045/;
UID=25627/;Section=2.MIME" URL "/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
I: + Ready for literal data
M:
M: --------------030308070208000400050907--
M: )
I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
M: {to I} The client uses GENURLAUTH command to request a URLAUTH
URL (see [URLAUTH]).
I: {to M} The IMAP server returns a URLAUTH URL suitable for later
retrieval with URLFETCH (see [URLAUTH] for details of the
semantics and steps).
M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=2005-10-
28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=
2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: A0054 OK GENURLAUTH completed
M: {to S} The client connects to the mail submission server and
starts a new mail transaction. It uses BURL to let the SMTP
submit server fetch the content of the message from the IMAP
Maes & Melnikov Standards Track [Page 7]
RFC 4550 Lemonade Profile June 2006
server. (See [BURL] for details of the semantics and steps.)
This allows the MUA to authorize the SMTP submit server to access
the message composed as a result of the CATENATE step. Note that
the second EHLO command is required after a successful STARTTLS
command. Also note that there might be a third required EHLO
command if the second EHLO response doesn't list any BURL options.
Section 2.4.2 demonstrates this.
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: MAIL FROM:<bob.ar></bob.ar>
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo></foo>
S: 250 2.1.5 foo@example.net OK.
M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
uid=45/;urlauth=submit+bar:internal:
91354a473744909de610943775f92038 LAST
Maes & Melnikov Standards Track [Page 8]
RFC 4550 Lemonade Profile June 2006
S: {to I} The mail submission server uses URLFETCH to fetch the
message to be sent. (See [URLAUTH] for details of the semantics
and steps. The so-called "pawn-ticket" authorization mechanism
uses a URI that contains its own authorization credentials.)
I: {to S} Provides the message composed as a result of the
CATENATE step.
Mail submission server opens IMAP connection to the IMAP server:
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a000 STARTTLS
I: a000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: * URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038" {15065}
...message body follows...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
Note that if the IMAP server doesn't send CAPABILITY response code
in the greeting, the mail submission server must issue the
CAPABILITY command to learn about supported IMAP extensions as
described in RFC 3501.
Also, if data confidentiality is not required, the mail submission
server may omit the STARTTLS command before issuing the LOGIN
command.
S: {to M} Submission server assembles the complete message, and if
the assembly succeeds, it returns OK to the MUA:
S: 250 2.5.0 Ok.
M: {to I} The client marks the message containing the forwarded
attachment on the IMAP server.
Maes & Melnikov Standards Track [Page 9]
RFC 4550 Lemonade Profile June 2006
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
Note: the UID STORE command shown above will only work if the
marked message is in the currently selected mailbox; otherwise, it
requires a SELECT. This command can be omitted. The untagged
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
is described in Section 2.8.
2.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions
In the [BURL]/[CHUNKING] variant of the Lemonade "forward without
download" strategy, messages are initially composed and edited within
an MUA. During submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING]
commands are used to create the messages from multiple parts. New
body parts are supplied using BDAT commands, while existing body
parts are referenced using [URLAUTH] format URLs in BURL commands.
The flow involved to support such a use case consists of:
M: {to I -- Optional} The client connects to the IMAP server,
optionally starts TLS (if data confidentiality is required),
authenticates, opens a mailbox ("INBOX" in the example below), and
fetches body structures (see [RFC3501]).
Example:
M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
"trip.txt")
"<960723163407.20117h@washington.example.com>"
"Your trip details" "BASE64" 4554 73) "MIXED"))
I: A0051 OK completed
M: {to I} The client uses GENURLAUTH command to request URLAUTH
URLs (see [URLAUTH]) referencing pieces of the message to be
assembled.
I: {to M} The IMAP server returns URLAUTH URLs suitable for later
retrieval with URLFETCH (see [URLAUTH] for details of the
semantics and steps).
M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
Maes & Melnikov Standards Track [Page 10]
RFC 4550 Lemonade Profile June 2006
INTERNAL "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF"
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: A0054 OK GENURLAUTH completed
M: {to S} The client connects to the mail submission server and
starts a new mail transaction. It uses BURL to instruct the SMTP
submit server to fetch from the IMAP server pieces of the message
to be sent (see [BURL] for details of the semantics and steps).
Note that the second EHLO command is required after a successful
STARTTLS command. The third EHLO command is required if and only
if the second EHLO response doesn't list any BURL options. See
Section 2.4.1 for an example of submission where the third EHLO
command/response is not present.
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
Maes & Melnikov Standards Track [Page 11]
RFC 4550 Lemonade Profile June 2006
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap imap://imap.example.org
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: MAIL FROM:<bob.ar> BODY=BINARY </bob.ar>
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo></foo>
S: 250 2.1.5 foo@example.net OK.
M: BDAT 475
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar></bar>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9
S: 250 2.5.0 OK
Maes & Melnikov Standards Track [Page 12]
RFC 4550 Lemonade Profile June 2006
M: BDAT 44 LAST
M:
M: --------------030308070208000400050907--
S: {to I} The mail submission server uses URLFETCH to fetch the
pieces of the message to be sent (see [URLAUTH] for details of the
semantics and steps). The so-called "pawn-ticket" authorization
mechanism uses a URI that contains its own authorization
credentials.
I: {to S} Returns the requested body parts.
Mail submission server opens IMAP connection to the IMAP server:
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" "imap://
bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: * URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" {84}
...message section follows...
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9" {15065}
...message section follows...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
Note that if the IMAP server doesn't send CAPABILITY response code
in the greeting, the mail submission server must issue the
CAPABILITY command to learn about supported IMAP extensions as
described in RFC 3501.
Maes & Melnikov Standards Track [Page 13]
RFC 4550 Lemonade Profile June 2006
Also, if data confidentiality is required, the mail submission
server should start TLS before issuing the LOGIN command.
S: {to M} Submission server assembles the complete message, and if
the assembly succeeds, it acknowledges acceptance of the message
by sending 250 response to the last BDAT command:
S: 250 2.5.0 Ok, message accepted.
M: {to I} The client marks the message containing the forwarded
attachment on the IMAP server.
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
Note: the UID STORE command shown above will only work if the
marked message is in the currently selected mailbox; otherwise, it
requires a SELECT. This command can be omitted. The untagged
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
is described in Section 2.8.
2.5. Normative Statements Related to Forward without Download
Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501],
CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This
support MUST be declared via CAPABILITY [RFC3501].
Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME
[8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This
support MUST be declared via EHLO [RFC2821]. BURL MUST support
URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
option following the BURL EHLO keyword (see [BURL] for more details).
Additional normative statements are provided in other sections.
2.6. Security Considerations for "pawn-tickets"
The so-called "pawn-ticket" authorization mechanism uses a URI, which
contains its own authorization credentials using [URLAUTH]. The
advantage of this mechanism is that the SMTP submit [SUBMIT] server
cannot access any data on the [RFC3501] server without a "pawn-
ticket" created by the client.
The "pawn-ticket" grants access only to the specific data that the
SMTP submit [SUBMIT] server is authorized to access, can be revoked
by the client, and can have a time-limited validity.
Maes & Melnikov Standards Track [Page 14]
RFC 4550 Lemonade Profile June 2006
2.7. The fcc Problem
The "fcc problem" refers to delivering a copy of a message to a "file
carbon copy" recipient. By far, the most common case of fcc is a
client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox"
mailbox.
In the traditional strategy, the MUA duplicates the effort spent in
transmitting to the MSA by writing the message to the fcc destination
in a separate step. This may be a write to a local disk file or an
APPEND to a mailbox on an IMAP server. The latter is one of the
"repetitive network data transmissions" that represents the "problem"
aspect of the "fcc problem".
The [CATENATE] extension to [RFC3501] can be used to address the fcc
problem. The final message is constructed in the mailbox designed
for outgoing mail. Note that the [CATENATE] extension can only
create a single message and only on the server that stages the
outgoing message for submission. Additional copies of the message
can be created on the same server using one or more COPY commands.
2.8. Registration of $Forwarded IMAP Keyword
The $Forwarded IMAP keyword is used by several IMAP clients to
specify that the message was resent to another email address,
embedded within or attached to a new message. A mail client sets
this keyword when it successfully forwards the message to another
email address. Typical usage of this keyword is to show a different
(or additional) icon for a message that has been forwarded. Once
set, the flag SHOULD NOT be cleared.
Lemonade-compliant servers MUST be able to store the $Forwarded
keyword. They MUST preserve it on the COPY operation. The servers
MUST support the SEARCH KEYWORD $Forwarded.
3. Message Submission
Lemonade-compliant mail submission servers are expected to implement
the following set of SMTP extensions to make message submission
efficient.
Lemonade clients should take advantage of these features.
Maes & Melnikov Standards Track [Page 15]
RFC 4550 Lemonade Profile June 2006
3.1. Pipelining
Mobile clients regularly use networks with a relatively high latency.
Avoidance of round-trips within a transaction has a great advantage
for reduction in both bandwidth and total transaction time. For this
reason, Lemonade-compliant mail submission servers MUST support the
SMTP Service Extensions for Command Pipelining [RFC2920].
Clients SHOULD pipeline SMTP commands when possible.
3.2. DSN Support
Lemonade-compliant mail submission servers MUST support SMTP service
extensions for delivery status notifications [RFC3461].
3.3. Message Size Declaration
Lemonade-compliant mail submission servers MUST support the SMTP
Service Extension for Message Size Declaration [RFC1870].
Lemonade-compliant mail submission servers MUST "expand" all BURL
parts before enforcing a message size limit.
A Lemonade-compliant client SHOULD use message size declaration. In
particular, it MUST NOT send a message to a mail submission server,
if the client knows that the message exceeds the maximal message size
advertised by the submission server.
3.4. Enhanced Status Code Support
Lemonade-compliant mail submission servers MUST support SMTP Service
Extension for Returning Enhanced Error Codes [RFC2034].
3.5. TLS
Lemonade-compliant mail submission servers MUST support SMTP Service
Extension for Secure SMTP over TLS [SMTP-TLS].
4. Quick Resynchronization
Lemonade-compliant IMAP servers MUST support the CONDSTORE
[CONDSTORE] extension. It allows a client to quickly resynchronize
any mailbox by asking the server to return all flag changes that have
occurred since the last known mailbox synchronization mark.
[IMAP-DISC] shows how to perform quick mailbox resynchronization.
Maes & Melnikov Standards Track [Page 16]
RFC 4550 Lemonade Profile June 2006
5. Additional IMAP Extensions
Lemonade-compliant IMAP servers MUST support the NAMESPACE
[NAMESPACE] extension. The extension allows clients to discover
shared mailboxes and mailboxes belonging to other users.
Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+]
extension. The extension allows clients to save a round-trip each
time a non-synchronizing literal is sent.
Lemonade-compliant IMAP servers MUST support the IDLE [IDLE]
extension. The extension allows clients to receive instant
notifications about changes in the selected mailbox, without needing
to poll for changes.
Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501]
as required by RFC 3501.
6. Summary of the Required IMAP and SMTP Extensions
-----------------------------------------------------|
| Name of SMTP extension | Comment |
|-------------------------|--------------------------|
| PIPELINING | Section 3.1 |
|-------------------------|--------------------------|
| DSN | Section 3.2 |
|-------------------------|--------------------------|
| SIZE | Section 3.3 |
|-------------------------|--------------------------|
| ENHANCEDSTATUSCODES | Section 3.4 |
|-------------------------|--------------------------|
| STARTTLS | Section 3.5 |
|-------------------------|--------------------------|
| BURL | Forward without download,|
| | Section 2 |
|-------------------------|--------------------------|
| URLAUTH support in BURL | Section 2.5 |
|-------------------------|--------------------------|
| CHUNKING, | Section 2.5 |
| BINARYMIME | Section 2.5 |
|-------------------------|--------------------------|
| 8BITMIME, | Required by BURL |
|-------------------------|--------------------------|
| AUTH | Required by Submission, |
| | See [SMTPAUTH]. |
|-------------------------|--------------------------|
Maes & Melnikov Standards Track [Page 17]
RFC 4550 Lemonade Profile June 2006
-----------------------------------------------------|
| Name of IMAP extension | Comment |
| or feature | |
|-------------------------|--------------------------|
| NAMESPACE | Section 5 |
|-------------------------|--------------------------|
| CONDSTORE | Section 4 |
|-------------------------|--------------------------|
| STARTTLS |Required by IMAP (RFC3501)|
|-------------------------|--------------------------|
| URLAUTH, | Forward without download,|
| CATENATE, | Section 2 |
| UIDPLUS | |
|-------------------------|--------------------------|
| LITERAL+ | Section 5 |
|-------------------------|--------------------------|
| IDLE | Section 5 |
|-------------------------|--------------------------|
| $Forwarded IMAP keyword | Section 2.8 |
|-------------------------|--------------------------|
7. Future work
The Lemonade Working Group is looking into additional issues related
to usage of email by mobile devices, possibly including:
- Media conversion (static and possibly streamed)
- Transport optimization for low or costly bandwidth and less
reliable mobile networks (e.g., quick reconnect)
- Server to client notifications, possibly outside of the
traditional IMAP band
- Dealing with firewall and intermediaries
- Compression and other bandwidth optimization
- Filtering
- Other considerations for mobile clients
8. Security Considerations
Security considerations on Lemonade "forward without download" are
discussed throughout Section 2. Additional security considerations
can be found in [RFC3501] and other documents describing other SMTP
and IMAP extensions comprising the Lemonade profile.
Note that the mandatory-to-implement authentication mechanism for
SMTP submission is described in [SUBMIT]. The mandatory-to-implement
authentication mechanism for IMAP is described in [RFC3501].
Maes & Melnikov Standards Track [Page 18]
RFC 4550 Lemonade Profile June 2006
8.1. Confidentiality Protection of Submitted Messages
When clients submit new messages, link protection such as TLS guards
against an eavesdropper seeing the contents of the submitted message.
It's worth noting, however, that even if TLS is not used, the
security risks are no worse if BURL is used to reference the text
than if the text is submitted directly. If BURL is not used, an
eavesdropper gains access to the full text of the message. If BURL
is used, the eavesdropper may or may not be able to gain such access,
depending on the form of BURL used. For example, some forms restrict
use of the URL to an entity authorized as a submission server or a
specific user.
8.2. TLS
When Lemonade clients use the BURL extension to mail submission,
which requires sending a URLAUTH token to the mail submission server,
such a token should be protected from interception to avoid a replay
attack that may disclose the contents of the message to an attacker.
TLS-based encryption of the mail submission path will provide
protection against this attack.
Lemonade clients SHOULD use TLS-protected IMAP and mail submission
channels when using BURL-based message submission to protect the
URLAUTH token from interception.
Lemonade-compliant mail submission servers SHOULD use TLS-protected
IMAP connections when fetching message content using the URLAUTH
token provided by the Lemonade client.
When a client uses SMTP STARTTLS to send a BURL command that
references non-public information, there is a user expectation that
the entire message content will be treated confidentially. To meet
this expectation, the message submission server should use STARTTLS
or a mechanism providing equivalent data confidentiality when
fetching the content referenced by that URL.
Maes & Melnikov Standards Track [Page 19]
RFC 4550 Lemonade Profile June 2006
9. References
9.1. Normative References
[BURL] Newman, C. "Message Submission BURL Extension", RFC 4468,
May 2006.
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", RFC 3030, December
2000.
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2920] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC
1870, November 1995.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
Maes & Melnikov Standards Track [Page 20]
RFC 4550 Lemonade Profile June 2006
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
9.2. Informative References
[IMAP-DISC] Melnikov, A., "Synchronization operations for
disconnected IMAP4 clients", Work in Progress, October
2004.
10. Acknowledgements
This document is a product of Lemonade WG. The editors thank the
Lemonade WG members that contributed comments and corrections; in
particular: Randy Gellens, Dave Cridland, and Greg Vaudreuil.
This document borrows some text from "Message Submission" (February
2004) by Mark Crispin, as well as from the trio [BURL], [CATENATE],
and [URLAUTH].
Maes & Melnikov Standards Track [Page 21]
RFC 4550 Lemonade Profile June 2006
Authors' Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
EMail: stephane.maes@oracle.com
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex
TW12 2BX
UK
EMail: Alexey.melnikov@isode.com
Maes & Melnikov Standards Track [Page 22]
RFC 4550 Lemonade Profile June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Maes & Melnikov Standards Track [Page 23]
Network Working Group P. Resnick, Ed.
Request for Comments: 5322 Qualcomm Incorporated
Obsoletes: 2822 October 2008
Updates: 4021
Category: Standards Track
Internet Message Format
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the
framework of "electronic mail" messages. This specification is a
revision of Request For Comments (RFC) 2822, which itself superseded
Request For Comments (RFC) 822, "Standard for the Format of ARPA
Internet Text Messages", updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs.
Resnick Standards Track [Page 1]
RFC 5322 Internet Message Format October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5
1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5
1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 5
1.2.3. Structure of This Document . . . . . . . . . . . . . . 5
2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . . 6
2.1. General Description . . . . . . . . . . . . . . . . . . . 6
2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . . 7
2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Unstructured Header Field Bodies . . . . . . . . . . . 8
2.2.2. Structured Header Field Bodies . . . . . . . . . . . . 8
2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . . 8
2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 10
3.2.2. Folding White Space and Comments . . . . . . . . . . . 11
3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. Quoted Strings . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14
3.3. Date and Time Specification . . . . . . . . . . . . . . . 14
3.4. Address Specification . . . . . . . . . . . . . . . . . . 16
3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 17
3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . . 18
3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19
3.6.1. The Origination Date Field . . . . . . . . . . . . . . 22
3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22
3.6.3. Destination Address Fields . . . . . . . . . . . . . . 23
3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25
3.6.5. Informational Fields . . . . . . . . . . . . . . . . . 27
3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 28
3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . . 30
3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 30
4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 32
4.2. Obsolete Folding White Space . . . . . . . . . . . . . . . 33
4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33
4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 35
4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35
4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 36
4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . . 36
4.5.3. Obsolete Destination Address Fields . . . . . . . . . 37
4.5.4. Obsolete Identification Fields . . . . . . . . . . . . 37
4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 37
Resnick Standards Track [Page 2]
RFC 5322 Internet Message Format October 2008
4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . . 38
4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 38
4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38
5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Example Messages . . . . . . . . . . . . . . . . . 43
Appendix A.1. Addressing Examples . . . . . . . . . . . . . . . 44
Appendix A.1.1. A Message from One Person to Another with
Simple Addressing . . . . . . . . . . . . . . . . 44
Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45
Appendix A.1.3. Group Addresses . . . . . . . . . . . . . . . . . 45
Appendix A.2. Reply Messages . . . . . . . . . . . . . . . . . . 46
Appendix A.3. Resent Messages . . . . . . . . . . . . . . . . . 47
Appendix A.4. Messages with Trace Fields . . . . . . . . . . . . 48
Appendix A.5. White Space, Comments, and Other Oddities . . . . 49
Appendix A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . 50
Appendix A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . 50
Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50
Appendix A.6.3. Obsolete White Space and Comments . . . . . . . . 51
Appendix B. Differences from Earlier Specifications . . . . . 52
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1. Normative References . . . . . . . . . . . . . . . . . . . 55
7.2. Informative References . . . . . . . . . . . . . . . . . . 55
Resnick Standards Track [Page 3]
RFC 5322 Internet Message Format October 2008
1. Introduction
1.1. Scope
This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the
framework of "electronic mail" messages. This specification is an
update to [RFC2822], which itself superseded [RFC0822], updating it
to reflect current practice and incorporating incremental changes
that were specified in other RFCs such as [RFC1123].
This document specifies a syntax only for text messages. In
particular, it makes no provision for the transmission of images,
audio, or other sorts of structured data in electronic mail messages.
There are several extensions published, such as the MIME document
series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
for the transmission of such data through electronic mail, either by
extending the syntax provided here or by structuring such messages to
conform to this syntax. Those mechanisms are outside of the scope of
this specification.
In the context of electronic mail, messages are viewed as having an
envelope and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. (See [RFC5321] for a
discussion of the envelope.) The contents comprise the object to be
delivered to the recipient. This specification applies only to the
format and some of the semantics of message contents. It contains no
specification of the information in the envelope.
However, some message systems may use information from the contents
to create the envelope. It is intended that this specification
facilitate the acquisition of such information by programs.
This specification is intended as a definition of what message
content format is to be passed between systems. Though some message
systems locally store messages in this format (which eliminates the
need for translation between formats) and others use formats that
differ from the one specified in this specification, local storage is
outside of the scope of this specification.
Note: This specification is not intended to dictate the internal
formats used by sites, the specific message system features that
they are expected to support, or any of the characteristics of
user interface programs that create or read messages. In
addition, this document does not specify an encoding of the
characters for either transport or storage; that is, it does not
specify the number of bits used or how those bits are specifically
transferred over the wire or stored on disk.
Resnick Standards Track [Page 4]
RFC 5322 Internet Message Format October 2008
1.2. Notational Conventions
1.2.1. Requirements Notation
This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in [RFC2119].
1.2.2. Syntactic Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation for the formal definitions of the syntax of
messages. Characters will be specified either by a decimal value
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
a case-insensitive literal value enclosed in quotation marks (e.g.,
"A" for either uppercase or lowercase A).
1.2.3. Structure of This Document
This document is divided into several sections.
This section, section 1, is a short introduction to the document.
Section 2 lays out the general description of a message and its
constituent parts. This is an overview to help the reader understand
some of the general principles used in the later portions of this
document. Any examples in this section MUST NOT be taken as
specification of the formal syntax of any part of a message.
Section 3 specifies formal ABNF rules for the structure of each part
of a message (the syntax) and describes the relationship between
those parts and their meaning in the context of a message (the
semantics). That is, it lays out the actual rules for the structure
of each part of a message (the syntax) as well as a description of
the parts and instructions for their interpretation (the semantics).
This includes analysis of the syntax and semantics of subparts of
messages that have specific structure. The syntax included in
section 3 represents messages as they MUST be created. There are
also notes in section 3 to indicate if any of the options specified
in the syntax SHOULD be used over any of the others.
Both sections 2 and 3 describe messages that are legal to generate
for purposes of this specification.
Resnick Standards Track [Page 5]
RFC 5322 Internet Message Format October 2008
Section 4 of this document specifies an "obsolete" syntax. There are
references in section 3 to these obsolete syntactic elements. The
rules of the obsolete syntax are elements that have appeared in
earlier versions of this specification or have previously been widely
used in Internet messages. As such, these elements MUST be
interpreted by parsers of messages in order to be conformant to this
specification. However, since items in this syntax have been
determined to be non-interoperable or to cause significant problems
for recipients of messages, they MUST NOT be generated by creators of
conformant messages.
Section 5 details security considerations to take into account when
implementing this specification.
Appendix A lists examples of different sorts of messages. These
examples are not exhaustive of the types of messages that appear on
the Internet, but give a broad overview of certain syntactic forms.
Appendix B lists the differences between this specification and
earlier specifications for Internet messages.
Appendix C contains acknowledgements.
2. Lexical Analysis of Messages
2.1. General Description
At the most basic level, a message is a series of characters. A
message that is conformant with this specification is composed of
characters with values in the range of 1 through 127 and interpreted
as US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document
sometimes refers to this range of characters as simply "US-ASCII
characters".
Note: This document specifies that messages are made up of
characters in the US-ASCII range of 1 through 127. There are
other documents, specifically the MIME document series ([RFC2045],
[RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
extend this specification to allow for values outside of that
range. Discussion of those mechanisms is not within the scope of
this specification.
Messages are divided into lines of characters. A line is a series of
characters that is delimited with the two characters carriage-return
and line-feed; that is, the carriage return (CR) character (ASCII
value 13) followed immediately by the line feed (LF) character (ASCII
value 10). (The carriage return/line feed pair is usually written in
this document as "CRLF".)
Resnick Standards Track [Page 6]
RFC 5322 Internet Message Format October 2008
A message consists of header fields (collectively called "the header
section of the message") followed, optionally, by a body. The header
section is a sequence of lines of characters with special syntax as
defined in this specification. The body is simply a sequence of
characters that follows the header section and is separated from the
header section by an empty line (i.e., a line with nothing preceding
the CRLF).
Note: Common parlance and earlier versions of this specification
use the term "header" to either refer to the entire header section
or to refer to an individual header field. To avoid ambiguity,
this document does not use the terms "header" or "headers" in
isolation, but instead always uses "header field" to refer to the
individual field and "header section" to refer to the entire
collection.
2.1.1. Line Length Limits
There are two limits that this specification places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
The 998 character limit is due to limitations in many implementations
that send, receive, or store IMF messages which simply cannot handle
more than 998 characters on a line. Receiving implementations would
do well to handle an arbitrarily large number of characters in a line
for robustness sake. However, there are so many implementations that
(in compliance with the transport requirements of [RFC5321]) do not
accept messages containing more than 1000 characters including the CR
and LF per line, it is important for implementations not to create
such messages.
The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [RFC5321] if they actually cause
information to be lost). Again, even though this limitation is put
on messages, it is incumbent upon implementations that display
messages to handle an arbitrarily large number of characters in a
line (certainly at least up to the 998 character limit) for the sake
of robustness.
Resnick Standards Track [Page 7]
RFC 5322 Internet Message Format October 2008
2.2. Header Fields
Header fields are lines beginning with a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF. A
field name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon. A field body may be composed of printable US-ASCII characters
as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,
ASCII value 9) characters (together known as the white space
characters, WSP). A field body MUST NOT include CR and LF except
when used in "folding" and "unfolding", as described in section
2.2.3. All field bodies MUST conform to the syntax described in
sections 3 and 4 of this specification.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this specification are defined simply as
"unstructured" (which is specified in section 3.2.5 as any printable
US-ASCII characters plus white space characters) with no further
restrictions. These are referred to as unstructured field bodies.
Semantically, unstructured field bodies are simply to be treated as a
single line of characters with no further processing (except for
"folding" and "unfolding" as described in section 2.2.3).
2.2.2. Structured Header Field Bodies
Some field bodies in this specification have a syntax that is more
restrictive than the unstructured field bodies described above.
These are referred to as "structured" field bodies. Structured field
bodies are sequences of specific lexical tokens as described in
sections 3 and 4 of this specification. Many of these tokens are
allowed (according to their syntax) to be introduced or end with
comments (as described in section 3.2.2) as well as the white space
characters, and those white space characters are subject to "folding"
and "unfolding" as described in section 2.2.3. Semantic analysis of
structured field bodies is given along with their syntax.
2.2.3. Long Header Fields
Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a
multiple-line representation; this is called "folding". The general
rule is that wherever this specification allows for folding white
space (not simply WSP characters), a CRLF may be inserted before any
WSP.
Resnick Standards Track [Page 8]
RFC 5322 Internet Message Format October 2008
For example, the header field:
Subject: This is a test
can be represented as:
Subject: This
is a test
Note: Though structured field bodies are defined in such a way
that folding can take place between many of the lexical tokens
(and even within some of the lexical tokens), folding SHOULD be
limited to placing the CRLF at higher-level syntactic breaks. For
instance, if a field body is defined as comma-separated values, it
is recommended that folding occur after the comma separating the
structured items in preference to other places where the field
could be folded, even if it is allowed elsewhere.
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding". Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP. Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation. An unfolded header field has no length restriction and
therefore may be indeterminately long.
2.3. Body
The body of a message is simply lines of US-ASCII characters. The
only two limitations on the body are as follows:
o CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
o Lines of characters in the body MUST be limited to 998 characters,
and SHOULD be limited to 78 characters, excluding the CRLF.
Note: As was stated earlier, there are other documents,
specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
[RFC4288], [RFC4289]), that extend (and limit) this specification
to allow for different sorts of message bodies. Again, these
mechanisms are beyond the scope of this document.
Resnick Standards Track [Page 9]
RFC 5322 Internet Message Format October 2008
3. Syntax
3.1. Introduction
The syntax as given in this section defines the legal syntax of
Internet messages. Messages that are conformant to this
specification MUST conform to the syntax in this section. If there
are options in this section where one option SHOULD be generated,
that is indicated either in the prose or in a comment next to the
syntax.
For the defined expressions, a short description of the syntax and
use is given, followed by the syntax in ABNF, followed by a semantic
analysis. The following primitive tokens that are used but otherwise
unspecified are taken from the "Core Rules" of [RFC5234], Appendix
B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.
In some of the definitions, there will be non-terminals whose names
start with "obs-". These "obs-" elements refer to tokens defined in
the obsolete syntax in section 4. In all cases, these productions
are to be ignored for the purposes of generating legal Internet
messages and MUST NOT be used as part of such a message. However,
when interpreting messages, these tokens MUST be honored as part of
the legal syntax. In this sense, section 3 defines a grammar for the
generation of messages, with "obs-" elements that are to be ignored,
while section 4 adds grammar for the interpretation of messages.
3.2. Lexical Tokens
The following rules are used to define an underlying lexical
analyzer, which feeds tokens to the higher-level parsers. This
section defines the tokens used in structured header field bodies.
Note: Readers of this specification need to pay special attention
to how these lexical tokens are used in both the lower-level and
higher-level syntax later in the document. Particularly, the
white space tokens and the comment tokens defined in section 3.2.2
get used in the lower-level tokens defined here, and those lower-
level tokens are in turn used as parts of the higher-level tokens
defined later. Therefore, white space and comments may be allowed
in the higher-level tokens even though they may not explicitly
appear in a particular definition.
3.2.1. Quoted characters
Some characters are reserved for special interpretation, such as
delimiting lexical tokens. To permit use of these characters as
uninterpreted data, a quoting mechanism is provided.
Resnick Standards Track [Page 10]
RFC 5322 Internet Message Format October 2008
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
Where any quoted-pair appears, it is to be interpreted as the
character alone. That is to say, the "\" character that appears as
part of a quoted-pair is semantically "invisible".
Note: The "\" character may appear in a message where it is not
part of a quoted-pair. A "\" character that does not appear in a
quoted-pair is not semantically invisible. The only places in
this specification where quoted-pair currently appears are
ccontent, qcontent, and in obs-dtext in section 4.
3.2.2. Folding White Space and Comments
White space characters, including white space used in folding
(described in section 2.2.3), may appear between many elements in
header field bodies. Also, strings of characters that are treated as
comments may be included in structured field bodies as characters
enclosed in parentheses. The following defines the folding white
space (FWS) and comment constructs.
Strings of characters enclosed in parentheses are considered comments
so long as they do not appear within a "quoted-string", as defined in
section 3.2.4. Comments may nest.
There are several places in this specification where comments and FWS
may be freely inserted. To accommodate that syntax, an additional
token for "CFWS" is defined for places where comments and/or FWS can
occur. However, where CFWS occurs in this specification, it MUST NOT
be inserted in such a way that any line of a folded header field is
made up entirely of WSP characters and nothing else.
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
Resnick Standards Track [Page 11]
RFC 5322 Internet Message Format October 2008
Throughout this specification, where FWS (the folding white space
token) appears, it indicates a place where folding, as discussed in
section 2.2.3, may take place. Wherever folding appears in a message
(that is, a header field body containing a CRLF followed by any WSP),
unfolding (removal of the CRLF) is performed before any further
semantic analysis is performed on that header field according to this
specification. That is to say, any CRLF that appears in FWS is
semantically "invisible".
A comment is normally used in a structured field body to provide some
human-readable informational text. Since a comment is allowed to
contain FWS, folding is permitted within the comment. Also note that
since quoted-pair is allowed in a comment, the parentheses and
backslash characters may appear in a comment, so long as they appear
as a quoted-pair. Semantically, the enclosing parentheses are not
part of the comment; the comment is what is contained between the two
parentheses. As stated earlier, the "\" in any quoted-pair and the
CRLF in any FWS that appears within the comment are semantically
"invisible" and therefore not part of the comment either.
Runs of FWS, comment, or CFWS that occur between lexical tokens in a
structured header field are semantically interpreted as a single
space character.
3.2.3. Atom
Several productions in structured header field bodies are simply
strings of certain basic characters. Such productions are called
atoms.
Some of the structured header field bodies also allow the period
character (".", ASCII value 46) within runs of atext. An additional
"dot-atom" token is defined for those purposes.
Note: The "specials" token does not appear anywhere else in this
specification. It is simply the visible (i.e., non-control, non-
white space) characters that do not appear in atext. It is
provided only because it is useful for implementers who use tools
that lexically analyze messages. Each of the characters in
specials can be used to indicate a tokenization point in lexical
analysis.
Resnick Standards Track [Page 12]
RFC 5322 Internet Message Format October 2008
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Special characters that do
"<" / ">" / ; not appear in atext
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
Both atom and dot-atom are interpreted as a single unit, comprising
the string of characters that make it up. Semantically, the optional
comments and FWS surrounding the rest of the characters are not part
of the atom; the atom is only the run of atext characters in an atom,
or the atext and "." characters in a dot-atom.
3.2.4. Quoted Strings
Strings of characters that include characters other than those
allowed in atoms can be represented in a quoted string format, where
the characters are surrounded by quote (DQUOTE, ASCII value 34)
characters.
Resnick Standards Track [Page 13]
RFC 5322 Internet Message Format October 2008
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
A quoted-string is treated as a unit. That is, quoted-string is
identical to atom, semantically. Since a quoted-string is allowed to
contain FWS, folding is permitted. Also note that since quoted-pair
is allowed in a quoted-string, the quote and backslash characters may
appear in a quoted-string so long as they appear as a quoted-pair.
Semantically, neither the optional CFWS outside of the quote
characters nor the quote characters themselves are part of the
quoted-string; the quoted-string is what is contained between the two
quote characters. As stated earlier, the "\" in any quoted-pair and
the CRLF in any FWS/CFWS that appears within the quoted-string are
semantically "invisible" and therefore not part of the quoted-string
either.
3.2.5. Miscellaneous Tokens
Three additional tokens are defined: word and phrase for combinations
of atoms and/or quoted-strings, and unstructured for use in
unstructured header fields and in some places within structured
header fields.
word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. Date and Time Specification
Date and time values occur in several header fields. This section
specifies the syntax for a full date and time specification. Though
folding white space is permitted throughout the date-time
specification, it is RECOMMENDED that a single space be used in each
place that FWS appears (whether it is required or optional); some
older implementations will not interpret longer sequences of folding
white space correctly.
Resnick Standards Track [Page 14]
RFC 5322 Internet Message Format October 2008
date-time = [ day-of-week "," ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
The day is the numeric day of the month. The year is any numeric
year 1900 or later.
The time-of-day specifies the number of hours, minutes, and
optionally seconds since midnight of the date indicated.
The date and time-of-day SHOULD express local time.
The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent. The "+" or "-" indicates whether the time-of-
day is ahead of (i.e., east of) or behind (i.e., west of) Universal
Time. The first two digits indicate the number of hours difference
from Universal Time, and the last two digits indicate the number of
additional minutes difference from Universal Time. (Hence, +hhmm
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
minutes). The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is
Resnick Standards Track [Page 15]
RFC 5322 Internet Message Format October 2008
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and that the date-time
contains no information about the local time zone.
A date-time specification MUST be semantically valid. That is, the
day-of-week (if included) MUST be the day implied by the date, the
numeric day-of-month MUST be between 1 and the number of days allowed
for the specified month (in the specified year), the time-of-day MUST
be in the range 00:00:00 through 23:59:60 (the number of seconds
allowing for a leap second; see [RFC1305]), and the last two digits
of the zone MUST be within the range 00 through 59.
3.4. Address Specification
Addresses occur in several message header fields to indicate senders
and recipients of messages. An address may either be an individual
mailbox, or a group of mailboxes.
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list
A mailbox receives mail. It is a conceptual entity that does not
necessarily pertain to file storage. For example, some sites may
choose to print mail on a printer and deliver the output to the
addressee's desk.
Normally, a mailbox is composed of two parts: (1) an optional display
name that indicates the name of the recipient (which can be a person
or a system) that could be displayed to the user of a mail
application, and (2) an addr-spec address enclosed in angle brackets
Resnick Standards Track [Page 16]
RFC 5322 Internet Message Format October 2008
("<" and ">"). There is an alternate simple form of a mailbox where
the addr-spec address appears alone, without the recipient's name or
the angle brackets. The Internet addr-spec address is described in
section 3.4.1.
Note: Some legacy implementations used the simple form where the
addr-spec appears without the angle brackets, but included the
name of the recipient in parentheses as a comment following the
addr-spec. Since the meaning of the information in a comment is
unspecified, implementations SHOULD use the full name-addr form of
the mailbox, instead of the legacy form, to specify the display
name associated with a mailbox. Also, because some legacy
implementations interpret the comment, comments generally SHOULD
NOT be used in address fields to avoid confusing such
implementations.
When it is desirable to treat several mailboxes as a single unit
(i.e., in a distribution list), the group construct can be used. The
group construct allows the sender to indicate a named group of
recipients. This is done by giving a display name for the group,
followed by a colon, followed by a comma-separated list of any number
of mailboxes (including zero and one), and ending with a semicolon.
Because the list of mailboxes can be empty, using the group construct
is also a simple way to communicate to recipients that the message
was sent to one or more named sets of recipients, without actually
providing the individual mailbox address for any of those recipients.
3.4.1. Addr-Spec Specification
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("@",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the quoted-
string form SHOULD NOT be used. Comments and folding white space
SHOULD NOT be used around the "@" in the addr-spec.
Note: A liberal syntax for the domain portion of addr-spec is
given here. However, the domain portion contains addressing
information specified by and used in other protocols (e.g.,
[RFC1034], [RFC1035], [RFC1123], [RFC5321]). It is therefore
incumbent upon implementations to conform to the syntax of
addresses for the context in which they are used.
Resnick Standards Track [Page 17]
RFC 5322 Internet Message Format October 2008
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as
described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-
literal form, the domain is interpreted as the literal Internet
address of the particular host. In both cases, how addressing is
used and how messages are transported to a particular host is covered
in separate documents, such as [RFC5321]. These mechanisms are
outside of the scope of this document.
The local-part portion is a domain-dependent string. In addresses,
it is simply interpreted on the particular host as a name of a
particular mailbox.
3.5. Overall Message Syntax
A message consists of header fields, optionally followed by a message
body. Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF. (See section 2.1.1 for explanation.)
In a message body, though all of the characters listed in the text
rule MAY be used, the use of US-ASCII control characters (values 1
through 8, 11, 12, and 14 through 31) is discouraged since their
interpretation by receivers for display is not guaranteed.
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
Resnick Standards Track [Page 18]
RFC 5322 Internet Message Format October 2008
The header fields carry most of the semantic information and are
defined in section 3.6. The body is simply a series of lines of text
that are uninterpreted for the purposes of this specification.
3.6. Field Definitions
The header fields of a message are defined here. All header fields
have the same general syntactic structure: a field name, followed by
a colon, followed by the field body. The specific syntax for each
header field is defined in the subsequent sections.
Note: In the ABNF syntax for each field in subsequent sections,
each field name is followed by the required colon. However, for
brevity, sometimes the colon is not referred to in the textual
description of the syntax. It is, nonetheless, required.
It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet. However, for the purposes of this specification,
header fields SHOULD NOT be reordered when a message is transported
or transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message. See sections 3.6.6 and 3.6.7 for more
information.
The only required header fields are the origination date field and
the originator address field(s). All other header fields are
syntactically optional. More information is contained in the table
following this definition.
Resnick Standards Track [Page 19]
RFC 5322 Internet Message Format October 2008
fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
The following table indicates limits on the number of times each
field may occur in the header section of a message as well as any
special limitations on the use of those fields. An asterisk ("*")
next to a value in the minimum or maximum column indicates that a
special restriction appears in the Notes column.
Resnick Standards Track [Page 20]
RFC 5322 Internet Message Format October 2008
+----------------+--------+------------+----------------------------+
| Field | Min | Max number | Notes |
| | number | | |
+----------------+--------+------------+----------------------------+
| trace | 0 | unlimited | Block prepended - see |
| | | | 3.6.7 |
| resent-date | 0* | unlimited* | One per block, required if |
| | | | other resent fields are |
| | | | present - see 3.6.6 |
| resent-from | 0 | unlimited* | One per block - see 3.6.6 |
| resent-sender | 0* | unlimited* | One per block, MUST occur |
| | | | with multi-address |
| | | | resent-from - see 3.6.6 |
| resent-to | 0 | unlimited* | One per block - see 3.6.6 |
| resent-cc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-bcc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 |
| orig-date | 1 | 1 | |
| from | 1 | 1 | See sender and 3.6.2 |
| sender | 0* | 1 | MUST occur with |
| | | | multi-address from - see |
| | | | 3.6.2 |
| reply-to | 0 | 1 | |
| to | 0 | 1 | |
| cc | 0 | 1 | |
| bcc | 0 | 1 | |
| message-id | 0* | 1 | SHOULD be present - see |
| | | | 3.6.4 |
| in-reply-to | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| references | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| subject | 0 | 1 | |
| comments | 0 | unlimited | |
| keywords | 0 | unlimited | |
| optional-field | 0 | unlimited | |
+----------------+--------+------------+----------------------------+
The exact interpretation of each field is described in subsequent
sections.
Resnick Standards Track [Page 21]
RFC 5322 Internet Message Format October 2008
3.6.1. The Origination Date Field
The origination date field consists of the field name "Date" followed
by a date-time specification.
orig-date = "Date:" date-time CRLF
The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time
that a user pushes the "send" or "submit" button in an application
program. In any case, it is specifically not intended to convey the
time that the message is actually transported, but rather the time at
which the human or other creator of the message has put the message
into its final form, ready for transport. (For example, a portable
computer user who is not connected to a network might queue a message
for delivery. The origination date is intended to contain the date
and time that the user queued the message, not the time when the user
connected to the network to send the message.)
3.6.2. Originator Fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a comma-
separated list of one or more mailbox specifications. If the from
field contains more than one mailbox specification in the mailbox-
list, then the sender field, containing the field name "Sender" and a
single mailbox specification, MUST appear in the message. In either
case, an optional reply-to field MAY also be included, which contains
the field name "Reply-To" and a comma-separated list of one or more
addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
Resnick Standards Track [Page 22]
RFC 5322 Internet Message Format October 2008
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
Note: The transmitter information is always present. The absence
of the "Sender:" field is sometimes mistakenly taken to mean that
the agent responsible for transmission of the message has not been
specified. This absence merely means that the transmitter is
identical to the author and is therefore not redundantly placed
into the "Sender:" field.
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the address(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. See also section
3.6.3 for more information on forming the destination addresses for a
reply.
3.6.3. Destination Address Fields
The destination fields of a message consist of three possible fields,
each of the same form: the field name, which is either "To", "Cc", or
"Bcc", followed by a comma-separated list of one or more addresses
(either mailbox or group syntax).
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" [address-list / CFWS] CRLF
The destination fields specify the recipients of the message. Each
destination field may have one or more addresses, and the addresses
indicate the intended recipients of the message. The only difference
between the three fields is how each is used.
The "To:" field contains the address(es) of the primary recipient(s)
of the message.
Resnick Standards Track [Page 23]
RFC 5322 Internet Message Format October 2008
The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
making a copy on a typewriter using carbon paper) contains the
addresses of others who are to receive the message, though the
content of the message may not be directed at them.
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.
When a message is a reply to another message, the mailboxes of the
authors of the original message (the mailboxes in the "From:" field)
or mailboxes specified in the "Reply-To:" field (if it exists) MAY
appear in the "To:" field of the reply since these would normally be
the primary recipients of the reply. If a reply is sent to a message
that has destination fields, it is often desirable to send a copy of
the reply to all of the recipients of the message, in addition to the
author. When such a reply is formed, addresses in the "To:" and
"Cc:" fields of the original message MAY appear in the "Cc:" field of
the reply, since these are normally secondary recipients of the
reply. If a "Bcc:" field is present in the original message,
addresses in that field MAY appear in the "Bcc:" field of the reply,
but they SHOULD NOT appear in the "To:" or "Cc:" fields.
Note: Some mail applications have automatic reply commands that
include the destination addresses of the original message in the
destination addresses of the reply. How those reply commands
behave is implementation dependent and is beyond the scope of this
document. In particular, whether or not to include the original
destination addresses when the original message had a "Reply-To:"
field is not addressed here.
Resnick Standards Track [Page 24]
RFC 5322 Internet Message Format October 2008
3.6.4. Identification Fields
Though listed as optional in the table in section 3.6, every message
SHOULD have a "Message-ID:" field. Furthermore, reply messages
SHOULD have "In-Reply-To:" and "References:" fields as appropriate
and as described below.
The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" fields each contain one or more
unique message identifiers, optionally separated by CFWS.
The message identifier (msg-id) syntax is a limited version of the
addr-spec construct enclosed in the angle bracket characters, "<" and
">". Unlike addr-spec, this syntax only permits the dot-atom-text
form on the left-hand side of the "@" and does not have internal CFWS
anywhere in the message identifier.
Note: As with addr-spec, a liberal syntax is given for the right-
hand side of the "@" in a msg-id. However, later in this section,
the use of a domain for the right-hand side of the "@" is
RECOMMENDED. Again, the syntax of domain constructs is specified
by and used in other protocols (e.g., [RFC1034], [RFC1035],
[RFC1123], [RFC5321]). It is therefore incumbent upon
implementations to conform to the syntax of addresses for the
context in which they are used.
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left = dot-atom-text / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-literal = "[" *dtext "]"
The "Message-ID:" field provides a unique message identifier that
refers to a particular version of a particular message. The
uniqueness of the message identifier is guaranteed by the host that
generates it (see below). This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A message
identifier pertains to exactly one version of a particular message;
subsequent revisions to the message each receive new message
identifiers.
Resnick Standards Track [Page 25]
RFC 5322 Internet Message Format October 2008
Note: There are many instances when messages are "changed", but
those changes do not constitute a new instantiation of that
message, and therefore the message would not get a new message
identifier. For example, when messages are introduced into the
transport system, they are often prepended with additional header
fields such as trace fields (described in section 3.6.7) and
resent fields (described in section 3.6.6). The addition of such
header fields does not change the identity of the message and
therefore the original "Message-ID:" field is retained. In all
cases, it is the meaning that the sender of the message wishes to
convey (i.e., whether this is the same message or a different
message) that determines whether or not the "Message-ID:" field
changes, not any particular syntactic difference that appears (or
does not appear) in the message.
The "In-Reply-To:" and "References:" fields are used when creating a
reply to a messa
Network Working Group J. Klensin
Request for Comments: 5321 October 2008
Obsoletes: 2821
Updates: 1123
Category: Standards Track
Simple Mail Transfer Protocol
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
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 submission"
protocol for "split-UA" (User Agent) mail reading systems and mobile
environments.
Klensin Standards Track [Page 1]
RFC 5321 SMTP October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
1.2. History and Context for This Document . . . . . . . . . . 5
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Definition and Registration of Extensions . . . . . . 10
2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
2.4. General Syntax Principles and Transaction Model . . . . . 16
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
3.4. Forwarding for Address Correction or Updating . . . . . . 21
3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
Klensin Standards Track [Page 2]
RFC 5321 SMTP October 2008
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
4.2.5. Reply Codes after DATA and the Subsequent
<crlf>.<crlf> . . . . . . . . . . . . . . . . . . . . 53 </crlf></crlf>
4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
Klensin Standards Track [Page 3]
RFC 5321 SMTP October 2008
6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
7.5. Information Disclosure in Announcements . . . . . . . . . 77
7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
7.7. Information Disclosure in Message Forwarding . . . . . . . 78
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
10.2. Informative References . . . . . . . . . . . . . . . . . . 82
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
Klensin Standards Track [Page 4]
RFC 5321 SMTP October 2008
1. Introduction
1.1. Transport of Electronic Mail
The objective of the Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. While this
document specifically discusses transport over TCP, other transports
are possible. Appendices to RFC 821 [1] describe some of them.
An important feature of SMTP is its capability to transport mail
across multiple networks, usually referred to as "SMTP mail relaying"
(see Section 3.6). A network consists of the mutually-TCP-accessible
hosts on the public Internet, the mutually-TCP-accessible hosts on a
firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
environment utilizing a non-TCP transport-level protocol. Using
SMTP, a process can transfer mail to another process on the same
network or to some other network via a relay or gateway process
accessible to both networks.
In this way, a mail message may pass through a number of intermediate
relay or gateway hosts on its path from sender to ultimate recipient.
The Mail eXchanger mechanisms of the domain name system (RFC 1035
[2], RFC 974 [12], and Section 5 of this document) are used to
identify the appropriate next-hop destination for a message being
transported.
1.2. History and Context for This Document
This document is a specification of the basic protocol for the
Internet electronic mail transport. It consolidates, updates and
clarifies, but does not add new or change existing functionality of
the following:
o the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [1],
o domain name system requirements and implications for mail
transport from RFC 1035 [2] and RFC 974 [12],
o the clarifications and applicability statements in RFC 1123 [3],
and
o material drawn from the SMTP Extension mechanisms in RFC 1869
[13].
Klensin Standards Track [Page 5]
RFC 5321 SMTP October 2008
o Editorial and clarification changes to RFC 2821 [14] to bring that
specification to Draft Standard.
It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC
1123 (replacing the mail transport materials of RFC 1123). However,
RFC 821 specifies some features that were not in significant use in
the Internet by the mid-1990s and (in appendices) some additional
transport models. Those sections are omitted here in the interest of
clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required
amplification. This material has been identified in multiple ways,
mostly by tracking flaming on various lists and newsgroups and
problems of unusual readings or interpretations that have appeared as
the SMTP extensions have been deployed. Where this specification
moves beyond consolidation and actually differs from earlier
documents, it supersedes them technically as well as textually.
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 submission" protocol, as recommended for Post Office
Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501
[17]). In general, the separate mail submission protocol specified
in RFC 4409 [18] is now preferred to direct use of SMTP; more
discussion of that subject appears in that document.
Section 2.3 provides definitions of terms specific to this document.
Except when the historical terminology is necessary for clarity, this
document uses the current 'client' and 'server' terminology to
identify the sending and receiving SMTP processes, respectively.
A companion document, RFC 5322 [4], discusses message header sections
and bodies and specifies formats and structures for them.
1.3. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5]. As each
of these terms was intentionally and carefully chosen to improve the
interoperability of email, each use of these terms is to be treated
as a conformance requirement.
Because this document has a long history and to avoid the risk of
various errors and of confusing readers and documents that point to
this one, most examples and the domain names they contain are
preserved from RFC 2821. Readers are cautioned that these are
Klensin Standards Track [Page 6]
RFC 5321 SMTP October 2008
illustrative examples that should not actually be used in either code
or configuration files.
2. The SMTP Model
2.1. Basic Structure
The SMTP design can be pictured as:
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
The means by which a mail message is presented to an SMTP client, and
how that client determines the identifier(s) ("names") of the
domain(s) to which mail messages are to be transferred, is a local
matter, and is not addressed by this document. In some cases, the
designated domain(s), or those determined by an SMTP client, will
identify the final destination(s) of the mail message. In other
cases, common with SMTP clients associated with implementations of
the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17])
protocols, or when the SMTP client is inside an isolated transport
service environment, the domain determined will identify an
intermediate destination through which all mail messages are to be
relayed. SMTP clients that transfer all traffic regardless of the
target domains associated with the individual messages, or that do
not maintain queues for retrying message transmissions that initially
cannot be completed, may otherwise conform to this specification but
are not considered fully-capable. Fully-capable SMTP
implementations, including the relays used by these less capable
ones, and their destinations, are expected to support all of the
queuing, retrying, and alternate address functions discussed in this
specification. In many situations and configurations, the less-
capable clients discussed above SHOULD be using the message
submission protocol (RFC 4409 [18]) rather than SMTP.
Klensin Standards Track [Page 7]
RFC 5321 SMTP October 2008
The means by which an SMTP client, once it has determined a target
domain, determines the identity of an SMTP server to which a copy of
a message is to be transferred, and then performs that transfer, is
covered by this document. To effect a mail transfer to an SMTP
server, an SMTP client establishes a two-way transmission channel to
that SMTP server. An SMTP client determines the address of an
appropriate host running an SMTP server by resolving a destination
domain name to either an intermediate Mail eXchanger host or a final
target host.
An SMTP server may be either the ultimate destination or an
intermediate "relay" (that is, it may assume the role of an SMTP
client after receiving the message) or "gateway" (that is, it may
transport the message further using some protocol other than SMTP).
SMTP commands are generated by the SMTP client and sent to the SMTP
server. SMTP replies are sent from the SMTP server to the SMTP
client in response to the commands.
In other words, message transfer can occur in a single connection
between the original SMTP-sender and the final SMTP-recipient, or can
occur in a series of hops through intermediary systems. In 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).
Once the transmission channel is established and initial handshaking
is completed, the SMTP client normally initiates a mail transaction.
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any lines in the header section or other
structure) itself. When the same message is sent to multiple
recipients, this protocol encourages the transmission of only one
copy of the data for all recipients at the same destination (or
intermediate relay) host.
The server responds to each command with a reply; replies may
indicate that the command was accepted, that additional commands are
expected, or that a temporary or permanent error condition exists.
Commands specifying the sender or recipients may include server-
permitted SMTP service extension requests, as discussed in
Section 2.2. The dialog is purposely lock-step, one-at-a-time,
although this can be modified by mutually agreed upon extension
requests such as command pipelining (RFC 2920 [19]).
Once a given mail message has been transmitted, the client may either
request that the connection be shut down or may initiate other mail
Klensin Standards Track [Page 8]
RFC 5321 SMTP October 2008
transactions. In addition, an SMTP client may use a connection to an
SMTP server for ancillary services such as verification of email
addresses or retrieval of mailing list subscriber addresses.
As suggested above, this protocol provides mechanisms for the
transmission of mail. Historically, this transmission normally
occurred directly from the sending user's host to the receiving
user's host when the two hosts are connected to the same transport
service. When they are not connected to the same transport service,
transmission occurs via one or more relay SMTP servers. A very
common case in the Internet today involves submission of the original
message to an intermediate, "message submission" server, which is
similar to a relay but has some additional properties; such servers
are discussed in Section 2.3.10 and at some length in RFC 4409 [18].
An intermediate host that acts as either an SMTP relay or as a
gateway into some other transmission environment is usually selected
through the use of the domain name service (DNS) Mail eXchanger
mechanism.
Usually, intermediate hosts are determined via the DNS MX record, not
by explicit "source" routing (see Section 5 and Appendix C and
Appendix F.2).
2.2. The Extension Model
2.2.1. Background
In an effort that started in 1990, approximately a decade after RFC
821 was completed, the protocol was modified with a "service
extensions" model that permits the client and server to agree to
utilize shared functionality beyond the original SMTP requirements.
The SMTP extension mechanism defines a means whereby an extended SMTP
client and server may recognize each other, and the server can inform
the client as to the service extensions that it supports.
Contemporary SMTP implementations MUST support the basic extension
mechanisms. For 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. (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.
SMTP is widely deployed and high-quality implementations have proven
to be very robust. However, the Internet community now considers
some services to be important that were not anticipated when the
protocol was first designed. If support for those services is to be
Klensin Standards Track [Page 9]
RFC 5321 SMTP October 2008
added, it must be done in a way that permits older implementations to
continue working acceptably. The extension framework consists of:
o The SMTP command EHLO, superseding the earlier HELO,
o a registry of SMTP service extensions,
o additional parameters to the SMTP MAIL and RCPT commands, and
o optional replacements for commands defined in this protocol, such
as for DATA in non-ASCII transmissions (RFC 3030 [20]).
SMTP's strength comes primarily from its simplicity. Experience with
many protocols has shown that protocols with few options tend towards
ubiquity, whereas protocols with many options tend towards obscurity.
Each and every extension, regardless of its benefits, must be
carefully scrutinized with respect to its implementation, deployment,
and interoperability costs. In many cases, the cost of extending the
SMTP service will likely outweigh the benefit.
2.2.2. Definition and Registration of Extensions
The IANA maintains a registry of SMTP service extensions. A
corresponding EHLO keyword value is associated with each extension.
Each service extension registered with the IANA must be defined in a
formal Standards-Track or IESG-approved Experimental protocol
document. The definition must include:
o the textual name of the SMTP service extension;
o the EHLO keyword value associated with the extension;
o the syntax and possible values of parameters associated with the
EHLO keyword value;
o any additional SMTP verbs associated with the extension
(additional verbs will usually be, but are not required to be, the
same as the EHLO keyword value);
o any new parameters the extension associates with the MAIL or RCPT
verbs;
o a description of how support for the extension affects the
behavior of a server and client SMTP; and
Klensin Standards Track [Page 10]
RFC 5321 SMTP October 2008
o the increment by which the extension is increasing the maximum
length of the commands MAIL and/or RCPT, over that specified in
this Standard.
In addition, any EHLO keyword value starting with an upper or lower
case "X" refers to a local SMTP service extension used exclusively
through bilateral agreement. Keywords beginning with "X" MUST NOT be
used in a registered service extension. Conversely, 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. A
conforming server MUST NOT offer non-"X"-prefixed keyword values that
are not described in a registered extension.
Additional verbs and parameter names are bound by the same rules as
EHLO keywords; specifically, verbs beginning with "X" are local
extensions that may not be registered or standardized. Conversely,
verbs not beginning with "X" must always be registered.
2.2.3. Special Issues with Extensions
Extensions that change fairly basic properties of SMTP operation are
permitted. The text in other sections of this document must be
understood in that context. In particular, extensions can change the
minimum limits specified in Section 4.5.3, can change the ASCII
character set requirement as mentioned above, or can introduce some
optional modes of message handling.
In 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. If 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. SMTP Terminology
2.3.1. Mail Objects
SMTP transports a mail object. A mail object contains an envelope
and content.
The SMTP envelope is sent as a series of SMTP protocol units
(described in Section 3). It consists of an originator address (to
Klensin Standards Track [Page 11]
RFC 5321 SMTP October 2008
which error reports should be directed), one or more recipient
addresses, and optional protocol extension material. Historically,
variations on the reverse-path (originator) address specification
command (MAIL) could be used to specify alternate delivery modes,
such as immediate display; those variations have now been deprecated
(see Appendix F and Appendix F.6).
The SMTP content is sent in the SMTP DATA protocol unit and has two
parts: the header section and the body. If the content conforms to
other contemporary standards, the header section consists of a
collection of header fields, each consisting of a header name, a
colon, and data, structured as in the message format specification
(RFC 5322 [4]); the body, if structured, is defined according to MIME
(RFC 2045 [21]). The content is textual in nature, expressed using
the US-ASCII repertoire [6]. Although SMTP extensions (such as
"8BITMIME", RFC 1652 [22]) may relax this restriction for the content
body, the content header fields are always encoded using the US-ASCII
repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24])
define an algorithm for representing header values outside the US-
ASCII repertoire, while still encoding them using the US-ASCII
repertoire.
2.3.2. Senders and Receivers
In RFC 821, the two hosts participating in an SMTP transaction were
described as the "SMTP-sender" and "SMTP-receiver". This document
has been changed to reflect current industry terminology and hence
refers to them as the "SMTP client" (or sometimes just "the client")
and "SMTP server" (or just "the server"), respectively. Since a
given host may act both as server and client in a relay situation,
"receiver" and "sender" terminology is still used where needed for
clarity.
2.3.3. Mail Agents and Message Stores
Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Agents" (MUAs or UAs) are normally thought of as the sources and
targets of mail. At the source, an MUA might collect mail to be
transmitted from a user and hand it off to an MTA; the final
("delivery") MTA would be thought of as handing the mail off to an
MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a "message store"). However, while these
terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs
often do not accurately match common, and conforming, practices with
Klensin Standards Track [Page 12]
RFC 5321 SMTP October 2008
Internet mail. Hence, the reader should be cautious about inferring
the strong relationships and responsibilities that might be implied
if these terms were used elsewhere.
2.3.4. Host
For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP
network) and supporting the SMTP protocol. Hosts 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
A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
for SMTP purposes to consist of a sequence of letters, digits, and
hyphens drawn from the ASCII character set [6]. Domain names are
used as names of hosts and of other entities in the domain name
hierarchy. For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [2]
and Section 5 of this specification.
The domain name, as described in this document and in RFC 1035 [2],
is the entire, fully-qualified name (often referred to as an "FQDN").
A domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:
o 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.
Klensin Standards Track [Page 13]
RFC 5321 SMTP October 2008
o 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.6. Buffer and State Table
SMTP sessions are stateful, with both parties carefully maintaining a
common view of the current state. In this document, we model this
state by a virtual "buffer" and a "state table" on the server that
may be used by the client to, for example, "clear the buffer" or
"reset the state table", causing the information in the buffer to be
discarded and the state to be returned to some previous state.
2.3.7. Commands and Replies
SMTP commands and, unless altered by a service extension, message
data, are transmitted from the sender to the receiver via the
transmission channel in "lines".
An SMTP reply is an acknowledgment (positive or negative) sent in
"lines" from receiver to sender via the transmission channel in
response to a command. The general form of a reply is a numeric
completion code (indicating failure or success) usually followed by a
text string. The codes are for use by programs and the text is
usually intended for human users. RFC 3463 [25], specifies further
structuring of the reply strings, including the use of supplemental
and more specific completion codes (see also RFC 5248 [26]).
2.3.8. Lines
Lines consist of zero or more data characters terminated by the
sequence ASCII character "CR" (hex value 0D) followed immediately by
ASCII character "LF" (hex value 0A). This termination sequence is
denoted as <crlf> in this document. Conforming implementations MUST </crlf>
NOT recognize or generate any other character or character sequence
as a line terminator. Limits MAY be imposed on line lengths by
servers (see Section 4).
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP 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></crlf>
sequence.
Klensin Standards Track [Page 14]
RFC 5321 SMTP October 2008
2.3.9. Message Content and Mail Data
The terms "message content" and "mail data" are used interchangeably
in this document to describe the material transmitted after the DATA
command is accepted and before the end of data indication is
transmitted. Message content includes the message header section and
the possibly structured message body. The MIME specification (RFC
2045 [21]) provides the standard mechanisms for structured message
bodies.
2.3.10. Originator, Delivery, Relay, and Gateway Systems
This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store that
a mail user agent is expected to subsequently access. A "relay" SMTP
system (usually referred to just as a "relay") receives mail from an
SMTP client and transmits it, without modification to the message
data other than adding trace information, to another SMTP server for
further relaying or for delivery.
A "gateway" SMTP system (usually referred to just as a "gateway")
receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway
system perform transformations to the message that are not permitted
to SMTP relay systems. For the purposes of this specification,
firewalls that rewrite addresses should be considered as gateways,
even if SMTP is used on both sides of them (see RFC 2979 [27]).
2.3.11. Mailbox and Address
As used in this specification, an "address" is a character string
that identifies a user to whom mail will be sent or a location into
which mail will be deposited. The term "mailbox" refers to that
depository. The two terms are typically used interchangeably unless
the distinction between the location in which mail is placed (the
mailbox) and a reference to it (the address) is important. An
address normally consists of user and domain specifications. The
standard mailbox naming convention is defined to be
"local-part@domain"; contemporary usage permits a much broader set of
applications than simple "user names". Consequently, and due to a
long history of problems when intermediate hosts have attempted to
Klensin Standards Track [Page 15]
RFC 5321 SMTP October 2008
optimize 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
SMTP commands and replies have a rigid syntax. All commands begin
with a command verb. All replies begin with a three digit numeric
code. In some commands and replies, arguments are required following
the verb or reply code. Some commands do not accept arguments (after
the verb), and some reply codes are followed, sometimes optionally,
by free form text. In both cases, where text appears, it is
separated from the verb or reply code by a space character. Complete
definitions of commands and replies appear in Section 4.
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part (SMTP
Extensions may explicitly specify case-sensitive elements). That 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. The
local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case
of mailbox local-parts. In particular, for some hosts, the user
"smith" is different from the user "Smith". However, exploiting the
case sensitivity of mailbox local-parts impedes interoperability and
is discouraged. Mailbox domains follow normal DNS rules and are
hence not case sensitive.
A few SMTP servers, in violation of this specification (and RFC 821)
require that command verbs be encoded by clients in upper case.
Implementations MAY wish to employ this encoding to accommodate those
servers.
The argument clause consists of a variable-length character string
ending with the end of the line, i.e., with the character sequence
<crlf>. The receiver will take no action until this sequence is </crlf>
received.
The syntax for each command is shown with the discussion of that
command. Common elements and parameters are shown in Section 4.1.2.
Commands and replies are composed of characters from the ASCII
character set [6]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted,
right justified, in an octet with the high-order bit cleared to zero.
More specifically, the unextended SMTP service provides 7-bit
Klensin Standards Track [Page 16]
RFC 5321 SMTP October 2008
transport only. An 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. If such messages are transmitted in
violation of this rule, receiving SMTP servers MAY clear the high-
order bit or reject the message as invalid. In 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. Of course, if the content is mislabeled and
the data path cannot accept the actual content, this may result in
the ultimate delivery of a severely garbled message to the recipient.
Delivery SMTP systems MAY reject such messages, or return them as
undeliverable, rather than deliver them. In the absence of a server-
offered extension explicitly permitting it, a sending SMTP system is
not permitted to send envelope commands in any character set other
than US-ASCII. Receiving systems SHOULD reject such commands,
normally using "500 syntax error - invalid character" replies.
8-bit message content transmission MAY be requested of the server by
a client using extended SMTP facilities, notably the "8BITMIME"
extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP
servers. However, 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. 8BITMIME
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.
The metalinguistic notation used in this document corresponds to the
"Augmented BNF" used in other Internet mail system documents. The
reader who is not familiar with that syntax should consult the ABNF
specification in RFC 5234 [7]. Metalanguage terms used in running
text are surrounded by pointed brackets (e.g., <crlf>) for clarity. </crlf>
The reader is cautioned that the grammar expressed in the
metalanguage is not comprehensive. There are many instances in which
provisions in the text constrain or otherwise modify the syntax or
semantics implied by the grammar.
3. The SMTP Procedures: An Overview
This section contains descriptions of the procedures used in SMTP:
session initiation, mail transaction, forwarding mail, verifying
mailbox names and expanding mailing lists, and opening and closing
exchanges. Comments on relaying, a note on mail domains, and a
discussion of changing roles are included at the end of this section.
Several complete scenarios are presented in Appendix D.
Klensin Standards Track [Page 17]
RFC 5321 SMTP October 2008
3.1. Session Initiation
An SMTP session is initiated when a client opens a connection to a
server and the server responds with an opening message.
SMTP 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. Implementations MAY make provision for
SMTP servers to disable the software and version announcement where
it causes security concerns. While some systems also identify their
contact point for mail problems, this is not a substitute for
maintaining the required "postmaster" address (see Section 4).
The 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. A 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". Since 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
Once the server has sent the greeting (welcoming) message and the
client has received it, the client normally sends the EHLO command to
the server, indicating the client's identity. In addition to opening
the session, use of EHLO indicates that the client is able to process
service extensions and requests that the server provide a list of the
extensions it supports. Older 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. Servers MUST NOT return the extended EHLO-
style response to a HELO command. For 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.
In the EHLO command, the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am <domain>" (and, </domain>
in the case of EHLO, "and I support service extension requests").
Klensin Standards Track [Page 18]
RFC 5321 SMTP October 2008
3.3. Mail Transactions
There are three steps to SMTP mail transactions. The transaction
starts with a MAIL command that gives the sender identification. (In
general, the MAIL command may be sent only when no mail transaction
is in progress; see Section 4.1.4.) A series of one or more RCPT
commands follows, giving the receiver information. Then, a DATA
command initiates transfer of the mail data and is terminated by the
"end of mail" data indicator, which also confirms the transaction.
The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <crlf></crlf></mail-parameters></reverse-path>
This command tells the SMTP-receiver that a new mail transaction is
starting and to reset all its state tables and buffers, including any
recipients or mail data. The <reverse-path> portion of the first or </reverse-path>
only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors (see Section 4.2 for a
discussion of error reporting). If accepted, the SMTP server returns
a "250 OK" reply. If 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). Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In 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. Normally, failures produce 550 or 553 replies.
Historically, the <reverse-path> was permitted to contain more than </reverse-path>
just a mailbox; however, contemporary systems SHOULD NOT use source
routing (see Appendix C).
The optional <mail-parameters> are associated with negotiated SMTP </mail-parameters>
service extensions (see Section 2.2).
The second step in the procedure is the RCPT command. This step of
the procedure can be repeated any number of times.
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <crlf></crlf></rcpt-parameters></forward-path>
The first or only argument to this command includes a forward-path
(normally a mailbox and domain, always surrounded by "<" and ">"
brackets) identifying one recipient. If accepted, the SMTP server
returns a "250 OK" reply and stores the forward-path. If the
Klensin Standards Track [Page 19]
RFC 5321 SMTP October 2008
recipient is known not to be a deliverable address, the SMTP server
returns a 550 reply, typically with a string such as "no such user -
" and the mailbox name (other circumstances and reply codes are
possible).
The <forward-path> can contain more than just a mailbox. </forward-path>
Historically, the <forward-path> was permitted to contain a source </forward-path>
routing list of hosts and the destination mailbox; however,
contemporary SMTP clients SHOULD NOT utilize source routes (see
Appendix C). Servers 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. Similarly, servers MAY
decline to accept mail that is destined for other hosts or systems.
These restrictions make a server useless as a relay for clients that
do not support full SMTP functionality. Consequently, restricted-
capability clients MUST NOT assume that any SMTP server on the
Internet can be used as their mail processing (relaying) site. If a
RCPT command appears without a previous MAIL command, the server MUST
return a 503 "Bad sequence of commands" response. The optional
<rcpt-parameters> are associated with negotiated SMTP service </rcpt-parameters>
extensions (see Section 2.2).
Since it has been a common source of errors, it is worth noting that
spaces are not permitted on either side of the colon following FROM
in the MAIL command or TO in the RCPT command. The syntax is exactly
as given above.
The third step in the procedure is the DATA command (or some
alternative specified in a service extension).
DATA <crlf></crlf>
If accepted, the SMTP server returns a 354 Intermediate reply and
considers all succeeding lines up to but not including the end of
mail data indicator to be the message text. When the end of text is
successfully received and stored, the SMTP-receiver sends a "250 OK"
reply.
Since the mail data is sent on the transmission channel, the end of
mail data must be indicated so that the command and reply dialog can
be resumed. SMTP indicates the end of the mail data by sending a
line containing only a "." (period or full stop). A transparency
procedure is used to prevent this from interfering with the user's
text (see Section 4.5.2).
The end of mail data indicator also confirms the mail transaction and
tells the SMTP server to now process the stored recipients and mail
Klensin Standards Track [Page 20]
RFC 5321 SMTP October 2008
data. If accepted, the SMTP server returns a "250 OK" reply. The
DATA command can fail at only two points in the protocol exchange:
If 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.
If 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.
If the verb is initially accepted and the 354 reply issued, the DATA
command should fail only if the mail transaction was incomplete (for
example, no recipients), if resources were unavailable (including, of
course, the server unexpectedly becoming unavailable), or if the
server determines that the message should be rejected for policy or
other reasons.
However, in practice, some servers do not perform recipient
verification until after the message text is received. These 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. Using a "550 mailbox not found" (or
equivalent) reply code after the data are accepted makes it difficult
or impossible for the client to determine which recipients failed.
When the RFC 822 format ([28], [4]) is being used, the mail data
include the header fields such as those named Date, Subject, To, Cc,
and From. Server 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. In 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.
Mail transaction commands MUST be used in the order discussed above.
3.4. Forwarding for Address Correction or Updating
Forwarding support is most often required to consolidate and simplify
addresses within, or relative to, some enterprise and less frequently
to establish addresses to link a person's prior address with a
current one. Silent forwarding of messages (without server
notification to the sender), for security or non-disclosure purposes,
is common in the contemporary Internet.
In both the enterprise and the "new address" cases, information
hiding (and sometimes security) considerations argue against exposure
of the "final" address through the SMTP protocol as a side effect of
the forwarding activity. This may be especially important when the
Klensin Standards Track [Page 21]
RFC 5321 SMTP October 2008
final address may not even be reachable by the sender. Consequently,
the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
especially the 251 (corrected destination) and 551 reply codes from
RCPT must be evaluated carefully by implementers and, when they are
available, by those configuring systems (see also Section 7.4).
In particular:
o Servers MAY forward messages when they are aware of an address
change. When they do so, they MAY either provide address-updating
information with a 251 code, or may forward "silently" and return
a 250 code. However, 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.
Alternately,
o Servers MAY reject messages or return them as non-deliverable when
they cannot be delivered precisely as addressed. When 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. However, 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.
SMTP 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. Commands for Debugging Addresses
3.5.1. Overview
SMTP provides commands to verify a user name or obtain the content of
a mailing list. This is done with the VRFY and EXPN commands, which
have character string arguments. Implementations SHOULD support VRFY
and EX
Network Working Group J. MyersRequest for Comments: 2554 Netscape Communications
Category: Standards Track March 1999
SMTP Service Extension
for Authentication
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Introduction
This document defines an SMTP service extension [ESMTP] whereby an
SMTP client may indicate an authentication mechanism to the server,
perform an authentication protocol exchange, and optionally negotiate
a security layer for subsequent protocol interactions. This
extension is a profile of the Simple Authentication and Security
Layer [SASL].
2. Conventions Used in this Document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
3. The Authentication service extension
(1) the name of the SMTP service extension is "Authentication"
(2) the EHLO keyword value associated with this extension is "AUTH"
Myers Standards Track [Page 1]
RFC 2554 SMTP Authentication March 1999
(3) The AUTH EHLO keyword contains as a parameter a space separated
list of the names of supported SASL mechanisms.
(4) a new SMTP verb "AUTH" is defined
(5) an optional parameter using the keyword "AUTH" is added to the
MAIL FROM command, and extends the maximum line length of the
MAIL FROM command by 500 characters.
(6) this extension is appropriate for the submission protocol
[SUBMIT].
4. The AUTH command
AUTH mechanism [initial-response]
Arguments:
a string identifying a SASL authentication mechanism.
an optional base64-encoded response
Restrictions:
After an AUTH command has successfully completed, no more AUTH
commands may be issued in the same session. After a successful
AUTH command completes, a server MUST reject any further AUTH
commands with a 503 reply.
The AUTH command is not permitted during a mail transaction.
Discussion:
The AUTH command indicates an authentication mechanism to the
server. If the server supports the requested authentication
mechanism, it performs an authentication protocol exchange to
authenticate and identify the user. Optionally, it also
negotiates a security layer for subsequent protocol
interactions. If the requested authentication mechanism is not
supported, the server rejects the AUTH command with a 504
reply.
The authentication protocol exchange consists of a series of
server challenges and client answers that are specific to the
authentication mechanism. A server challenge, otherwise known
as a ready response, is a 334 reply with the text part
containing a BASE64 encoded string. The client answer consists
of a line containing a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
with a single "*". If the server receives such an answer, it
MUST reject the AUTH command by sending a 501 reply.
Myers Standards Track [Page 2]
RFC 2554 SMTP Authentication March 1999
The optional initial-response argument to the AUTH command is
used to save a round trip when using authentication mechanisms
that are defined to send no data in the initial challenge.
When the initial-response argument is used with such a
mechanism, the initial empty challenge is not sent to the
client and the server uses the data in the initial-response
argument as if it were sent in response to the empty challenge.
Unlike a zero-length client answer to a 334 reply, a zero-
length initial response is sent as a single equals sign ("=").
If the client uses an initial-response argument to the AUTH
command with a mechanism that sends data in the initial
challenge, the server rejects the AUTH command with a 535
reply.
If the server cannot BASE64 decode the argument, it rejects the
AUTH command with a 501 reply. If the server rejects the
authentication data, it SHOULD reject the AUTH command with a
535 reply unless a more specific error code, such as one listed
in section 6, is appropriate. Should the client successfully
complete the authentication exchange, the SMTP server issues a
235 reply.
The service name specified by this protocol's profile of SASL
is "smtp".
If a security layer is negotiated through the SASL
authentication exchange, it takes effect immediately following
the CRLF that concludes the authentication exchange for the
client, and the CRLF of the success reply for the server. Upon
a security layer's taking effect, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a
220 service ready greeting). The server MUST discard any
knowledge obtained from the client, such as the argument to the
EHLO command, which was not obtained from the SASL negotiation
itself. The client MUST discard any knowledge obtained from
the server, such as the list of SMTP service extensions, which
was not obtained from the SASL negotiation itself (with the
exception that a client MAY compare the list of advertised SASL
mechanisms before and after authentication in order to detect
an active down-negotiation attack). The client SHOULD send an
EHLO command as the first command after a successful SASL
negotiation which results in the enabling of a security layer.
The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any security layers. If an AUTH command
fails, the client may try another authentication mechanism by
issuing another AUTH command.
Myers Standards Track [Page 3]
RFC 2554 SMTP Authentication March 1999
If an AUTH command fails, the server MUST behave the same as if
the client had not issued the AUTH command.
The BASE64 string may in general be arbitrarily long. Clients
and servers MUST be able to support challenges and responses
that are as long as are generated by the authentication
mechanisms they support, independent of any line length
limitations the client or server may have in other parts of its
protocol implementation.
Examples:
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
5. The AUTH parameter to the MAIL FROM command
AUTH=addr-spec
Arguments:
An addr-spec containing the identity which submitted the message
to the delivery system, or the two character sequence "<>"
indicating such an identity is unknown or insufficiently
authenticated. To comply with the restrictions imposed on ESMTP
parameters, the addr-spec is encoded inside an xtext. The syntax
of an xtext is described in section 5 of [ESMTP-DSN].
Discussion:
The optional AUTH parameter to the MAIL FROM command allows
cooperating agents in a trusted environment to communicate the
authentication of individual messages.
If the server trusts the authenticated identity of the client to
assert that the message was originally submitted by the supplied
addr-spec, then the server SHOULD supply the same addr-spec in an
AUTH parameter when relaying the message to any server which
supports the AUTH extension.
Myers Standards Track [Page 4]
RFC 2554 SMTP Authentication March 1999
A MAIL FROM parameter of AUTH=<> indicates that the original
submitter of the message is not known. The server MUST NOT treat
the message as having been originally submitted by the client.
If the AUTH parameter to the MAIL FROM is not supplied, the
client has authenticated, and the server believes the message is
an original submission by the client, the server MAY supply the
client's identity in the addr-spec in an AUTH parameter when
relaying the message to any server which supports the AUTH
extension.
If the server does not sufficiently trust the authenticated
identity of the client, or if the client is not authenticated,
then the server MUST behave as if the AUTH=<> parameter was
supplied. The server MAY, however, write the value of the AUTH
parameter to a log file.
If an AUTH=<> parameter was supplied, either explicitly or due to
the requirement in the previous paragraph, then the server MUST
supply the AUTH=<> parameter when relaying the message to any
server which it has authenticated to using the AUTH extension.
A server MAY treat expansion of a mailing list as a new
submission, setting the AUTH parameter to the mailing list
address or mailing list administration address when relaying the
message to list subscribers.
It is conforming for an implementation to be hard-coded to treat
all clients as being insufficiently trusted. In that case, the
implementation does nothing more than parse and discard
syntactically valid AUTH parameters to the MAIL FROM command and
supply AUTH=<> parameters to any servers to which it
authenticates using the AUTH extension.
Examples:
C: MAIL FROM:<e> AUTH=e+3Dmc2@example.com </e>
S: 250 OK
Myers Standards Track [Page 5]
RFC 2554 SMTP Authentication March 1999
6. Error Codes
The following error codes may be used to indicate various conditions
as described.
432 A password transition is needed
This response to the AUTH command indicates that the user needs to
transition to the selected authentication mechanism. This typically
done by authenticating once using the PLAIN authentication mechanism.
534 Authentication mechanism is too weak
This response to the AUTH command indicates that the selected
authentication mechanism is weaker than server policy permits for
that user.
538 Encryption required for requested authentication mechanism
This response to the AUTH command indicates that the selected
authentication mechanism may only be used when the underlying SMTP
connection is encrypted.
454 Temporary authentication failure
This response to the AUTH command indicates that the authentication
failed due to a temporary server failure.
530 Authentication required
This response may be returned by any command other than AUTH, EHLO,
HELO, NOOP, RSET, or QUIT. It indicates that server policy requires
authentication in order to perform the requested action.
Myers Standards Track [Page 6]
RFC 2554 SMTP Authentication March 1999
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
UPALPHA = %x41-5A ;; Uppercase: A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z
ALPHA = UPALPHA / LOALPHA ;; case insensitive
DIGIT = %x30-39 ;; Digits 0-9
HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
hexchar = "+" HEXDIGIT HEXDIGIT
xchar = %x21-2A / %x2C-3C / %x3E-7E
;; US-ASCII except for "+", "=", SPACE and CTL
xtext = *(xchar / hexchar)
AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
auth_type = 1*20AUTH_CHAR
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
*(CRLF [base64]) CRLF
auth_param = "AUTH=" xtext
;; The decoded form of the xtext MUST be either
;; an addr-spec or the two characters "<>"
base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64_terminal = (2base64_char "==") / (3base64_char "=")
continue_req = "334" SPACE [base64] CRLF
Myers Standards Track [Page 7]
RFC 2554 SMTP Authentication March 1999
CR = %x0C ;; ASCII CR, carriage return
CRLF = CR LF
CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
LF = %x0A ;; ASCII LF, line feed
SPACE = %x20 ;; ASCII SP, space
8. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extensions", RFC 1869, November
1995.
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC
2476, December 1998.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
Myers Standards Track [Page 8]
RFC 2554 SMTP Authentication March 1999
9. Security Considerations
Security issues are discussed throughout this memo.
If a client uses this extension to get an encrypted tunnel through an
insecure network to a cooperating server, it needs to be configured
to never send mail to that server when the connection is not mutually
authenticated and encrypted. Otherwise, an attacker could steal the
client's mail by hijacking the SMTP connection and either pretending
the server does not support the Authentication extension or causing
all AUTH commands to fail.
Before the SASL negotiation has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker.
For this reason, clients and servers MUST discard any knowledge
obtained prior to the start of the SASL negotiation upon completion
of a SASL negotiation which results in a security layer.
This mechanism does not protect the TCP port, so an active attacker
may redirect a relay connection attempt to the submission port
[SUBMIT]. The AUTH=<> parameter prevents such an attack from causing
an relayed message without an envelope authentication to pick up the
authentication of the relay client.
A message submission client may require the user to authenticate
whenever a suitable SASL mechanism is advertised. Therefore, it may
not be desirable for a submission server [SUBMIT] to advertise a SASL
mechanism when use of that mechanism grants the client no benefits
over anonymous submission.
This extension is not intended to replace or be used instead of end-
to-end message signature and encryption systems such as S/MIME or
PGP. This extension addresses a different problem than end-to-end
systems; it has the following key differences:
(1) it is generally useful only within a trusted enclave
(2) it protects the entire envelope of a message, not just the
message's body.
(3) it authenticates the message submission, not authorship of the
message content
(4) it can give the sender some assurance the message was
delivered to the next hop in the case where the sender
mutually authenticates with the next hop and negotiates an
appropriate security layer.
Myers Standards Track [Page 9]
RFC 2554 SMTP Authentication March 1999
Additional security considerations are mentioned in the SASL
specification [SASL].
10. Author's Address
John Gardiner Myers
Netscape Communications
501 East Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043
EMail: jgmyers@netscape.com
Myers Standards Track [Page 10]
RFC 2554 SMTP Authentication March 1999
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Myers Standards Track [Page 11]
Network Working Group R. GellensRequest for Comments: 2476 QUALCOMM
Category: Standards Track J. Klensin
MCI
December 1998
Message Submission
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Table of Contents
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Information . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3
2.2. Conventions Used in this Document . . . . . . . . . . . 4
3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . 4
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4
3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5
3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Submission Rejection Code . . . . . . . . . . . 6
4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7
5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7
6.2. Require Authentication . . . . . . . . . . . . . . . . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8
6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
Gellens & Klensin Standards Track [Page 1]
RFC 2476 Message Submission December 1998
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15
1. Abstract
SMTP was defined as a message *transfer* protocol, that is, a means
to route (if needed) and deliver finished (complete) messages.
Message Transfer Agents (MTAs) are not supposed to alter the message
text, except to add 'Received', 'Return-Path', and other header
fields as required by [SMTP-MTA].
However, SMTP is now also widely used as a message *submission*
protocol, that is, a means for message user agents (MUAs) to
introduce new messages into the MTA routing network. The process
which accepts message submissions from MUAs is termed a Message
Submission Agent (MSA).
Messages being submitted are in some cases finished (complete)
messages, and in other cases are unfinished (incomplete) in some
aspect or other. Unfinished messages need to be completed to ensure
they conform to [MESSAGE-FORMAT], and later requirements. For
example, the message may lack a proper 'Date' header field, and
domains might not be fully qualified. In some cases, the MUA may be
unable to generate finished messages (for example, it might not know
its time zone). Even when submitted messages are complete, local
site policy may dictate that the message text be examined or modified
in some way. Such completions or modifications have been shown to
cause harm when performed by downstream MTAs -- that is, MTAs after
the first-hop submission MTA -- and are in general considered to be
outside the province of standardized MTA functionality.
Separating messages into submissions and transfers allows developers
and network administrators to more easily:
* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail
* Implement authenticated submission, including off-site submission
by authorized users such as travelers
Gellens & Klensin Standards Track [Page 2]
RFC 2476 Message Submission December 1998
* Separate the relevant software code differences, thereby making
each code base more straightforward and allowing for different
programs for relay and submission
* Detect configuration problems with a site's mail clients
* Provide a basis for adding enhanced submission services in the
future
This memo describes a low cost, deterministic means for messages to
be identified as submissions, and specifies what actions are to be
taken by a submission server.
Public comments should be sent to the IETF Submit mailing list,
<ietf-submit>. To subscribe, send a message containing </ietf-submit>
SUBSCRIBE to <ietf-submit-request>. Private comments may be </ietf-submit-request>
sent to the authors.
2. Document Information
2.1. Definitions of Terms Used in this Memo
Fully-Qualified
Containing or consisting of a domain which can be globally resolved
using the global Domain Name Service; that is, not a local alias or
partial specification.
Message Submission Agent (MSA)
A process which conforms to this specification, which acts as a
submission server to accept messages from MUAs, and either delivers
them or acts as an SMTP client to relay them to an MTA.
Message Transfer Agent (MTA)
A process which conforms to [SMTP-MTA], which acts as an SMTP server
to accept messages from an MSA or another MTA, and either delivers
them or acts as an SMTP client to relay them to another MTA.
Message User Agent (MUA)
A process which acts (usually on behalf of a user) to compose and
submit new messages, and process delivered messages. In the split-
MUA model, POP or IMAP is used to access delivered messages.
Gellens & Klensin Standards Track [Page 3]
RFC 2476 Message Submission December 1998
2.2. Conventions Used in this Document
In examples, "C:" is used to indicate lines sent by the client, and
"S:" indicates those sent by the server. Line breaks within a
command example are for editorial purposes only.
Examples use the 'example.net' domain.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS].
3. Message Submission
3.1. Submission Identification
Port 587 is reserved for email message submission as specified in
this document. Messages received on this port are defined to be
submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with
additional restrictions as specified here.
While most email clients and servers can be configured to use port
587 instead of 25, there are cases where this is not possible or
convenient. A site MAY choose to use port 25 for message submission,
by designating some hosts to be MSAs and others to be MTAs.
3.2. Message Rejection and Bouncing
MTAs and MSAs MAY implement message rejection rules that rely in part
on whether the message is a submission or a relay.
For example, some sites might configure their MTA to reject all RCPT
TOs for messages that do not reference local users, and configure
their MSA to reject all message submissions that do not come from
authorized users, based on IP address, or authenticated identity.
NOTE: It is better to reject a message than to risk sending one that
is damaged. This is especially true for problems that are
correctable by the MUA, for example, an invalid 'From' field.
If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD immediately reject the
message. A message can be immediately rejected by returning a 550
code to the MAIL FROM command.
Gellens & Klensin Standards Track [Page 4]
RFC 2476 Message Submission December 1998
Note that a null return path, that is, MAIL FROM:<>, is permitted
and MUST be accepted. (MUAs need to generate null return-path
messages for a variety of reasons, including disposition
notifications.)
Except in the case where the MSA is unable to determine a valid
return path for the message being submitted, text in this
specification which instructs an MSA to issue a rejection code MAY be
complied with by accepting the message and subsequently generating a
bounce message. (That is, if the MSA is going to reject a message for
any reason except being unable to determine a return path, it can
optionally do an immediate rejection or accept the message and then
mail a bounce.)
NOTE: In the normal case of message submission, immediately
rejecting the message is preferred, as it gives the user and MUA
direct feedback. To properly handle delayed bounces the client MUA
must maintain a queue of messages it has submitted, and match bounces
to them.
3.3. Authorized Submission
Numerous methods have been used to ensure that only authorized users
are able to submit messages. These methods include authenticated
SMTP, IP address restrictions, secure IP, and prior POP
authentication.
Authenticated SMTP [SMTP-AUTH] has been proposed. It allows the MSA
to determine an authorization identity for the message submission,
which is not tied to other protocols.
IP address restrictions are very widely implemented, but do not allow
for travellers and similar situations, and can be spoofed.
Secure IP [IPSEC] can also be used, and provides additional benefits
of protection against eavesdropping and traffic analysis.
Requiring a POP [POP3] authentication (from the same IP address)
within some amount of time (for example, 20 minutes) prior to the
start of a message submission session has also been used, but this
does impose restrictions on clients as well as servers which may
cause difficulties. Specifically, the client must do a POP
authentication before an SMTP submission session, and not all clients
are capable and configured for this. Also, the MSA must coordinate
with the POP server, which may be difficult. There is also a window
during which an unauthorized user can submit messages and appear to
be a prior authorized user.
Gellens & Klensin Standards Track [Page 5]
RFC 2476 Message Submission December 1998
3.4. Enhanced Status Codes
This memo suggests several enhanced status codes [SMTP-CODES] for
submission-specific rejections. The specific codes used are:
5.6.0 Bad content. The content of the header or text is
improper.
5.6.2 Bad domain or address. Invalid or improper domain or address
in MAIL FROM, RCPT TO, or DATA.
5.7.1 Not allowed. The address in MAIL FROM appears to have
insufficient submission rights, or is invalid, or is not
authorized with the authentication used; the address in a
RCPT TO command is inconsistent with the permissions given to
the user; the message data is rejected based on the
submitting user.
5.7.0 Site policy. The message appears to violate site policy in
some way.
4. Mandatory Actions
An MSA MUST do all of the following:
4.1. General Submission Rejection Code
Unless covered by a more precise response code, response code 554 is
to be used to reject a MAIL FROM, RCPT TO, or DATA command that
contains something improper. Enhanced status code 5.6.0 is to be
used if no other code is more specific.
4.2. Ensure All Domains are Fully-Qualified
The MSA MUST ensure that all domains in the envelope are fully-
qualified.
If the MSA examines or alters the message text in way, except to add
trace header fields [SMTP-MTA], it MUST ensure that all domains in
address header fields are fully-qualified.
Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
command which contains improper domain references.
NOTE: A frequent local convention is to accept single-level domains
(for example, 'sales') and then to expand the reference by adding the
remaining portion of the domain name (for example, to
Gellens & Klensin Standards Track [Page 6]
RFC 2476 Message Submission December 1998
'sales.example.net'). Local conventions that permit single-level
domains SHOULD reject, rather than expand, incomplete multi-level
domains, since such expansion is particularly risky.
5. Recommended Actions
The MSA SHOULD do all of the following:
5.1. Enforce Address Syntax
An MSA SHOULD reject messages with illegal syntax in a sender or
recipient envelope address.
If the MSA examines or alters the message text in way, except to add
trace header fields, it SHOULD reject messages with illegal address
syntax in address header fields.
Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command
that contains a detectably improper address.
When addresses are resolved after submission of the message body,
reply code 554 with enhanced status code 5.6.2 is to be used after
end-of-data, if the message contains invalid addresses in the header.
5.2. Log Errors
The MSA SHOULD log message errors, especially apparent
misconfigurations of client software.
Note: It can be very helpful to notify the administrator when
problems are detected with local mail clients. This is another
advantage of distinguishing submission from relay: system
administrators might be interested in local configuration problems,
but not in client problems at other sites.
6. Optional Actions
The MSA MAY do any of the following:
6.1. Enforce Submission Rights
The MSA MAY issue an error response to the MAIL FROM command if the
address in MAIL FROM appears to have insufficient submission rights,
or is not authorized with the authentication used (if the session has
been authenticated).
Reply code 550 with enhanced status code 5.7.1 is used for this
purpose.
Gellens & Klensin Standards Track [Page 7]
RFC 2476 Message Submission December 1998
6.2. Require Authentication
The MSA MAY issue an error response to the MAIL FROM command if the
session has not been authenticated.
Section 3.3 discusses authentication mechanisms.
Reply code 530 [SMTP-AUTH] is used for this purpose.
6.3. Enforce Permissions
The MSA MAY issue an error response to the RCPT TO command if
inconsistent with the permissions given to the user (if the session
has been authenticated).
Reply code 550 with enhanced status code 5.7.1 is used for this
purpose.
6.4. Check Message Data
The MSA MAY issue an error response to the DATA command or send a
failure result after end-of-data if the submitted message is
syntactically invalid, or seems inconsistent with permissions given
to the user (if known), or violates site policy in some way.
Reply code 554 is used for syntactic problems in the data. Reply
code 501 is used if the command itself is not syntactically valid.
Reply code 550 with enhanced status code 5.7.1 is used to reject
based on the submitting user. Reply code 550 with enhanced status
code 5.7.0 is used if the message violates site policy.
7. Interaction with SMTP Extensions
The following table lists the current standards-track and
Experimental SMTP extensions. Listed are the RFC, name, an
indication as to the use of the extension on the submit port, and a
reference:
RFC Name Submission Reference
---- --------------- ---------- ------------------
2197 Pipelining SHOULD [PIPELINING]
2034 Error Codes SHOULD [CODES-EXTENSION]
1985 ETRN MUST NOT [ETRN]
1893 Extended Codes SHOULD [SMTP-CODES]
1891 DSN SHOULD [DSN]
1870 Size MAY [SIZE]
1846 521 MUST NOT [521REPLY]
1845 Checkpoint MAY [Checkpoint]
Gellens & Klensin Standards Track [Page 8]
RFC 2476 Message Submission December 1998
1830 Binary MAY [CHUNKING]
1652 8-bit MIME SHOULD [8BITMIME]
---- Authentication ------ [SMTP-AUTH]
Future SMTP extensions should explicitly specify if they are valid on
the Submission port.
Some SMTP extensions are especially useful for message submission:
Extended Status Codes [SMTP-CODES], SHOULD be supported and used
according to [CODES-EXTENSION]. This permits the MSA to notify the
client of specific configuration or other problems in more detail
than the response codes listed in this memo. Because some rejections
are related to a site's security policy, care should be used not to
expose more detail than is needed to correct the problem.
[PIPELINING] SHOULD be supported by the MSA.
[SMTP-AUTH] allows the MSA to validate the authority and determine
the identity of the submitting user.
Any references to the DATA command in this memo also refer to any
substitutes for DATA, such as the BDAT command used with [CHUNKING].
8. Message Modifications
Sites MAY modify submissions to ensure compliance with standards and
site policy. This section describes a number of such modifications
that are often considered useful.
NOTE: As a matter of guidance for local decisions to implement
message modification, a paramount rule is to limit such actions to
remedies for specific problems that have clear solutions. This is
especially true with address elements. For example, indiscriminately
appending a domain to an address or element which lacks one typically
results in more broken addresses. An unqualified address must be
verified to be a valid local part in the domain before the domain can
be safely added.
8.1. Add 'Sender'
The MSA MAY add or replace the 'Sender' field, if the identity of the
sender is known and this is not given in the 'From' field.
The MSA MUST ensure that any address it places in a 'Sender' field is
in fact a valid mail address.
Gellens & Klensin Standards Track [Page 9]
RFC 2476 Message Submission December 1998
8.2. Add 'Date'
The MSA MAY add a 'Date' field to the submitted message, if it lacks
it, or correct the 'Date' field if it does not conform to [MESSAGE-
FORMAT] syntax.
8.3. Add 'Message-ID'
The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or
it is not valid syntax (as defined by [MESSAGE-FORMAT]).
8.4. Transfer Encode
The MSA MAY apply transfer encoding to the message according to MIME
conventions, if needed and not harmful to the MIME type.
8.5. Sign the Message
The MSA MAY (digitally) sign or otherwise add authentication
information to the message.
8.6. Encrypt the Message
The MSA MAY encrypt the message for transport to reflect
organizational policies.
NOTE: To be useful, the addition of a signature and/or encryption by
the MSA generally implies that the connection between the MUA and MSA
must itself be secured in some other way, e.g., by operating inside
of a secure environment, by securing the submission connection at the
transport layer, or by using an [SMTP-AUTH] mechanism that provides
for session integrity.
8.7. Resolve Aliases
The MSA MAY resolve aliases (CNAME records) for domain names, in the
envelope and optionally in address fields of the header, subject to
local policy.
NOTE: Unconditionally resolving aliases could be harmful. For
example, if www.example.net and ftp.example.net are both aliases for
mail.example.net, rewriting them could lose useful information.
8.8. Header Rewriting
The MSA MAY rewrite local parts and/or domains, in the envelope and
optionally in address fields of the header, according to local
policy. For example, a site may prefer to rewrite 'JRU' as '
Gellens & Klensin Standards Track [Page 10]
RFC 2476 Message Submission December 1998
J.Random.User' in order to hide logon names, and/or to rewrite '
squeeky.sales.example.net' as 'zyx.example.net' to hide machine names
and make it easier to move users.
However, only addresses, local-parts, or domains which match specific
local MSA configuration settings should be altered. It would be very
dangerous for the MSA to apply data-independent rewriting rules, such
as always deleting the first element of a domain name. So, for
example, a rule which strips the left-most element of the domain if
the complete domain matches '*.foo.example.net' would be acceptable.
9. Security Considerations
Separation of submission and relay of messages can allow a site to
implement different policies for the two types of services, including
requiring use of additional security mechanisms for one or both. It
can do this in a way which is simpler, both technically and
administratively. This increases the likelihood that policies will
be applied correctly.
Separation also can aid in tracking and preventing unsolicited bulk
email.
For example, a site could configure its MSA to require authentication
before accepting a message, and could configure its MTA to reject all
RCPT TOs for non-local users. This can be an important element in a
site's total email security policy.
If a site fails to require any form of authorization for message
submissions (see section 3.3 for discussion), it is allowing open use
of its resources and name; unsolicited bulk email can be injected
using its facilities.
10. Acknowledgments
This updated memo has been revised in part based on comments and
discussions which took place on and off the IETF-Submit mailing list.
The help of those who took the time to review the draft and make
suggestions is appreciated, especially that of Dave Crocker, Ned
Freed, Keith Moore, John Myers, and Chris Newman.
Special thanks to Harald Alvestrand, who got this effort started.
Gellens & Klensin Standards Track [Page 11]
RFC 2476 Message Submission December 1998
11. References
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
RFC 1846, September 1995.
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
D. Crocker, "SMTP Service Extension for 8bit-
MIMEtransport", RFC 1652, July 1994.
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP
Service Extension for Checkpoint/Restart", RFC
1845, September 1995.
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages",
RFC 1830, August 1995.
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
[DSN] Moore, K., "SMTP Service Extension for Delivery
Status Notifications", RFC 1891, January 1996.
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
D. Crocker, "SMTP Service Extensions", STD 10, RFC
1869, November 1995.
[ETRN] De Winter, J., "SMTP Service Extension for Remote
Message Queue Starting", RFC 1985, August 1996.
[HEADERS] Palme, J., "Common Internet Message Headers", RFC
2076, February 1997.
[IPSEC] Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 1825, August 1995.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Gellens & Klensin Standards Track [Page 12]
RFC 2476 Message Submission December 1998
[MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982;
Braden, R., Editor, "Requirements for Internet
Hosts -- Application and Support", STD 3, RFC 1123,
October 1989.
[PIPELINING] Freed, N., "SMTP Service Extension for Command
Pipelining", RFC 2197, September 1997.
[POP3] Myers, J. and M. Rose, "Post Office Protocol --
Version 3", STD 53, RFC 1939, May 1996.
[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10,
RFC 1870, November 1995.
[SMTP-AUTH] Myers, J., "SMTP Service Extension for
Authentication", Work in Progress.
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 1893, January 1996.
[SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD
10, RFC 821, August 1982.
Partridge, C., "Mail Routing and the Domain
System", STD 14, RFC 974, January 1986.
Braden, R., Editor, "Requirements for Internet
Hosts -- Application and Support", STD 3, RFC 1123,
October 1989.
Gellens & Klensin Standards Track [Page 13]
RFC 2476 Message Submission December 1998
12. Authors' Addresses
Randall Gellens
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, CA 92121-2779
U.S.A.
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
John C. Klensin
MCI Telecommunications
800 Boylston St, 7th floor
Boston, MA 02199
USA
Phone: +1 617 960 1011
EMail: klensin@mci.net
Gellens & Klensin Standards Track [Page 14]
RFC 2476 Message Submission December 1998
13. Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
Gellens & Klensin Standards Track [Page 15]
Network Working Group M. Wong
Request for Comments: 4408 W. Schlitt
Category: Experimental April 2006
Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
are published simultaneously as Experimental RFCs, although there is
no general technical consensus and efforts to reconcile the two
approaches have failed. As such, these documents have not received
full IETF review and are published "AS-IS" to document the different
approaches as they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred
and cautions the reader that there are serious open issues for each
approach and concerns about using them in tandem. The IESG believes
that documenting the different approaches does less harm than not
documenting them.
Note that the Sender ID experiment may use DNS records that may have
been created for the current SPF experiment or earlier versions in
this set of experiments. Depending on the content of the record,
this may mean that Sender-ID heuristics would be applied incorrectly
to a message. Depending on the actions associated by the recipient
with those heuristics, the message may not be delivered or may be
discarded on receipt.
Participants relying on Sender ID experiment DNS records are warned
that they may lose valid messages in this set of circumstances.
aParticipants publishing SPF experiment DNS records should consider
the advice given in section 3.4 of RFC 4406 and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
Wong & Schlitt Experimental [Page 1]
RFC 4408 Sender Policy Framework (SPF) April 2006
Participants in the Sender-ID experiment need to be aware that the
way Resent-* header fields are used will result in failure to receive
legitimate email when interacting with standards-compliant systems
(specifically automatic forwarders which comply with the standards by
not adding Resent-* headers, and systems which comply with RFC 822
but have not yet implemented RFC 2822 Resent-* semantics). It would
be inappropriate to advance Sender-ID on the standards track without
resolving this interoperability problem.
The community is invited to observe the success or failure of the two
approaches during the two years following publication, in order that
a community consensus can be reached in the future.
Abstract
E-mail on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending
host can use as the reverse-path of a message or the domain given on
the SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby a domain may
explicitly authorize the hosts that are allowed to use its domain
name, and a receiving host may check such authorization.
Table of Contents
1. Introduction ....................................................4
1.1. Protocol Status ............................................4
1.2. Terminology ................................................5
2. Operation .......................................................5
2.1. The HELO Identity ..........................................5
2.2. The MAIL FROM Identity .....................................5
2.3. Publishing Authorization ...................................6
2.4. Checking Authorization .....................................6
2.5. Interpreting the Result ....................................7
2.5.1. None ................................................8
2.5.2. Neutral .............................................8
2.5.3. Pass ................................................8
2.5.4. Fail ................................................8
2.5.5. SoftFail ............................................9
2.5.6. TempError ...........................................9
2.5.7. PermError ...........................................9
3. SPF Records .....................................................9
3.1. Publishing ................................................10
3.1.1. DNS Resource Record Types ..........................10
3.1.2. Multiple DNS Records ...............................11
3.1.3. Multiple Strings in a Single DNS record ............11
3.1.4. Record Size ........................................11
3.1.5. Wildcard Records ...................................11
Wong & Schlitt Experimental [Page 2]
RFC 4408 Sender Policy Framework (SPF) April 2006
4. The check_host() Function ......................................12
4.1. Arguments .................................................12
4.2. Results ...................................................13
4.3. Initial Processing ........................................13
4.4. Record Lookup .............................................13
4.5. Selecting Records .........................................13
4.6. Record Evaluation .........................................14
4.6.1. Term Evaluation ....................................14
4.6.2. Mechanisms .........................................15
4.6.3. Modifiers ..........................................15
4.7. Default Result ............................................16
4.8. Domain Specification ......................................16
5. Mechanism Definitions ..........................................16
5.1. "all" .....................................................17
5.2. "include" .................................................18
5.3. "a" .......................................................19
5.4. "mx" ......................................................20
5.5. "ptr" .....................................................20
5.6. "ip4" and "ip6" ...........................................21
5.7. "exists" ..................................................22
6. Modifier Definitions ...........................................22
6.1. redirect: Redirected Query ................................23
6.2. exp: Explanation ..........................................23
7. The Received-SPF Header Field ..................................25
8. Macros .........................................................27
8.1. Macro Definitions .........................................27
8.2. Expansion Examples ........................................30
9. Implications ...................................................31
9.1. Sending Domains ...........................................31
9.2. Mailing Lists .............................................32
9.3. Forwarding Services and Aliases ...........................32
9.4. Mail Services .............................................34
9.5. MTA Relays ................................................34
10. Security Considerations .......................................35
10.1. Processing Limits ........................................35
10.2. SPF-Authorized E-Mail May Contain Other False
Identities ...............................................37
10.3. Spoofed DNS and IP Data ..................................37
10.4. Cross-User Forgery .......................................37
10.5. Untrusted Information Sources ............................38
10.6. Privacy Exposure .........................................38
11. Contributors and Acknowledgements .............................38
12. IANA Considerations ...........................................39
12.1. The SPF DNS Record Type ..................................39
12.2. The Received-SPF Mail Header Field .......................39
13. References ....................................................39
13.1. Normative References .....................................39
13.2. Informative References ...................................40
Wong & Schlitt Experimental [Page 3]
RFC 4408 Sender Policy Framework (SPF) April 2006
Appendix A. Collected ABNF .......................................42
Appendix B. Extended Examples ....................................44
B.1. Simple Examples ..........................................44
B.2. Multiple Domain Example ..................................45
B.3. DNSBL Style Example ......................................46
B.4. Multiple Requirements Example ............................46
1. Introduction
The current E-Mail infrastructure has the property that any host
injecting mail into the mail system can identify itself as any domain
name it wants. Hosts can do this at a variety of levels: in
particular, the session, the envelope, and the mail headers.
Although this feature is desirable in some circumstances, it is a
major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
Furthermore, many domain name holders are understandably concerned
about the ease with which other entities may make use of their domain
names, often with malicious intent.
This document defines a protocol by which domain owners may authorize
hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
Compliant domain holders publish Sender Policy Framework (SPF)
records specifying which hosts are permitted to use their names, and
compliant mail receivers use the published SPF records to test the
authorization of sending Mail Transfer Agents (MTAs) using a given
"HELO" or "MAIL FROM" identity during a mail transaction.
An additional benefit to mail receivers is that after the use of an
identity is verified, local policy decisions about the mail can be
made based on the sender's domain, rather than the host's IP address.
This is advantageous because reputation of domain names is likely to
be more accurate than reputation of host IP addresses. Furthermore,
if a claimed identity fails verification, local policy can take
stronger action against such E-Mail, such as rejecting it.
1.1. Protocol Status
SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many
discussed and debated in development forums.
The goal of this document is to clearly document the protocol defined
by earlier draft specifications of SPF as used in existing
implementations. This conception of SPF is sometimes called "SPF
Classic". It is understood that particular implementations and
Wong & Schlitt Experimental [Page 4]
RFC 4408 Sender Policy Framework (SPF) April 2006
deployments may differ from, and build upon, this work. It is hoped
that we have nonetheless captured the common understanding of SPF
version 1.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document is concerned with the portion of a mail message
commonly called "envelope sender", "return path", "reverse path",
"bounce address", "2821 FROM", or "MAIL FROM". Since these terms are
either not well defined or often used casually, this document defines
the "MAIL FROM" identity in Section 2.2. Note that other terms that
may superficially look like the common terms, such as "reverse-path",
are used only with the defined meanings from normative documents.
2. Operation
2.1. The HELO Identity
The "HELO" identity derives from either the SMTP HELO or EHLO command
(see [RFC2821]). These commands supply the SMTP client (sending
host) for the SMTP session. Note that requirements for the domain
presented in the EHLO or HELO command are not always clear to the
sending party, and SPF clients must be prepared for the "HELO"
identity to be malformed or an IP address literal. At the time of
this writing, many legitimate E-Mails are delivered with invalid HELO
domains.
It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
identity, but also separately check the "HELO" identity by applying
the check_host() function (Section 4) to the "HELO" identity as the
<sender>. </sender>
2.2. The MAIL FROM Identity
The "MAIL FROM" identity derives from the SMTP MAIL command (see
[RFC2821]). This command supplies the "reverse-path" for a message,
which generally consists of the sender mailbox, and is the mailbox to
which notification messages are to be sent if there are problems
delivering the message.
[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
RFC 2821). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document
Wong & Schlitt Experimental [Page 5]
RFC 4408 Sender Policy Framework (SPF) April 2006
defines the "MAIL FROM" identity to be the mailbox composed of the
localpart "postmaster" and the "HELO" identity (which may or may not
have been checked separately before).
SPF clients MUST check the "MAIL FROM" identity. SPF clients check
the "MAIL FROM" identity by applying the check_host() function to the
"MAIL FROM" identity as the <sender>. </sender>
2.3. Publishing Authorization
An SPF-compliant domain MUST publish a valid SPF record as described
in Section 3. This record authorizes the use of the domain name in
the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
If domain owners choose to publish SPF records, it is RECOMMENDED
that they end in "-all", or redirect to other records that do, so
that a definitive determination of authorization can be made.
Domain holders may publish SPF records that explicitly authorize no
hosts if mail should never originate using that domain.
When changing SPF records, care must be taken to ensure that there is
a transition period so that the old policy remains valid until all
legitimate E-Mail has been checked.
2.4. Checking Authorization
A mail receiver can perform a set of SPF checks for each mail message
it receives. An SPF check tests the authorization of a client host
to emit mail with a given identity. Typically, such checks are done
by a receiving MTA, but can be performed elsewhere in the mail
processing chain so long as the required information is available and
reliable. At least the "MAIL FROM" identity MUST be checked, but it
is RECOMMENDED that the "HELO" identity also be checked beforehand.
Without explicit approval of the domain owner, checking other
identities against SPF version 1 records is NOT RECOMMENDED because
there are cases that are known to give incorrect results. For
example, almost all mailing lists rewrite the "MAIL FROM" identity
(see Section 9.2), but some do not change any other identities in the
message. The scenario described in Section 9.3, sub-section 1.2, is
another example. Documents that define other identities should
define the method for explicit approval.
It is possible that mail receivers will use the SPF check as part of
a larger set of tests on incoming mail. The results of other tests
may influence whether or not a particular SPF check is performed.
For example, finding the sending host's IP address on a local white
Wong & Schlitt Experimental [Page 6]
RFC 4408 Sender Policy Framework (SPF) April 2006
list may cause all other tests to be skipped and all mail from that
host to be accepted.
When a mail receiver decides to perform an SPF check, it MUST use a
correctly-implemented check_host() function (Section 4) evaluated
with the correct parameters. Although the test as a whole is
optional, once it has been decided to perform a test it must be
performed as specified so that the correct semantics are preserved
between publisher and receiver.
To make the test, the mail receiver MUST evaluate the check_host()
function with the arguments set as follows:
<ip> - the IP address of the SMTP client that is emitting the </ip>
mail, either IPv4 or IPv6.
<domain> - the domain portion of the "MAIL FROM" or "HELO" identity. </domain>
<sender> - the "MAIL FROM" or "HELO" identity. </sender>
Note that the <domain> argument may not be a well-formed domain name. </domain>
For example, if the reverse-path was null, then the EHLO/HELO domain
is used, with its associated problems (see Section 2.1). In these
cases, check_host() is defined in Section 4.3 to return a "None"
result.
Although invalid, malformed, or non-existent domains cause SPF checks
to return "None" because no SPF record can be found, it has long been
the policy of many MTAs to reject E-Mail from such domains,
especially in the case of invalid "MAIL FROM". In order to prevent
the circumvention of SPF records, rejecting E-Mail from invalid
domains should be considered.
Implementations must take care to correctly extract the <domain> from </domain>
the data given with the SMTP MAIL FROM command as many MTAs will
still accept such things as source routes (see [RFC2821], Appendix
C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
These archaic features have been maliciously used to bypass security
systems.
2.5. Interpreting the Result
This section describes how software that performs the authorization
should interpret the results of the check_host() function. The
authorization check SHOULD be performed during the processing of the
SMTP transaction that sends the mail. This allows errors to be
returned directly to the sending MTA by way of SMTP replies.
Wong & Schlitt Experimental [Page 7]
RFC 4408 Sender Policy Framework (SPF) April 2006
Performing the authorization after the SMTP transaction has finished
may cause problems, such as the following: (1) It may be difficult to
accurately extract the required information from potentially
deceptive headers; (2) legitimate E-Mail may fail because the
sender's policy may have since changed.
Generating non-delivery notifications to forged identities that have
failed the authorization check is generally abusive and against the
explicit wishes of the identity owner.
2.5.1. None
A result of "None" means that no records were published by the domain
or that no checkable sender domain could be determined from the given
identity. The checking software cannot ascertain whether or not the
client host is authorized.
2.5.2. Neutral
The domain owner has explicitly stated that he cannot or does not
want to assert whether or not the IP address is authorized. A
"Neutral" result MUST be treated exactly like the "None" result; the
distinction exists only for informational purposes. Treating
"Neutral" more harshly than "None" would discourage domain owners
from testing the use of SPF records (see Section 9.1).
2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity. The domain can now, in the sense of
reputation, be considered responsible for sending the message.
Further policy checks can now proceed with confidence in the
legitimate use of the identity.
2.5.4. Fail
A "Fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. The checking
software can choose to mark the mail based on this or to reject the
mail outright.
If the checking software chooses to reject the mail during the SMTP
transaction, then it SHOULD use an SMTP reply code of 550 (see
[RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
(DSN) code (see [RFC3464]), in addition to an appropriate reply text.
The check_host() function may return either a default explanation
string or one from the domain that published the SPF records (see
Section 6.2). If the information does not originate with the
Wong & Schlitt Experimental [Page 8]
RFC 4408 Sender Policy Framework (SPF) April 2006
checking software, it should be made clear that the text is provided
by the sender's domain. For example:
550-5.7.1 SPF MAIL FROM check failed:
550-5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html
2.5.5. SoftFail
A "SoftFail" result should be treated as somewhere between a "Fail"
and a "Neutral". The domain believes the host is not authorized but
is not willing to make that strong of a statement. Receiving
software SHOULD NOT reject the message based solely on this result,
but MAY subject the message to closer scrutiny than normal.
The domain owner wants to discourage the use of this host and thus
desires limited feedback when a "SoftFail" result occurs. For
example, the recipient's Mail User Agent (MUA) could highlight the
"SoftFail" status, or the receiving MTA could give the sender a
message using a technique called "greylisting" whereby the MTA can
issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
first time the message is received, but accept it the second time.
2.5.6. TempError
A "TempError" result means that the SPF client encountered a
transient error while performing the check. Checking software can
choose to accept or temporarily reject the message. If the message
is rejected during the SMTP transaction for this reason, the software
SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
code.
2.5.7. PermError
A "PermError" result means that the domain's published records could
not be correctly interpreted. This signals an error condition that
requires manual intervention to be resolved, as opposed to the
TempError result. Be aware that if the domain owner uses macros
(Section 8), it is possible that this result is due to the checked
identities having an unexpected format.
3. SPF Records
An SPF record is a DNS Resource Record (RR) that declares which hosts
are, and are not, authorized to use a domain name for the "HELO" and
"MAIL FROM" identities. Loosely, the record partitions all hosts
into permitted and not-permitted sets (though some hosts might fall
into neither category).
Wong & Schlitt Experimental [Page 9]
RFC 4408 Sender Policy Framework (SPF) April 2006
The SPF record is a single string of text. An example record is the
following:
v=spf1 +mx a:colo.example.com/28 -all
This record has a version of "spf1" and three directives: "+mx",
"a:colo.example.com/28" (the + is implied), and "-all".
3.1. Publishing
Domain owners wishing to be SPF compliant must publish SPF records
for the hosts that are used in the "MAIL FROM" and "HELO" identities.
The SPF records are placed in the DNS tree at the host name it
pertains to, not a subdomain under it, such as is done with SRV
records. This is the same whether the TXT or SPF RR type (see
Section 3.1.1) is used.
The example above in Section 3 might be published via these lines in
a domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all"
When publishing via TXT records, beware of other TXT records
published there for other purposes. They may cause problems with
size limits (see Section 3.1.4).
3.1.1. DNS Resource Record Types
This document defines a new DNS RR of type SPF, code 99. The format
of this type is identical to the TXT RR [RFC1035]. For either type,
the character content of the record is encoded as [US-ASCII].
It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose.
An SPF-compliant domain name SHOULD have SPF records of both RR
types. A compliant domain name MUST have a record of at least one
type. If a domain has records of both types, they MUST have
identical content. For example, instead of publishing just one
record as in Section 3.1 above, it is better to publish:
example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
Wong & Schlitt Experimental [Page 10]
RFC 4408 Sender Policy Framework (SPF) April 2006
Example RRs in this document are shown with the TXT record type;
however, they could be published with the SPF type or with both
types.
3.1.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an
authorization check to select more than one record. See Section 4.5
for the selection rules.
3.1.3. Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
record (either TXT or SPF RR types) can be composed of more than one
string. If a published record contains multiple strings, then the
record MUST be treated as if those strings are concatenated together
without adding spaces. For example:
IN TXT "v=spf1 .... first" "second string..."
MUST be treated as equivalent to
IN TXT "v=spf1 .... firstsecond string..."
SPF or TXT records containing multiple strings are useful in
constructing records that would exceed the 255-byte maximum length of
a string within a single TXT or SPF RR record.
3.1.4. Record Size
The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets.
This will keep even older DNS implementations from falling over to
TCP. Since the answer size is dependent on many things outside the
scope of this document, it is only possible to give this guideline:
If the combined length of the DNS name and the text of all the
records of a given type (TXT or SPF) is under 450 characters, then
DNS answers should fit in UDP packets. Note that when computing the
sizes for queries of the TXT format, one must take into account any
other TXT records published at the domain name. Records that are too
long to fit in a single UDP packet MAY be silently ignored by SPF
clients.
3.1.5. Wildcard Records
Use of wildcard records for publishing is not recommended. Care must
be taken if wildcard records are used. If a domain publishes
wildcard MX records, it may want to publish wildcard declarations,
Wong & Schlitt Experimental [Page 11]
RFC 4408 Sender Policy Framework (SPF) April 2006
subject to the same requirements and problems. In particular, the
declaration must be repeated for any host that has any RR records at
all, and for subdomains thereof. For example, the example given in
[RFC1034], Section 4.3.3, could be extended with the following:
X.COM. MX 10 A.X.COM
X.COM. TXT "v=spf1 a:A.X.COM -all"
*.X.COM. MX 10 A.X.COM
*.X.COM. TXT "v=spf1 a:A.X.COM -all"
A.X.COM. A 1.2.3.4
A.X.COM. MX 10 A.X.COM
A.X.COM. TXT "v=spf1 a:A.X.COM -all"
*.A.X.COM. MX 10 A.X.COM
*.A.X.COM. TXT "v=spf1 a:A.X.COM -all"
Notice that SPF records must be repeated twice for every name within
the domain: once for the name, and once with a wildcard to cover the
tree under the name.
Use of wildcards is discouraged in general as they cause every name
under the domain to exist and queries against arbitrary names will
never return RCODE 3 (Name Error).
4. The check_host() Function
The check_host() function fetches SPF records, parses them, and
interprets them to determine whether a particular host is or is not
permitted to send mail with a given identity. Mail receivers that
perform this check MUST correctly evaluate the check_host() function
as described here.
Implementations MAY use a different algorithm than the canonical
algorithm defined here, so long as the results are the same in all
cases.
4.1. Arguments
The check_host() function takes these arguments:
<ip> - the IP address of the SMTP client that is emitting the </ip>
mail, either IPv4 or IPv6.
<domain> - the domain that provides the sought-after authorization </domain>
information; initially, the domain portion of the "MAIL
FROM" or "HELO" identity.
Wong & Schlitt Experimental [Page 12]
RFC 4408 Sender Policy Framework (SPF) April 2006
<sender> - the "MAIL FROM" or "HELO" identity. </sender>
The domain portion of <sender> will usually be the same as the </sender>
<domain> argument when check_host() is initially evaluated. However, </domain>
this will generally not be true for recursive evaluations (see
Section 5.2 below).
Actual implementations of the check_host() function may need
additional arguments.
4.2. Results
The function check_host() can return one of several results described
in Section 2.5. Based on the result, the action to be taken is
determined by the local policies of the receiver.
4.3. Initial Processing
If the <domain> is malformed (label longer than 63 characters, zero- </domain>
length label not at the end, etc.) or is not a fully qualified domain
name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
check_host() immediately returns the result "None".
If the <sender> has no localpart, substitute the string "postmaster" </sender>
for the localpart.
4.4. Record Lookup
In accordance with how the records are published (see Section 3.1
above), a DNS query needs to be made for the <domain> name, querying </domain>
for either RR type TXT, SPF, or both. If both SPF and TXT RRs are
looked up, the queries MAY be done in parallel.
If all DNS lookups that are made return a server failure (RCODE 2),
or other error (RCODE other than 0 or 3), or time out, then
check_host() exits immediately with the result "TempError".
4.5. Selecting Records
Records begin with a version section:
record = version terms *SP
version = "v=spf1"
Starting with the set of records that were returned by the lookup,
record selection proceeds in two steps:
Wong & Schlitt Experimental [Page 13]
RFC 4408 Sender Policy Framework (SPF) April 2006
1. Records that do not begin with a version section of exactly
"v=spf1" are discarded. Note that the version section is
terminated either by an SP character or the end of the record. A
record with a version section of "v=spf10" does not match and must
be discarded.
2. If any records of type SPF are in the set, then all records of
type TXT are discarded.
After the above steps, there should be exactly one record remaining
and evaluation can proceed. If there are two or more records
remaining, then check_host() exits immediately with the result of
"PermError".
If no matching records are returned, an SPF client MUST assume that
the domain makes no SPF declarations. SPF processing MUST stop and
return "None".
4.6. Record Evaluation
After one SPF record has been selected, the check_host() function
parses and interprets it to find a result for the current test. If
there are any syntax errors, check_host() returns immediately with
the result "PermError".
Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not syntactically well formed.
However, in all cases, any syntax errors anywhere in the record MUST
be detected.
4.6.1. Term Evaluation
There are two types of terms: mechanisms and modifiers. A record
contains an ordered list of these as specified in the following
Augmented Backus-Naur Form (ABNF).
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
Most mechanisms allow a ":" or "/" character after the name.
Wong & Schlitt Experimental [Page 14]
RFC 4408 Sender Policy Framework (SPF) April 2006
Modifiers always contain an equals ('=') character immediately after
the name, and before any ":" or "/" characters that may be part of
the macro-string.
Terms that do not contain any of "=", ":", or "/" are mechanisms, as
defined in Section 5.
As per the definition of the ABNF notation in [RFC4234], mechanism
and modifier names are case-insensitive.
4.6.2. Mechanisms
Each mechanism is considered in turn from left to right. If there
are no more mechanisms, the result is specified in Section 4.7.
When a mechanism is evaluated, one of three things can happen: it can
match, not match, or throw an exception.
If it matches, processing ends and the qualifier value is returned as
the result of that record. If it does not match, processing
continues with the next mechanism. If it throws an exception,
mechanism processing ends and the exception value is returned.
The possible qualifiers, and the results they return are as follows:
"+" Pass
"-" Fail
"~" SoftFail
"?" Neutral
The qualifier is optional and defaults to "+".
When a mechanism matches and the qualifier is "-", then a "Fail"
result is returned and the explanation string is computed as
described in Section 6.2.
The specific mechanisms are described in Section 5.
4.6.3. Modifiers
Modifiers are not mechanisms: they do not return match or not-match.
Instead they provide additional information. Although modifiers do
not directly affect the evaluation of the record, the "redirect"
modifier has an effect after all the mechanisms have been evaluated.
Wong & Schlitt Experimental [Page 15]
RFC 4408 Sender Policy Framework (SPF) April 2006
4.7. Default Result
If none of the mechanisms match and there is no "redirect" modifier,
then the check_host() returns a result of "Neutral", just as if
"?all" were specified as the last directive. If there is a
"redirect" modifier, check_host() proceeds as defined in Section 6.1.
Note that records SHOULD always use either a "redirect" modifier or
an "all" mechanism to explicitly terminate processing.
For example:
v=spf1 +mx -all
or
v=spf1 +mx redirect=_spf.example.com
4.8. Domain Specification
Several of these mechanisms and modifiers have a <domain-spec></domain-spec>
section. The <domain-spec> string is macro expanded (see Section 8). </domain-spec>
The resulting string is the common presentation form of a fully-
qualified DNS name: a series of labels separated by periods. This
domain is called the <target-name> in the rest of this document. </target-name>
Note: The result of the macro expansion is not subject to any further
escaping. Hence, this facility cannot produce all characters that
are legal in a DNS label (e.g., the control characters). However,
this facility is powerful enough to express legal host names and
common utility labels (such as "_spf") that are used in DNS.
For several mechanisms, the <domain-spec> is optional. If it is not </domain-spec>
provided, the <domain> is used as the <target-name>. </target-name></domain>
5. Mechanism Definitions
This section defines two types of mechanisms.
Basic mechanisms contribute to the language framework. They do not
specify a particular type of authorization scheme.
all
include
Designated sender mechanisms are used to designate a set of <ip></ip>
addresses as being permitted or not permitted to use the <domain> for </domain>
sending mail.
Wong & Schlitt Experimental [Page 16]
RFC 4408 Sender Policy Framework (SPF) April 2006
a
mx
ptr
ip4
ip6
exists
The following conventions apply to all mechanisms that perform a
comparison between <ip> and an IP address at any point: </ip>
If no CIDR-length is given in the directive, then <ip> and the IP </ip>
address are compared for equality. (Here, CIDR is Classless Inter-
Domain Routing.)
If a CIDR-length is specified, then only the specified number of
high-order bits of <ip> and the IP address are compared for equality. </ip>
When any mechanism fetches host addresses to compare with <ip>, when </ip>
<ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 </ip></ip>
address, AAAA records are fetched. Even if the SMTP connection is
via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
2.5.5) MUST still be considered an IPv4 address.
Several mechanisms rely on information fetched from DNS. For these
DNS queries, except where noted, if the DNS server returns an error
(RCODE other than 0 or 3) or the query times out, the mechanism
throws the exception "TempError". If the server returns "domain does
not exist" (RCODE 3), then evaluation of the mechanism continues as
if the server returned no error (RCODE 0) and zero answer records.
5.1. "all"
all = "all"
The "all" mechanism is a test that always matches. It is used as the
rightmost mechanism in a record to provide an explicit default.
For example:
v=spf1 a mx -all
Mechanisms after "all" will never be tested. Any "redirect" modifier
(Section 6.1) has no effect when there is an "all" mechanism.
Wong & Schlitt Experimental [Page 17]
RFC 4408 Sender Policy Framework (SPF) April 2006
5.2. "include"
include = "include" ":" domain-spec
The "include" mechanism triggers a recursive evaluation of
check_host(). The domain-spec is expanded as per Section 8. Then
check_host() is evaluated with the resulting string as the <domain>. </domain>
The <ip> and <sender> arguments remain the same as in the current </sender></ip>
evaluation of check_host().
In hindsight, the name "include" was poorly chosen. Only the
evaluated result of the referenced SPF record is used, rather than
acting as if the referenced SPF record was literally included in the
first. For example, evaluating a "-all" directive in the referenced
record does not terminate the overall processing and does not
necessarily result in an overall "Fail". (Better names for this
mechanism would have been "if-pass", "on-pass", etc.)
The "include" mechanism makes it possible for one domain to designate
multiple administratively-independent domains. For example, a vanity
domain "example.net" might send mail using the servers of
administratively-independent domains example.com and example.org.
Example.net could say
IN TXT "v=spf1 include:example.com include:example.org -all"
This would direct check_host() to, in effect, check the records of
example.com and example.org for a "Pass" result. Only if the host
were not permitted for either of those domains would the result be
"Fail".
Wong & Schlitt Experimental [Page 18]
RFC 4408 Sender Policy Framework (SPF) April 2006
Whether this mechanism matches, does not match, or throws an
exception depends on the result of the recursive evaluation of
check_host():
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| Pass | match |
| | |
| Fail | not match |
| | |
| SoftFail | not match |
| | |
| Neutral | not match |
| | |
| TempError | throw TempError |
| | |
| PermError | throw PermError |
| | |
| None | throw PermError |
+---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative
boundaries. Although it is possible to use includes to consolidate
multiple domains that share the same set of designated hosts, domains
are encouraged to use redirects where possible, and to minimize the
number of includes within a single administrative domain. For
example, if example.com and example.org were managed by the same
entity, and if the permitted set of hosts for both domains was
"mx:example.com", it would be possible for example.org to specify
"include:example.com", but it would be preferable to specify
"redirect=example.com" or even "mx:example.com".
5.3. "a"
This mechanism matches if <ip> is one of the <target-name>'s IP </target-name></ip>
addresses.
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
An address lookup is done on the <target-name>. The <ip> is compared </ip></target-name>
to the returned address(es). If any address matches, the mechanism
matches.
Wong & Schlitt Experimental [Page 19]
RFC 4408 Sender Policy Framework (SPF) April 2006
5.4. "mx"
This mechanism matches if <ip> is one of the MX hosts for a domain </ip>
name.
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
check_host() first performs an MX lookup on the <target-name>. Then </target-name>
it performs an address lookup on each MX name returned. The <ip> is </ip>
compared to each returned IP address. To prevent Denial of Service
(DoS) attacks, more than 10 MX names MUST NOT be looked up during the
evaluation of an "mx" mechanism (see Section 10). If any address
matches, the mechanism matches.
Note regarding implicit MXs: If the <target-name> has no MX records, </target-name>
check_host() MUST NOT pretend the target is its single MX, and MUST
NOT default to an A lookup on the <target-name> directly. This </target-name>
behavior breaks with the legacy "implicit MX" rule. See [RFC2821],
Section 5. If such behavior is desired, the publisher should specify
an "a" directive.
5.5. "ptr"
This mechanism tests whether the DNS reverse-mapping for <ip> exists </ip>
and correctly points to a domain name within a particular domain.
PTR = "ptr" [ ":" domain-spec ]
First, the <ip>'s name is looked up using this procedure: perform a </ip>
DNS reverse-mapping for <ip>, looking up the corresponding PTR record </ip>
in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
if it is an IPv6 address. For each record returned, validate the
domain name by looking up its IP address. To prevent DoS attacks,
more than 10 PTR names MUST NOT be looked up during the evaluation of
a "ptr" mechanism (see Section 10). If <ip> is among the returned IP </ip>
addresses, then that domain name is validated. In pseudocode:
sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
sending-domain_names are found, use at most 10. for each name in
(sending-domain_names) {
IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name;
} }
Check all validated domain names to see if they end in the
<target-name> domain. If any do, this mechanism matches. If no </target-name>
validated domain name can be found, or if none of the validated
Wong & Schlitt Experimental [Page 20]
RFC 4408 Sender Policy Framework (SPF) April 2006
domain names end in the <target-name>, this mechanism fails to match. </target-name>
If a DNS error occurs while doing the PTR RR lookup, then this
mechanism fails to match. If a DNS error occurs while doing an A RR
lookup, then that domain name is skipped and the search continues.
Pseudocode:
for each name in (validated-sending-domain_names) {
if name ends in <domain-spec>, return match. </domain-spec>
if name is <domain-spec>, return match. </domain-spec>
}
return no-match.
This mechanism matches if the <target-name> is either an ancestor of </target-name>
a validated domain name or if the <target-name> and a validated </target-name>
domain name are the same. For example: "mail.example.com" is within
the domain "example.com", but "mail.bad-example.com" is not.
Note: Use of this mechanism is discouraged because it is slow, it is
not as reliable as other mechanisms in cases of DNS errors, and it
places a large burden on the arpa name servers. If used, proper PTR
records must be in place for the domain's hosts and the "ptr"
mechanism should be one of the last mechanisms checked.
5.6. "ip4" and "ip6"
These mechanisms test whether <ip> is contained within a given IP </ip>
network.
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as section per></as>
; e.g., 2001:DB8::CD30
The <ip> is compared to the given network. If CIDR-length high-order </ip>
bits match, the mechanism matches.
Wong & Schlitt Experimental [Page 21]
RFC 4408 Sender Policy Framework (SPF) April 2006
If ip4-cidr-length is omitted, it is taken to be "/32". If
ip6-cidr-length is omitted, it is taken to be "/128". It is not
permitted to omit parts of the IP address instead of using CIDR
notations. That is, use 192.0.2.0/24 instead of 192.0.2.
5.7. "exists"
This mechanism is used to construct an arbitrary domain name that is
used for a DNS A record query. It allows for complicated schemes
involving arbitrary parts of the mail envelope to determine what is
permitted.
exists = "exists" ":" domain-spec
The domain-spec is expanded as per Section 8. The resulting domain
name is used for a DNS A RR lookup. If any A record is returned,
this mechanism matches. The lookup type is A even when the
connection type is IPv6.
Domains can use this mechanism to specify arbitrarily complex
queries. For example, suppose example.com publishes the record:
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
The <target-name> might expand to </target-name>
"1.2.0.192.someuser._spf.example.com". This makes fine-grained
decisions possible at the level of the user and client IP address.
This mechanism enables queries that mimic the style of tests that
existing anti-spam DNS blacklists (DNSBL) use.
6. Modifier Definitions
Modifiers are name/value pairs that provide additional information.
Modifiers always have an "=" separating the name and the value.
The modifiers defined in this document ("redirect" and "exp") MAY
appear anywhere in the record, but SHOULD appear at the end, after
all mechanisms. Ordering of these two modifiers does not matter.
These two modifiers MUST NOT appear in a record more than once each.
If they do, then check_host() exits with a result of "PermError".
Unrecognized modifiers MUST be ignored no matter where in a record,
or how often. This allows implementations of this document to
gracefully handle records with modifiers that are defined in other
specifications.
Wong & Schlitt Experimental [Page 22]
RFC 4408 Sender Policy Framework (SPF) April 2006
6.1. redirect: Redirected Query
If all mechanisms fail to match, and a "redirect" modifier is
present, then processing proceeds as follows:
redirect = "redirect" "=" domain-spec
The domain-spec portion of the redirect section is expanded as per
the macro rules in Section 8. Then check_host() is evaluated with
the resulting string as the <domain>. The <ip> and <sender></sender></ip></domain>
arguments remain the same as current evaluation of check_host().
The result of this new evaluation of check_host() is then considered
the result of the current evaluation with the exception that if no
SPF record is found, or if the target-name is malformed, the result
is a "PermError" rather than "None".
Note that the newly-queried domain may itself specify redirect
processing.
This facility is intended for use by organizations that wish to apply
the same record to multiple domains. For example:
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by
the same record. This can be an administrative advantage.
Note: In general, the domain "A" cannot reliably use a redirect to
another domain "B" not under the same administrative control. Since
the <sender> stays the same, there is no guarantee that the record at </sender>
domain "B" will correctly work for mailboxes in domain "A",
especially if domain "B" uses mechanisms involving localparts. An
"include" directive may be more appropriate.
For clarity, it is RECOMMENDED that any "redirect" modifier appear as
the very last term in a record.
6.2. exp: Explanation
explanation = "exp" "=" domain-spec
If check_host() results in a "Fail" due to a mechanism match (such as
"-all"), and the "exp" modifier is present, then the explanation
string returned is computed as described below. If no "exp" modifier
Wong & Schlitt Experimental [Page 23]
RFC 4408 Sender Policy Framework (SPF) April 2006
is present, then either a default explanation string or an empty
explanation string may be returned.
The <domain-spec> is macro expanded (see Section 8) and becomes the </domain-spec>
<target-name>. The DNS TXT record for the <target-name> is fetched. </target-name></target-name>
If <domain-spec> is empty, or there are any DNS processing errors </domain-spec>
(any RCODE other than 0), or if no records are returned, or if more
than one record is returned, or if there are syntax errors in the
explanation string, then proceed as if no exp modifier was given.
The fetched TXT record's strings are concatenated with no spaces, and
then treated as an <explain-string>, which is macro-expanded. This </explain-string>
final result is the explanation string. Implementations MAY limit
the length of the resulting explanation string to allow for other
protocol constraints and/or reasonable processing limits. Since the
explanation string is intended for an SMTP response and [RFC2821]
Section 2.4 says that responses are in [US-ASCII], the explanation
string is also limited to US-ASCII.
Software evaluating check_host() can use this string to communicate
information from the publishing domain in the form of a short message
or URL. Software SHOULD make it clear that the explanation string
comes from a third party. For example, it can prepend the macro
string "%{o} explains: " to the explanation, such as shown in Section
2.5.4.
Suppose example.com has this record:
v=spf1 mx -all exp=explain._spf.%{d}
Here are some examples of possible explanation TXT records at
explain._spf.example.com:
"Mail from example.com should only be sent by its own servers."
-- a simple, constant message
"%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more information, including the IP
address that failed the check
"See http://%{d}/why.html?s=%{S}&i=%{I}"
-- a complicated example that constructs a URL with the
arguments to check_host() so that a web page can be
generated with detailed, custom instructions
Note: During recursion into an "include" mechanism, an exp= modifier
from the <target-name> MUST NOT be used. In contrast, when executing </target-name>
Wong & Schlitt Experimental [Page 24]
RFC 4408 Sender Policy Framework (SPF) April 2006
a "redirect" modifier, an exp= modifier from the original domain MUST
NOT be used.
7. The Received-SPF Header Field
It is RECOMMENDED that SMTP receivers record the result of SPF
processing in the message header. If an SMTP receiver chooses to do
so, it SHOULD use the "Received-SPF" header field defined here for
each identity that was checked. This information is intended for the
recipient. (Information intended for the sender is described in
Section 6.2, Explanation.)
The Received-SPF header field is a trace field (see [RFC2822] Section
3.6.7) and SHOULD be prepended to the existing header, above the
Received: field that is generated by the SMTP receiver. It MUST
appear above all other Received-SPF fields in the message. The
header field has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
"None" / "TempError" / "PermError"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
mechanism / "x-" name / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
dot-atom = <unquoted per as word></unquoted>
quoted-string = <quoted per as string></quoted>
comment = <comment per as string></comment>
CFWS = <comment or folding white space as per></comment>
Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. Delany
M. Libbey
Yahoo! Inc
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
DomainKeys Identified Mail (DKIM) Signatures
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today. Protection of email identity may assist in the
global control of "spam" and "phishing".
Allman, et al. Standards Track [Page 1]
RFC 4871 DKIM Signatures May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17
3.6. Key Management and Representation . . . . . . . . . . . . 25
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Normalize the Message to Prevent Transport Conversions . . 35
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Extract Signatures from the Message . . . . . . . . . . . 41
6.2. Communicate Verification Results . . . . . . . . . . . . . 46
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52
Allman, et al. Standards Track [Page 2]
RFC 4871 DKIM Signatures May 2007
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57
9.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60
A.1. The user composes an email . . . . . . . . . . . . . . . . 60
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69
Allman, et al. Standards Track [Page 3]
RFC 4871 DKIM Signatures May 2007
1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.
The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the
message body;
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities;
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation;
o signature verification failure does not force rejection of the
message;
o no attempt is made to include encryption as part of the mechanism;
o message archiving is not a design goal.
DKIM:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce
deployment time;
o can be deployed incrementally;
o allows delegation of signing to third parties.
Allman, et al. Standards Track [Page 4]
RFC 4871 DKIM Signatures May 2007
1.1. Signing Identity
DKIM separates the question of the identity of the signer of the
message from the purported author of the message. In particular, a
signature includes the identity of the signer. Verifiers can use the
signing information to decide how they want to process the message.
The signing identity is included as part of the signature header
field.
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field because of the broad methods of interpretation by
recipient mail systems, including MUAs.
1.2. Scalability
DKIM is designed to support the extreme scalability requirements that
characterize the email identification problem. There are currently
over 70 million domains and a much larger number of individual
addresses. DKIM seeks to preserve the positive aspects of the
current email infrastructure, such as the ability for anyone to
communicate with anyone else without introduction.
1.3. Simple Key Management
DKIM differs from traditional hierarchical public-key systems in that
no Certificate Authority infrastructure is required; the verifier
requests the public key from a repository in the domain of the
claimed signer directly rather than from a third party.
The DNS is proposed as the initial mechanism for the public keys.
Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available.
2. Terminology and Definitions
This section defines terms used in the rest of the document. Syntax
descriptions use the form described in Augmented BNF for Syntax
Specifications [RFC4234].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Allman, et al. Standards Track [Page 5]
RFC 4871 DKIM Signatures May 2007
2.1. Signers
Elements in the mail system that sign messages on behalf of a domain
are referred to as signers. These may be MUAs (Mail User Agents),
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
agents such as mailing list exploders. In general, any signer will
be involved in the injection of a message into the message system in
some way. The key issue is that a message must be signed before it
leaves the administrative domain of the signer.
2.2. Verifiers
Elements in the mail system that verify signatures are referred to as
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.
In most cases it is expected that verifiers will be close to an end
user (reader) of the message or some consuming agent such as a
mailing list exploder.
2.3. Whitespace
There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]).
o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined.
The formal ABNF for these are (WSP and LWSP are given for information
only):
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS.
2.4. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
Allman, et al. Standards Track [Page 6]
RFC 4871 DKIM Signatures May 2007
2.5. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive.
The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted strings)
o "sub-domain"
The following tokens are imported from [RFC2822]:
o "field-name" (name of a header field)
o "dot-atom-text" (in the Local-part of an email address)
The following tokens are imported from [RFC2045]:
o "qp-section" (a single line of quoted-printable-encoded text)
o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey
the rules of RFC 4234 and must be interpreted accordingly,
particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc.
2.6. DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding.
Allman, et al. Standards Track [Page 7]
RFC 4871 DKIM Signatures May 2007
ABNF:
dkim-quoted-printable =
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways:
1. Whitespace in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does
not permit encoding of CR or LF characters that are part of a
CRLF line break.
2. Whitespace in the encoded text is ignored. This is to allow
tags encoded using DKIM-Quoted-Printable to be wrapped as
needed. In particular, RFC 2045 requires that line breaks in
the input be represented as physical line breaks; that is not
the case here.
3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded
text is being used).
3. Protocol Elements
Protocol Elements are conceptual parts of the protocol that are not
specific to either signers or verifiers. The protocol descriptions
for signers and verifiers are described in later sections (Signer
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This
section must be read in the context of those sections.
3.1. Selectors
To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using "selectors". For example,
selectors might indicate the names of office locations (e.g.,
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date
(e.g., "january2005", "february2005", etc.), or even the individual
user.
Allman, et al. Standards Track [Page 8]
RFC 4871 DKIM Signatures May 2007
Selectors are needed to support some important use cases. For
example:
o Domains that want to delegate signing capability for a specific
address for a given duration to a partner, such as an advertising
provider or other outsourced function.
o Domains that want to allow frequent travelers to send messages
locally without the need to connect with a particular MSA.
o "Affinity" domains (e.g., college alumni associations) that
provide forwarding of incoming mail, but that do not operate a
mail submission agent for outgoing mail.
Periods are allowed in selectors and are component separators. When
keys are retrieved from the DNS, periods in selectors define DNS
label boundaries in a manner similar to the conventional use in
domain names. Selector components might be used to combine dates
with locations, for example, "march2005.reykjavik". In a DNS
implementation, this can be used to allow delegation of a portion of
the selector namespace.
ABNF:
selector = sub-domain *( "." sub-domain )
The number of public keys and corresponding selectors for each domain
is determined by the domain owner. Many domain owners will be
satisfied with just one selector, whereas administratively
distributed organizations may choose to manage disparate selectors
and key pairs in different regions or on different email servers.
Beyond administrative convenience, selectors make it possible to
seamlessly replace public keys on a routine basis. If a domain
wishes to change from using a public key associated with selector
"january2005" to a public key associated with selector
"february2005", it merely makes sure that both public keys are
advertised in the public-key repository concurrently for the
transition period during which email may be in transit prior to
verification. At the start of the transition period, the outbound
email servers are configured to sign with the "february2005" private
key. At the end of the transition period, the "january2005" public
key is removed from the public-key repository.
INFORMATIVE NOTE: A key may also be revoked as described below.
The distinction between revoking and removing a key selector
record is subtle. When phasing out keys as described above, a
signing domain would probably simply remove the key record after
Allman, et al. Standards Track [Page 9]
RFC 4871 DKIM Signatures May 2007
the transition period. However, a signing domain could elect to
revoke the key (but maintain the key record) for a further period.
There is no defined semantic difference between a revoked key and
a removed key.
While some domains may wish to make selector values well known,
others will want to take care not to allocate selector names in a way
that allows harvesting of data by outside parties. For example, if
per-user keys are issued, the domain owner will need to make the
decision as to whether to associate this selector directly with the
user name, or make it some unassociated random value, such as a
fingerprint of the public key.
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key
(for example, changing the key associated with a user's name)
makes it impossible to tell the difference between a message that
didn't verify because the key is no longer valid versus a message
that is actually forged. For this reason, signers are ill-advised
to reuse selectors for new keys. A better strategy is to assign
new keys to new selectors.
3.2. Tag=Value Lists
DKIM uses a simple "tag=value" syntax in several contexts, including
in messages and domain signature records.
Values are a series of strings containing either plain text, "base64"
text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid,
Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6).
The name of the tag will determine the encoding of each value.
Unencoded semicolon (";") characters MUST NOT occur in the tag value,
since that separates tag-specs.
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined
below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF8-encoded text in tag=value
lists.
Allman, et al. Standards Track [Page 10]
RFC 4871 DKIM Signatures May 2007
Formally, the syntax rules are as follows:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant.
Tags MUST be interpreted in a case-sensitive manner. Values MUST be
processed as case sensitive unless the specific tag description of
semantics specifies case insensitivity.
Tags with duplicate names MUST NOT occur within a single tag-list; if
a tag name does occur more than once, the entire tag-list is invalid.
Whitespace within a value MUST be retained unless explicitly excluded
by the specific tag description.
Tag=value pairs that represent the default value MAY be included to
aid legibility.
Unrecognized tags MUST be ignored.
Tags that have an empty value are not the same as omitted tags. An
omitted tag is treated as having the default value; a tag with an
empty value explicitly designates the empty string as the value. For
example, "g=" does not mean "g=*", even though "g=*" is the default
for that tag.
3.3. Signing and Verification Algorithms
DKIM supports multiple digital signature algorithms. Two algorithms
are defined by this specification at this time: rsa-sha1 and rsa-
sha256. The rsa-sha256 algorithm is the default if no algorithm is
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256.
Signers MUST implement and SHOULD sign using rsa-sha256.
Allman, et al. Standards Track [Page 11]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever
possible.
3.3.1. The rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
The signing algorithm SHOULD use a public exponent of 65537.
3.3.2. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
3.3.3. Key Sizes
Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, signers MUST use RSA keys of at least 1024 bits for
long-lived keys. Verifiers MUST be able to validate signatures with
keys ranging from 512 bits to 2048 bits, and they MAY be able to
validate signatures with larger keys. Verifier policies may use the
length of the signing key as one metric for determining whether a
signature is acceptable.
Factors that should influence the key size choice include the
following:
o The practical constraint that large (e.g., 4096 bit) keys may not
fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 1024 bits are
subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email
Allman, et al. Standards Track [Page 12]
RFC 4871 DKIM Signatures May 2007
o Keys can be replaced on a regular basis, thus their lifetime can
be relatively short
o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes.
3.3.4. Other Algorithms
Other algorithms MAY be defined in the future. Verifiers MUST ignore
any signatures using algorithms that they do not implement.
3.4. Canonicalization
Empirical evidence demonstrates that some mail servers and relay
systems modify email in transit, potentially invalidating a
signature. There are two competing perspectives on such
modifications. For most signers, mild modification of email is
immaterial to the authentication status of the email. For such
signers, a canonicalization algorithm that survives modest in-transit
modification is preferred.
Other signers demand that any modification of the email, however
minor, result in a signature verification failure. These signers
prefer a canonicalization algorithm that does not tolerate in-transit
modification of the signed email.
Some signers may be willing to accept modifications to header fields
that are within the bounds of email standards such as [RFC2822], but
are unwilling to accept any modification to the body of messages.
To satisfy all requirements, two canonicalization algorithms are
defined for each of the header and the body: a "simple" algorithm
that tolerates almost no modification and a "relaxed" algorithm that
tolerates common modifications such as whitespace replacement and
header field line rewrapping. A signer MAY specify either algorithm
for header or body when signing an email. If no canonicalization
algorithm is specified by the signer, the "simple" algorithm defaults
for both header and body. Verifiers MUST implement both
canonicalization algorithms. Note that the header and body may use
different canonicalization algorithms. Further canonicalization
algorithms MAY be defined in the future; verifiers MUST ignore any
signatures that use unrecognized canonicalization algorithms.
Canonicalization simply prepares the email for presentation to the
signing or verification algorithm. It MUST NOT change the
Allman, et al. Standards Track [Page 13]
RFC 4871 DKIM Signatures May 2007
transmitted data in any way. Canonicalization of header fields and
body are described below.
NOTE: This section assumes that the message is already in "network
normal" format (text is ASCII encoded, lines are separated with CRLF
characters, etc.). See also Section 5.3 for information about
normalizing the message.
3.4.1. The "simple" Header Canonicalization Algorithm
The "simple" header canonicalization algorithm does not change header
fields in any way. Header fields MUST be presented to the signing or
verification algorithm exactly as they are in the message being
signed or verified. In particular, header field names MUST NOT be
case folded and whitespace MUST NOT be changed.
3.4.2. The "relaxed" Header Canonicalization Algorithm
The "relaxed" header canonicalization algorithm MUST apply the
following steps in order:
o Convert all header field names (not the header field values) to
lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".
o Unfold all header field continuation lines as described in
[RFC2822]; in particular, lines with terminators embedded in
continued header field values (that is, CRLF sequences followed by
WSP) MUST be interpreted without the CRLF. Implementations MUST
NOT remove the CRLF at the end of the header field value.
o Convert all sequences of one or more WSP characters to a single SP
character. WSP characters here include those before and after a
line folding boundary.
o Delete all WSP characters at the end of each unfolded header field
value.
o Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value. The
colon separator MUST be retained.
3.4.3. The "simple" Body Canonicalization Algorithm
The "simple" body canonicalization algorithm ignores all empty lines
at the end of the message body. An empty line is a line of zero
length after removal of the line terminator. If there is no body or
no trailing CRLF on the message body, a CRLF is added. It makes no
Allman, et al. Standards Track [Page 14]
RFC 4871 DKIM Signatures May 2007
other changes to the message body. In more formal terms, the
"simple" body canonicalization algorithm converts "0*CRLF" at the end
of the body to a single "CRLF".
Note that a completely empty or missing body is canonicalized as a
single "CRLF"; that is, the canonicalized length will be 2 octets.
3.4.4. The "relaxed" Body Canonicalization Algorithm
The "relaxed" body canonicalization algorithm:
o Ignores all whitespace at the end of lines. Implementations MUST
NOT remove the CRLF at the end of the line.
o Reduces all sequences of WSP within a line to a single SP
character.
o Ignores all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3.
INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead.
3.4.5. Body Length Limits
A body length count MAY be specified to limit the signature
calculation to an initial prefix of the body text, measured in
octets. If the body length count is not specified, the entire
message body is signed.
INFORMATIVE RATIONALE: This capability is provided because it is
very common for mailing lists to add trailers to messages (e.g.,
instructions how to get off the list). Until those messages are
also signed, the body length count is a useful tool for the
verifier since it may as a matter of policy accept messages having
valid signatures with extraneous data.
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
an attack in which an attacker modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes and to defeat duplicate message detection
algorithms. To avoid this attack, signers should be wary of using
Allman, et al. Standards Track [Page 15]
RFC 4871 DKIM Signatures May 2007
this tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length, perhaps
based on other criteria.
The body length count allows the signer of a message to permit data
to be appended to the end of the body of a signed message. The body
length count MUST be calculated following the canonicalization
algorithm; for example, any whitespace ignored by a canonicalization
algorithm is not included as part of the body length count. Signers
of MIME messages that include a body length count SHOULD be sure that
the length extends to the closing MIME boundary string.
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that
the only acceptable modifications are to add to the MIME postlude
would use a body length count encompassing the entire final MIME
boundary string, including the final "--CRLF". A signer wishing
to allow additional MIME parts but not modification of existing
parts would use a body length count extending through the final
MIME boundary string, omitting the final "--CRLF". Note that this
only works for some MIME types, e.g., multipart/mixed but not
multipart/signed.
A body length count of zero means that the body is completely
unsigned.
Signers wishing to ensure that no modification of any sort can occur
should specify the "simple" canonicalization algorithm for both
header and body and omit the body length count.
3.4.6. Canonicalization Examples (INFORMATIVE)
In the following examples, actual whitespace is used only for
clarity. The actual input and output text is designated using
bracketed descriptors: "<sp>" for a space character, "<htab>" for a </htab></sp>
tab character, and "<crlf>" for a carriage-return/line-feed sequence. </crlf>
For example, "X <sp> Y" and "X<sp>Y" represent the same three </sp></sp>
characters.
Example 1: A message reading:
A: <sp> X <crlf></crlf></sp>
B <sp> : <sp> Y <htab><crlf></crlf></htab></sp></sp>
<htab> Z <sp><sp><crlf></crlf></sp></sp></htab>
<crlf></crlf>
<sp> C <sp><crlf></crlf></sp></sp>
D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>
<crlf></crlf>
<crlf></crlf>
Allman, et al. Standards Track [Page 16]
RFC 4871 DKIM Signatures May 2007
when canonicalized using relaxed canonicalization for both header and
body results in a header reading:
a:X <crlf></crlf>
b:Y <sp> Z <crlf></crlf></sp>
and a body reading:
<sp> C <crlf></crlf></sp>
D <sp> E <crlf></crlf></sp>
Example 2: The same message canonicalized using simple
canonicalization for both header and body results in a header
reading:
A: <sp> X <crlf></crlf></sp>
B <sp> : <sp> Y <htab><crlf></crlf></htab></sp></sp>
<htab> Z <sp><sp><crlf></crlf></sp></sp></htab>
and a body reading:
<sp> C <sp><crlf></crlf></sp></sp>
D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>
Example 3: When processed using relaxed header canonicalization and
simple body canonicalization, the canonicalized version has a header
of:
a:X <crlf></crlf>
b:Y <sp> Z <crlf></crlf></sp>
and a body reading:
<sp> C <sp><crlf></crlf></sp></sp>
D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>
3.5. The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header
field. This header field contains all of the signature and key-
fetching data. The DKIM-Signature value is a tag-list as described
in Section 3.2.
The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in Section 3.6 of [RFC2822], and hence
SHOULD NOT be reordered and SHOULD be prepended to the message.
Allman, et al. Standards Track [Page 17]
RFC 4871 DKIM Signatures May 2007
The DKIM-Signature header field being created or verified is always
included in the signature calculation, after the rest of the header
fields being signed; however, when calculating or verifying the
signature, the value of the "b=" tag (signature value) of that DKIM-
Signature header field MUST be treated as though it were an empty
string. Unknown tags in the DKIM-Signature header field MUST be
included in the signature calculation but MUST be otherwise ignored
by verifiers. Other DKIM-Signature header fields that are included
in the signature should be treated as normal header fields; in
particular, the "b=" tag is not treated specially.
The encodings for each field type are listed below. Tags described
as qp-section are encoded as described in Section 6.7 of MIME Part
One [RFC2045], with the additional conversion of semicolon characters
to "=3B"; intuitively, this is one line of quoted-printable encoded
text. The dkim-quoted-printable syntax is defined in Section 2.6.
Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Unrecognized tags MUST be
ignored.
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison
on this value; for example, "1" is not the same as "1.0".
ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this
specification are released.
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms.
ABNF:
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
Allman, et al. Standards Track [Page 18]
RFC 4871 DKIM Signatures May 2007
b= The signature data (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Signer Actions (Section 5) for how the signature is
computed.
ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
bh= The hash of the canonicalized body part of the message as limited
by the "l=" tag (base64; REQUIRED). Whitespace is ignored in
this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Section 3.7 for how the body hash is computed.
ABNF:
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string
c= Message canonicalization (plain-text; OPTIONAL, default is
"simple/simple"). This tag informs the verifier of the type of
canonicalization used to prepare the message for signing. It
consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the
header and "simple" is used for the body. For example,
"c=relaxed" is treated the same as "c=relaxed/simple".
ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension
d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid.
Allman, et al. Standards Track [Page 19]
RFC 4871 DKIM Signatures May 2007
Internationalized domain names MUST be encoded as described in
[RFC3490].
ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal
h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields
do not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature
header field that is being created or verified, but may include
others. Folding whitespace (FWS) MAY be included on either side
of the colon separator. Header field names MUST be compared
against actual header field names in a case-insensitive manner.
This list MUST NOT be empty. See Section 5.4 for a discussion of
choosing header fields to sign.
ABNF:
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name )
hdr-name = field-name
INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those
header fields before verification. However, since a signer
cannot possibly know what header fields might be created in
the future, and that some MUAs might present header fields
that are embedded inside a message (e.g., as a message/rfc822
content type), the security of this solution is not total.
INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent
header fields prevents an attacker from inserting an actual
header field with a null value.
Allman, et al. Standards Track [Page 20]
RFC 4871 DKIM Signatures May 2007
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@"
followed by the domain from the "d=" tag). The syntax is a
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function.
ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. In such cases, the signer may
wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit
to an individual user name within their domain. It can do so
by including the domain part but not the Local-part of the
identity.
INFORMATIVE DISCUSSION: This document does not require the value
of the "i=" tag to match the identity in any message header
fields. This is considered to be a verifier policy issue.
Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by
an attacker. Hence reliance on the use of these options
should be strictly limited. In particular, it is not at all
clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the
"i=" options.
l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
default is entire body). This tag informs the verifier of the
number of octets in the body of the email after canonicalization
included in the cryptographic hash, starting from 0 immediately
following the CRLF preceding the body. This value MUST NOT be
larger than the actual number of octets in the canonicalized
message body.
Allman, et al. Standards Track [Page 21]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
allow display of fraudulent content without appropriate
warning to end users. The "l=" tag is intended for
increasing signature robustness when sending to mailing lists
that both modify their content and do not sign their
messages. However, using the "l=" tag enables attacks in
which an intermediary with malicious intent modifies a
message to include content that solely benefits the attacker.
It is possible for the appended content to completely replace
the original content in the end recipient's eyes and to
defeat duplicate message detection algorithms. Examples are
described in Security Considerations (Section 8). To avoid
this attack, signers should be extremely wary of using this
tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length.
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76
decimal digits. This constraint is not intended to predict
the size of future messages or to require implementations to
use an integer representation large enough to represent the
maximum possible value, but is intended to remind the
implementer to check the length of this and all other tags
during verification and to test for integer overflow when
decoding the value. Implementers may need to limit the
actual value expressed to a value smaller than 10^76, e.g.,
to allow a message to fit within the available storage space.
ABNF:
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT
q= A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns/txt"). Each
query method is of the form "type[/options]", where the syntax
and semantics of the options depend on the type and specified
options. If there are multiple query mechanisms listed, the
choice of query mechanism MUST NOT change the interpretation of
the signature. Implementations MUST use the recognized query
mechanisms in the order presented.
Currently, the only valid value is "dns/txt", which defines the DNS
TXT record lookup algorithm described elsewhere in this document.
The only option defined for the "dns" query type is "txt", which
MUST be included. Verifiers and signers MUST support "dns/txt".
Allman, et al. Standards Track [Page 22]
RFC 4871 DKIM Signatures May 2007
ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value
s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED).
ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The
value is expressed as an unsigned integer in decimal ASCII. This
value is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at
least 10^12 (until approximately AD 200,000; this fits into 40
bits). To avoid denial-of-service attacks, implementations MAY
consider any value longer than 12 digits to be infinite. Leap
seconds are not counted. Implementations MAY ignore signatures
that have a timestamp in the future.
ABNF:
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
x= Signature Expiration (plain-text unsigned decimal integer;
RECOMMENDED, default is no expiration). The format is the same
as in the "t=" tag, represented as an absolute date, not as a
time delta from the signing timestamp. The value is expressed as
an unsigned integer in decimal ASCII, with the same constraints
on the value in the "t=" tag. Signatures MAY be considered
invalid if the verification time at the verifier is past the
expiration date. The verification time should be the time that
the message was first received at the administrative domain of
the verifier if that time is reliably available; otherwise the
current time should be used. The value of the "x=" tag MUST be
greater than the value of the "t=" tag if both are present.
Allman, et al. Standards Track [Page 23]
RFC 4871 DKIM Signatures May 2007
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay
defense.
ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
z= Copied header fields (dkim-quoted-printable, but see description;
OPTIONAL, default is null). A vertical-bar-separated list of
selected header fields present when the message was signed,
including both the field name and value. It is not required to
include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a
copied header field must be encoded). Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value. After encoding, FWS MAY be added at
arbitrary locations in order to avoid excessively long lines;
such whitespace is NOT part of the value of the header field, and
MUST be removed before decoding.
The header fields referenced by the "h=" tag refer to the fields in
the RFC 2822 header of the message, not to any copied fields in
the "z=" tag. Copied header field values are for diagnostic use.
Header fields with characters requiring conversion (perhaps from
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted
as described in MIME Part Three [RFC2047].
ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines:
Allman, et al. Standards Track [Page 24]
RFC 4871 DKIM Signatures May 2007
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
3.6. Key Management and Representation
Signature applications require some level of assurance that the
verification public key is associated with the claimed signer. Many
applications achieve this by using public key certificates issued by
a trusted third party. However, DKIM can achieve a sufficient level
of security, with significantly enhanced scalability, by simply
having the verifier query the purported signer's DNS entry (or some
security-equivalent) in order to retrieve the public key.
DKIM keys can potentially be stored in multiple types of key servers
and in multiple formats. The storage and format of keys are
irrelevant to the remainder of the DKIM algorithm.
Parameters to the key lookup algorithm are the type of the lookup
(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM-
Signature header field), and the selector (the "s=" tag).
public_key = dkim_find_key(q_val, d_val, s_val)
This document defines a single binding, using DNS TXT records to
distribute the keys. Other bindings may be defined in the future.
3.6.1. Textual Representation
It is expected that many key servers will choose to present the keys
in an otherwise unstructured text format (for example, an XML form
would not be considered to be unstructured text for this purpose).
The following definition MUST be used for any DKIM key represented in
an otherwise unstructured textual form.
The overall syntax is a tag-list as described in Section 3.2. The
current valid tags are described below. Other tags MAY be present
and MUST be ignored by any implementation that does not understand
them.
Allman, et al. Standards Track [Page 25]
RFC 4871 DKIM Signatures May 2007
v= Version of the DKIM key record (plain-text; RECOMMENDED, default
is "DKIM1"). If specified, this tag MUST be set
Network Working Group J. FentonRequest for Comments: 4686 Cisco Systems, Inc.
Category: Informational September 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides an analysis of some threats against Internet
mail that are intended to be addressed by signature-based mail
authentication, in particular DomainKeys Identified Mail. It
discusses the nature and location of the bad actors, what their
capabilities are, and what they intend to accomplish via their
attacks.
Fenton Informational [Page 1]
RFC 4686 DKIM Threat Analysis September 2006
Table of Contents
1. Introduction ....................................................3
1.1. Terminology and Model ......................................3
1.2. Document Structure .........................................5
2. The Bad Actors ..................................................6
2.1. Characteristics ............................................6
2.2. Capabilities ...............................................6
2.3. Location ...................................................8
2.3.1. Externally-Located Bad Actors .......................8
2.3.2. Within Claimed Originator's Administrative Unit .....8
2.3.3. Within Recipient's Administrative Unit ..............9
3. Representative Bad Acts .........................................9
3.1. Use of Arbitrary Identities ................................9
3.2. Use of Specific Identities ................................10
3.2.1. Exploitation of Social Relationships ...............10
3.2.2. Identity-Related Fraud .............................11
3.2.3. Reputation Attacks .................................11
3.2.4. Reflection Attacks .................................11
4. Attacks on Message Signing .....................................12
4.1. Attacks against Message Signatures ........................12
4.1.1. Theft of Private Key for Domain ....................13
4.1.2. Theft of Delegated Private Key .....................13
4.1.3. Private Key Recovery via Side Channel Attack .......14
4.1.4. Chosen Message Replay ..............................14
4.1.5. Signed Message Replay ..............................16
4.1.6. Denial-of-Service Attack against Verifier ..........16
4.1.7. Denial-of-Service Attack against Key Service .......17
4.1.8. Canonicalization Abuse .............................17
4.1.9. Body Length Limit Abuse ............................17
4.1.10. Use of Revoked Key ................................18
4.1.11. Compromise of Key Server ..........................18
4.1.12. Falsification of Key Service Replies ..............19
4.1.13. Publication of Malformed Key Records
and/or Signatures .................................19
4.1.14. Cryptographic Weaknesses in Signature Generation ..20
4.1.15. Display Name Abuse ................................21
4.1.16. Compromised System within Originator's Network ....21
4.1.17. Verification Probe Attack .........................21
4.1.18. Key Publication by Higher-Level Domain ............22
4.2. Attacks against Message Signing Practices .................23
4.2.1. Look-Alike Domain Names ............................23
4.2.2. Internationalized Domain Name Abuse ................23
4.2.3. Denial-of-Service Attack against Signing
Practices ..........................................24
4.2.4. Use of Multiple From Addresses .....................24
4.2.5. Abuse of Third-Party Signatures ....................24
4.2.6. Falsification of Sender Signing Practices Replies ..25
Fenton Informational [Page 2]
RFC 4686 DKIM Threat Analysis September 2006
4.3. Other Attacks .............................................25
4.3.1. Packet Amplification Attacks via DNS ...............25
5. Derived Requirements ...........................................26
6. Security Considerations ........................................26
7. Informative References .........................................27
Appendix A. Acknowledgements ......................................28
1. Introduction
The DomainKeys Identified Mail (DKIM) protocol is being specified by
the IETF DKIM Working Group. The DKIM protocol defines a mechanism
by which email messages can be cryptographically signed, permitting a
signing domain to claim responsibility for the use of a given email
address. Message recipients can verify the signature by querying the
signer's domain directly to retrieve the appropriate public key, and
thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain. This document
addresses threats relative to two works in progress by the DKIM
Working Group, the DKIM signature specification [DKIM-BASE] and DKIM
Sender Signing Practices [DKIM-SSP].
Once the attesting party or parties have been established, the
recipient may evaluate the message in the context of additional
information such as locally-maintained whitelists, shared reputation
services, and/or third-party accreditation. The description of these
mechanisms is outside the scope of the IETF DKIM Working Group
effort. By applying a signature, a good player enables a verifier to
associate a positive reputation with the message, in hopes that it
will receive preferential treatment by the recipient.
This effort is not intended to address threats associated with
message confidentiality nor does it intend to provide a long-term
archival signature.
1.1. Terminology and Model
An administrative unit (AU) is the portion of the path of an email
message that is under common administration. The originator and
recipient typically develop trust relationships with the
administrative units that send and receive their email, respectively,
to perform the signing and verification of their messages.
The origin address is the address on an email message, typically the
RFC 2822 From: address, which is associated with the alleged author
of the message and is displayed by the recipient's Mail User Agent
(MUA) as the source of the message.
Fenton Informational [Page 3]
RFC 4686 DKIM Threat Analysis September 2006
The following diagram illustrates a typical usage flowchart for DKIM:
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[Internet]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+
DKIM operates entirely on the content (body and selected header
fields) of the message, as defined in RFC 2822 [RFC2822]. The
transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and
such elements as the envelope-from and envelope-to addresses and the
HELO domain are not relevant to DKIM verification. This is an
intentional decision made to allow verification of messages via
protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
which an MUA acting as a verifier might use.
The Sender Signing Practices Query referred to in the diagram above
is a means by which the verifier can query the alleged author's
domain to determine their practices for signing messages, which in
turn may influence their evaluation of the message. If, for example,
a message arrives without any valid signatures, and the alleged
author's domain advertises that they sign all messages, the verifier
might handle that message differently than if a signature was not
necessarily to be expected.
Fenton Informational [Page 4]
RFC 4686 DKIM Threat Analysis September 2006
1.2. Document Structure
The remainder of this document describes the problems that DKIM might
be expected to address, and the extent to which it may be successful
in so doing. These are described in terms of the potential bad
actors, their capabilities and location in the network, and the bad
acts that they might wish to commit.
This is followed by a description of postulated attacks on DKIM
message signing and on the use of Sender Signing Practices to assist
in the treatment of unsigned messages. A list of derived
requirements is also presented, which is intended to guide the DKIM
design and review process.
The sections dealing with attacks on DKIM each begin with a table
summarizing the postulated attacks in each category along with their
expected impact and likelihood. The following definitions were used
as rough criteria for scoring the attacks:
Impact:
High: Affects the verification of messages from an entire domain
or multiple domains
Medium: Affects the verification of messages from specific users,
Mail Transfer Agents (MTAs), and/or bounded time periods
Low: Affects the verification of isolated individual messages
only
Likelihood:
High: All email users should expect this attack on a frequent
basis
Medium: Email users should expect this attack occasionally;
frequently for a few users
Low: Attack is expected to be rare and/or very infrequent
Fenton Informational [Page 5]
RFC 4686 DKIM Threat Analysis September 2006
2. The Bad Actors
2.1. Characteristics
The problem space being addressed by DKIM is characterized by a wide
range of attackers in terms of motivation, sophistication, and
capabilities.
At the low end of the spectrum are bad actors who may simply send
email, perhaps using one of many commercially available tools, that
the recipient does not want to receive. These tools typically allow
one to falsify the origin address of messages, and may, in the
future, be capable of generating message signatures as well.
At the next tier are what would be considered "professional" senders
of unwanted email. These attackers would deploy specific
infrastructure, including Mail Transfer Agents (MTAs), registered
domains and networks of compromised computers ("zombies") to send
messages, and in some cases to harvest addresses to which to send.
These senders often operate as commercial enterprises and send
messages on behalf of third parties.
The most sophisticated and financially-motivated senders of messages
are those who stand to receive substantial financial benefit, such as
from an email-based fraud scheme. These attackers can be expected to
employ all of the above mechanisms and additionally may attack the
Internet infrastructure itself, including DNS cache-poisoning attacks
and IP routing attacks.
2.2. Capabilities
In general, the bad actors described above should be expected to have
access to the following:
1. An extensive corpus of messages from domains they might wish to
impersonate
2. Knowledge of the business aims and model for domains they might
wish to impersonate
3. Access to public keys and associated authorization records
associated with the domain
and the ability to do at least some of the following:
1. Submit messages to MTAs and Message Submission Agents (MSAs) at
multiple locations in the Internet
Fenton Informational [Page 6]
RFC 4686 DKIM Threat Analysis September 2006
2. Construct arbitrary message header fields, including those
claiming to be mailing lists, resenders, and other mail agents
3. Sign messages on behalf of domains under their control
4. Generate substantial numbers of either unsigned or apparently-
signed messages that might be used to attempt a denial-of-service
attack
5. Resend messages that may have been previously signed by the
domain
6. Transmit messages using any envelope information desired
7. Act as an authorized submitter for messages from a compromised
computer
As noted above, certain classes of bad actors may have substantial
financial motivation for their activities, and therefore should be
expected to have more capabilities at their disposal. These include:
1. Manipulation of IP routing. This could be used to submit
messages from specific IP addresses or difficult-to-trace
addresses, or to cause diversion of messages to a specific
domain.
2. Limited influence over portions of DNS using mechanisms such as
cache poisoning. This might be used to influence message routing
or to falsify advertisements of DNS-based keys or signing
practices.
3. Access to significant computing resources, for example, through
the conscription of worm-infected "zombie" computers. This could
allow the bad actor to perform various types of brute-force
attacks.
4. Ability to eavesdrop on existing traffic, perhaps from a wireless
network.
Either of the first two of these mechanisms could be used to allow
the bad actor to function as a man-in-the-middle between author and
recipient, if that attack is useful.
Fenton Informational [Page 7]
RFC 4686 DKIM Threat Analysis September 2006
2.3. Location
Bad actors or their proxies can be located anywhere in the Internet.
Certain attacks are possible primarily within the administrative unit
of the claimed originator and/or recipient domain have capabilities
beyond those elsewhere, as described in the below sections. Bad
actors can also collude by acting from multiple locations (a
"distributed bad actor").
It should also be noted that with the use of "zombies" and other
proxies, externally-located bad actors may gain some of the
capabilities of being located within the claimed originator's or
recipient's administrative unit. This emphasizes the importance of
appropriate security measures, such as authenticated submission of
messages, even within administrative units.
2.3.1. Externally-Located Bad Actors
DKIM focuses primarily on bad actors located outside of the
administrative units of the claimed originator and the recipient.
These administrative units frequently correspond to the protected
portions of the network adjacent to the originator and recipient. It
is in this area that the trust relationships required for
authenticated message submission do not exist and do not scale
adequately to be practical. Conversely, within these administrative
units, there are other mechanisms such as authenticated message
submission that are easier to deploy and more likely to be used than
DKIM.
External bad actors are usually attempting to exploit the "any to
any" nature of email that motivates most recipient MTAs to accept
messages from anywhere for delivery to their local domain. They may
generate messages without signatures, with incorrect signatures, or
with correct signatures from domains with little traceability. They
may also pose as mailing lists, greeting cards, or other agents that
legitimately send or resend messages on behalf of others.
2.3.2. Within Claimed Originator's Administrative Unit
Bad actors in the form of rogue or unauthorized users or malware-
infected computers can exist within the administrative unit
corresponding to a message's origin address. Since the submission of
messages in this area generally occurs prior to the application of a
message signature, DKIM is not directly effective against these bad
actors. Defense against these bad actors is dependent upon other
means, such as proper use of firewalls, and Message Submission Agents
that are configured to authenticate the author.
Fenton Informational [Page 8]
RFC 4686 DKIM Threat Analysis September 2006
In the special case where the administrative unit is non-contiguous
(e.g., a company that communicates between branches over the external
Internet), DKIM signatures can be used to distinguish between
legitimate externally-originated messages and attempts to spoof
addresses in the local domain.
2.3.3. Within Recipient's Administrative Unit
Bad actors may also exist within the administrative unit of the
message recipient. These bad actors may attempt to exploit the trust
relationships that exist within the unit. Since messages will
typically only have undergone DKIM verification at the administrative
unit boundary, DKIM is not effective against messages submitted in
this area.
For example, the bad actor may attempt to spoof a header field
indicating the results of verification. This header field would
normally be added by the verifier, which would also detect spoofed
header fields on messages it was attempting to verify. This could be
used to falsely indicate that the message was authenticated
successfully.
As in the originator case, these bad actors can be dealt with by
controlling the submission of messages within the administrative
unit. Since DKIM permits verification to occur anywhere within the
recipient's administrative unit, these threats can also be minimized
by moving verification closer to the recipient, such as at the Mail
Delivery Agent (MDA), or on the recipient's MUA itself.
3. Representative Bad Acts
One of the most fundamental bad acts being attempted is the delivery
of messages that are not intended to have been sent by the alleged
originating domain. As described above, these messages might merely
be unwanted by the recipient, or might be part of a confidence scheme
or a delivery vector for malware.
3.1. Use of Arbitrary Identities
This class of bad acts includes the sending of messages that aim to
obscure the identity of the actual author. In some cases, the actual
sender might be the bad actor, or in other cases might be a third-
party under the control of the bad actor (e.g., a compromised
computer).
Particularly when coupled with sender signing practices that indicate
the domain owner signs all messages, DKIM can be effective in
mitigating against the abuse of addresses not controlled by bad
Fenton Informational [Page 9]
RFC 4686 DKIM Threat Analysis September 2006
actors. DKIM is not effective against the use of addresses
controlled by bad actors. In other words, the presence of a valid
DKIM signature does not guarantee that the signer is not a bad actor.
It also does not guarantee the accountability of the signer, since
DKIM does not attempt to identify the signer individually, but rather
identifies the domain that they control. Accreditation and
reputation systems and locally-maintained whitelists and blacklists
can be used to enhance the accountability of DKIM-verified addresses
and/or the likelihood that signed messages are desirable.
3.2. Use of Specific Identities
A second major class of bad acts involves the assertion of specific
identities in email.
Note that some bad acts involving specific identities can sometimes
be accomplished, although perhaps less effectively, with similar
looking identities that mislead some recipients. For example, if the
bad actor is able to control the domain "examp1e.com" (note the "one"
between the p and e), they might be able to convince some recipients
that a message from admin@examp1e.com is really from
admin@example.com. Similar types of attacks using internationalized
domain names have been hypothesized where it could be very difficult
to see character differences in popular typefaces. Similarly, if
example2.com was controlled by a bad actor, the bad actor could sign
messages from bigbank.example2.com, which might also mislead some
recipients. To the extent that these domains are controlled by bad
actors, DKIM is not effective against these attacks, although it
could support the ability of reputation and/or accreditation systems
to aid the user in identifying them.
DKIM is effective against the use of specific identities only when
there is an expectation that such messages will, in fact, be signed.
The primary means for establishing this is the use of Sender Signing
Practices (SSP), which will be specified by the IETF DKIM Working
Group.
3.2.1. Exploitation of Social Relationships
One reason for asserting a specific origin address is to encourage a
recipient to read and act on particular email messages by appearing
to be an acquaintance or previous correspondent that the recipient
might trust. This tactic has been used by email-propagated malware
that mail themselves to addresses in the infected host's address
book. In this case, however, the author's address may not be
falsified, so DKIM would not be effective in defending against this
act.
Fenton Informational [Page 10]
RFC 4686 DKIM Threat Analysis September 2006
It is also possible for address books to be harvested and used by an
attacker to post messages from elsewhere. DKIM could be effective in
mitigating these acts by limiting the scope of origin addresses for
which a valid signature can be obtained when sending the messages
from other locations.
3.2.2. Identity-Related Fraud
Bad acts related to email-based fraud often, but not always, involve
the transmission of messages using specific origin addresses of other
entities as part of the fraud scheme. The use of a specific address
of origin sometimes contributes to the success of the fraud by
helping convince the recipient that the message was actually sent by
the alleged author.
To the extent that the success of the fraud depends on or is enhanced
by the use of a specific origin address, the bad actor may have
significant financial motivation and resources to circumvent any
measures taken to protect specific addresses from unauthorized use.
When signatures are verified by or for the recipient, DKIM is
effective in defending against the fraudulent use of origin addresses
on signed messages. When the published sender signing practices of
the origin address indicate that all messages from that address
should be signed, DKIM further mitigates against the attempted
fraudulent use of the origin address on unsigned messages.
3.2.3. Reputation Attacks
Another motivation for using a specific origin address in a message
is to harm the reputation of another, commonly referred to as a
"joe-job". For example, a commercial entity might wish to harm the
reputation of a competitor, perhaps by sending unsolicited bulk email
on behalf of that competitor. It is for this reason that reputation
systems must be based on an identity that is, in practice, fairly
reliable.
3.2.4. Reflection Attacks
A commonly-used tactic by some bad actors is the indirect
transmission of messages by intentionally mis-addressing the message
and causing it to be "bounced", or sent to the return address (RFC
2821 envelope-from address) on the message. In this case, the
specific identity asserted in the email is that of the actual target
of the message, to whom the message is "returned".
DKIM does not, in general, attempt to validate the RFC2821.mailfrom
return address on messages, either directly (noting that the mailfrom
Fenton Informational [Page 11]
RFC 4686 DKIM Threat Analysis September 2006
address is an element of the SMTP protocol, and not the message
content on which DKIM operates), or via the optional Return-Path
header field. Furthermore, as is noted in Section 4.4 of RFC 2821
[RFC2821], it is common and useful practice for a message's return
path not to correspond to the origin address. For these reasons,
DKIM is not effective against reflection attacks.
4. Attacks on Message Signing
Bad actors can be expected to exploit all of the limitations of
message authentication systems. They are also likely to be motivated
to degrade the usefulness of message authentication systems in order
to hinder their deployment. Both the signature mechanism itself and
declarations made regarding use of message signatures (referred to
here as Sender Signing Practices or SSP) can be expected to be the
target of attacks.
4.1. Attacks against Message Signatures
The following is a summary of postulated attacks against DKIM
signatures:
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Theft of private key for domain | High | Low |
| Theft of delegated private key | Medium | Medium |
| Private key recovery via side channel attack| High | Low |
| Chosen message replay | Low | M/H |
| Signed message replay | Low | High |
| Denial-of-service attack against verifier | High | Medium |
| Denial-of-service attack against key service| High | Medium |
| Canonicalization abuse | Low | Medium |
| Body length limit abuse | Medium | Medium |
| Use of revoked key | Medium | Low |
| Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low |
| signatures | | |
| Cryptographic weaknesses in signature | High | Low |
| generation | | |
| Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium |
| network | | |
| Verification probe attack | Medium | Medium |
| Key publication by higher-level domain | High | Low |
+---------------------------------------------+--------+------------+
Fenton Informational [Page 12]
RFC 4686 DKIM Threat Analysis September 2006
4.1.1. Theft of Private Key for Domain
Message signing technologies such as DKIM are vulnerable to theft of
the private keys used to sign messages. This includes "out-of-band"
means for this theft, such as burglary, bribery, extortion, and the
like, as well as electronic means for such theft, such as a
compromise of network and host security around the place where a
private key is stored.
Keys that are valid for all addresses in a domain typically reside in
MTAs that should be located in well-protected sites, such as data
centers. Various means should be employed for minimizing access to
private keys, such as non-existence of commands for displaying their
value, although ultimately memory dumps and the like will probably
contain the keys. Due to the unattended nature of MTAs, some
countermeasures, such as the use of a pass phrase to "unlock" a key,
are not practical to use. Other mechanisms, such as the use of
dedicated hardware devices that contain the private key and perform
the cryptographic signature operation, would be very effective in
denying export of the private key to those without physical access to
the device. Such devices would almost certainly make the theft of
the key visible, so that appropriate action (revocation of the
corresponding public key) can be taken should that happen.
4.1.2. Theft of Delegated Private Key
There are several circumstances where a domain owner will want to
delegate the ability to sign messages for the domain to an individual
user or a third party associated with an outsourced activity such as
a corporate benefits administrator or a marketing campaign. Since
these keys may exist on less well-protected devices than the domain's
own MTAs, they will in many cases be more susceptible to compromise.
In order to mitigate this exposure, keys used to sign such messages
can be restricted by the domain owner to be valid for signing
messages only on behalf of specific addresses in the domain. This
maintains protection for the majority of addresses in the domain.
A related threat is the exploitation of weaknesses in the delegation
process itself. This threat can be mitigated through the use of
customary precautions against the theft of private keys and the
falsification of public keys in transit. For example, the exposure
to theft can be minimized if the delegate generates the keypair to be
used, and sends the public key to the domain owner. The exposure to
falsification (substitution of a different public key) can be reduced
if this transmission is signed by the delegate and verified by the
domain owner.
Fenton Informational [Page 13]
RFC 4686 DKIM Threat Analysis September 2006
4.1.3. Private Key Recovery via Side Channel Attack
All popular digital signature algorithms are subject to a variety of
side channel attacks. The most well-known of these are timing
channels [Kocher96], power analysis [Kocher99], and cache timing
analysis [Bernstein04]. Most of these attacks require either
physical access to the machine or the ability to run processes
directly on the target machine. Defending against these attacks is
out of scope for DKIM.
However, remote timing analysis (at least on local area networks) is
known to be feasible [Boneh03], particularly in server-type platforms
where the attacker can inject traffic that will immediately be
subject to the cryptographic operation in question. With enough
samples, these techniques can be used to extract private keys even in
the face of modest amounts of noise in the timing measurements.
The three commonly proposed countermeasures against timing analysis
are:
1. Make the operation run in constant time. This turns out in
practice to be rather difficult.
2. Make the time independent of the input data. This can be
difficult, but see [Boneh03] for more details.
3. Use blinding. This is generally considered the best current
practice countermeasure, and while not proved generally secure is
a countermeasure against known timing attacks. It adds about
2-10% to the cost of the operation and is implemented in many
common cryptographic libraries. Unfortunately, Digital Signature
Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have
standard methods though some defenses may exist.
Note that adding random delays to the operation is only a partial
countermeasure. Because the noise is generally uniformly
distributed, a large enough number of samples can be used to average
it out and extract an accurate timing signal.
4.1.4. Chosen Message Replay
Chosen message replay refers to the scenario where the attacker
creates a message and obtains a signature for it by sending it
through an MTA authorized by the originating domain to
himself/herself or an accomplice. They then "replay" the signed
message by sending it, using different envelope addresses, to a
(typically large) number of other recipients.
Fenton Informational [Page 14]
RFC 4686 DKIM Threat Analysis September 2006
Due to the requirement to get an attacker-generated message signed,
chosen message replay would most commonly be experienced by consumer
ISPs or others offering email accounts to clients, particularly where
there is little or no accountability to the account holder (the
attacker in this case). One approach to solving this problem is for
the domain to only sign email for clients that have passed a vetting
process to provide traceability to the message originator in the
event of abuse. At present, the low cost of email accounts (zero)
does not make it practical for any vetting to occur. It remains to
be seen whether this will be the model with signed mail as well, or
whether a higher level of trust will be required to obtain an email
signature.
A variation on this attack involves the attacker sending a message
with the intent of obtaining a signed reply containing their original
message. The reply might come from an innocent user or might be an
automatic response such as a "user unknown" bounce message. In some
cases, this signed reply message might accomplish the attacker's
objectives if replayed. This variation on chosen message replay can
be mitigated by limiting the extent to which the original content is
quoted in automatic replies, and by the use of complementary
mechanisms such as egress content filtering.
Revocation of the signature or the associated key is a potential
countermeasure. However, the rapid pace at which the message might
be replayed (especially with an army of "zombie" computers), compared
with the time required to detect the attack and implement the
revocation, is likely to be problematic. A related problem is the
likelihood that domains will use a small number of signing keys for a
large number of customers, which is beneficial from a caching
standpoint but is likely to result in a great deal of collateral
damage (in the form of signature verification failures) should a key
be revoked suddenly.
Signature revocation addresses the collateral damage problem at the
expense of significant scaling requirements. At the extreme,
verifiers could be required to check for revocation of each signature
verified, which would result in very significant transaction rates.
An alternative, "revocation identifiers", has been proposed, which
would permit revocation on an intermediate level of granularity,
perhaps on a per-account basis. Messages containing these
identifiers would result in a query to a revocation database, which
might be represented in DNS.
Further study is needed to determine if the benefits from revocation
(given the potential speed of a replay attack) outweigh the
transactional cost of querying a revocation database.
Fenton Informational [Page 15]
RFC 4686 DKIM Threat Analysis September 2006
4.1.5. Signed Message Replay
Signed message replay refers to the retransmission of already-signed
messages to additional recipients beyond those intended by the author
or the original poster of the message. The attacker arranges to
receive a message from the victim, and then retransmits it intact but
with different envelope addresses. This might be done, for example,
to make it look like a legitimate sender of messages is sending a
large amount of spam. When reputation services are deployed, this
could damage the author's reputation or that of the author's domain.
A larger number of domains are potential victims of signed message
replay than chosen message replay because the former does not require
the ability for the attacker to send messages from the victim domain.
However, the capabilities of the attacker are lower. Unless coupled
with another attack such as body length limit abuse, it isn't
possible for the attacker to use this, for example, for advertising.
Many mailing lists, especially those that do not modify the content
of the message and signed header fields and hence do not invalidate
the signature, engage in a form of signed message replay. The use of
body length limits and other mechanisms to enhance the survivability
of messages effectively enhances the ability to do so. The only
things that distinguish this case from undesirable forms of signed
message replay is the intent of the replayer, which cannot be
determined by the network.
4.1.6. Denial-of-Service Attack against Verifier
While it takes some computing resources to sign and verify a
signature, it takes negligible computing resources to generate an
invalid signature. An attacker could therefore construct a "make
work" attack against a verifier, by sending a large number of
incorrectly-signed messages to a given verifier, perhaps with
multiple signatures each. The motivation might be to make it too
expensive to verify messages.
While this attack is feasible, it can be greatly mitigated by the
manner in which the verifier operates. For example, it might decide
to accept only a certain number of signatures per message, limit the
maximum key size it will accept (to prevent outrageously large
signatures from causing unneeded work), and verify signatures in a
particular order. The verifier could also maintain state
representing the current signature verification failure rate and
adopt a defensive posture when attacks may be under way.
Fenton Informational [Page 16]
RFC 4686 DKIM Threat Analysis September 2006
4.1.7. Denial-of-Service Attack against Key Service
An attacker might also attempt to degrade the availability of an
originator's key service, in order to cause that originator's
messages to be unverifiable. One way to do this might be to quickly
send a large number of messages with signatures that reference a
particular key, thereby creating a heavy load on the key server.
Other types of DoS attacks on the key server or the network
infrastructure serving it are also possible.
The best defense against this attack is to provide redundant key
servers, preferably on geographically-separate parts of the Internet.
Caching also helps a great deal, by decreasing the load on
authoritative key servers when there are many simultaneous key
requests. The use of a key service protocol that minimizes the
transactional cost of key lookups is also beneficial. It is noted
that the Domain Name System has all these characteristics.
4.1.8. Canonicalization Abuse
Canonicalization algorithms represent a tradeoff between the survival
of the validity of a message signature and the desire not to allow
the message to be altered inappropriately. In the past,
canonicalization algorithms have been proposed that would have
permitted attackers, in some cases, to alter the meaning of a
message.
Message signatures that support multiple canonicalization algorithms
give the signer the ability to decide the relative importance of
signature survivability and immutability of the signed content. If
an unexpected vulnerability appears in a canonicalization algorithm
in general use, new algorithms can be deployed, although it will be a
slow process because the signer can never be sure which algorithm(s)
the verifier supports. For this reason, canonicalization algorithms,
like cryptographic algorithms, should undergo a wide and careful
review process.
4.1.9. Body Length Limit Abuse
A body length limit is an optional indication from the signer of how
much content has been signed. The verifier can either ignore the
limit, verify the specified portion of the message, or truncate the
message to the specified portion and verify it. The motivation for
this feature is the behavior of many mailing lists that add a
trailer, perhaps identifying the list, at the end of messages.
Fenton Informational [Page 17]
RFC 4686 DKIM Threat Analysis September 2006
When body length limits are used, there is the potential for an
attacker to add content to the message. It has been shown that this
content, although at the end, can cover desirable content, especially
in the case of HTML messages.
If the body length isn't specified, or if the verifier decides to
ignore the limit, body length limits are moot. If the verifier or
recipient truncates the message at the signed content, there is no
opportunity for the attacker to add anything.
If the verifier observes body length limits when present, there is
the potential that an attacker can make undesired content visible to
the recipient. The size of the appended content makes little
difference, because it can simply be a URL reference pointing to the
actual content. Receiving MUAs can mitigate this threat by, at a
minimum, identifying the unsigned content in the message.
4.1.10. Use of Revoked Key
The benefits obtained by caching of key records opens the possibility
that keys that have been revoked may be used for some period of time
after their revocation. The best examples of this occur when a
holder of a key delegated by the domain administrator must be
unexpectedly deauthorized from sending mail on behalf of one or more
addresses in the domain.
The caching of key records is normally short-lived, on the order of
hours to days. In many cases, this threat can be mitigated simply by
setting a short time-to-live (TTL) for keys not under the domain
administrator's direct control (assuming, of course, that control of
the TTL value may be specified for each record, as it can with DNS).
In some cases, such as the recovery following a stolen private key
belonging to one of the domain's MTAs, the possibility of theft and
the effort required to revoke the key authorization must be
considered when choosing a TTL. The chosen TTL must be long enough
to mitigate denial-of-service attacks and provide reasonable
transaction efficiency, and no longer.
4.1.11. Compromise of Key Server
Rather than by attempting to obtain a private key, an attacker might
instead focus efforts on the server used to publish public keys for a
domain. As in the key theft case, the motive might be to allow the
attacker to sign messages on behalf of the domain. This attack
provides the attacker with the additional capability to remove
legitimate keys from publication, thereby denying the domain the
ability for the signatures on its mail to verify correctly.
Fenton Informational [Page 18]
RFC 4686 DKIM Threat Analysis September 2006
In order to limit the ability to sign a message to entities
authorized by the owner of a signing domain, a relationship must be
established between the signing address and the location from which a
public key is obtained to verify the message. DKIM does this by
publishing either the public key or a reference to it within the DNS
hierarchy of the signing domain. The verifier derives the location
from which to retrieve the public key from the signing address or
domain. The security of the verification process is therefore
dependent on the security of the DNS hierarchy for the signing
domain.
An attacker might successfully compromise the host that is the
primary key server for the signing domain, such as the domain's DNS
master server. Another approach might be to compromise a higher-
level DNS server and change the delegation of name servers for the
signing domain to others under the control of the attacker.
This attack can be mitigated somewhat by independent monitoring to
audit the key service. Such auditing of the key service should occur
by means of zone transfers rather than queries to the zone's primary
server, so that the addition of records to the zone can be detected.
4.1.12. Falsification of Key Service Replies
Replies from the key service may also be spoofed by a suitably
positioned attacker. For DNS, one such way to do this is "cache
poisoning", in which the attacker provides unnecessary (and
incorrect) additional information in DNS replies, which is cached.
DNSSEC [RFC4033] is the preferred means of mitigating this threat,
but the current uptake rate for DNSSEC is slow enough that one would
not like to create a dependency on its deployment. In the case of a
cache poisoning attack, the vulnerabilities created by this attack
are both localized and of limited duration, although records with
relatively long TTL may persist beyond the attack itself.
4.1.13. Publication of Malformed Key Records and/or Signatures
In this attack, the attacker publishes suitably crafted key records
or sends mail with intentionally malformed signatures, in an attempt
to confuse the verifier and perhaps disable verification altogether.
This attack is really a characteristic of an implementation
vulnerability, a buffer overflow or lack of bounds checking, for
example, rather than a vulnerability of the signature mechanism
itself. This threat is best mitigated by careful implementation and
creation of test suites that challenge the verification process.
Fenton Informational [Page 19]
RFC 4686 DKIM Threat Analysis September 2006
4.1.14. Cryptographic Weaknesses in Signature Generation
The cryptographic algorithms used to generate mail signatures,
specifically the hash algorithm and digital signature generation and
verification operations, may over time be subject to mathematical
techniques that degrade their security. At this writing, the SHA-1
hash algorithm is the subject of extensive mathematical analysis that
has considerably lowered the time required to create two messages
with the same hash value. This trend can be expected to continue.
One consequence of a weakness in the hash algorithm is a hash
collision attack. Hash collision attacks in message signing systems
involve the same person creating two different messages that have the
same hash value, where only one of the two messages would normally be
signed. The attack is based on the second message inheriting the
signature of the first. For DKIM, this means that a sender might
create a "good" message and a "bad" message, where some filter at the
signing party's site would sign the good message but not the bad
message. The attacker gets the good message signed, and then
incorporates that signature in the bad message. This scenario is not
common, but could happen, for example, at a site that does content
analysis on messages before signing them.
Current known attacks against SHA-1 make this attack extremely
difficult to mount, but as attacks improve and computing power
becomes more readily available, such an attack could become
achievable.
The message signature system must be designed to support multiple
signature and hash algorithms, and the signing domain must be able to
specify which algorithms it uses to sign messages. The choice of
algorithms must be published in key records, and not only in the
signature itself, to ensure that an attacker is not able to create
signatures using algorithms weaker than the domain wishes to permit.
Because the signer and verifier of email do not, in general,
communicate directly, negotiation of the algorithms used for signing
cannot occur. In other words, a signer has no way of knowing which
algorithm(s) a verifier supports or (due to mail forwarding) where
the verifier is. For this reason, it is expected that once message
signing is widely deployed, algorithm change will occur slowly, and
legacy algorithms will need to be supported for a considerable
period. Algorithms used for message signatures therefore need to be
secure against expected cryptographic developments several years into
the future.
Fenton Informational [Page 20]
RFC 4686 DKIM Threat Analysis September 2006
4.1.15. Display Name Abuse
Message signatures only relate to the address-specification portion
of an email address, while some MUAs only display (or some recipients
only pay attention to) the display name portion of the address. This
inconsistency leads to an attack where the attacker uses a From
header field such as:
From: "Dudley DoRight" <whiplash></whiplash>
In this example, the attacker, whiplash@example.org, can sign the
message and still convince some recipients that the message is from
Dudley DoRight, who is presumably a trusted individual. Coupled with
the use of a throw-away domain or email address, it may be difficult
to hold the attacker accountable for using another's display name.
This is an attack that must be dealt with in the recipient's MUA.
One approach is to require that the signer's address specification
(and not just the display name) be visible to the recipient.
4.1.16. Compromised System within Originator's Network
In many cases, MTAs may be configured to accept and sign messages
that originate within the topological boundaries of the originator's
network (i.e., within a firewall). The increasing use of compromised
systems to send email presents a problem for such policies, because
the attacker, using a compromised system as a proxy, can generate
signed mail at will.
Several approaches exist for mitigating this attack. The use of
authenticated submission, even within the network boundaries, can be
used to limit the addresses for which the attacker may obtain a
signature. It may also help locate the compromised system that is
the source of the messages more quickly. Content analysis of
outbound mail to identify undesirable and malicious content, as well
as monitoring of the volume of messages being sent by users, may also
prevent arbitrary messages from being signed and sent.
4.1.17. Verification Probe Attack
As noted above, bad actors (attackers) can sign messages on behalf of
domains they control. Since they may also control the key service
(e.g., the authoritative DNS name servers for the _domainkey
subdomain), it is possible for them to observe public key lookups,
and their source, when messages are verified.
Fenton Informational [Page 21]
RFC 4686 DKIM Threat Analysis September 2006
One such attack, which we will refer to as a "verification probe", is
to send a message with a DKIM signature to each of many addresses in
a mailing list. The messages need not contain valid signatures, and
each instance of the message would typically use a different
selector. The attacker could then monitor key service requests and
determine which selectors had been accessed, and correspondingly
which addressees used DKIM verification. This could be used to
target future mailings at recipients who do not use DKIM
verification, on the premise that these addressees are more likely to
act on the message contents.
4.1.18. Key Publication by Higher-Level Domain
In order to support the ability of a domain to sign for subdomains
under its administrative control, DKIM permits the domain of a
signature (d= tag) to be any higher-level domain than the signature's
address (i= or equivalent). However, since there is no mechanism for
determining common administrative control of a subdomain, it is
possible for a parent to publish keys that are valid for any domain
below them in the DNS hierarchy. In other words, mail from the
domain example.anytown.ny.us could be signed using keys published by
anytown.ny.us, ny.us, or us, in addition to the domain itself.
Operation of a domain always requires a trust relationship with
higher-level domains. Higher-level domains already have ultimate
power over their subdomains: they could change the name server
delegation for the domain or disenfranchise it entirely. So it is
unlikely that a higher-level domain would intentionally compromise a
subdomain in this manner. However, if higher-level domains send mail
on their own behalf, they may wish to publish keys at their own
level. Higher-level domains must employ special care in the
delegation of keys they publish to ensure that any of their
subdomains are not compromised by misuse of such keys.
Fenton Informational [Page 22]
RFC 4686 DKIM Threat Analysis September 2006
4.2. Attacks against Message Signing Practices
The following is a summary of postulated attacks against signing
practices:
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium |
| practices | | |
| Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Practices | Medium | Medium |
| replies | | |
+---------------------------------------------+--------+------------+
4.2.1. Look-Alike Domain Names
Attackers may attempt to circumvent signing practices of a domain by
using a domain name that is close to, but not the same as, the domain
with signing practices. For instance, "example.com" might be
replaced by "examp1e.com". If the message is not to be signed, DKIM
does not require that the domain used actually exist (although other
mechanisms may make this a requirement). Services exist to monitor
domain registrations to identify potential domain name abuse, but
naturally do not identify the use of unregistered domain names.
A related attack is possible when the MUA does not render the domain
name in an easily recognizable format. If, for example, a Chinese
domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the
unfamiliarity of that representation may enable other domains to more
easily be mis-recognized as the expected domain.
Users that are unfamiliar with internet naming conventions may also
mis-recognize certain names. For example, users may confuse
online.example.com with online-example.com, the latter of which may
have been registered by an attacker.
4.2.2. Internationalized Domain Name Abuse
Internationalized domain names present a special case of the look-
alike domain name attack described above. Due to similarities in the
appearance of many Unicode characters, domains (particularly those
drawing characters from different groups) may be created that are
visually indistinguishable from other, possibly high-value domains.
This is discussed in detail in Unicode Technical Report 36 [UTR36].
Fenton Informational [Page 23]
RFC 4686 DKIM Threat Analysis September 2006
Surveillance of domain registration records may point out some of
these, but there are many such similarities. As in the look-alike
domain attack above, this technique may also be used to circumvent
sender signing practices of other domains.
4.2.3. Denial-of-Service Attack against Signing Practices
Just as the publication of public keys by a domain can be impacted by
an attacker, so can the publication of Sender Signing Practices (SSP)
by a domain. In the case of SSP, the transmission of large amounts
of unsigned mail purporting to come from the domain can result in a
heavy transaction load requesting the SSP record. More general DoS
Network Working Group P. Resnick, EditorRequest for Comments: 2822 QUALCOMM Incorporated
Obsoletes: 822 April 2001
Category: Standards Track
Internet Message Format
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages. This standard supersedes the one specified in Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages", updating it to reflect current practice and incorporating
incremental changes that were specified in other RFCs.
Table of Contents
1. Introduction ............................................... 3
1.1. Scope .................................................... 3
1.2. Notational conventions ................................... 4
1.2.1. Requirements notation .................................. 4
1.2.2. Syntactic notation ..................................... 4
1.3. Structure of this document ............................... 4
2. Lexical Analysis of Messages ............................... 5
2.1. General Description ...................................... 5
2.1.1. Line Length Limits ..................................... 6
2.2. Header Fields ............................................ 7
2.2.1. Unstructured Header Field Bodies ....................... 7
2.2.2. Structured Header Field Bodies ......................... 7
2.2.3. Long Header Fields ..................................... 7
2.3. Body ..................................................... 8
3. Syntax ..................................................... 9
3.1. Introduction ............................................. 9
3.2. Lexical Tokens ........................................... 9
3.2.1. Primitive Tokens ....................................... 9
3.2.2. Quoted characters ......................................10
3.2.3. Folding white space and comments .......................11
3.2.4. Atom ...................................................12
3.2.5. Quoted strings .........................................13
3.2.6. Miscellaneous tokens ...................................13
3.3. Date and Time Specification ..............................14
3.4. Address Specification ....................................15
3.4.1. Addr-spec specification ................................16
3.5 Overall message syntax ....................................17
3.6. Field definitions ........................................18
3.6.1. The origination date field .............................20
3.6.2. Originator fields ......................................21
3.6.3. Destination address fields .............................22
3.6.4. Identification fields ..................................23
3.6.5. Informational fields ...................................26
3.6.6. Resent fields ..........................................26
3.6.7. Trace fields ...........................................28
3.6.8. Optional fields ........................................29
4. Obsolete Syntax ............................................29
4.1. Miscellaneous obsolete tokens ............................30
4.2. Obsolete folding white space .............................31
4.3. Obsolete Date and Time ...................................31
4.4. Obsolete Addressing ......................................33
4.5. Obsolete header fields ...................................33
4.5.1. Obsolete origination date field ........................34
4.5.2. Obsolete originator fields .............................34
4.5.3. Obsolete destination address fields ....................34
4.5.4. Obsolete identification fields .........................35
4.5.5. Obsolete informational fields ..........................35
4.5.6. Obsolete resent fields .................................35
4.5.7. Obsolete trace fields ..................................36
4.5.8. Obsolete optional fields ...............................36
5. Security Considerations ....................................36
6. Bibliography ...............................................37
7. Editor's Address ...........................................38
8. Acknowledgements ...........................................39
Appendix A. Example messages ..................................41
A.1. Addressing examples ......................................41
A.1.1. A message from one person to another with simple
addressing .............................................41
A.1.2. Different types of mailboxes ...........................42
A.1.3. Group addresses ........................................43
A.2. Reply messages ...........................................43
A.3. Resent messages ..........................................44
A.4. Messages with trace fields ...............................46
A.5. White space, comments, and other oddities ................47
A.6. Obsoleted forms ..........................................47
A.6.1. Obsolete addressing ....................................48
A.6.2. Obsolete dates .........................................48
A.6.3. Obsolete white space and comments ......................48
Appendix B. Differences from earlier standards ................49
Appendix C. Notices ...........................................50
Full Copyright Statement ......................................51
1. Introduction
1.1. Scope
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages. This standard supersedes the one specified in Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages" [], updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs
[STD3].
This standard specifies a syntax only for text messages. In
particular, it makes no provision for the transmission of images,
audio, or other sorts of structured data in electronic mail messages.
There are several extensions published, such as the MIME document
series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
transmission of such data through electronic mail, either by
extending the syntax provided here or by structuring such messages to
conform to this syntax. Those mechanisms are outside of the scope of
this standard.
In the context of electronic mail, messages are viewed as having an
envelope and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. (See [RFC2821] for a
discussion of the envelope.) The contents comprise the object to be
delivered to the recipient. This standard applies only to the format
and some of the semantics of message contents. It contains no
specification of the information in the envelope.
However, some message systems may use information from the contents
to create the envelope. It is intended that this standard facilitate
the acquisition of such information by programs.
This specification is intended as a definition of what message
content format is to be passed between systems. Though some message
systems locally store messages in this format (which eliminates the
need for translation between formats) and others use formats that
differ from the one specified in this standard, local storage is
outside of the scope of this standard.
Note: This standard is not intended to dictate the internal formats
used by sites, the specific message system features that they are
expected to support, or any of the characteristics of user interface
programs that create or read messages. In addition, this standard
does not specify an encoding of the characters for either transport
or storage; that is, it does not specify the number of bits used or
how those bits are specifically transferred over the wire or stored
on disk.
1.2. Notational conventions
1.2.1. Requirements notation
This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in [RFC2119].
1.2.2. Syntactic notation
This standard uses the Augmented Backus-Naur Form (ABNF) notation
specified in [RFC2234] for the formal definitions of the syntax of
messages. Characters will be specified either by a decimal value
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
a case-insensitive literal value enclosed in quotation marks (e.g.,
"A" for either uppercase or lowercase A). See [RFC2234] for the full
description of the notation.
1.3. Structure of this document
This document is divided into several sections.
This section, section 1, is a short introduction to the document.
Section 2 lays out the general description of a message and its
constituent parts. This is an overview to help the reader understand
some of the general principles used in the later portions of this
document. Any examples in this section MUST NOT be taken as
specification of the formal syntax of any part of a message.
Section 3 specifies formal ABNF rules for the structure of each part
of a message (the syntax) and describes the relationship between
those parts and their meaning in the context of a message (the
semantics). That is, it describes the actual rules for the structure
of each part of a message (the syntax) as well as a description of
the parts and instructions on how they ought to be interpreted (the
semantics). This includes analysis of the syntax and semantics of
subparts of messages that have specific structure. The syntax
included in section 3 represents messages as they MUST be created.
There are also notes in section 3 to indicate if any of the options
specified in the syntax SHOULD be used over any of the others.
Both sections 2 and 3 describe messages that are legal to generate
for purposes of this standard.
Section 4 of this document specifies an "obsolete" syntax. There are
references in section 3 to these obsolete syntactic elements. The
rules of the obsolete syntax are elements that have appeared in
earlier revisions of this standard or have previously been widely
used in Internet messages. As such, these elements MUST be
interpreted by parsers of messages in order to be conformant to this
standard. However, since items in this syntax have been determined
to be non-interoperable or to cause significant problems for
recipients of messages, they MUST NOT be generated by creators of
conformant messages.
Section 5 details security considerations to take into account when
implementing this standard.
Section 6 is a bibliography of references in this document.
Section 7 contains the editor's address.
Section 8 contains acknowledgements.
Appendix A lists examples of different sorts of messages. These
examples are not exhaustive of the types of messages that appear on
the Internet, but give a broad overview of certain syntactic forms.
Appendix B lists the differences between this standard and earlier
standards for Internet messages.
Appendix C has copyright and intellectual property notices.
2. Lexical Analysis of Messages
2.1. General Description
At the most basic level, a message is a series of characters. A
message that is conformant with this standard is comprised of
characters with values in the range 1 through 127 and interpreted as
US-ASCII characters [ASCII]. For brevity, this document sometimes
refers to this range of characters as simply "US-ASCII characters".
Note: This standard specifies that messages are made up of characters
in the US-ASCII range of 1 through 127. There are other documents,
specifically the MIME document series [RFC2045, RFC2046, RFC2047,
RFC2048, RFC2049], that extend this standard to allow for values
outside of that range. Discussion of those mechanisms is not within
the scope of this standard.
Messages are divided into lines of characters. A line is a series of
characters that is delimited with the two characters carriage-return
and line-feed; that is, the carriage return (CR) character (ASCII
value 13) followed immediately by the line feed (LF) character (ASCII
value 10). (The carriage-return/line-feed pair is usually written in
this document as "CRLF".)
A message consists of header fields (collectively called "the header
of the message") followed, optionally, by a body. The header is a
sequence of lines of characters with special syntax as defined in
this standard. The body is simply a sequence of characters that
follows the header and is separated from the header by an empty line
(i.e., a line with nothing preceding the CRLF).
2.1.1. Line Length Limits
There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
The 998 character limit is due to limitations in many implementations
which send, receive, or store Internet Message Format messages that
simply cannot handle more than 998 characters on a line. Receiving
implementations would do well to handle an arbitrarily large number
of characters in a line for robustness sake. However, there are so
many implementations which (in compliance with the transport
requirements of [RFC2821]) do not accept messages containing more
than 1000 character including the CR and LF per line, it is important
for implementations not to create such messages.
The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [RFC2821] if they actually cause
information to be lost). Again, even though this limitation is put on
messages, it is encumbant upon implementations which display messages
to handle an arbitrarily large number of characters in a line
(certainly at least up to the 998 character limit) for the sake of
robustness.
2.2. Header Fields
Header fields are lines composed of a field name, followed by a colon
(":"), followed by a field body, and terminated by CRLF. A field
name MUST be composed of printable US-ASCII characters (i.e.,
characters that have values between 33 and 126, inclusive), except
colon. A field body may be composed of any US-ASCII characters,
except for CR and LF. However, a field body may contain CRLF when
used in header "folding" and "unfolding" as described in section
2.2.3. All field bodies MUST conform to the syntax described in
sections 3 and 4 of this standard.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as
"unstructured" (which is specified below as any US-ASCII characters,
except for CR and LF) with no further restrictions. These are
referred to as unstructured field bodies. Semantically, unstructured
field bodies are simply to be treated as a single line of characters
with no further processing (except for header "folding" and
"unfolding" as described in section 2.2.3).
2.2.2. Structured Header Field Bodies
Some field bodies in this standard have specific syntactical
structure more restrictive than the unstructured field bodies
described above. These are referred to as "structured" field bodies.
Structured field bodies are sequences of specific lexical tokens as
described in sections 3 and 4 of this standard. Many of these tokens
are allowed (according to their syntax) to be introduced or end with
comments (as described in section 3.2.3) as well as the space (SP,
ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
(together known as the white space characters, WSP), and those WSP
characters are subject to header "folding" and "unfolding" as
described in section 2.2.3. Semantic analysis of structured field
bodies is given along with their syntax.
2.2.3. Long Header Fields
Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a multiple
line representation; this is called "folding". The general rule is
that wherever this standard allows for folding white space (not
simply WSP characters), a CRLF may be inserted before any WSP. For
example, the header field:
Subject: This is a test
can be represented as:
Subject: This
is a test
Note: Though structured field bodies are defined in such a way that
folding can take place between many of the lexical tokens (and even
within some of the lexical tokens), folding SHOULD be limited to
placing the CRLF at higher-level syntactic breaks. For instance, if
a field body is defined as comma-separated values, it is recommended
that folding occur after the comma separating the structured items in
preference to other places where the field could be folded, even if
it is allowed elsewhere.
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding". Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP. Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.
2.3. Body
The body of a message is simply lines of US-ASCII characters. The
only two limitations on the body are as follows:
- CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
- Lines of characters in the body MUST be limited to 998 characters,
and SHOULD be limited to 78 characters, excluding the CRLF.
Note: As was stated earlier, there are other standards documents,
specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
that extend this standard to allow for different sorts of message
bodies. Again, these mechanisms are beyond the scope of this
document.
3. Syntax
3.1. Introduction
The syntax as given in this section defines the legal syntax of
Internet messages. Messages that are conformant to this standard
MUST conform to the syntax in this section. If there are options in
this section where one option SHOULD be generated, that is indicated
either in the prose or in a comment next to the syntax.
For the defined expressions, a short description of the syntax and
use is given, followed by the syntax in ABNF, followed by a semantic
analysis. Primitive tokens that are used but otherwise unspecified
come from [RFC2234].
In some of the definitions, there will be nonterminals whose names
start with "obs-". These "obs-" elements refer to tokens defined in
the obsolete syntax in section 4. In all cases, these productions
are to be ignored for the purposes of generating legal Internet
messages and MUST NOT be used as part of such a message. However,
when interpreting messages, these tokens MUST be honored as part of
the legal syntax. In this sense, section 3 defines a grammar for
generation of messages, with "obs-" elements that are to be ignored,
while section 4 adds grammar for interpretation of messages.
3.2. Lexical Tokens
The following rules are used to define an underlying lexical
analyzer, which feeds tokens to the higher-level parsers. This
section defines the tokens used in structured header field bodies.
Note: Readers of this standard need to pay special attention to how
these lexical tokens are used in both the lower-level and
higher-level syntax later in the document. Particularly, the white
space tokens and the comment tokens defined in section 3.2.3 get used
in the lower-level tokens defined here, and those lower-level tokens
are in turn used as parts of the higher-level tokens defined later.
Therefore, the white space and comments may be allowed in the
higher-level tokens even though they may not explicitly appear in a
particular definition.
3.2.1. Primitive Tokens
The following are primitive tokens referred to elsewhere in this
standard, but not otherwise defined in [RFC2234]. Some of them will
not appear anywhere else in the syntax, but they are convenient to
refer to in other parts of this document.
Note: The "specials" below are just such an example. Though the
specials token does not appear anywhere else in this standard, it is
useful for implementers who use tools that lexically analyze
messages. Each of the characters in specials can be used to indicate
a tokenization point in lexical analysis.
NO-WS-CTL = %d1-8 / ; US-ASCII control characters
%d11 / ; that do not include the
%d12 / ; carriage return, line feed,
%d14-31 / ; and white space characters
%d127
text = %d1-9 / ; Characters excluding CR and LF
%d11 /
%d12 /
%d14-127 /
obs-text
specials = "(" / ")" / ; Special characters used in
"<" / ">" / ; other parts of the syntax
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
No special semantics are attached to these tokens. They are simply
single characters.
3.2.2. Quoted characters
Some characters are reserved for special interpretation, such as
delimiting lexical tokens. To permit use of these characters as
uninterpreted data, a quoting mechanism is provided.
quoted-pair = ("\" text) / obs-qp
Where any quoted-pair appears, it is to be interpreted as the text
character alone. That is to say, the "\" character that appears as
part of a quoted-pair is semantically "invisible".
Note: The "\" character may appear in a message where it is not part
of a quoted-pair. A "\" character that does not appear in a
quoted-pair is not semantically invisible. The only places in this
standard where quoted-pair currently appears are ccontent, qcontent,
dcontent, no-fold-quote, and no-fold-literal.
3.2.3. Folding white space and comments
White space characters, including white space used in folding
(described in section 2.2.3), may appear between many elements in
header field bodies. Also, strings of characters that are treated as
comments may be included in structured field bodies as characters
enclosed in parentheses. The following defines the folding white
space (FWS) and comment constructs.
Strings of characters enclosed in parentheses are considered comments
so long as they do not appear within a "quoted-string", as defined in
section 3.2.5. Comments may nest.
There are several places in this standard where comments and FWS may
be freely inserted. To accommodate that syntax, an additional token
for "CFWS" is defined for places where comments and/or FWS can occur.
However, where CFWS occurs in this standard, it MUST NOT be inserted
in such a way that any line of a folded header field is made up
entirely of WSP characters and nothing else.
FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
obs-FWS
ctext = NO-WS-CTL / ; Non white space controls
%d33-39 / ; The rest of the US-ASCII
%d42-91 / ; characters not including "(",
%d93-126 ; ")", or "\"
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
Throughout this standard, where FWS (the folding white space token)
appears, it indicates a place where header folding, as discussed in
section 2.2.3, may take place. Wherever header folding appears in a
message (that is, a header field body containing a CRLF followed by
any WSP), header unfolding (removal of the CRLF) is performed before
any further lexical analysis is performed on that header field
according to this standard. That is to say, any CRLF that appears in
FWS is semantically "invisible."
A comment is normally used in a structured field body to provide some
human readable informational text. Since a comment is allowed to
contain FWS, folding is permitted within the comment. Also note that
since quoted-pair is allowed in a comment, the parentheses and
backslash characters may appear in a comment so long as they appear
as a quoted-pair. Semantically, the enclosing parentheses are not
part of the comment; the comment is what is contained between the two
parentheses. As stated earlier, the "\" in any quoted-pair and the
CRLF in any FWS that appears within the comment are semantically
"invisible" and therefore not part of the comment either.
Runs of FWS, comment or CFWS that occur between lexical tokens in a
structured field header are semantically interpreted as a single
space character.
3.2.4. Atom
Several productions in structured header field bodies are simply
strings of certain basic characters. Such productions are called
atoms.
Some of the structured header field bodies also allow the period
character (".", ASCII value 46) within runs of atext. An additional
"dot-atom" token is defined for those purposes.
atext = ALPHA / DIGIT / ; Any character except controls,
"!" / "#" / ; SP, and specials.
"$" / "%" / ; Used for atoms
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Both atom and dot-atom are interpreted as a single unit, comprised of
the string of characters that make it up. Semantically, the optional
comments and FWS surrounding the rest of the characters are not part
of the atom; the atom is only the run of atext characters in an atom,
or the atext and "." characters in a dot-atom.
3.2.5. Quoted strings
Strings of characters that include characters other than those
allowed in atoms may be represented in a quoted string format, where
the characters are surrounded by quote (DQUOTE, ASCII value 34)
characters.
qtext = NO-WS-CTL / ; Non white space controls
%d33 / ; The rest of the US-ASCII
%d35-91 / ; characters not including "\"
%d93-126 ; or the quote character
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
A quoted-string is treated as a unit. That is, quoted-string is
identical to atom, semantically. Since a quoted-string is allowed to
contain FWS, folding is permitted. Also note that since quoted-pair
is allowed in a quoted-string, the quote and backslash characters may
appear in a quoted-string so long as they appear as a quoted-pair.
Semantically, neither the optional CFWS outside of the quote
characters nor the quote characters themselves are part of the
quoted-string; the quoted-string is what is contained between the two
quote characters. As stated earlier, the "\" in any quoted-pair and
the CRLF in any FWS/CFWS that appears within the quoted-string are
semantically "invisible" and therefore not part of the quoted-string
either.
3.2.6. Miscellaneous tokens
Three additional tokens are defined, word and phrase for combinations
of atoms and/or quoted-strings, and unstructured for use in
unstructured header fields and in some places within structured
header fields.
word = atom / quoted-string
phrase = 1*word / obs-phrase
utext = NO-WS-CTL / ; Non white space controls
%d33-126 / ; The rest of US-ASCII
obs-utext
unstructured = *([FWS] utext) [FWS]
3.3. Date and Time Specification
Date and time occur in several header fields. This section specifies
the syntax for a full date and time specification. Though folding
white space is permitted throughout the date-time specification, it
is RECOMMENDED that a single space be used in each place that FWS
appears (whether it is required or optional); some older
implementations may not interpret other occurrences of folding white
space correctly.
date-time = [ day-of-week "," ] date FWS time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
year = 4*DIGIT / obs-year
month = (FWS month-name FWS) / obs-month
month-name = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
day = ([FWS] 1*2DIGIT) / obs-day
time = time-of-day FWS zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (( "+" / "-" ) 4DIGIT) / obs-zone
The day is the numeric day of the month. The year is any numeric
year 1900 or later.
The time-of-day specifies the number of hours, minutes, and
optionally seconds since midnight of the date indicated.
The date and time-of-day SHOULD express local time.
The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent. The "+" or "-" indicates whether the
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
Universal Time. The first two digits indicate the number of hours
difference from Universal Time, and the last two digits indicate the
number of minutes difference from Universal Time. (Hence, +hhmm
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
minutes). The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and therefore
indicates that the date-time contains no information about the local
time zone.
A date-time specification MUST be semantically valid. That is, the
day-of-the-week (if included) MUST be the day implied by the date,
the numeric day-of-month MUST be between 1 and the number of days
allowed for the specified month (in the specified year), the
time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
number of seconds allowing for a leap second; see [STD12]), and the
zone MUST be within the range -9959 through +9959.
3.4. Address Specification
Addresses occur in several message header fields to indicate senders
and recipients of messages. An address may either be an individual
mailbox, or a group of mailboxes.
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
group = display-name ":" [mailbox-list / CFWS] ";"
[CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
A mailbox receives mail. It is a conceptual entity which does not
necessarily pertain to file storage. For example, some sites may
choose to print mail on a printer and deliver the output to the
addressee's desk. Normally, a mailbox is comprised of two parts: (1)
an optional display name that indicates the name of the recipient
(which could be a person or a system) that could be displayed to the
user of a mail application, and (2) an addr-spec address enclosed in
angle brackets ("<" and ">"). There is also an alternate simple form
of a mailbox where the addr-spec address appears alone, without the
recipient's name or the angle brackets. The Internet addr-spec
address is described in section 3.4.1.
Note: Some legacy implementations used the simple form where the
addr-spec appears without the angle brackets, but included the name
of the recipient in parentheses as a comment following the addr-spec.
Since the meaning of the information in a comment is unspecified,
implementations SHOULD use the full name-addr form of the mailbox,
instead of the legacy form, to specify the display name associated
with a mailbox. Also, because some legacy implementations interpret
the comment, comments generally SHOULD NOT be used in address fields
to avoid confusing such implementations.
When it is desirable to treat several mailboxes as a single unit
(i.e., in a distribution list), the group construct can be used. The
group construct allows the sender to indicate a named group of
recipients. This is done by giving a display name for the group,
followed by a colon, followed by a comma separated list of any number
of mailboxes (including zero and one), and ending with a semicolon.
Because the list of mailboxes can be empty, using the group construct
is also a simple way to communicate to recipients that the message
was sent to one or more named sets of recipients, without actually
providing the individual mailbox address for each of those
recipients.
3.4.1. Addr-spec specification
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("@",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the
quoted-string form SHOULD NOT be used. Comments and folding white
space SHOULD NOT be used around the "@" in the addr-spec.
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
dcontent = dtext / quoted-pair
dtext = NO-WS-CTL / ; Non white space controls
%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including "[",
; "]", or "\"
The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as
described in [STD3, STD13, STD14]. In the domain-literal form, the
domain is interpreted as the literal Internet address of the
particular host. In both cases, how addressing is used and how
messages are transported to a particular host is covered in the mail
transport document [RFC2821]. These mechanisms are outside of the
scope of this document.
The local-part portion is a domain dependent string. In addresses,
it is simply interpreted on the particular host as a name of a
particular mailbox.
3.5 Overall message syntax
A message consists of header fields, optionally followed by a message
body. Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF. (See section 2.1.1 for explanation.)
In a message body, though all of the characters listed in the text
rule MAY be used, the use of US-ASCII control characters (values 1
through 8, 11, 12, and 14 through 31) is discouraged since their
interpretation by receivers for display is not guaranteed.
message = (fields / obs-fields)
[CRLF body]
body = *(*998text CRLF) *998text
The header fields carry most of the semantic information and are
defined in section 3.6. The body is simply a series of lines of text
which are uninterpreted for the purposes of this standard.
3.6. Field definitions
The header fields of a message are defined here. All header fields
have the same general syntactic structure: A field name, followed by
a colon, followed by the field body. The specific syntax for each
header field is defined in the subsequent sections.
Note: In the ABNF syntax for each field in subsequent sections, each
field name is followed by the required colon. However, for brevity
sometimes the colon is not referred to in the textual description of
the syntax. It is, nonetheless, required.
It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet. However, for the purposes of this standard, header
fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message. See sections 3.6.6 and 3.6.7 for more
information.
The only required header fields are the origination date field and
the originator address field(s). All other header fields are
syntactically optional. More information is contained in the table
following this definition.
fields = *(trace
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
The following table indicates limits on the number of times each
field may occur in a message header as well as any special
limitations on the use of those fields. An asterisk next to a value
in the minimum or maximum column indicates that a special restriction
appears in the Notes column.
Field Min number Max number Notes
trace 0 unlimited Block prepended - see
3.6.7
resent-date 0* unlimited* One per block, required
if other resent fields
present - see 3.6.6
resent-from 0 unlimited* One per block - see
3.6.6
resent-sender 0* unlimited* One per block, MUST
occur with multi-address
resent-from - see 3.6.6
resent-to 0 unlimited* One per block - see
3.6.6
resent-cc 0 unlimited* One per block - see
3.6.6
resent-bcc 0 unlimited* One per block - see
3.6.6
resent-msg-id 0 unlimited* One per block - see
3.6.6
orig-date 1 1
from 1 1 See sender and 3.6.2
sender 0* 1 MUST occur with multi-
address from - see 3.6.2
reply-to 0 1
to 0 1
cc 0 1
bcc 0 1
message-id 0* 1 SHOULD be present - see
3.6.4
in-reply-to 0* 1 SHOULD occur in some
replies - see 3.6.4
references 0* 1 SHOULD occur in some
replies - see 3.6.4
subject 0 1
comments 0 unlimited
keywords 0 unlimited
optional-field 0 unlimited
The exact interpretation of each field is described in subsequent
sections.
3.6.1. The origination date field
The origination date field consists of the field name "Date" followed
by a date-time specification.
orig-date = "Date:" date-time CRLF
The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time
that a user pushes the "send" or "submit" button in an application
program. In any case, it is specifically not intended to convey the
time that the message is actually transported, but rather the time at
which the human or other creator of the message has put the message
into its final form, ready for transport. (For example, a portable
computer user who is not connected to a network might queue a message
for delivery. The origination date is intended to contain the date
and time that the user queued the message, not the time when the user
connected to the network to send the message.)
3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the mailbox(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. See also section
3.6.3 for more information on forming the destination addresses for a
reply.
3.6.3. Destination address fields
The destination fields of a message consist of three possible fields,
each of the same form: The field name, which is either "To", "Cc", or
"Bcc", followed by a comma-separated list of one or more addresses
(either mailbox or group syntax).
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" (address-list / [CFWS]) CRLF
The destination fields specify the recipients of the message. Each
destination field may have one or more addresses, and each of the
addresses indicate the intended recipients of the message. The only
difference between the three fields is how each is used.
The "To:" field contains the address(es) of the primary recipient(s)
of the message.
The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
making a copy on a typewriter using carbon paper) contains the
addresses of others who are to receive the message, though the
content of the message may not be directed at them.
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.
When a message is a reply to another message, the mailboxes of the
authors of the original message (the mailboxes in the "From:" field)
or mailboxes specified in the "Reply-To:" field (if it exists) MAY
appear in the "To:" field of the reply since these would normally be
the primary recipients of the reply. If a reply is sent to a message
that has destination fields, it is often desirable to send a copy of
the reply to all of the recipients of the message, in addition to the
author. When such a reply is formed, addresses in the "To:" and
"Cc:" fields of the original message MAY appear in the "Cc:" field of
the reply, since these are normally secondary recipients of the
reply. If a "Bcc:" field is present in the original message,
addresses in that field MAY appear in the "Bcc:" field of the reply,
but SHOULD NOT appear in the "To:" or "Cc:" fields.
Note: Some mail applications have automatic reply commands that
include the destination addresses of the original message in the
destination addresses of the reply. How those reply commands behave
is implementation dependent and is beyond the scope of this document.
In particular, whether or not to include the original destination
addresses when the original message had a "Reply-To:" field is not
addressed here.
3.6.4. Identification fields
Though optional, every message SHOULD have a "Message-ID:" field.
Furthermore, reply messages SHOULD have "In-Reply-To:" and
"References:" fields as appropriate, as described below.
The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" field each contain one or more
unique message identifiers, optionally separated by CFWS.
The message identifier (msg-id) is similar in syntax to an angle-addr
construct without the internal CFWS.
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left = dot-atom-text / no-fold-quote / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE
no-fold-literal = "[" *(dtext / quoted-pair) "]"
The "Message-ID:" field provides a unique message identifier that
refers to a particular version of a particular message. The
uniqueness of the message identifier is guaranteed by the host that
generates it (see below). This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A message
identifier pertains to exactly one instantiation of a particular
message; subsequent revisions to the message each receive new message
identifiers.
Note: There are many instances when messages are "changed", but those
changes do not constitute a new instantiation of that message, and
therefore the message would not get a new message identifier. For
example, when messages are introduced into the transport system, they
are often prepended with additional header fields such as trace
fields (described in section 3.6.7) and resent fields (described in
section 3.6.6). The addition of such header fields does not change
the identity of the message and therefore the original "Message-ID:"
field is retained. In all cases, it is the meaning that the sender
of the message wishes to convey (i.e., whether this is the same
message or a different message) that determines whether or not the
"Message-ID:" field changes, not any particular syntactic difference
that appears (or does not appear) in the message.
The "In-Reply-To:" and "References:" fields are used when creating a
reply to a message. They hold the message identifier of the original
message and the message identifiers of other messages (for example,
in the case of a reply to a message which was itself a reply). The
"In-Reply-To:" field may be used to identify the message (or
messages) to which the new message is a reply, while the
"References:" field may be used to identify a "thread" of
conversation.
When creating a reply to a message, the "In-Reply-To:" and
"References:" fields of the resultant message are constructed as
follows:
The "In-Reply-To:" field will contain the contents of the "Message-
ID:" field of the message to which this one is a reply (the "parent
message"). If there is more than one parent message, then the "In-
Reply-To:" field will contain the contents of all of the parents'
"Message-ID:" fields. If there is no "Message-ID:" field in any of
the parent messages, then the new message will have no "In-Reply-To:"
field.
The "References:" field will contain the contents of the parent's
"References:" field (if any) followed by the contents of the parent's
"Message-ID:" field (if any). If the parent message does not contain
a "References:" field but does have an "In-Reply-To:" field
containing a single message identifier, then the "References:" field
will contain the contents of the parent's "In-Reply-To:" field
followed by the contents of the parent's "Message-ID:" field (if
any). If the parent has none of the "References:", "In-Reply-To:",
or "Message-ID:" fields, then the new message will have no
"References:" field.
Note: Some implementations parse the "References:" field to display
the "thread of the discussion". These implementations assume that
each new message is a reply to a single parent and hence that they
can walk backwards through the "References:" field to find the parent
of each message listed there. Therefore, trying to form a
"References:" field for a reply that has multiple parents is
discouraged and how to do so is not defined in this document.
The message identifier (msg-id) itself MUST be a globally unique
identifier for a message. The generator of the message identifier
MUST guarantee that the msg-id is unique. There are several
algorithms that can be used to accomplish this. Since the msg-id has
a similar syntax to angle-addr (identical except that comments and
folding white space are not allowed), a good method is to put the
domain name (or a domain literal IP address) of the host on which the
message identifier was created on the right hand side of the "@", and
put a combination of the current absolute date and time along with
some other currently unique (perhaps sequential) identifier available
on the system (for example, a process id number) on the left hand
side. Using a date on the left hand side and a domain name or domain
literal on the right hand side makes it possible to guarantee
uniqueness since no two hosts use the same domain name or IP address
at the same time. Though other algorithms will work, it is
RECOMMENDED that the right hand side contain some domain identifier
(either of the host itself or otherwise) such that the generator of
the message identifier can guarantee the uniqueness of the left hand
side within the scope of that domain.
Semantically, the angle bracket characters are not part of the
msg-id; the msg-id is what is contained between the two angle bracket
characters.
3.6.5. Informational fields
The informational fields are all optional. The "Keywords:" field
contains a comma-separated list of one or more words or
quoted-strings. The "Subject:" and "Comments:" fields are
unstructured fields as defined in section 2.2.1, and therefore may
contain text or folding w
Network Working Group M. Crispin
Request for Comments: 3501 University of Washington
Obsoletes: 2060 March 2003
Category: Standards Track
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev1 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders. IMAP4rev1 also provides the capability for an offline
client to resynchronize with the server.
IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes, checking for new messages, permanently removing messages,
setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
and selective fetching of message attributes, texts, and portions
thereof. Messages in IMAP4rev1 are accessed by the use of numbers.
These numbers are either message sequence numbers or unique
identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in RFC 2244.
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as RFC 2821.
Crispin Standards Track [Page 1]
RFC 3501 IMAPv4 March 2003
Table of Contents
IMAP4rev1 Protocol Specification ................................ 4
1. How to Read This Document ............................... 4
1.1. Organization of This Document ........................... 4
1.2. Conventions Used in This Document ....................... 4
1.3. Special Notes to Implementors ........................... 5
2. Protocol Overview ....................................... 6
2.1. Link Level .............................................. 6
2.2. Commands and Responses .................................. 6
2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
2.3. Message Attributes ...................................... 8
2.3.1. Message Numbers ......................................... 8
2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
2.3.1.2. Message Sequence Number Message Attribute ....... 10
2.3.2. Flags Message Attribute ................................. 11
2.3.3. Internal Date Message Attribute ......................... 12
2.3.4. [RFC-2822] Size Message Attribute ....................... 12
2.3.5. Envelope Structure Message Attribute .................... 12
2.3.6. Body Structure Message Attribute ........................ 12
2.4. Message Texts ........................................... 13
3. State and Flow Diagram .................................. 13
3.1. Not Authenticated State ................................. 13
3.2. Authenticated State ..................................... 13
3.3. Selected State .......................................... 13
3.4. Logout State ............................................ 14
4. Data Formats ............................................ 16
4.1. Atom .................................................... 16
4.2. Number .................................................. 16
4.3. String .................................................. 16
4.3.1. 8-bit and Binary Strings ................................ 17
4.4. Parenthesized List ...................................... 17
4.5. NIL ..................................................... 17
5. Operational Considerations .............................. 18
5.1. Mailbox Naming .......................................... 18
5.1.1. Mailbox Hierarchy Naming ................................ 19
5.1.2. Mailbox Namespace Naming Convention ..................... 19
5.1.3. Mailbox International Naming Convention ................. 19
5.2. Mailbox Size and Message Status Updates ................. 21
5.3. Response when no Command in Progress .................... 21
5.4. Autologout Timer ........................................ 22
5.5. Multiple Commands in Progress ........................... 22
6. Client Commands ........................................ 23
6.1. Client Commands - Any State ............................ 24
6.1.1. CAPABILITY Command ..................................... 24
6.1.2. NOOP Command ........................................... 25
6.1.3. LOGOUT Command ......................................... 26
Crispin Standards Track [Page 2]
RFC 3501 IMAPv4 March 2003
6.2. Client Commands - Not Authenticated State .............. 26
6.2.1. STARTTLS Command ....................................... 27
6.2.2. AUTHENTICATE Command ................................... 28
6.2.3. LOGIN Command .......................................... 30
6.3. Client Commands - Authenticated State .................. 31
6.3.1. SELECT Command ......................................... 32
6.3.2. EXAMINE Command ........................................ 34
6.3.3. CREATE Command ......................................... 34
6.3.4. DELETE Command ......................................... 35
6.3.5. RENAME Command ......................................... 37
6.3.6. SUBSCRIBE Command ...................................... 39
6.3.7. UNSUBSCRIBE Command .................................... 39
6.3.8. LIST Command ........................................... 40
6.3.9. LSUB Command ........................................... 43
6.3.10. STATUS Command ......................................... 44
6.3.11. APPEND Command ......................................... 46
6.4. Client Commands - Selected State ....................... 47
6.4.1. CHECK Command .......................................... 47
6.4.2. CLOSE Command .......................................... 48
6.4.3. EXPUNGE Command ........................................ 49
6.4.4. SEARCH Command ......................................... 49
6.4.5. FETCH Command .......................................... 54
6.4.6. STORE Command .......................................... 58
6.4.7. COPY Command ........................................... 59
6.4.8. UID Command ............................................ 60
6.5. Client Commands - Experimental/Expansion ............... 62
6.5.1. X<atom> Command ........................................ 62
7. Server Responses ....................................... 62
7.1. Server Responses - Status Responses .................... 63
7.1.1. OK Response ............................................ 65
7.1.2. NO Response ............................................ 66
7.1.3. BAD Response ........................................... 66
7.1.4. PREAUTH Response ....................................... 67
7.1.5. BYE Response ........................................... 67
7.2. Server Responses - Server and Mailbox Status ........... 68
7.2.1. CAPABILITY Response .................................... 68
7.2.2. LIST Response .......................................... 69
7.2.3. LSUB Response .......................................... 70
7.2.4 STATUS Response ........................................ 70
7.2.5. SEARCH Response ........................................ 71
7.2.6. FLAGS Response ......................................... 71
7.3. Server Responses - Mailbox Size ........................ 71
7.3.1. EXISTS Response ........................................ 71
7.3.2. RECENT Response ........................................ 72
7.4. Server Responses - Message Status ...................... 72
7.4.1. EXPUNGE Response ....................................... 72
7.4.2. FETCH Response ......................................... 73
7.5. Server Responses - Command Continuation Request ........ 79
Crispin Standards Track [Page 3]
RFC 3501 IMAPv4 March 2003
8. Sample IMAP4rev1 connection ............................ 80
9. Formal Syntax .......................................... 81
10. Author's Note .......................................... 92
11. Security Considerations ................................ 92
11.1. STARTTLS Security Considerations ....................... 92
11.2. Other Security Considerations .......................... 93
12. IANA Considerations .................................... 94
Appendices ..................................................... 95
A. References ............................................. 95
B. Changes from RFC 2060 .................................. 97
C. Key Word Index ......................................... 103
Author's Address ............................................... 107
Full Copyright Statement ....................................... 108
IMAP4rev1 Protocol Specification
1. How to Read This Document
1.1. Organization of This Document
This document is written from the point of view of the implementor of
an IMAP4rev1 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev1
operates.
Sections 6, 7, and 9 describe the IMAP commands, responses, and
syntax, respectively. The relationships among these are such that it
is almost impossible to understand any of them separately. In
particular, do not attempt to deduce command syntax from the command
section alone; instead refer to the Formal Syntax section.
1.2. Conventions Used in This Document
"Conventions" are basic principles or procedures. Document
conventions are noted in this section.
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [KEYWORDS].
The word "can" (not "may") is used to refer to a possible
circumstance or situation, as opposed to an optional facility of the
protocol.
Crispin Standards Track [Page 4]
RFC 3501 IMAPv4 March 2003
"User" is used to refer to a human user, whereas "client" refers to
the software being run by the user.
"Connection" refers to the entire sequence of client/server
interaction from the initial establishment of the network connection
until its termination.
"Session" refers to the sequence of client/server interaction from
the time that a mailbox is selected (SELECT or EXAMINE command) until
the time that selection ends (SELECT or EXAMINE of another mailbox,
CLOSE command, or connection termination).
Characters are 7-bit US-ASCII unless otherwise specified. Other
character sets are indicated using a "CHARSET", as described in
[MIME-IMT] and defined in [CHARSET]. CHARSETs have important
additional semantics in addition to defining character set; refer to
these documents for more detail.
There are several protocol conventions in IMAP. These refer to
aspects of the specification which are not strictly part of the IMAP
protocol, but reflect generally-accepted practice. Implementations
need to be aware of these conventions, and avoid conflicts whether or
not they implement the convention. For example, "&" may not be used
as a hierarchy delimiter since it conflicts with the Mailbox
International Naming Convention, and other uses of "&" in mailbox
names are impacted as well.
1.3. Special Notes to Implementors
Implementors of the IMAP protocol are strongly encouraged to read the
IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
conjunction with this document, to help understand the intricacies of
this protocol and how best to build an interoperable product.
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with
the IMAP4 protocol described in RFC 1730; the exception being in
certain facilities added in RFC 1730 that proved problematic and were
subsequently removed. In the course of the evolution of IMAP4rev1,
some aspects in the earlier protocols have become obsolete. Obsolete
commands, responses, and data formats which an IMAP4rev1
implementation can encounter when used with an earlier implementation
are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct)
Crispin Standards Track [Page 5]
RFC 3501 IMAPv4 March 2003
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest.
IMAP was originally developed for the older [RFC-822] standard, and
as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. With the exception of RFC822.SIZE, there are more modern
replacements; for example, the modern version of RFC822.HEADER is
BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a
reference to the updated [RFC-2822] standard.
2. Protocol Overview
2.1. Link Level
The IMAP4rev1 protocol assumes a reliable data stream such as that
provided by TCP. When TCP is used, an IMAP4rev1 server listens on
port 143.
2.2. Commands and Responses
An IMAP4rev1 connection consists of the establishment of a
client/server network connection, an initial greeting from the
server, and client/server interactions. These client/server
interactions consist of a client command, server data, and a server
completion result response.
All interactions transmitted by client and server are in the form of
lines, that is, strings that end with a CRLF. The protocol receiver
of an IMAP4rev1 client or server is either reading a line, or is
reading a sequence of octets with a known count followed by a line.
2.2.1. Client Protocol Sender and Server Protocol Receiver
The client command begins an operation. Each client command is
prefixed with an identifier (typically a short alphanumeric string,
e.g., A0001, A0002, etc.) called a "tag". A different tag is
generated by the client for each command.
Clients MUST follow the syntax outlined in this specification
strictly. It is a syntax error to send a command with missing or
extraneous spaces or arguments.
There are two cases in which a line from the client does not
represent a complete command. In one case, a command argument is
quoted with an octet count (see the description of literal in String
under Data Formats); in the other case, the command arguments require
server feedback (see the AUTHENTICATE command). In either case, the
Crispin Standards Track [Page 6]
RFC 3501 IMAPv4 March 2003
server sends a command continuation request response if it is ready
for the octets (if appropriate) and the remainder of the command.
This response is prefixed with the token "+".
Note: If instead, the server detected an error in the
command, it sends a BAD completion response with a tag
matching the command (as described below) to reject the
command and prevent the client from sending any more of the
command.
It is also possible for the server to send a completion
response for some other command (if multiple commands are
in progress), or untagged data. In either case, the
command continuation request is still pending; the client
takes the appropriate action for the response, and reads
another response from the server. In all cases, the client
MUST send a complete command (including receiving all
command continuation request responses and command
continuations for the command) before initiating a new
command.
The protocol receiver of an IMAP4rev1 server reads a command line
from the client, parses the command and its arguments, and transmits
server data and a server command completion result response.
2.2.2. Server Protocol Sender and Client Protocol Receiver
Data transmitted by the server to the client and status responses
that do not indicate command completion are prefixed with the token
"*", and are called untagged responses.
Server data MAY be sent as a result of a client command, or MAY be
sent unilaterally by the server. There is no syntactic difference
between server data that resulted from a specific command and server
data that were sent unilaterally.
The server completion result response indicates the success or
failure of the operation. It is tagged with the same tag as the
client command which began the operation. Thus, if more than one
command is in progress, the tag in a server completion response
identifies the command to which the response applies. There are
three possible server completion responses: OK (indicating success),
NO (indicating failure), or BAD (indicating a protocol error such as
unrecognized command or command syntax error).
Servers SHOULD enforce the syntax outlined in this specification
strictly. Any client command with a protocol syntax error, including
(but not limited to) missing or extraneous spaces or arguments,
Crispin Standards Track [Page 7]
RFC 3501 IMAPv4 March 2003
SHOULD be rejected, and the client given a BAD server completion
response.
The protocol receiver of an IMAP4rev1 client reads a response line
from the server. It then takes action on the response based upon the
first token of the response, which can be a tag, a "*", or a "+".
A client MUST be prepared to accept any server response at all times.
This includes server data that was not requested. Server data SHOULD
be recorded, so that the client can reference its recorded copy
rather than sending a command to the server to request the data. In
the case of certain server data, the data MUST be recorded.
This topic is discussed in greater detail in the Server Responses
section.
2.3. Message Attributes
In addition to message text, each message has several attributes
associated with it. These attributes can be retrieved individually
or in conjunction with other attributes or message texts.
2.3.1. Message Numbers
Messages in IMAP4rev1 are accessed by one of two numbers; the unique
identifier or the message sequence number.
2.3.1.1. Unique Identifier (UID) Message Attribute
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. Unique identifiers
are assigned in a strictly ascending fashion in the mailbox; as each
message is added to the mailbox it is assigned a higher UID than the
message(s) which were added previously. Unlike message sequence
numbers, unique identifiers are not necessarily contiguous.
The unique identifier of a message MUST NOT change during the
session, and SHOULD NOT change between sessions. Any change of
unique identifiers between sessions MUST be detectable using the
UIDVALIDITY mechanism discussed below. Persistent unique identifiers
are required for a client to resynchronize its state from a previous
session with the server (e.g., disconnected or offline access
clients); this is discussed further in [IMAP-DISC].
Crispin Standards Track [Page 8]
RFC 3501 IMAPv4 March 2003
Associated with every mailbox are two values which aid in unique
identifier handling: the next unique identifier value and the unique
identifier validity value.
The next unique identifier value is the predicted value that will be
assigned to a new message in the mailbox. Unless the unique
identifier validity also changes (see below), the next unique
identifier value MUST have the following two characteristics. First,
the next unique identifier value MUST NOT change unless new messages
are added to the mailbox; and second, the next unique identifier
value MUST change whenever new messages are added to the mailbox,
even if those new messages are subsequently expunged.
Note: The next unique identifier value is intended to
provide a means for a client to determine whether any
messages have been delivered to the mailbox since the
previous time it checked this value. It is not intended to
provide any guarantee that any message will have this
unique identifier. A client can only assume, at the time
that it obtains the next unique identifier value, that
messages arriving after that time will have a UID greater
than or equal to that value.
The unique identifier validity value is sent in a UIDVALIDITY
response code in an OK untagged response at mailbox selection time.
If unique identifiers from an earlier session fail to persist in this
session, the unique identifier validity value MUST be greater than
the one used in the earlier session.
Note: Ideally, unique identifiers SHOULD persist at all
times. Although this specification recognizes that failure
to persist can be unavoidable in certain server
environments, it STRONGLY ENCOURAGES message store
implementation techniques that avoid this problem. For
example:
1) Unique identifiers MUST be strictly ascending in the
mailbox at all times. If the physical message store is
re-ordered by a non-IMAP agent, this requires that the
unique identifiers in the mailbox be regenerated, since
the former unique identifiers are no longer strictly
ascending as a result of the re-ordering.
2) If the message store has no mechanism to store unique
identifiers, it must regenerate unique identifiers at
each session, and each session must have a unique
UIDVALIDITY value.
Crispin Standards Track [Page 9]
RFC 3501 IMAPv4 March 2003
3) If the mailbox is deleted and a new mailbox with the
same name is created at a later date, the server must
either keep track of unique identifiers from the
previous instance of the mailbox, or it must assign a
new UIDVALIDITY value to the new instance of the
mailbox. A good UIDVALIDITY value to use in this case
is a 32-bit representation of the creation date/time of
the mailbox. It is alright to use a constant such as
1, but only if it guaranteed that unique identifiers
will never be reused, even in the case of a mailbox
being deleted (or renamed) and a new mailbox by the
same name created at some future time.
4) The combination of mailbox name, UIDVALIDITY, and UID
must refer to a single immutable message on that server
forever. In particular, the internal date, [RFC-2822]
size, envelope, body structure, and message texts
(RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
fetch data items) must never change. This does not
include message numbers, nor does it include attributes
that can be set by a STORE command (e.g., FLAGS).
2.3.1.2. Message Sequence Number Message Attribute
A relative position from 1 to the number of messages in the mailbox.
This position MUST be ordered by ascending unique identifier. As
each new message is added, it is assigned a message sequence number
that is 1 higher than the number of messages in the mailbox before
that new message was added.
Message sequence numbers can be reassigned during the session. For
example, when a message is permanently removed (expunged) from the
mailbox, the message sequence number for all subsequent messages is
decremented. The number of messages in the mailbox is also
decremented. Similarly, a new message can be assigned a message
sequence number that was once held by some other message prior to an
expunge.
In addition to accessing messages by relative position in the
mailbox, message sequence numbers can be used in mathematical
calculations. For example, if an untagged "11 EXISTS" is received,
and previously an untagged "8 EXISTS" was received, three new
messages have arrived with message sequence numbers of 9, 10, and 11.
Another example, if message 287 in a 523 message mailbox has UID
12345, there are exactly 286 messages which have lesser UIDs and 236
messages which have greater UIDs.
Crispin Standards Track [Page 10]
RFC 3501 IMAPv4 March 2003
2.3.2. Flags Message Attribute
A list of zero or more named tokens associated with the message. A
flag is set by its addition to this list, and is cleared by its
removal. There are two types of flags in IMAP4rev1. A flag of
either type can be permanent or session-only.
A system flag is a flag name that is pre-defined in this
specification. All system flags begin with "\". Certain system
flags (\Deleted and \Seen) have special semantics described
elsewhere. The currently-defined system flags are:
\Seen
Message has been read
\Answered
Message has been answered
\Flagged
Message is "flagged" for urgent/special attention
\Deleted
Message is "deleted" for removal by later EXPUNGE
\Draft
Message has not completed composition (marked as a draft).
\Recent
Message is "recently" arrived in this mailbox. This session
is the first session to have been notified about this
message; if the session is read-write, subsequent sessions
will not see \Recent set for this message. This flag can not
be altered by the client.
If it is not possible to determine whether or not this
session is the first session to be notified about a message,
then that message SHOULD be considered recent.
If multiple connections have the same mailbox selected
simultaneously, it is undefined which of these connections
will see newly-arrived messages with \Recent set and which
will see it without \Recent set.
A keyword is defined by the server implementation. Keywords do not
begin with "\". Servers MAY permit the client to define new keywords
in the mailbox (see the description of the PERMANENTFLAGS response
code for more information).
Crispin Standards Track [Page 11]
RFC 3501 IMAPv4 March 2003
A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which the client can add or remove from the
message flags permanently; that is, concurrent and subsequent
sessions will see any change in permanent flags. Changes to session
flags are valid only in that session.
Note: The \Recent system flag is a special case of a
session flag. \Recent can not be used as an argument in a
STORE or APPEND command, and thus can not be changed at
all.
2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This
is not the date and time in the [RFC-2822] header, but rather a
date and time which reflects when the message was received. In
the case of messages delivered via [SMTP], this SHOULD be the
date and time of final delivery of the message as defined by
[SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
command, this SHOULD be the internal date and time of the source
message. In the case of messages delivered by the IMAP4rev1
APPEND command, this SHOULD be the date and time as specified in
the APPEND command description. All other cases are
implementation defined.
2.3.4. [RFC-2822] Size Message Attribute
The number of octets in the message, as expressed in [RFC-2822]
format.
2.3.5. Envelope Structure Message Attribute
A parsed representation of the [RFC-2822] header of the message.
Note that the IMAP Envelope structure is not the same as an
[SMTP] envelope.
2.3.6. Body Structure Message Attribute
A parsed representation of the [MIME-IMB] body structure
information of the message.
Crispin Standards Track [Page 12]
RFC 3501 IMAPv4 March 2003
2.4. Message Texts
In addition to being able to fetch the full [RFC-2822] text of a
message, IMAP4rev1 permits the fetching of portions of the full
message text. Specifically, it is possible to fetch the
[RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
body part, or a [MIME-IMB] header.
3. State and Flow Diagram
Once the connection between client and server is established, an
IMAP4rev1 connection is in one of four states. The initial
state is identified in the server greeting. Most commands are
only valid in certain states. It is a protocol error for the
client to attempt a command while the connection is in an
inappropriate state, and the server will respond with a BAD or
NO (depending upon server implementation) command completion
result.
3.1. Not Authenticated State
In the not authenticated state, the client MUST supply
authentication credentials before most commands will be
permitted. This state is entered when a connection starts
unless the connection has been pre-authenticated.
3.2. Authenticated State
In the authenticated state, the client is authenticated and MUST
select a mailbox to access before commands that affect messages
will be permitted. This state is entered when a
pre-authenticated connection starts, when acceptable
authentication credentials have been provided, after an error in
selecting a mailbox, or after a successful CLOSE command.
3.3. Selected State
In a selected state, a mailbox has been selected to access.
This state is entered when a mailbox has been successfully
selected.
Crispin Standards Track [Page 13]
RFC 3501 IMAPv4 March 2003
3.4. Logout State
In the logout state, the connection is being terminated. This
state can be entered as a result of a client request (via the
LOGOUT command) or by unilateral action on the part of either
the client or server.
If the client requests the logout state, the server MUST send an
untagged BYE response and a tagged OK response to the LOGOUT
command before the server closes the connection; and the client
MUST read the tagged OK response to the LOGOUT command before
the client closes the connection.
A server MUST NOT unilaterally close the connection without
sending an untagged BYE response that contains the reason for
having done so. A client SHOULD NOT unilaterally close the
connection, and instead SHOULD issue a LOGOUT command. If the
server detects that the client has unilaterally closed the
connection, the server MAY omit the untagged BYE response and
simply close its connection.
Crispin Standards Track [Page 14]
RFC 3501 IMAPv4 March 2003
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
(1) connection without pre-authentication (OK greeting)
(2) pre-authenticated connection (PREAUTH greeting)
(3) rejected connection (BYE greeting)
(4) successful LOGIN or AUTHENTICATE command
(5) successful SELECT or EXAMINE command
(6) CLOSE command, or failed SELECT or EXAMINE command
(7) LOGOUT command, server shutdown, or connection closed
Crispin Standards Track [Page 15]
RFC 3501 IMAPv4 March 2003
4. Data Formats
IMAP4rev1 uses textual commands and responses. Data in
IMAP4rev1 can be in one of several forms: atom, number, string,
parenthesized list, or NIL. Note that a particular data item
may take more than one form; for example, a data item defined as
using "astring" syntax may be either an atom or a string.
4.1. Atom
An atom consists of one or more non-special characters.
4.2. Number
A number consists of one or more digit characters, and
represents a numeric value.
4.3. String
A string is in one of two forms: either literal or quoted
string. The literal form is the general form of string. The
quoted string form is an alternative that avoids the overhead of
processing a literal at the cost of limitations of characters
which may be used.
A literal is a sequence of zero or more octets (including CR and
LF), prefix-quoted with an octet count in the form of an open
brace ("{"), the number of octets, close brace ("}"), and CRLF.
In the case of literals transmi
Network Working Group J. Myers
Request for Comments: 1939 Carnegie Mellon
STD: 53 M. Rose
Obsoletes: 1725 Dover Beach Consulting, Inc.
Category: Standards Track May 1996
Post Office Protocol - Version 3
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Table of Contents
1. Introduction ................................................ 2
2. A Short Digression .......................................... 2
3. Basic Operation ............................................. 3
4. The AUTHORIZATION State ..................................... 4
QUIT Command ................................................ 5
5. The TRANSACTION State ....................................... 5
STAT Command ................................................ 6
LIST Command ................................................ 6
RETR Command ................................................ 8
DELE Command ................................................ 8
NOOP Command ................................................ 9
RSET Command ................................................ 9
6. The UPDATE State ............................................ 10
QUIT Command ................................................ 10
7. Optional POP3 Commands ...................................... 11
TOP Command ................................................. 11
UIDL Command ................................................ 12
USER Command ................................................ 13
PASS Command ................................................ 14
APOP Command ................................................ 15
8. Scaling and Operational Considerations ...................... 16
9. POP3 Command Summary ........................................ 18
10. Example POP3 Session ....................................... 19
11. Message Format ............................................. 19
12. References ................................................. 20
13. Security Considerations .................................... 20
14. Acknowledgements ........................................... 20
15. Authors' Addresses ......................................... 21
Appendix A. Differences from RFC 1725 .......................... 22
Myers & Rose Standards Track [Page 1]
RFC 1939 POP3 May 1996
Appendix B. Command Index ...................................... 23
1. Introduction
On certain types of smaller nodes in the Internet it is often
impractical to maintain a message transport system (MTS). For
example, a workstation may not have sufficient resources (cycles,
disk space) in order to permit a SMTP server [RFC821] and associated
local mail delivery system to be kept resident and continuously
running. Similarly, it may be expensive (or impossible) to keep a
personal computer interconnected to an IP-style network for long
amounts of time (the node is lacking the resource known as
"connectivity").
Despite this, it is often very useful to be able to manage mail on
these smaller nodes, and they often support a user agent (UA) to aid
the tasks of mail handling. To solve this problem, a node which can
support an MTS entity offers a maildrop service to these less endowed
nodes. The Post Office Protocol - Version 3 (POP3) is intended to
permit a workstation to dynamically access a maildrop on a server
host in a useful fashion. Usually, this means that the POP3 protocol
is used to allow a workstation to retrieve mail that the server is
holding for it.
POP3 is not intended to provide extensive manipulation operations of
mail on the server; normally, mail is downloaded and then deleted. A
more advanced (and complex) protocol, IMAP4, is discussed in
[RFC1730].
For the remainder of this memo, the term "client host" refers to a
host making use of the POP3 service, while the term "server host"
refers to a host which offers the POP3 service.
2. A Short Digression
This memo does not specify how a client host enters mail into the
transport system, although a method consistent with the philosophy of
this memo is presented here:
When the user agent on a client host wishes to enter a message
into the transport system, it establishes an SMTP connection to
its relay host and sends all mail to it. This relay host could
be, but need not be, the POP3 server host for the client host. Of
course, the relay host must accept mail for delivery to arbitrary
recipient addresses, that functionality is not required of all
SMTP servers.
Myers & Rose Standards Track [Page 2]
RFC 1939 POP3 May 1996
3. Basic Operation
Initially, the server host starts the POP3 service by listening on
TCP port 110. When a client host wishes to make use of the service,
it establishes a TCP connection with the server host. When the
connection is established, the POP3 server sends a greeting. The
client and POP3 server then exchange commands and responses
(respectively) until the connection is closed or aborted.
Commands in the POP3 consist of a case-insensitive keyword, possibly
followed by one or more arguments. All commands are terminated by a
CRLF pair. Keywords and arguments consist of printable ASCII
characters. Keywords and arguments are each separated by a single
SPACE character. Keywords are three or four characters long. Each
argument may be up to 40 characters long.
Responses in the POP3 consist of a status indicator and a keyword
possibly followed by additional information. All responses are
terminated by a CRLF pair. Responses may be up to 512 characters
long, including the terminating CRLF. There are currently two status
indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
send the "+OK" and "-ERR" in upper case.
Responses to certain commands are multi-line. In these cases, which
are clearly indicated below, after sending the first line of the
response and a CRLF, any additional lines are sent, each terminated
by a CRLF pair. When all lines of the response have been sent, a
final line is sent, consisting of a termination octet (decimal code
046, ".") and a CRLF pair. If any line of the multi-line response
begins with the termination octet, the line is "byte-stuffed" by
pre-pending the termination octet to that line of the response.
Hence a multi-line response is terminated with the five octets
"CRLF.CRLF". When examining a multi-line response, the client checks
to see if the line begins with the termination octet. If so and if
octets other than CRLF follow, the first octet of the line (the
termination octet) is stripped away. If so and if CRLF immediately
follows the termination character, then the response from the POP
server is ended and the line containing ".CRLF" is not considered
part of the multi-line response.
A POP3 session progresses through a number of states during its
lifetime. Once the TCP connection has been opened and the POP3
server has sent the greeting, the session enters the AUTHORIZATION
state. In this state, the client must identify itself to the POP3
server. Once the client has successfully done this, the server
acquires resources associated with the client's maildrop, and the
session enters the TRANSACTION state. In this state, the client
requests actions on the part of the POP3 server. When the client has
Myers & Rose Standards Track [Page 3]
RFC 1939 POP3 May 1996
issued the QUIT command, the session enters the UPDATE state. In
this state, the POP3 server releases any resources acquired during
the TRANSACTION state and says goodbye. The TCP connection is then
closed.
A server MUST respond to an unrecognized, unimplemented, or
syntactically invalid command by responding with a negative status
indicator. A server MUST respond to a command issued when the
session is in an incorrect state by responding with a negative status
indicator. There is no general method for a client to distinguish
between a server which does not implement an optional command and a
server which is unwilling or unable to process the command.
A POP3 server MAY have an inactivity autologout timer. Such a timer
MUST be of at least 10 minutes' duration. The receipt of any command
from the client during that interval should suffice to reset the
autologout timer. When the timer expires, the session does NOT enter
the UPDATE state--the server should close the TCP connection without
removing any messages or sending any response to the client.
4. The AUTHORIZATION State
Once the TCP connection has been opened by a POP3 client, the POP3
server issues a one line greeting. This can be any positive
response. An example might be:
S: +OK POP3 server ready
The POP3 session is now in the AUTHORIZATION state. The client must
now identify and authenticate itself to the POP3 server. Two
possible mechanisms for doing this are described in this document,
the USER and PASS command combination and the APOP command. Both
mechanisms are described later in this document. Additional
authentication mechanisms are described in [RFC1734]. While there is
no single authentication mechanism that is required of all POP3
servers, a POP3 server must of course support at least one
authentication mechanism.
Once the POP3 server has determined through the use of any
authentication command that the client should be given access to the
appropriate maildrop, the POP3 server then acquires an exclusive-
access lock on the maildrop, as necessary to prevent messages from
being modified or removed before the session enters the UPDATE state.
If the lock is successfully acquired, the POP3 server responds with a
positive status indicator. The POP3 session now enters the
TRANSACTION state, with no messages marked as deleted. If the
maildrop cannot be opened for some reason (for example, a lock can
not be acquired, the client is denied access to the appropriate
Myers & Rose Standards Track [Page 4]
RFC 1939 POP3 May 1996
maildrop, or the maildrop cannot be parsed), the POP3 server responds
with a negative status indicator. (If a lock was acquired but the
POP3 server intends to respond with a negative status indicator, the
POP3 server must release the lock prior to rejecting the command.)
After returning a negative status indicator, the server may close the
connection. If the server does not close the connection, the client
may either issue a new authentication command and start again, or the
client may issue the QUIT command.
After the POP3 server has opened the maildrop, it assigns a message-
number to each message, and notes the size of each message in octets.
The first message in the maildrop is assigned a message-number of
"1", the second is assigned "2", and so on, so that the nth message
in a maildrop is assigned a message-number of "n". In POP3 commands
and responses, all message-numbers and message sizes are expressed in
base-10 (i.e., decimal).
Here is the summary for the QUIT command when used in the
AUTHORIZATION state:
QUIT
Arguments: none
Restrictions: none
Possible Responses:
+OK
Examples:
C: QUIT
S: +OK dewey POP3 server signing off
5. The TRANSACTION State
Once the client has successfully identified itself to the POP3 server
and the POP3 server has locked and opened the appropriate maildrop,
the POP3 session is now in the TRANSACTION state. The client may now
issue any of the following POP3 commands repeatedly. After each
command, the POP3 server issues a response. Eventually, the client
issues the QUIT command and the POP3 session enters the UPDATE state.
Myers & Rose Standards Track [Page 5]
RFC 1939 POP3 May 1996
Here are the POP3 commands valid in the TRANSACTION state:
STAT
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
The POP3 server issues a positive response with a line
containing information for the maildrop. This line is
called a "drop listing" for that maildrop.
In order to simplify parsing, all POP3 servers are
required to use a certain format for drop listings. The
positive response consists of "+OK" followed by a single
space, the number of messages in the maildrop, a single
space, and the size of the maildrop in octets. This memo
makes no requirement on what follows the maildrop size.
Minimal implementations should just end that line of the
response with a CRLF pair. More advanced implementations
may include other information.
NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the drop
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.
Note that messages marked as deleted are not counted in
either total.
Possible Responses:
+OK nn mm
Examples:
C: STAT
S: +OK 2 320
LIST [msg]
Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted
Myers & Rose Standards Track [Page 6]
RFC 1939 POP3 May 1996
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If an argument was given and the POP3 server issues a
positive response with a line containing information for
that message. This line is called a "scan listing" for
that message.
If no argument was given and the POP3 server issues a
positive response, then the response given is multi-line.
After the initial +OK, for each message in the maildrop,
the POP3 server responds with a line containing
information for that message. This line is also called a
"scan listing" for that message. If there are no
messages in the maildrop, then the POP3 server responds
with no scan listings--it issues a positive response
followed by a line containing a termination octet and a
CRLF pair.
In order to simplify parsing, all POP3 servers are
required to use a certain format for scan listings. A
scan listing consists of the message-number of the
message, followed by a single space and the exact size of
the message in octets. Methods for calculating the exact
size of the message are described in the "Message Format"
section below. This memo makes no requirement on what
follows the message size in the scan listing. Minimal
implementations should just end that line of the response
with a CRLF pair. More advanced implementations may
include other information, as parsed from the message.
NOTE: This memo STRONGLY discourages implementations
from supplying additional information in the scan
listing. Other, optional, facilities are discussed
later on which permit the client to parse the messages
in the maildrop.
Note that messages marked as deleted are not listed.
Possible Responses:
+OK scan listing follows
-ERR no such message
Examples:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
Myers & Rose Standards Track [Page 7]
RFC 1939 POP3 May 1996
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop
RETR msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the message corresponding to the given
message-number, being careful to byte-stuff the termination
character (as with all multi-line responses).
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
DELE msg
Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted
Restrictions:
may only be given in the TRANSACTION state
Myers & Rose Standards Track [Page 8]
RFC 1939 POP3 May 1996
Discussion:
The POP3 server marks the message as deleted. Any future
reference to the message-number associated with the message
in a POP3 command generates an error. The POP3 server does
not actually delete the message until the POP3 session
enters the UPDATE state.
Possible Responses:
+OK message deleted
-ERR no such message
Examples:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted
NOOP
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
The POP3 server does nothing, it merely replies with a
positive response.
Possible Responses:
+OK
Examples:
C: NOOP
S: +OK
RSET
Arguments: none
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If any messages have been marked as deleted by the POP3
server, they are unmarked. The POP3 server then replies
Myers & Rose Standards Track [Page 9]
RFC 1939 POP3 May 1996
with a positive response.
Possible Responses:
+OK
Examples:
C: RSET
S: +OK maildrop has 2 messages (320 octets)
6. The UPDATE State
When the client issues the QUIT command from the TRANSACTION state,
the POP3 session enters the UPDATE state. (Note that if the client
issues the QUIT command from the AUTHORIZATION state, the POP3
session terminates but does NOT enter the UPDATE state.)
If a session terminates for some reason other than a client-issued
QUIT command, the POP3 session does NOT enter the UPDATE state and
MUST not remove any messages from the maildrop.
QUIT
Arguments: none
Restrictions: none
Discussion:
The POP3 server removes all messages marked as deleted
from the maildrop and replies as to the status of this
operation. If there is an error, such as a resource
shortage, encountered while removing messages, the
maildrop may result in having some or none of the messages
marked as deleted be removed. In no case may the server
remove any messages not marked as deleted.
Whether the removal was successful or not, the server
then releases any exclusive-access lock on the maildrop
and closes the TCP connection.
Possible Responses:
+OK
-ERR some deleted messages not removed
Examples:
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
...
C: QUIT
Myers & Rose Standards Track [Page 10]
RFC 1939 POP3 May 1996
S: +OK dewey POP3 server signing off (2 messages left)
...
7. Optional POP3 Commands
The POP3 commands discussed above must be supported by all minimal
implementations of POP3 servers.
The optional POP3 commands described below permit a POP3 client
greater freedom in message handling, while preserving a simple POP3
server implementation.
NOTE: This memo STRONGLY encourages implementations to support
these commands in lieu of developing augmented drop and scan
listings. In short, the philosophy of this memo is to put
intelligence in the part of the POP3 client and not the POP3
server.
TOP msg n
Arguments:
a message-number (required) which may NOT refer to to a
message marked as deleted, and a non-negative number
of lines (required)
Restrictions:
may only be given in the TRANSACTION state
Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the headers of the message, the blank
line separating the headers from the body, and then the
number of lines of the indicated message's body, being
careful to byte-stuff the termination character (as with
all multi-line responses).
Note that if the number of lines requested by the POP3
client is greater than than the number of lines in the
body, then the POP3 server sends the entire message.
Possible Responses:
+OK top of message follows
-ERR no such message
Examples:
C: TOP 1 10
S: +OK
Myers & Rose Standards Track [Page 11]
RFC 1939 POP3 May 1996
S: <the POP3 server sends the headers of the
message, a blank line, and the first 10 lines
of the body of the message>
S: .
...
C: TOP 100 3
S: -ERR no such message
UIDL [msg]
Arguments:
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted
Restrictions:
may only be given in the TRANSACTION state.
Discussion:
If an argument was given and the POP3 server issues a positive
response with a line containing information for that message.
This line is called a "unique-id listing" for that message.
If no argument was given and the POP3 server issues a positive
response, then the response given is multi-line. After the
initial +OK, for each message in the maildrop, the POP3 server
responds with a line containing information for that message.
This line is called a "unique-id listing" for that message.
In order to simplify parsing, all POP3 servers are required to
use a certain format for unique-id listings. A unique-id
listing consists of the message-number of the message,
followed by a single space and the unique-id of the message.
No information follows the unique-id in the unique-id listing.
The unique-id of a message is an arbitrary server-determined
string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions. This
persistence is required even if a session ends without
entering the UPDATE state. The server should never reuse an
unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
Note that messages marked as deleted are not listed.
While it is generally preferable for server implementations
to store arbitrarily assigned unique-ids in the maildrop,
Myers & Rose Standards Track [Page 12]
RFC 1939 POP3 May 1996
this specification is intended to permit unique-ids to be
calculated as a hash of the message. Clients should be able
to handle a situation where two identical copies of a
message in a maildrop have the same unique-id.
Possible Responses:
+OK unique-id listing follows
-ERR no such message
Examples:
C: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
...
C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
...
C: UIDL 3
S: -ERR no such message, only 2 messages in maildrop
USER name
Arguments:
a string identifying a mailbox (required), which is of
significance ONLY to the server
Restrictions:
may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command
Discussion:
To authenticate using the USER and PASS command
combination, the client must first issue the USER
command. If the POP3 server responds with a positive
status indicator ("+OK"), then the client may issue
either the PASS command to complete the authentication,
or the QUIT command to terminate the POP3 session. If
the POP3 server responds with a negative status indicator
("-ERR") to the USER command, then the client may either
issue a new authentication command or may issue the QUIT
command.
The server may return a positive response even though no
such mailbox exists. The server may return a negative
response if mailbox exists, but does not permit plaintext
Myers & Rose Standards Track [Page 13]
RFC 1939 POP3 May 1996
password authentication.
Possible Responses:
+OK name is a valid mailbox
-ERR never heard of mailbox name
Examples:
C: USER frated
S: -ERR sorry, no mailbox for frated here
...
C: USER mrose
S: +OK mrose is a real hoopy frood
PASS string
Arguments:
a server/mailbox-specific password (required)
Restrictions:
may only be given in the AUTHORIZATION state immediately
after a successful USER command
Discussion:
When the client issues the PASS command, the POP3 server
uses the argument pair from the USER and PASS commands to
determine if the client should be given access to the
appropriate maildrop.
Since the PASS command has exactly one argument, a POP3
server may treat spaces in the argument as part of the
password, instead of as argument separators.
Possible Responses:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked
...
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)
Myers & Rose Standards Track [Page 14]
RFC 1939 POP3 May 1996
APOP name digest
Arguments:
a string identifying a mailbox and a MD5 digest string
(both required)
Restrictions:
may only be given in the AUTHORIZATION state after the POP3
greeting or after an unsuccessful USER or PASS command
Discussion:
Normally, each POP3 session starts with a USER/PASS
exchange. This results in a server/user-id specific
password being sent in the clear on the network. For
intermittent use of POP3, this may not introduce a sizable
risk. However, many POP3 client implementations connect to
the POP3 server on a regular basis -- to check for new
mail. Further the interval of session initiation may be on
the order of five minutes. Hence, the risk of password
capture is greatly enhanced.
An alternate method of authentication is required which
provides for both or
Network Working Group J. Klensin, Editor
Request for Comments: 2821 AT&T Laboratories
Obsoletes: 821, 974, 1869 April 2001
Updates: 1123
Category: Standards Track
Simple Mail Transfer Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document is a self-contained specification of the basic protocol
for the Internet electronic mail transport. It consolidates, updates
and clarifies, but doesn't add new or change existing functionality
of the following:
- the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [30],
- domain name system requirements and implications for mail
transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123 [2],
and
- material drawn from the SMTP Extension mechanisms [19].
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the
mail transport materials of RFC 1123). However, RFC 821 specifies
some features that were not in significant use in the Internet by the
mid-1990s and (in appendices) some additional transport models.
Those sections are omitted here in the interest of clarity and
brevity; readers needing them should refer to RFC 821.
Klensin Standards Track [Page 1]
RFC 2821 Simple Mail Transfer Protocol April 2001
It also includes some additional material from RFC 1123 that required
amplification. This material has been identified in multiple ways,
mostly by tracking flaming on various lists and newsgroups and
problems of unusual readings or interpretations that have appeared as
the SMTP extensions have been deployed. Where this specification
moves beyond consolidation and actually differs from earlier
documents, it supersedes them technically as well as textually.
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 submission' protocol, as recommended for POP [3, 26]
and IMAP [6]. Additional submission issues are discussed in RFC 2476
[15].
Section 2.3 provides definitions of terms specific to this document.
Except when the historical terminology is necessary for clarity, this
document uses the current 'client' and 'server' terminology to
identify the sending and receiving SMTP processes, respectively.
A companion document [32] discusses message headers, message bodies
and formats and structures for them, and their relationship.
Table of Contents
1. Introduction .................................................. 4
2. The SMTP Model ................................................ 5
2.1 Basic Structure .............................................. 5
2.2 The Extension Model .......................................... 7
2.2.1 Background ................................................. 7
2.2.2 Definition and Registration of Extensions .................. 8
2.3 Terminology .................................................. 9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .............................. 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
Klensin Standards Track [Page 2]
RFC 2821 Simple Mail Transfer Protocol April 2001
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specifications ....................................... 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
4.1.5 Private-use Commands ....................................... 40
4.2 SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3 Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ........................................ 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
Klensin Standards Track [Page 3]
RFC 2821 Simple Mail Transfer Protocol April 2001
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ................................ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ....................................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ........................................... 67
9. References .................................................... 68
10. Editor's Address ............................................. 70
11. Acknowledgments .............................................. 70
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ................................................. 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ................................ 76
Full Copyright Statement ......................................... 79
1. Introduction
The objective of the Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. While this
document specifically discusses transport over TCP, other transports
are possible. Appendices to RFC 821 describe some of them.
An important feature of SMTP is its capability to transport mail
across networks, usually referred to as "SMTP mail relaying" (see
section 3.8). A network consists of the mutually-TCP-accessible
hosts on the public Internet, the mutually-TCP-accessible hosts on a
firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
environment utilizing a non-TCP transport-level protocol. Using
Klensin Standards Track [Page 4]
RFC 2821 Simple Mail Transfer Protocol April 2001
SMTP, a process can transfer mail to another process on the same
network or to some other network via a relay or gateway process
accessible to both networks.
In this way, a mail message may pass through a number of intermediate
relay or gateway hosts on its path from sender to ultimate recipient.
The Mail eXchanger mechanisms of the domain name system [22, 27] (and
section 5 of this document) are used to identify the appropriate
next-hop destination for a message being transported.
2. The SMTP Model
2.1 Basic Structure
The SMTP design can be pictured as:
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
The means by which a mail message is presented to an SMTP client, and
how that client determines the domain name(s) to which mail messages
are to be transferred is a local matter, and is not addressed by this
document. In some cases, the domain name(s) transferred to, or
determined by, an SMTP client will identify the final destination(s)
of the mail message. In other cases, common with SMTP clients
associated with implementations of the POP [3, 26] or IMAP [6]
protocols, or when the SMTP client is inside an isolated transport
service environment, the domain name determined will identify an
intermediate destination through which all mail messages are to be
relayed. SMTP clients that transfer all traffic, regardless of the
target domain names associated with the individual messages, or that
do not maintain queues for retrying message transmissions that
initially cannot be completed, may otherwise conform to this
specification but are not considered fully-capable. Fully-capable
SMTP implementations, including the relays used by these less capable
Klensin Standards Track [Page 5]
RFC 2821 Simple Mail Transfer Protocol April 2001
ones, and their destinations, are expected to support all of the
queuing, retrying, and alternate address functions discussed in this
specification.
The means by which an SMTP client, once it has determined a target
domain name, determines the identity of an SMTP server to which a
copy of a message is to be transferred, and then performs that
transfer, is covered by this document. To effect a mail transfer to
an SMTP server, an SMTP client establishes a two-way transmission
channel to that SMTP server. An SMTP client determines the address
of an appropriate host running an SMTP server by resolving a
destination domain name to either an intermediate Mail eXchanger host
or a final target host.
An SMTP server may be either the ultimate destination or an
intermediate "relay" (that is, it may assume the role of an SMTP
client after receiving the message) or "gateway" (that is, it may
transport the message further using some protocol other than SMTP).
SMTP commands are generated by the SMTP client and sent to the SMTP
server. SMTP replies are sent from the SMTP server to the SMTP
client in response to the commands.
In other words, message transfer can occur in a single connection
between the original SMTP-sender and the final SMTP-recipient, or can
occur in a series of hops through intermediary systems. In either
case, a formal handoff of responsibility for the message occurs: the
protocol requires that a server accept responsibility for either
delivering a message or properly reporting the failure to do so.
Once the transmission channel is established and initial handshaking
completed, the SMTP client normally initiates a mail transaction.
Such a transaction consists of a series of commands to specify the
originator and destination of the mail and transmission of the
message content (including any headers or other structure) itself.
When the same message is sent to multiple recipients, this protocol
encourages the transmission of only one copy of the data for all
recipients at the same destination (or intermediate relay) host.
The server responds to each command with a reply; replies may
indicate that the command was accepted, that additional commands are
expected, or that a temporary or permanent error condition exists.
Commands specifying the sender or recipients may include server-
permitted SMTP service extension requests as discussed in section
2.2. The dialog is purposely lock-step, one-at-a-time, although this
can be modified by mutually-agreed extension requests such as command
pipelining [13].
Klensin Standards Track [Page 6]
RFC 2821 Simple Mail Transfer Protocol April 2001
Once a given mail message has been transmitted, the client may either
request that the connection be shut down or may initiate other mail
transactions. In addition, an SMTP client may use a connection to an
SMTP server for ancillary services such as verification of email
addresses or retrieval of mailing list subscriber addresses.
As suggested above, this protocol provides mechanisms for the
transmission of mail. This transmission normally occurs directly
from the sending user's host to the receiving user's host when the
two hosts are connected to the same transport service. When they are
not connected to the same transport service, transmission occurs via
one or more relay SMTP servers. An intermediate host that acts as
either an SMTP relay or as a gateway into some other transmission
environment is usually selected through the use of the domain name
service (DNS) Mail eXchanger mechanism.
Usually, intermediate hosts are determined via the DNS MX record, not
by explicit "source" routing (see section 5 and appendices C and
F.2).
2.2 The Extension Model
2.2.1 Background
In an effort that started in 1990, approximately a decade after RFC
821 was completed, the protocol was modified with a "service
extensions" model that permits the client and server to agree to
utilize shared functionality beyond the original SMTP requirements.
The SMTP extension mechanism defines a means whereby an extended SMTP
client and server may recognize each other, and the server can inform
the client as to the service extensions that it supports.
Contemporary SMTP implementations MUST support the basic extension
mechanisms. For 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. (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.
SMTP is widely deployed and high-quality implementations have proven
to be very robust. However, the Internet community now considers
some services to be important that were not anticipated when the
protocol was first designed. If support for those services is to be
added, it must be done in a way that permits older implementations to
continue working acceptably. The extension framework consists of:
Klensin Standards Track [Page 7]
RFC 2821 Simple Mail Transfer Protocol April 2001
- The SMTP command EHLO, superseding the earlier HELO,
- a registry of SMTP service extensions,
- additional parameters to the SMTP MAIL and RCPT commands, and
- optional replacements for commands defined in this protocol, such
as for DATA in non-ASCII transmissions [33].
SMTP's strength comes primarily from its simplicity. Experience with
many protocols has shown that protocols with few options tend towards
ubiquity, whereas protocols with many options tend towards obscurity.
Each and every extension, regardless of its benefits, must be
carefully scrutinized with respect to its implementation, deployment,
and interoperability costs. In many cases, the cost of extending the
SMTP service will likely outweigh the benefit.
2.2.2 Definition and Registration of Extensions
The IANA maintains a registry of SMTP service extensions. A
corresponding EHLO keyword value is associated with each extension.
Each service extension registered with the IANA must be defined in a
formal standards-track or IESG-approved experimental protocol
document. The definition must include:
- the textual name of the SMTP service extension;
- the EHLO keyword value associated with the extension;
- the syntax and possible values of parameters associated with the
EHLO keyword value;
- any additional SMTP verbs associated with the extension
(additional verbs will usually be, but are not required to be, the
same as the EHLO keyword value);
- any new parameters the extension associates with the MAIL or RCPT
verbs;
- a description of how support for the extension affects the
behavior of a server and client SMTP; and,
- the increment by which the extension is increasing the maximum
length of the commands MAIL and/or RCPT, over that specified in
this standard.
Klensin Standards Track [Page 8]
RFC 2821 Simple Mail Transfer Protocol April 2001
In addition, any EHLO keyword value starting with an upper or lower
case "X" refers to a local SMTP service extension used exclusively
through bilateral agreement. Keywords beginning with "X" MUST NOT be
used in a registered service extension. Conversely, 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. A
conforming server MUST NOT offer non-"X"-prefixed keyword values that
are not described in a registered extension.
Additional verbs and parameter names are bound by the same rules as
EHLO keywords; specifically, verbs beginning with "X" are local
extensions that may not be registered or standardized. Conversely,
verbs not beginning with "X" must always be registered.
2.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described below.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances
when the particular behavior is acceptable or even useful, but the
full implications should be understood and the case carefully
weighed before implementing any behavior described with this
label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because the vendor feels
that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular
option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with
reduced functionality. In the same vein an implementation which
Klensin Standards Track [Page 9]
RFC 2821 Simple Mail Transfer Protocol April 2001
does include a particular option MUST be prepared to interoperate
with another implementation which does not include the option
(except, of course, for the feature the option provides.)
2.3.1 Mail Objects
SMTP transports a mail object. A mail object contains an envelope
and content.
The SMTP envelope is sent as a series of SMTP protocol units
(described in section 3). It consists of an originator address (to
which error reports should be directed); one or more recipient
addresses; and optional protocol extension material. Historically,
variations on the recipient address specification command (RCPT TO)
could be used to specify alternate delivery modes, such as immediate
display; those variations have now been deprecated (see appendix F,
section F.6).
The SMTP content is sent in the SMTP DATA protocol unit and has two
parts: the headers and the body. If the content conforms to other
contemporary standards, the headers form a collection of field/value
pairs structured as in the message format specification [32]; the
body, if structured, is defined according to MIME [12]. The content
is textual in nature, expressed using the US-ASCII repertoire [1].
Although SMTP extensions (such as "8BITMIME" [20]) may relax this
restriction for the content body, the content headers are always
encoded using the US-ASCII repertoire. A MIME extension [23] defines
an algorithm for representing header values outside the US-ASCII
repertoire, while still encoding them using the US-ASCII repertoire.
2.3.2 Senders and Receivers
In RFC 821, the two hosts participating in an SMTP transaction were
described as the "SMTP-sender" and "SMTP-receiver". This document
has been changed to reflect current industry terminology and hence
refers to them as the "SMTP client" (or sometimes just "the client")
and "SMTP server" (or just "the server"), respectively. Since a
given host may act both as server and client in a relay situation,
"receiver" and "sender" terminology is still used where needed for
clarity.
2.3.3 Mail Agents and Message Stores
Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Agents" (MUAs or UAs) are normally thought of as the sources and
Klensin Standards Track [Page 10]
RFC 2821 Simple Mail Transfer Protocol April 2001
targets of mail. At the source, an MUA might collect mail to be
transmitted from a user and hand it off to an MTA; the final
("delivery") MTA would be thought of as handing the mail off to an
MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a "message store"). However, while these
terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs
often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader should be cautious about inferring
the strong relationships and responsibilities that might be implied
if these terms were used elsewhere.
2.3.4 Host
For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP
network) and supporting the SMTP protocol. Hosts are known by names
(see "domain"); identifying them by numerical address is discouraged.
2.3.5 Domain
A domain (or domain name) consists of one or more dot-separated
components. These components ("labels" in DNS terminology [22]) are
restricted for SMTP purposes to consist of a sequence of letters,
digits, and hyphens drawn from the ASCII character set [1]. Domain
names are used as names of hosts and of other entities in the domain
name hierarchy. For example, a domain may refer to an alias (label
of a CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See [22] and
section 5 of this specification.
The domain name, as described in this document and in [22], is the
entire, fully-qualified name (often referred to as an "FQDN"). A
domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
2.3.6 Buffer and State Table
SMTP sessions are stateful, with both parties carefully maintaining a
common view of the current state. In this document we model this
state by a virtual "buffer" and a "state table" on the server which
may be used by the client to, for example, "clear the buffer" or
"reset the state table," causing the information in the buffer to be
discarded and the state to be returned to some previous state.
Klensin Standards Track [Page 11]
RFC 2821 Simple Mail Transfer Protocol April 2001
2.3.7 Lines
SMTP commands and, unless altered by a service extension, message
data, are transmitted in "lines". Lines consist of zero or more data
characters terminated by the sequence ASCII character "CR" (hex value
0D) followed immediately by ASCII character "LF" (hex value 0A).
This termination sequence is denoted as <CRLF> in this document.
Conforming implementations MUST NOT recognize or generate any other
character or character sequence as a line terminator. Limits MAY be
imposed on line lengths by servers (see section 4.5.3).
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP 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.8 Originator, Delivery, Relay, and Gateway Systems
This specification makes a distinction among four types of SMTP
systems, based on the role those systems play in transmitting
electronic mail. An "originating" system (sometimes called an SMTP
originator) introduces mail into the Internet or, more generally,
into a transport service environment. A "delivery" SMTP system is
one that receives mail from a transport service environment and
passes it to a mail user agent or deposits it in a message store
which a mail user agent is expected to subsequently access. A
"relay" SMTP system (usually referred to just as a "relay") receives
mail from an SMTP client and transmits it, without modification to
the message data other than adding trace information, to another SMTP
server for further relaying or for delivery.
A "gateway" SMTP system (usually referred to just as a "gateway")
receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway
system perform transformations to the message that are not permitted
to SMTP relay systems. For the purposes of this specification,
firewalls that rewrite addresses should be considered as gateways,
even if SMTP is used on both sides of them (see [11]).
Klensin Standards Track [Page 12]
RFC 2821 Simple Mail Transfer Protocol April 2001
2.3.9 Message Content and Mail Data
The terms "message content" and "mail data" are used interchangeably
in this document to describe the material transmitted after the DATA
command is accepted and before the end of data indication is
transmitted. Message content includes message headers and the
possibly-structured message body. The MIME specification [12]
provides the standard mechanisms for structured message bodies.
2.3.10 Mailbox and Address
As used in this specification, an "address" is a character string
that identifies a user to whom mail will be sent or a location into
which mail will be deposited. The term "mailbox" refers to that
depository. The two terms are typically used interchangeably unless
the distinction between the location in which mail is placed (the
mailbox) and a reference to it (the address) is important. An
address normally consists of user and domain specifications. The
standard mailbox naming convention is defined to be "local-
": contemporary usage permits a much broader set of
applications than simple "user names". Consequently, and due to a
long history of problems when intermediate hosts have attempted to
optimize 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.3.11 Reply
An SMTP reply is an acknowledgment (positive or negative) sent from
receiver to sender via the transmission channel in response to a
command. The general form of a reply is a numeric completion code
(indicating failure or success) usually followed by a text string.
The codes are for use by programs and the text is usually intended
for human users. Recent work [34] has specified further structuring
of the reply strings, including the use of supplemental and more
specific completion codes.
2.4 General Syntax Principles and Transaction Model
SMTP commands and replies have a rigid syntax. All commands begin
with a command verb. All Replies begin with a three digit numeric
code. In some commands and replies, arguments MUST follow the verb
or reply code. Some commands do not accept arguments (after the
verb), and some reply codes are followed, sometimes optionally, by
free form text. In both cases, where text appears, it is separated
from the verb or reply code by a space character. Complete
definitions of commands and replies appear in section 4.
Klensin Standards Track [Page 13]
RFC 2821 Simple Mail Transfer Protocol April 2001
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part (SMTP
Extensions may explicitly specify case-sensitive elements). That 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. This
is NOT true of a mailbox local-part. The local-part of a mailbox
MUST BE treated as case sensitive. Therefore, SMTP implementations
MUST take care to preserve the case of mailbox local-parts. Mailbox
domains are not case sensitive. In particular, for some hosts the
user "smith" is different from the user "Smith". However, exploiting
the case sensitivity of mailbox local-parts impedes interoperability
and is discouraged.
A few SMTP servers, in violation of this specification (and RFC 821)
require that command verbs be encoded by clients in upper case.
Implementations MAY wish to employ this encoding to accommodate those
servers.
The argument field consists of a variable length character string
ending with the end of the line, i.e., with the character sequence
<CRLF>. The receiver will take no action until this sequence is
received.
The syntax for each command is shown with the discussion of that
command. Common elements and parameters are shown in section 4.1.2.
Commands and replies are composed of characters from the ASCII
character set [1]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.
More specifically, the unextended SMTP service provides seven bit
transport only. An originating SMTP client which has not
successfully negotiated an appropriate extension with a particular
server MUST NOT transmit messages with information in the high-order
bit of octets. If such messages are transmitted in violation of this
rule, receiving SMTP servers MAY clear the high-order bit or reject
the message as invalid. In 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.
Of course, if the content is mislabeled and the data path cannot
accept the actual content, this may result in ultimate delivery of a
severely garbled message to the recipient. Delivery SMTP systems MAY
reject ("bounce") such messages rather than deliver them. No sending
SMTP system is permitted to send envelope commands in any character
Klensin Standards Track [Page 14]
RFC 2821 Simple Mail Transfer Protocol April 2001
set other than US-ASCII; receiving systems SHOULD reject such
commands, normally using "500 syntax error - invalid character"
replies.
Eight-bit message content transmission MAY be requested of the server
by a client using extended SMTP facilities, notably the "8BITMIME"
extension [20]. 8BITMIME SHOULD be supported by SMTP servers.
However, it MUST not be construed as authorization to transmit
unrestricted eight bit material. 8BITMIME 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.
The metalinguistic notation used in this document corresponds to the
"Augmented BNF" used in other Internet mail system documents. The
reader who is not familiar with that syntax should consult the ABNF
specification [8]. Metalanguage terms used in running text are
surrounded by pointed brackets (e.g., <CRLF>) for clarity.
3. The SMTP Procedures: An Overview
This section contains descriptions of the procedures used in SMTP:
session initiation, the mail transaction, forwarding mail, verifying
mailbox names and expanding mailing lists, and the opening and
closing exchanges. Comments on relaying, a note on mail domains, and
a discussion of changing roles are included at the end of this
section. Several complete scenarios are presented in appendix D.
3.1 Session Initiation
An SMTP session is initiated when a client opens a connection to a
server and the server responds with an opening message.
SMTP 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. Implementations MAY make provision for
SMTP servers to disable the software and version announcement where
it causes security concerns. While some systems also identify their
contact point for mail problems, this is not a substitute for
maintaining the required "postmaster" address (see section 4.5.1).
The SMTP protocol allows a server to formally reject a transaction
while still allowing the initial connection as follows: a 554
response MAY be given in the initial connection opening message
instead of the 220. A 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
Klensin Standards Track [Page 15]
RFC 2821 Simple Mail Transfer Protocol April 2001
"503 bad sequence of commands". Since 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
Once the server has sent the welcoming message and the client has
received it, the client normally sends the EHLO command to the
server, indicating the client's identity. In addition to opening the
session, use of EHLO indicates that the client is able to process
service extensions and requests that the server provide a list of the
extensions it supports. Older SMTP systems which are unable to
support service extensions and contemporary clients which do not
require service extensions in the mail session being initiated, MAY
use HELO instead of EHLO. Servers MUST NOT return the extended
EHLO-style response to a HELO command. For 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.
In the EHLO command the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am <domain>" (and,
in the case of EHLO, "and I support service extension requests").
3.3 Mail Transactions
There are three steps to SMTP mail transactions. The transaction
starts with a MAIL command which gives the sender identification.
(In general, the MAIL command may be sent only when no mail
transaction is in progress; see section 4.1.4.) A series of one or
more RCPT commands follows giving the receiver information. Then a
DATA command initiates transfer of the mail data and is terminated by
the "end of mail" data indicator, which also confirms the
transaction.
The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
This command tells the SMTP-receiver that a new mail transaction is
starting and to reset all its state tables and buffers, including any
recipients or mail data. The <reverse-path> portion of the first or
only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors (see section 4.2 for a
discussion of error reporting). If accepted, the SMTP server returns
a 250 OK reply. If the mailbox specification is not acceptable for
some reason, the server MUST return a reply indicating whether the
Klensin Standards Track [Page 16]
RFC 2821 Simple Mail Transfer Protocol April 2001
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). Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In 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. Normally, failures produce 550 or 553 replies.
Historically, the <reverse-path> can contain more than just a
mailbox, however, contemporary systems SHOULD NOT use source routing
(see appendix C).
The optional <mail-parameters> are associated with negotiated SMTP
service extensions (see section 2.2).
The second step in the procedure is the RCPT command.
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
Network Working Group D. Crocker
Request for Comments: 2142 Internet Mail Consortium
Category: Standards Track May 1997
MAILBOX NAMES FOR
COMMON SERVICES, ROLES AND FUNCTIONS
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
ABSTRACT
This specification enumerates and describes Internet mail addresses
(mailbox name @ host reference) to be used when contacting personnel
at an organization. Mailbox names are provided for both operations
and business functions. Additional mailbox names and aliases are not
prohibited, but organizations which support email exchanges with the
Internet are encouraged to support AT LEAST each mailbox name for
which the associated function exists within the organization.
1. RATIONALE AND SCOPE
Various Internet documents have specified mailbox names to be used
when reaching the operators of the new service; for example, [RFC822
6.3, C.6] requires the presence of a <> mailbox name
on all hosts that have an SMTP server. Other protocols have defacto
standards for well known mailbox names, such as <USENET@domain> for
NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]).
Defacto standards also exist for well known mailbox names which have
nothing to do with a particular protocol, e.g., <ABUSE@domain> and
<TROUBLE@domain>.
The purpose of this memo is to aggregate and specify the basic set of
mailbox names which organizations need to support. Most
organizations do not need to support the full set of mailbox names
defined here, since not every organization will implement the all of
the associated services. However, if a given service is offerred,
then the associated mailbox name(es) must be supported, resulting in
delivery to a recipient appropriate for the referenced service or
role.
Crocker Standards Track [Page 1]
RFC 2142 Mailbox Names May 1997
If a host is not configured to accept mail directly, but it
implements a service for which this specification defines a mailbox
name, that host must have an MX RR set (see [RFC974]) and the mail
exchangers specified by this RR set must recognize the referenced
host's domain name as "local" for the purpose of accepting mail bound
for the defined mailbox name. Note that this is true even if the
advertised domain name is not the same as the host's domain name; for
example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it
advertises the domain name VIX.COM in its "Path:" headers, then mail
must be deliverable to both <USENET@VIX.COM> and
<USENET@DATA.RAMONA.VIX.COM>, even though these addresses might be
delivered to different final destinations.
The scope of a well known mailbox name is its domain name. Servers
accepting mail on behalf of a domain must accept and correctly
process mailbox names for that domain, even if the server, itself,
does not support the associated service. So, for example, if an NNTP
server advertises the organization's top level domain in "Path:"
headers (see [RFC977]) the mail exchangers for that top level domain
must accept mail to <USENET@domain> even if the mail exchanger hosts
do not, themselves, serve the NNTP protocol.
2. INVARIANTS
For well known names that are not related to specific protocols, only
the organization's top level domain name are required to be valid.
For example, if an Internet service provider's domain name is
COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid and
supported, even though the customers whose activity generates
complaints use hosts with more specific domain names like
SHELL1.COMPANY.COM. Note, however, that it is valid and encouraged
to support mailbox names for sub-domains, as appropriate.
Mailbox names must be recognized independent of character case. For
example, POSTMASTER, postmaster, Postmaster, PostMaster, and even
PoStMaStEr are to be treated the same, with delivery to the same
mailbox.
Implementations of these well known names need to take account of the
expectations of the senders who will use them. Sending back an
automatic mail acknowledgement is usually helpful (though we suggest
caution against the possibility of "duelling mail robots" and the
resulting mail loops).
Crocker Standards Track [Page 2]
RFC 2142 Mailbox Names May 1997
3. BUSINESS-RELATED MAILBOX NAMES
These names are related to an organization's line-of-business
activities. The INFO name is often tied to an autoresponder, with a
range of standard files available.
MAILBOX AREA USAGE
----------- ---------------- ---------------------------
INFO Marketing Packaged information about the
organization, products, and/or
services, as appropriate
MARKETING Marketing Product marketing and
marketing communications
SALES Sales Product purchase information
SUPPORT Customer Service Problems with product or
service
4. NETWORK OPERATIONS MAILBOX NAMES
Operations addresses are intended to provide recourse for customers,
providers and others who are experiencing difficulties with the
organization's Internet service.
MAILBOX AREA USAGE
----------- ---------------- ---------------------------
ABUSE Customer Relations Inappropriate public behaviour
NOC Network Operations Network infrastructure
SECURITY Network Security Security bulletins or queries
5. SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
For major Internet protocol services, there is a mailbox defined for
receiving queries and reports. (Synonyms are included, here, due to
their extensive installed base.)
MAILBOX SERVICE SPECIFICATIONS
----------- ---------------- ---------------------------
POSTMASTER SMTP [RFC821], [RFC822]
HOSTMASTER DNS [RFC1033-RFC1035]
USENET NNTP [RFC977]
NEWS NNTP Synonym for USENET
WEBMASTER HTTP [RFC 2068]
WWW HTTP Synonym for WEBMASTER
UUCP UUCP [RFC976]
FTP FTP [RFC959]
Crocker Standards Track [Page 3]
RFC 2142 Mailbox Names May 1997
6. MAILING LIST ADMINISTRATION MAILBOX
Mailing lists have an administrative mailbox name to which add/drop
requests and other meta-queries can be sent.
For a mailing list whose submission mailbox name is:
there MUST be the administrative mailbox name:
Distribution List management software, such as MajorDomo and
Listserv, also have a single mailbox name associated with the
software on that system -- usually the name of the software -- rather
than a particular list on that system. Use of such mailbox names
requires participants to know the type of list software employed at
the site. This is problematic. Consequently:
LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,
INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE
MAILBOX NAMES.
7. DOMAIN NAME SERVICE ADMINISTRATION MAILBOX
In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
Authority record (SOA RR) has a field for specifying the mailbox name
of the zone's administrator.
This field must be a simple word without metacharacters (such as "%"
or "!" or "::"), and a mail alias should be used on the relevant mail
exchanger hosts to direct zone administration mail to the appropriate
mailbox.
For simplicity and regularity, it is strongly recommended that the
well known mailbox name HOSTMASTER always be used
<HOSTMASTER@domain>.
Crocker Standards Track [Page 4]
RFC 2142 Mailbox Names May 1997
8. AUTONOMOUS SYSTEM MAILBOX
Several Internet registries implement mailing lists for Autonomous
System contacts. So, for example, mail sent to <AS3557@RA.NET> will
at the time of this writing reach the technical contact for
Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and
[RFC1656]).
Not all Autonomous Systems are registered with all registries,
however, and so undeliverable mailbox names under this scheme should
be treated as an inconvenience rather than as an error or a standards
violation.
9. SECURITY CONSIDERATIONS
Denial of service attacks (flooding a mailbox with junk) will be
easier after this document becomes a standard, since more systems
will support the same set of mailbox names.
10. REFERENCES
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, Information Sciences Institute, August 1982.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, Information Sciences Institute, October 1985.
[RFC974] Partridge, C., "Mail routing and the domain system", STD 14,
RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
[RFC976] Horton, M., "UUCP mail interchange format standard", RFC
976, Bell Laboratories, February 1986.
[RFC977] Kantor, B., et al, "Network News Transfer Protocol: A
Proposed Standard for the Stream-Based Transmission of News", RFC
977, University of California, February 1986.
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC
1033, SRI International, November 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
Crocker Standards Track [Page 5]
RFC 2142 Mailbox Names May 1997
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",
RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.
[RFC1655] Rekhter, Y., et al, "Application of the Border Gateway
Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM
Corp., July 1994.
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, cisco Systems, July 1994.
[HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --
HTTP/1.0", RFC 1945, May 1996.
11. ACKNOWLEDGEMENTS
This specification derived from an earlier draft written by Paul
Vixie. Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D.
Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and
Ed Morin for their comments on that draft.
12. AUTHOR'S ADDRESS
Dave Crocker
Internet Mail Consortium
127 Segre Ave.
Santa Cruz, CA
Phone: +1 408 246 8253
EMail: dcrocker@imc.org
Crocker Standards Track [Page 6]
I regularly get requests to reprint or re-publish these guidelines: I am happy for you to use them, provided you agree to the following reasonable conditions:
- You must attribute my copyright in the republished or reprinted item. The sentence "These guidelines are Copyright (c) 1990-2006, David Harris, all rights reserved" appearing anywhere visible in the document is sufficient to meet this requirement.
- The guidelines must be published or reprinted complete and exactly as they appear on this site. In particular, you may not omit any part, nor modify the spelling or grammar in any way. The only exception to this requirement is that the reference to "setting your personal name in Pegasus Mail" in the section entitled "Addresses and personal names" may be edited out. Aside from this change, no other modifications are permitted.
- You may not use the guidelines in any publication or context that promotes or condones the sending of spam (unsolicited commercial e-mail).
Provided you meet these conditions, you do not have to approach us for specific publication permission.
/David Harris