RFC Errata
Found 15 records.
Status: Verified (3)
RFC 5321, "Simple Mail Transfer Protocol", October 2008
Note: This RFC has been updated by RFC 7504
Source of RFC: IETF - NON WORKING GROUPArea Assignment: art
Errata ID: 1683
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Roberto Javier Godoy
Date Reported: 2009-02-15
Verifier Name: Alexey Melnikov
Date Verified: 2009-09-07
Section 4.4 says:
Additional-Registered-Clauses = CFWS Atom FWS String
It should say:
Additional-Registered-Clauses = 1*(CFWS Atom FWS String)
Notes:
1. The rule Additional-Registered-Clauses is used by the rule Opt-info (also in section 4.4, page 59) as:
Opt-info = [Via] [With] [ID] [For] [Additional-Registered-Clauses]
2. The ABNF comment for Additional-Registered-Clauses states that "Additional standard clauses may be added in this location by future standards and registration with IANA."
3. Each sequence (CFWS Atom FWS String) represents a single clause.
Errata ID: 4198
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jasen Betts
Date Reported: 2014-12-09
Verifier Name: Barry Leiba
Date Verified: 2014-12-09
Section 4.2 says:
Whenever possible, a receiver- SMTP SHOULD test the first digit (severity indication) of the reply code.
It should say:
Whenever possible, a sender- SMTP SHOULD test the first digit (severity indication) of a reply code it receives.
Notes:
The "sender" is the entity that issues commands and receives response codes (from the "receiver").
Errata ID: 2578
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dominic Sayers
Date Reported: 2010-10-18
Verifier Name: Peter Saint-Andre
Date Verified: 2010-11-12
Section 4.1.2 says:
Terminals not defined in this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax in Section 6 of RFC 5234 [7] or in the message format syntax in RFC 5322 [4].
It should say:
Terminals not defined in this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the "core" syntax in Appendix B of RFC 5234 [7] or in the message format syntax in RFC 5322 [4].
Notes:
The core syntax of ABNF is defined in Appendix B "Core ABNF of ABNF" of RFC 5234, not Section 6, which lists the document's references.
Status: Held for Document Update (6)
RFC 5321, "Simple Mail Transfer Protocol", October 2008
Note: This RFC has been updated by RFC 7504
Source of RFC: IETF - NON WORKING GROUPArea Assignment: art
Errata ID: 1543
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Brett Watson
Date Reported: 2008-10-08
Held for Document Update by: Pete Resnick
Section 3.8 says:
SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly.
It should say:
SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 421 response had been received and act accordingly.
Notes:
SMTP clients are told to act as though a 451 response ("Requested action aborted: local error in processing") had been received when context clearly indicates that a 421 response ("Service not available, closing transmission channel") was intended.
Errata ID: 4315
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Rodrigo Speller
Date Reported: 2015-03-27
Held for Document Update by: Barry Leiba
Date Held: 2015-03-28
Section 4.1.3 says:
IPv6-full = IPv6-hex 7(":" IPv6-hex) IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" IPv6-hex)] ; The "::" represents at least 2 16-bit groups of ; zeros. No more than 6 groups in addition to the ; "::" may be present. IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal ; The "::" represents at least 2 16-bit groups of ; zeros. No more than 4 groups in addition to the ; "::" and IPv4-address-literal may be present.
It should say:
IPv6-full = IPv6-hex 7(":" IPv6-hex) IPv6-comp = "::" [IPv6-hex *6(":" IPv6-hex)] | IPv6-hex "::" [IPv6-hex *5(":" IPv6-hex)] | IPv6-hex 1(":" IPv6-hex) "::" [IPv6-hex *4(":" IPv6-hex)] | IPv6-hex 2(":" IPv6-hex) "::" [IPv6-hex *3(":" IPv6-hex)] | IPv6-hex 3(":" IPv6-hex) "::" [IPv6-hex *2(":" IPv6-hex)] | IPv6-hex 4(":" IPv6-hex) "::" [IPv6-hex *1(":" IPv6-hex)] | IPv6-hex 5(":" IPv6-hex) "::" [IPv6-hex] | IPv6-hex 6(":" IPv6-hex) "::" ; The "::" represents at least one 16-bit groups of ; zeros. No more than 7 groups in addition to the ; "::" may be present. IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal IPv6v4-comp = ("::" [IPv6-hex *4(":" IPv6-hex) ":"] | IPv6-hex "::" [IPv6-hex *3(":" IPv6-hex) ":"] | IPv6-hex 1(":" IPv6-hex) "::" [IPv6-hex *2(":" IPv6-hex) ":"] | IPv6-hex 2(":" IPv6-hex) "::" [IPv6-hex *1(":" IPv6-hex) ":"] | IPv6-hex 3(":" IPv6-hex) "::" [IPv6-hex ":"] | IPv6-hex 4(":" IPv6-hex) "::") IPv4-address-literal ; The "::" represents at least one 16-bit groups of ; zeros. No more than 5 groups in addition to the ; "::" and IPv4-address-literal may be present.
Notes:
I had the same impression that Michael Rushton (Errata 2467).
Searching about what says the others RFCs ([RFC 3986] , [RFC 4291] , [RFC 5952]), I believe that Michael Rushton's affirmative may be right.
Case 1 - Section 3.2.2 of [RFC 3986] says:
"(...) A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision." (sic).
Transcription of Section 3.2.2 of [RFC 3986]
"(...)
A 128-bit IPv6 address is divided into eight 16-bit pieces. Each piece is represented numerically in case-insensitive hexadecimal, using one to four hexadecimal digits (leading zeroes are permitted). The eight encoded pieces are given most-significant first, separated by colon characters. Optionally, the least-significant two pieces may instead be represented in IPv4 address textual format. A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision.
(...)"
Case 2 - Section 2.2 of [RFC 4291] says:
"(...) The use of "::" indicates one or more groups of 16 bits of zeros. (...)" (sic).
Transcription of Item 2, Section 2.2 of [RFC 4291]
"2. Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain long strings of zero bits. In order to make writing addresses containing zero bits easier, a special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress leading or trailing zeros in an address.
(...)"
Case 3 - Recommendations of [RFC 5952]
In reply to the question of Errata 2467, was quoted the words of Section 4.2.2 of [RFC 5952], that recommends:
"The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct." (sic).
But the Section 4 of the same RFC, says:
"(...) The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format."
Transcription of Section 4 and 4.2.2 of [RFC 5952]
"4. A Recommendation for IPv6 Text Representation
A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. It is advised that humans also follow these recommendations when spelling an address.
(...)
4.2.2. Handling One 16-Bit 0 Field
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.
(...)"
Therefore, it is clear that the intent of what was said in Section 4.2.2 only serves to standardize the generation and not to interpretation of a IPv6 representation.
For more explanations see:
RFC 4291 - Errata 2702, 2735 and 2466
http://www.rfc-editor.org/errata_search.php?rfc=4291
RFC 4291 - Errata 2735 discussion
http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html
[RFC 3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC 4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC 5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
===== Verifier notes =====
The text in 5321 was correct at the time of publication, according to advice from the IPv6 folks. This was, of course, well before 5952 came out. This report has been noted in the notes for a future 5321bis document.
Errata ID: 5414
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Romerstein
Date Reported: 2018-06-29
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13
Section 4.1.2 says:
Quoted-string = DQUOTE *QcontentSMTP DQUOTE
It should say:
Quoted-string = DQUOTE 1*QcontentSMTP DQUOTE
Notes:
As written, this allows for an email envelope recipient (Forward-path) with a NULL value for the local part of their address. This is a functional departure from similar wording in the preceding RFC 821, which defines quoted-string in such a way as to require at least one character that is not one of the surrounding quotation marks.
Errata ID: 1851
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2009-09-08
Held for Document Update by: Pete Resnick
Section 4.1.1.5. says:
There are circumstances, contrary to the intent of this specification, in which an SMTP server may receive an indication that the underlying TCP connection has been closed or reset. To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared.
Notes:
That text seems inappropriate in the RESET (RSET) section. It should presumably be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to section 3.8. Terminating Sessions and Connections.
Errata ID: 3447
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrien de Croy
Date Reported: 2013-01-07
Held for Document Update by: Barry Leiba
Date Held: 2013-01-09
Section 4.4 says:
When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. ... SMTP servers performing a relay function MUST NOT inspect the message data ... For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
It should say:
When the delivery SMTP server makes the "final delivery" of a message, it MUST insert a return-path line at the beginning of the mail data. For this to be unambiguous, exactly one return path MUST be present when the message is delivered.
Notes:
There are contradictory and ambiguous statements in this section. Return-path is classified in 5322 as optional. It's not 100% clear in the original text whether the server MUST prepend the return-path header or not.
Do we really want to prohibit inspection by relays in this section? I would imagine this MUST level requirement is routinely ignored anyway.
Alternatively, we decide that Return-path is truly optional and change the first sentence to make that clear instead of the strongly implied MUST.
--- VERIFIER NOTES ---
This erratum would normally meet the criteria for "Rejected", but
it points out that as it currently stands, RFC 5321 is in need of
some work, perhaps in the process of advancing it on the Standards
Track to Internet Standard. The erratum raises some issues, which
I'll note here:
1. RFC 5321 uses the capitalized key words from RFC 2119 only sparingly,
and much of the normative language in the document is written in plain
English ("the server does this", rather than "the server MUST do this").
This is by intent, and is certainly not an error in the document, but
some people find it less clear.
2. While RFC 5321 and RFC 5322 go hand in hand for most of us most of
the time, they are quite separable. RFC 5321 can be used to transfer
data that does not conform to the format in RFC 5322, and message stores
can contain messages in RFC 5322 format that were not put there via
SMTP (RFC 5321). As a result, there are sometimes things that seem
contradictory between the two documents, if one is not aware of this
situation.
3. RFC 5321 specifies a protocol that we know is not fully followed
everywhere. That there are known variants does not mean that we should
define the protocol any less rigorously, and the claim that a requirement
of the protocol is "routinely ignored" may well be true, but is not
relevant to how the protocol is defined.
All that said, the points need to be considered when a revision of
RFC 5321 is taken on, and I'm marking this as "Held for Document Update"
so that it will be staring us in the face is and when that happens.
Errata ID: 5711
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Guillaume Fortin-Debigaré
Date Reported: 2019-04-29
Held for Document Update by: Barry Leiba
Date Held: 2019-11-13
Section D.3 says:
C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John.
It should say:
C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John.
Notes:
Since step 1 and step 2 are transmitting the same message, the relay host should not change its body.
The previous version of this document, RFC 2821, had the "John." signature centered by padding spaces before it on both steps, not just step 2.
Status: Rejected (6)
RFC 5321, "Simple Mail Transfer Protocol", October 2008
Note: This RFC has been updated by RFC 7504
Source of RFC: IETF - NON WORKING GROUPArea Assignment: art
Errata ID: 4055
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dave Crocker
Date Reported: 2014-07-19
Rejected by: Barry Leiba
Date Rejected: 2014-07-19
Section 3.6.2 says:
This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message.
It should say:
This specification does not deal with the verification of return paths for use in delivery notifications.
Notes:
Neither SPF nor DKIM determine "validity" of an address. SPF determines whether an IP Address is 'authorized' to send mail with a particular domain name in the return address, but that does not validate the entire address, nevermind validating any destination or author addresses. DKIM has nothing at all to do with any existing address or domain name elsewhere in the message.
So I suggest merely dropping the problematic sentence.
--VERIFIER NOTES--
This is a change request, not an errata report.
Errata ID: 4079
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sergey Afonin
Date Reported: 2014-08-12
Rejected by: Pete Resnick
Date Rejected: 2014-09-29
Section 4.3.2. says:
DATA I: 354 -> data -> S: 250 E: 552, 554, 451, 452 E: 450, 550 (rejections for policy reasons) E: 503, 554
It should say:
DATA I: 354 -> data -> S: 250 E: 552, 554, 451, 452 E: 450, 550 (rejections for policy reasons) E: 451, 503, 554
Notes:
"E: 451" after DATA exists in section 4.3.2 of RFC 2821:
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
--VERIFIER NOTES--
As discussed with the reporter: As far as we can tell, it was the intention to remove 451 in the transition from 2821 to 5321. This is not an error in the document. Error codes can be used by extensions without an update to 5321.
Errata ID: 4265
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Vance Kochenderfer
Date Reported: 2015-02-07
Rejected by: Barry Leiba
Date Rejected: 2015-03-01
Section F.2 says:
SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address.
It should say:
SMTP servers MUST continue to accept source route syntax within RFC 5322 headers as specified in the main body of this document and in RFC 1123. They SHOULD ignore source routes specified in envelope addresses and utilize only the target domain, or MAY decline to accept envelope addresses that specify source routes.
Notes:
The current wording of Section F.2 appears to contradict Sections 3.3 and 3.6.1.
Section 3.3 states: "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."
Section 3.6.1 states: "SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes."
RFC 1123 contains *two* separate relevant requirements: Section 5.2.6 states "A receiver-SMTP MUST accept the explicit source route syntax in the envelope..." and Section 5.2.19 states "Internet host software SHOULD NOT create an RFC-822 header containing an address with an explicit source route, but MUST accept such headers for compatibility with earlier systems."
It appears that Sections 3.3 and 3.6.1 are intended to remove the requirement to accept source route syntax within envelope addresses, but the current wording of Section F.2 contradicts this. If the intent of Section F.2 is only to continue the requirement to accept source route syntax within message headers, this should be made clear. The proposed text is written with this assumption in mind. If the intent of RFC 5321 is to remove both requirements, the proposed wording for Section F.2 requires further revision.
Also, if the intent of Sections 3.3 and 3.6.1 is to treat source routing differently for a <forward-path> and <reverse-path>, this should be clarified in all three sections. The proposed text assumes the requirements for both are the same.
--VERIFIER NOTES--
The text as it is, is what was intended. Moreover, this is another step along the way toward the deprecation of source routes, a path we started on a good many years ago. John Klensin is taking input for his working copy of a 5321bis, if specific text changes are suggested.
Errata ID: 6561
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Seiichi Hamada
Date Reported: 2021-04-27
Rejected by: Francesca Palombini
Date Rejected: 2022-03-25
Section 4.1.2. says:
Domain = sub-domain *("." sub-domain)
It should say:
Domain = sub-domain *("." sub-domain)[.]
Notes:
RFC-1034 section 3.1 say " Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot." and also say 'a character string which represents a complete domain name (often called "absolute"). For example, "poneria.ISI.EDU." '.
It is necessary to allow a dot at the end of the domain name.
--VERIFIER NOTES--
As reported by John C Klensin in https://mailarchive.ietf.org/arch/msg/iesg/sAzZQpgOkD75eKQiS-RlWrmPhDk/ : The syntax used in SMTP predates RFC 1034. This possible change was discussed in the DRUMS WG when RFC 2821 was being assembled and rejected as likely to cause harm with existing implementations. If he recalls, that topic was revisited in the YAM WG that developed RFC 5321 with the conclusion to not reopen it.
So it is a substantive matter and not an editorial change and hence, as an erratum, it is rejected.
Errata ID: 2467
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Rushton
Date Reported: 2010-08-16
Rejected by: Pete Resnick
Date Rejected: 2011-06-11
Section 4.1.3 says:
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" IPv6-hex)] ; The "::" represents at least 2 16-bit groups of ; zeros. No more than 6 groups in addition to the ; "::" may be present. IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal ; The "::" represents at least 2 16-bit groups of ; zeros. No more than 4 groups in addition to the ; "::" and IPv4-address-literal may be present.
It should say:
IPv6-comp = [IPv6-hex *6(":" IPv6-hex)] "::" [IPv6-hex *6(":" IPv6-hex)] ; The "::" represents at least 1 16-bit groups of ; zeros. No more than 7 groups in addition to the ; "::" may be present. IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal IPv6v4-comp = [IPv6-hex *4(":" IPv6-hex)] "::" [IPv6-hex *4(":" IPv6-hex) ":"] IPv4-address-literal ; The "::" represents at least 1 16-bit groups of ; zeros. No more than 5 groups in addition to the ; "::" and IPv4-address-literal may be present.
Notes:
As per RFC 4291 and RFC 3986, "::" can represent a single 16-bit group of zeroes.
--VERIFIER NOTES--
As per RFC 5952:
4.2.2. Handling One 16-Bit 0 Field
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.
Errata ID: 1820
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2009-07-30
Rejected by: Lisa Dusseault
Date Rejected: 2009-07-31
Section 3.9.2 says:
A mailing list may be said to operate by "redistribution" rather than by "forwarding". [...] Note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case. [...]
It should say:
A mailing list may be said to operate by "redistribution" rather than by "forwarding". [...] Note that the key difference between handling aliases (Section 3.9.1) and lists (this subsection) is the change to the backward-pointing address in this case. [...]
Notes:
The change replaces the second occurrence of "forwarding" with "lists" in the first paragraph of section 3.9.2.
The term "forwarding" is generally used as a synonym of transmitting as opposed to delivering locally. The beginning of this section attempts to introduce the term "redistribution" for the specific type of transmission described therein. The phrase where the change is necessary, in its original wording, contradicts both the first phrase in its own paragraph, and the last phrase of the preceding section about aliases, which says that handling aliases may result in forwarding.
--VERIFIER NOTES--
This should be taken up with the group revising SMTP. The language chosen was intentional, so a fix is not as simple as an errata.