Bruce Lilly wrote:
Where do you see this in 2822 ?
| 2.2. Header Fields
[...]
| A field body may be composed of any US-ASCII characters,
| except for CR and LF. However, a field body may contain
| CRLF when used in header "folding" and "unfolding" as
| described in section 2.2.3. All field bodies MUST conform
| to the syntax described in sections 3 and 4
That doesn't talk about the trailing [FWS] in <unstructured>.
It's also not straight forward with the CR and LF as found in:
| obs-qp = "\" (%d0-127)
| obs-text = *LF *CR *(obs-char *LF *CR)
| 3.6.8. Optional fields
[...]
| They MUST conform to the syntax of an optional-field.
| This is a field name, made up of the printable US-ASCII
| characters except SP and colon, followed by a colon,
| followed by any text which conforms to unstructured.
That allows the trailing [FWS] in the X-SPAM header field (or
whatever its name was) reported by the OP.
| Appendix B:
| 13. Folding continuation lines cannot contain only white
| space.*
That's a list of _claimed_ differences from STD 11:
| Items marked with an asterisk (*) below are items which
| appear in section 4 of this document and therefore can no
| longer be generated.
Therefore point 13 is talking about obs-FWS, not trailing FWS:
| 4.2. Obsolete folding white space
|
| 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)
The trailing [FWS] in <unstructured> is erroneous, in RfC 2822
and in its numerous USEFOR children, starting with the USEFOR
incarnation of <unstructured>. Apparently RFC 2822 didn't want
it this way, but it forgot to say so explicitly.
And we're _copying_ this bug to USEFOR, I can't believe it. :-(
The Appendix B text clearly identifies the problem which is
the subject of the current discussion.
It addressses only obs-FWS as indicated by the (*). Example
A.6.3 illustrates the [CFWS] rule, the trailing [FWS] somehow
escaped in the wild - hard to find it, obs-FWS hides it almost
everywhere, it only affects <unstructured> in RfC 2822. But in
USEFOR it hits about ten header fields ending with [FWS] CRLF.
The 2822 grammar as written does not correspond to the prose
specifying no continuation lines containing only whitespace.
The prose is misleading. We are only guessing the intention
based on an unrelated example, an unrelated point in the list
of differences, and a related MUST NOT valid only for the CFWS.
No big issue for RfC 2822, it only affects X-header fields and
other unstructured header fields, but for USEFOR it's far more
serious.
so far nobody supported a s/[FWS]/*WSP/ cleanup in USEFOR.
USEFOR has no jurisdiction over RFC 2822.
Now that it's finally clear that the next step for RfC 2822
will be historic we can freely fix all bugs we find in USEFOR.
Bye, Frank