RFC Errata
Found 7 records.
Status: Verified (5)
RFC 4954, "SMTP Service Extension for Authentication", July 2007
Note: This RFC has been updated by RFC 5248
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 1
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rob Siemborski
Date Reported: 2007-07-19
Section 4.1 says:
S: 220-smtp.example.com ESMTP Server
It should say:
S: 220 smtp.example.com ESMTP Server
Notes:
There are 3 instances of this (one on p. 7 and two on p. 8).
Errata ID: 1021
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Verifier Name: Alexey Melnikov
Date Verified: 2007-08-25
Section 5 says:
Note:
For the purposes of this discussion, "authenticated identity"
refers to the identity (if any) derived from the authorization
| identity of previous AUTH command, while the terms "authorized
identity" and "supplied <mailbox>" refer to the sender identity
that is being associated with a particular message.
It should say:
Note:
For the purposes of this discussion, "authenticated identity"
refers to the identity (if any) derived from the authorization
| identity of the previous AUTH command, while the terms
"authorized identity" and "supplied <mailbox>" refer to the
sender identity that is being associated with a particular
message.
Notes:
missing article
from pending
Errata ID: 1022
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Verifier Name: Alexey Melnikov
Date Verified: 2007-08-25
Section 9 says:
Additional security considerations for [PLAIN] over | [TLS] are mentioned in Section 15 of this document.
It should say:
Additional security considerations for [PLAIN] over | [TLS] are mentioned in Section 14 of this document.
Notes:
wrong document-internal reference
from pending
Errata ID: 4015
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey 'jf' Lim
Date Reported: 2014-06-15
Verifier Name: Barry Leiba
Date Verified: 2014-07-01
Section 4 says:
See also Section 15 for additional requirements on implementations of [PLAIN] over [TLS].
It should say:
See also Section 14 for additional requirements on implementations of [PLAIN] over [TLS].
Notes:
----- Verifier Notes -----
This happened when the RFC Editor moved the authors' addresses out of numbered section 13, and caused the subsequent sections to be renumbered. We missed the internal reference.
Errata ID: 5224
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bastian Schumacher
Date Reported: 2018-01-02
Verifier Name: Orie Steele
Date Verified: 2024-04-01
Section 4 says:
If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in Section 5.1 of [SASL]. [...] If use of the initial response argument would cause the AUTH command to exceed this length, the client MUST NOT use the initial response parameter (and instead proceed as defined in Section 5.1 of [SASL]).
It should say:
If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in Section 5.1 of [RFC 2222]. [...] If use of the initial response argument would cause the AUTH command to exceed this length, the client MUST NOT use the initial response parameter (and instead proceed as defined in Section 5.1 of [RFC 2222]).
Notes:
[SASL] points to RFC 4422 that does not contain a Section 5.1.
So the Original text leads to confusion. The referenced Text can be found in RFC 2222 instead.
Status: Held for Document Update (1)
RFC 4954, "SMTP Service Extension for Authentication", July 2007
Note: This RFC has been updated by RFC 5248
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 1019
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Held for Document Update by: Alexey Melnikov
Section 1 says:
| When compared to RFC 2554, this document deprecates use of the 538 response code, adds a new Enhanced Status Code, adds a requirement to | support SASLprep profile for preparing authorization identities, | recommends use of RFC 3848 transmission types in the Received trace | header field, and clarifies interaction with SMTP PIPELINING [PIPELINING] extension.
It should say:
| When compared to RFC 2554, this document deprecates the use of the 538 response code, adds a new Enhanced Status Code, adds a | requirement to support the SASLprep profile for preparing | authorization identities, recommends the use of RFC 3848 transmission | types in the Received trace header field, and clarifies the | interaction with the SMTP PIPELINING [PIPELINING] extension.
Notes:
missing articles
Status: Rejected (1)
RFC 4954, "SMTP Service Extension for Authentication", July 2007
Note: This RFC has been updated by RFC 5248
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 1020
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-25
Rejected by: Alexey Melnikov
Date Rejected: 2007-08-25
Section 9 says:
(4) Section 9 -- distorted sentence The 4th paragraph of Section 9, on mid-page 14, says: [...] The AUTH=<> parameter prevents such an attack from causing a relayed | message and, in the absence of other envelope authentication, from | picking up the authentication of the relay client. IMHO, this sentence is distorted and potentially misleading. The RFC should perhaps better say: [...] The AUTH=<> parameter prevents such an attack from causing a relayed | message, in the absence of other envelope authentication, to pick up the authentication of the relay client. This is essentially what RFC 2554 said in this place, and which makes much more sense to me.
It should say:
-
Notes:
---VERIFIER NOTE---
I tend to disagree in this case. The "and" was certainly missing in the original text. I also think the new version is more readable.