RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (4)

RFC 4954, "SMTP Service Extension for Authentication", July 2007

Note: This RFC has been updated by RFC 5248

Source of RFC: IETF - NON WORKING GROUP
Area 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.

Status: Reported (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 GROUP
Area Assignment: app

Errata ID: 5224
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bastian Schumacher
Date Reported: 2018-01-02

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 GROUP
Area 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 GROUP
Area 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.

Report New Errata



Advanced Search