errata logo graphic

Found 9 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: 2578

Status: Verified
Type: Editorial

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 (3)

RFC5321, "Simple Mail Transfer Protocol", October 2008

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

Errata ID: 1543

Status: Held for Document Update
Type: Technical

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

Status: Held for Document Update
Type: Editorial

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

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.


Status: Rejected (4)

RFC5321, "Simple Mail Transfer Protocol", October 2008

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

Errata ID: 4055

Status: Rejected
Type: Technical

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

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

Status: Rejected
Type: Editorial

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

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.


Report New Errata