Re: Malformed header - what would you do?

On Tue July 19 2005 20:04, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > extension/user-defined (unlike 822, 2822 does not officially
> > distinguish the two distinct types) fields must conform to
> > the unstructured field restrictions on syntax, and that would
> > include the restriction on whitespace-only header lines.
> 
> Where do you see this in 2822 ?

2.2. Header Fields

   Header fields are lines composed of 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.  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 of this standard.
[...]
3.6.8. Optional fields

   Fields may appear in messages that are otherwise unspecified in this
   standard.  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.

   The field names of any optional-field MUST NOT be identical to any
   field name specified elsewhere in this standard.

optional-field  =       field-name ":" unstructured CRLF

field-name      =       1*ftext

ftext           =       %d33-57 /               ; Any character except
                        %d59-126                ;  controls, SP, and
                                                ;  ":".

   For the purposes of this standard, any optional field is
   uninterpreted.

And in Appendix B:

   13. Folding continuation lines cannot contain only white space.*

The Appendix B text clearly identifies the problem which is the subject
of the current discussion.

Note that CFWS is:
CFWS            =       *([FWS] comment) (([FWS] comment) / FWS)
and need not contain a comment; it can consist of FWS alone.

> I found...  
> 
> | unstructured    =       *([FWS] utext) [FWS]
> 
> ...and that allows a trailing FWS.  It should be *WSP to avoid
> a whitespace-only header line.  The "MUST NOT" for CFWS isn't
> good enough, <unstructured> has no CFWS.

The 2822 grammar as written does not correspond to the prose specifying
no continuation lines containing only whitespace.  The "simplified"
ABNF discussed here more than a year ago does prohibit whitespace-only
continuation lines.

> >>> Is the software adding the 'X-SPAM-STATUS' line wrong
>  
> > Does the software claim conformance with RFC 2822?  If so, yes.
> 
> I'm not convinced.  But so far nobody supported a s/[FWS]/*WSP/
> cleanup in USEFOR.

USEFOR has no jurisdiction over RFC 2822.