RFC Errata
Found 7 records.
Status: Verified (2)
RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003
Note: This RFC has been obsoleted by RFC 9051
Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 261
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Crispin
Date Reported: 2007-06-13
Section 2.3.1.1, page 8:
old:
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
[...]
new:
An unsigned 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
[...]
-----
Section 2.3.1.1, page 9:
old:
Associated with every mailbox are two values which aid in unique
identifier handling: the next unique identifier value and the unique
identifier validity value.
new:
Associated with every mailbox are two 32-bit unsigned values which
aid in unique identifier handling: the next unique identifier value
(UIDNEXT) and the unique identifier validity value (UIDVALIDITY).
-----
Section 5.1.3, page 19:
old:
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
represented in modified BASE64, with a further modification from
[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
used to represent any printing US-ASCII character which can represent
itself.
new:
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
represented in modified BASE64, with a further modification from
[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
used to represent any printing US-ASCII character which can represent
itself. Only characters inside the modified BASE64 alphabet are
permitted in modified BASE64 text.
-----
Section 5.4, page 22:
old:
If a server has an inactivity autologout timer, the duration of that
timer MUST be at least 30 minutes. The receipt of ANY command from
the client during that interval SHOULD suffice to reset the
autologout timer.
new:
If a server has an inactivity autologout timer that applies to
sessions after authentication, the duration of that timer MUST be at
least 30 minutes. The receipt of ANY command from the client during
that interval SHOULD suffice to reset the autologout timer.
Section 5.5, page 22:
old:
Note: UID FETCH, UID STORE, and UID SEARCH are different
commands from FETCH, STORE, and SEARCH. If the client
sends a UID command, it must wait for a completion result
response before sending a command with message sequence
numbers.
new:
Note: EXPUNGE responses are permitted while UID FETCH,
UID STORE, and UID SEARCH are in progress. If the client
sends a UID command, it must wait for a completion result
response before sending a command which uses message
sequence numbers (this may include UID SEARCH). Any
message sequence numbers in an argument to UID SEARCH
are associated with messages prior to the effect of any
untagged EXPUNGE returned by the UID SEARCH.
-----
Section 6.2.1, page 27:
old:
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities after
STARTTLS.
new:
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities, and
in particular SHOULD NOT advertise the STARTTLS capability, after
a successful STARTTLS command.
-----
Section 6.2.2, page 28:
old:
The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
consisting of a single "*". If the server receives such a
response, it MUST reject the AUTHENTICATE command by sending a
tagged BAD response.
new:
The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
consisting of a single "*". If the server receives such a
response, or if it receives an invalid BASE64 string (e.g.
characters outside the BASE64 alphabet, or non-terminal "="), it
MUST reject the AUTHENTICATE command by sending a tagged BAD
response.
Section 6.3.4, page 36:
old:
It is permitted to delete a name that has inferior hierarchical
names and does not have the \Noselect mailbox name attribute. In
this case, all messages in that mailbox are removed, and the name
will acquire the \Noselect mailbox name attribute.
new:
It is permitted to delete a name that has inferior hierarchical
names and does not have the \Noselect mailbox name attribute. If
the server implementation does not permit deleting the name while
inferior hierarchical names exists the \Noselect mailbox name
attribute is set for that name. In any case, all messages in
that mailbox are removed by the DELETE command.
-----
Section 6.3.10, page 44:
old:
Responses: untagged responses: STATUS
new:
Responses: REQUIRED untagged response: STATUS
-----
Section 6.4.3, page 49:
old:
The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, an untagged EXPUNGE response is
sent for each message that is removed.
new:
The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, an untagged EXPUNGE response is
sent for each message that is removed. Note that if any messages
with the \Recent flag set are expunged, an untagged RECENT response
is sent after the untagged EXPUNGE(s) to update the client's count
of RECENT messages.
-----
Section 6.4.4, page 50:
old:
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
new:
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text. US-ASCII MUST be supported; other [CHARSET]s MAY be supported.
-----
Section 6.4.4, page 50:
old:
In all search keys that use strings, a message matches the key if
the string is a substring of the field. The matching is
case-insensitive.
new:
In all search keys that use strings, a message matches the key if
the string is a substring of the associated text. The matching is
case-insensitive. Note that the empty string is a substring; this
is useful when doing a HEADER search.
-----
Section 6.4.4, page 54:
old:
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
new:
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
S: + Ready for literal text
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
-----
Section 7.2.2, page 70:
old:
If it is not feasible for the server to determine whether or not
the mailbox is "interesting", or if the name is a \Noselect name,
the server SHOULD NOT send either \Marked or \Unmarked.
new:
If it is not feasible for the server to determine whether or not
the mailbox is "interesting", the server SHOULD NOT send either
\Marked or \Unmarked. The server MUST NOT send more than one of
\Marked, \Unmarked, and \Noselect for a single mailbox, and MAY
send none of these.
-----
Section 7.4.2, page 75:
old:
body location
A string list giving the body content URI as defined in
[LOCATION].
new:
body location
A string giving the body content URI as defined in
[LOCATION].
Section 7.4.2, page 77:
old:
body location
A string list giving the body content URI as defined in
[LOCATION].
new:
body location
A string giving the body content URI as defined in
[LOCATION].
Formal Syntax, Page 84:
old:
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
new:
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
charset = atom / quoted
-----
Formal Syntax, Page 89:
old:
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
new:
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
-----
Formal Syntax, Page 89:
old:
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
new:
search = "SEARCH" [SP "CHARSET" SP charset] 1*(SP search-key)
-----
Formal Syntax, Page 90:
old:
sequence-set = (seq-number / seq-range) *("," sequence-set)
new:
sequence-set = (seq-number / seq-range) ["," sequence-set]
-----
Formal Syntax, Page 90:
old:
status-att-list = status-att SP number *(SP status-att SP number)
new:
status-att-val = ("MESSAGES" SP number) / ("RECENT" SP number) /
("UIDNEXT" SP nz-number) / ("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number)
status-att-list = status-att-val *(SP status-att-val)
-----
IANA Considerations, Page 94:
new:
GSSAPI/Kerberos/SASL service names are registered by publishing a
standards track or IESG approved experimental RFC. The registry
is currently located at:
http://www.iana.org/assignments/gssapi-service-names
As this specification defines the "imap" service name previously
defined in RFC 1731, the registry will be updated accordingly.
-----
Normative References, Page 95:
old:
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
new:
[LANGUAGE-TAGS] Alvestrand, H., "Content Language Headers",
RFC 3282, May 2002.
Appendix B, Page 103:
new:
115) Add support for Content-Location to BODYSTRUCTURE.
It should say:
[see above]
Notes:
from pending
Errata ID: 3032
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bron Gondwana
Date Reported: 2011-11-15
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-15
Section 6.3.1 says:
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY
[...]
OK [UNSEEN <n>]
The message sequence number of the first unseen
message in the mailbox. If this is missing, the
client can not make any assumptions about the first
unseen message in the mailbox, and needs to issue a
SEARCH command if it wants to find it.
It should say:
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY, UNSEEN (if any unseen exist)
[...]
OK [UNSEEN <n>]
The message sequence number of the first unseen
message in the mailbox. If there are any unseen
messages in the mailbox, an UNSEEN response MUST
be sent, if not it MUST be omitted.
If this is missing, the client cannot make any
assumptions about the first unseen message in the
mailbox, and needs to issue a SEARCH command if
it wants to find it.
Notes:
There is a conflict between "REQUIRED" on the UNSEEN response and having no value to send. This change documents the approach taken by existing servers.
Status: Held for Document Update (3)
RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003
Note: This RFC has been obsoleted by RFC 9051
Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 6637
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: TornaxO7
Date Reported: 2021-07-10
Held for Document Update by: Andy Newton
Date Held: 2025-11-01
Section 9 says:
envelope = "(" env-date SP env-subject SP env-from SP
env-sender SP env-reply-to SP env-to SP env-cc SP
env-bcc SP env-in-reply-to SP env-message-id ")"
It should say:
envelope = "(" env-date SP env-subject SP env-from SP
env-sender SP env-reply-to SP env-to SP env-cc SP
env-bcc SP env-in-reply-to SP env-message-id SP
env-references ")"
Notes:
Section 2.3.5 says:
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.
Althought RFC-2822 is obsolete by RFC-5322 now, both says that the envelope should inlcude a "References:" header-field but the definition of the envelope in section 9 of RFC-3501 (see the part in "Original Text" above) doesn't include the "references" field.
Errata ID: 3093
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Pallas
Date Reported: 2012-01-18
Held for Document Update by: Pete Resnick
Section 6.3.11 says:
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.
It should say:
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.
Notes:
Possibly the result of a search-and-replace, these occurrences of "must" and "may" are not RFC 2119 usages.
Errata ID: 6160
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gene Smith
Date Reported: 2020-05-07
Held for Document Update by: Barry Leiba
Date Held: 2020-05-08
Section Page 89 says:
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
; CHARSET argument to MUST be registered with IANA
It should say:
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
; CHARSET argument MUST be registered with IANA
Notes:
An errata already exists for the first line above: astring replaced with charset. The 2nd line seems to have an extra word, "to".
Status: Rejected (2)
RFC 3501, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", March 2003
Note: This RFC has been obsoleted by RFC 9051
Note: This RFC has been updated by RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3445
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Slusarz
Date Reported: 2013-01-06
Rejected by: Barry Leiba
Date Rejected: 2013-01-08
Section 6.3.1 says:
OK [UIDNEXT <n>]
The next unique identifier value. Refer to section
2.3.1.1 for more information. If this is missing,
the client can not make any assumptions about the
next unique identifier value.
It should say:
OK [UIDNEXT <n>]
The next unique identifier value. Refer to section
2.3.1.1 for more information.
Notes:
The UIDNEXT response to a SELECT/EXAMINE command is a "REQUIRED OK untagged response" (see Sections 6.3.1 & 6.3.2; see also Appendix B #34). The UIDNEXT response code requires a nz-number per the ABNF (Section 9). Therefore the UIDNEXT value can never be "missing" from a SELECT/EXAMINE, and no assumptions about client behavior should be mentioned.
As currently phrased, the UIDNEXT text implies that the response MAY be missing, which is in direct conflict with the requirements in Sections 6.3.1/6.3.2 that UIDNEXT MUST always be present. REQUIRED appears to be the proper requirement based on the previously mentioned change entry.
See discussion on the IMAP protocol discussion list (http://thread.gmane.org/gmane.mail.imap.general/3163).
--VERIFIER NOTES--
Look at the paragraph above the responses in Section 6.3.1. It says this:
The SELECT command selects a mailbox so that messages in the
mailbox can be accessed. Before returning an OK to the client,
the server MUST send the following untagged data to the client.
Note that earlier versions of this protocol only required the
FLAGS, EXISTS, and RECENT untagged data; consequently, client
implementations SHOULD implement default behavior for missing data
as discussed with the individual item.
The text that you're suggesting removing is there very purposefully,
and should NOT be removed. That said, I think this is not very clear,
and I would like to see a future document update re-word things to
make it clearer.
The point is that these are REQUIRED in the current version of the protocol,
but that because they were optional in an earlier version, and that version is
not distinguishable from this one in operation, clients SHOULD support the
earlier version by taking the actions specified in the even that some or all of
these untagged OK responses are missing.
Errata ID: 6636
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: TornaxO7
Date Reported: 2021-07-10
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-21
Throughout the document, when it says:
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.
It should say:
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof.
Notes:
RFC-3501 still refers to RFC-2822 which is obsoleted by RFC-5322. **One** example can be seen in the "Original text" section.
--VERIFIER NOTES--
Errata reports are for issues that were errors at the time of publication. RFC 5322 was published after RFC 3501, so RFC 2822 was the correct reference when RFC 3501 was published.