RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (6)

RFC 5322, "Internet Message Format", October 2008

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

Errata ID: 1905
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Wolf Lammen
Date Reported: 2009-10-09
Verifier Name: Pete Resnick
Date Verified: 2011-06-11

Section 4.1 says:

   obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)

It should say:

   obs-unstruct    =   *( (*CR 1*(obs-utext / FWS)) / 1*LF ) *CR

Notes:

It looks to me, as if the rule for obs-unstruct matches any US_ASCII character sequence, and is, hence, either overly complicated, or simply wrong. For example: CR LF 'A' is matched by the original rule (loop matches CR first, then LF 'A'). If I understand the accompaying text right, the intention was to allow for reversed sequences LF CR, as well as bare CR and LF sequences, but strictly forbid any occurrence of CR LF (in that order). This would be expressed by my rule, that basically states that any sequence of CR either is at the end, or is followed by a non-LF, or an FWS

[Alexey: removed unchanged ABNF rules, corrected an obvious error in the description of the change.]

Errata ID: 1908
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Wolf Lammen
Date Reported: 2009-10-11
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24

Section 4.2 says:

   In the obsolete syntax, any amount of folding white space MAY be
   inserted where the obs-FWS rule is allowed.  This creates the
   possibility of having two consecutive "folds" in a line, and
   therefore the possibility that a line which makes up a folded header
   field could be composed entirely of white space.

   obs-FWS         =   1*WSP *(CRLF 1*WSP)

It should say:

   In the obsolete syntax, any amount of folding white space MAY be
   inserted where the obs-FWS rule is allowed.  This creates the
   possibility of having two consecutive "folds" in a line, and
   therefore the possibility that a line which makes up a folded header
   field could be composed entirely of white space.

   obs-FWS         =   1*([CRLF] WSP)

Notes:

If I understand the relevant portions of RFC 822 right (notably section 3.1.1
["The general rule is that wherever there may be linear-white-space...
a CRLF followed by ... LWSP-char(s) may instead be inserted"], along with
section 3.1.4, section 3.3), it is permitted to extend a phrase
atom SPACE atom
by inserting linear-white-space (CRLF SPACE CRLF SPACE) instead, yielding:
atom CRLF SPACE CRLF SPACE atom
However, this is not recognized by the rules of RFC 5322, because the new
syntax forbids consecutive foldings, whereas obs-FWS requires a leading
white-space character at the beginning.

Errata ID: 3979
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Occil
Date Reported: 2014-04-30
Verifier Name: Pete Resnick
Date Verified: 2014-04-30

Section 3.6.7; 4.5.7 says:

received        =   "Received:" *received-token ";" date-time CRLF

obs-received    =   "Received" *WSP ":" *received-token CRLF

It should say:

received        =   "Received:" [1*received-token / CFWS]
                      ";" date-time CRLF

obs-received    =   "Received" *WSP ":" [1*received-token / CFWS] CRLF

Notes:

"The 'Received:' field contains a (possibly empty) list of tokens followed by a semicolon and a date-time specification." As it was originally written, though, whitespace and comments are disallowed right after the colon if the list of tokens is empty: for example, the header field "Received: ; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (with a space after the first colon) would be invalid according to the current spec; only "Received:; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (without a space) would be.

Verifier note: The erratum is clearly correct. There are other possible ABNF solutions, but the one above is sufficient to fix the problem.

Errata ID: 1766
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nick Levinson
Date Reported: 2009-04-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24

Section 3.4.1 says:

If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the quoted-
string form SHOULD NOT be used.

It should say:

If the
string can be represented as a dot-atom (that is, it contains no 
characters other than atext characters or one or more of "." 
surrounded by atext characters), then the dot-atom form SHOULD 
be used and the quoted-string form SHOULD NOT be used.

Notes:

Based on sec. 3.2.3 ("dot-atom = [CFWS] dot-atom-text [CFWS]" (brackets so in original) & "dot-atom-text = 1*atext *('.' 1*atext)") and on appx. A.1.2 (the example "john.q.public@example.com").

Errata ID: 2515
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Rushton
Date Reported: 2010-09-10
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section Appendix A.5 says:

From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>

It should say:

From: Pete(A nice \) chap) <pete@silly.test(his host)>

Notes:

Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."

Errata ID: 2579
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Dominic Sayers
Date Reported: 2010-10-18
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section Appendix A.5 says:

   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

It should say:

   To:A Group(Some people)
        :Chris Jones <c@public.example(Chris's host.)>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

Notes:

Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."

Status: Reported (2)

RFC 5322, "Internet Message Format", October 2008

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

Errata ID: 5918
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Marcus Bointon
Date Reported: 2019-11-26

Section 2.2 says:

Header fields are lines beginning with a field name, followed by a
   colon (":"), followed by a field body, and terminated by CRLF.  A
   field name MUST be composed of printable US-ASCII characters (i.e.,
   characters that have values between 33 and 126, inclusive), except
   colon.

Notes:

I'm reporting an omission rather than a correction. The description of field names in S2.2 does not describe any length limit, but it implicitly prohibits folding by not permitting WSP chars in the name. 3.6.8 defines an ABNF for field-name, but does not specify a length limit either.

As far as I can see this means that field names should be limited to 77 characters – the field name and a trailing : – after which the field body can start after FWS on the next line.

I suspect this will be open to some debate, so I'm not sure what to suggest as a correction beyond that. Nor do I know whether common clients & servers impose their own arbitrary limits on field names.

Errata ID: 6639
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Brennan Vincent
Date Reported: 2021-07-12

Section 3.3 says:

   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

It should say:

   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / [FWS] obs-zone

Notes:

The current syntax does not allow space before an obs-zone. Thus, it rejects header items like:

Date: Mon, 12 Jul 2021 18:32:01 GMT

which are still being produced today by, for example, mail(1) on FreeBSD.

Report New Errata