Dear
Matt:
>> it would be a
bug in Declude to behave in this way <<
You
may be right - but I'm not that certain about that being a bug (unless you
expect Declude to perform a "syntax check" of these user
headers).
RFC822
states:
3.1.1. LONG HEADER
FIELDS
Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called "folding". The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may instead be inserted. In
other words, as long as CRLF is followed by a SPACE in the new line, the line
X-Spam-Tests-Failed Weight
would
have to be treated as a conintuation of the PRIOR header
field.
However, in the absence of:
a) a
leading space,
b) a
valid header field name
it
might actually be PROPER to err on the side of safety and consider this the
"end" of the headers.
After
all, we don't want to create a vulnerability where someone could insert
"data" into the header that Outlook might skip...
Best
Regards
|
Title: Message
- RE: [Declude.JunkMail] Something new with v 2.0.... Andy Schmidt
- RE: [Declude.JunkMail] Something new with v... Nick
- RE: [Declude.JunkMail] Something new with v... Andy Schmidt
- Re: [Declude.JunkMail] Something new with v... Frederick Samarelli
- [Declude.JunkMail] Still can't install ... S.J.Stanaitis
- Re: [Declude.JunkMail] Still can't ... S.J.Stanaitis
- RE: [Declude.JunkMail] Still can't ... John Tolmachoff \(Lists\)