Re: Malformed header - what would you do?

Paul Smith <[email protected]> wrote:
 
> Our software treats that line as a continuation of the 'X-SPAM-STATUS' 
> line, but Outlook Express treats it as the end of the message header.

Your software is correct, and the Microsoft software is incorrect.

RFC-822 (now 23 years old) makes it perfectly clear that a field always
ends with a CRLF, and the header is separated from the body by a CRLF,
implying that there is a completely empty line between the header and
body.

     field       =  field-name ":" [ field-body ] CRLF
     message     =  fields *( CRLF *text )       ; Everything after
                                                 ;  first null line
                                                 ;  is message body

The spec is not completely rigorous, because there is no rule that says
that "fields" is a sequence of "field", but the null-line separator is
clarified in prose:

    A message consists of header fields and, optionally, a body.  The
    body is simply a sequence of lines containing ASCII characters.  It
    is separated from the headers by a null line (i.e., a line with
    nothing preceding the CRLF).

> Part of me says that we should make our software send a 25kV surge    
> down the line to fry the computer which was adding the superfluous    
> tab character,                                                        
>
> Is the software adding the 'X-SPAM-STATUS' line wrong (ie is it
> allowed to have FWS at the end of a line and put a CRLF before that
> final FWS)?

That software is wrong according to RFC-2822, which is only four years
old.  It forbids the creation of messages containing whitespace-only
lines in the header, but still requires all parsers to handle them
properly, because they were valid under RFC-822.

> What would you do?  Is our software wrong?

Your software is not wrong to simply add a header field.  One thing
you might consider is to first repair the header by removing all
whitespace-only lines, or just whitespace-only lines at the end of the
header, if that's easier.  In general, mucking with somebody else's
headers is a no-no and is dangerous, but this would just be a form of
refolding (which is supposed to be safe) for the purpose of making the
message more conformant to RFC-2822, so it's probably justifiable (in my
opinion).

AMC