errata logo graphic

Found 6 records.

Status: Verified (4)

RFC4954, "SMTP Service Extension for Authentication", July 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1

Status: Verified
Type: Editorial

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

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

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

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: Held for Document Update (1)

RFC4954, "SMTP Service Extension for Authentication", July 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1019

Status: Held for Document Update
Type: Editorial

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)

RFC4954, "SMTP Service Extension for Authentication", July 2007

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1020

Status: Rejected
Type: Editorial

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