Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> 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
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
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
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