errata logo graphic

Found 10 records.

Status: Verified (2)

RFC5321, "Simple Mail Transfer Protocol", October 2008

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

Errata ID: 1683

Status: Verified
Type: Technical

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: 1683

Status: Verified
Type: Technical

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.


Status: Reported (6)

RFC5321, "Simple Mail Transfer Protocol", October 2008

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

Errata ID: 1543

Status: Reported
Type: Technical

Reported By: Brett Watson
Date Reported: 2008-10-08

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: 1543

Status: Reported
Type: Technical

Reported By: Brett Watson
Date Reported: 2008-10-08

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: 2467

Status: Reported
Type: Editorial

Reported By: Michael Rushton
Date Reported: 2010-08-16

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.


Errata ID: 1851

Status: Reported
Type: Editorial

Reported By: Alessandro Vesely
Date Reported: 2009-09-08

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: 2467

Status: Reported
Type: Editorial

Reported By: Michael Rushton
Date Reported: 2010-08-16

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.


Errata ID: 1851

Status: Reported
Type: Editorial

Reported By: Alessandro Vesely
Date Reported: 2009-09-08

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.


Status: Rejected (2)

RFC5321, "Simple Mail Transfer Protocol", October 2008

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

Errata ID: 1820

Status: Rejected
Type: Editorial

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.


Errata ID: 1820

Status: Rejected
Type: Editorial

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.