Re: [exim] Spam using a space to separate message body and h…

Top Page
Delete this message
Reply to this message
Author: Exim User's Mailing List
Date:  
To: Exim User's Mailing List
Subject: Re: [exim] Spam using a space to separate message body and header...
Eric Bullen wrote:
> Attached is a email I just received that shows the problem I was speaking
> of. At the end of the email- Exim added a "X-FromHost:" header line to the
> message. I am running Exim 4.52.
>
> The MD5 of the attachment is: b4fe082a6ba2d756a1205662bcda2a86
>
> Thanks for everyone's help in this.
>
> -Eric


Very amusing. I've never gone into the source code, however, my understanding
is that a a header is considered part of the previous line if it starts with a
space. This is how we can get multi-line headers. The entire body of this
message is prefixed with a space so it may all be considered part of the
Content-Transfer-Encoding header. I would have thought a blank line would have
stopped that though.

To the RFC's!

<quote> <!-- slightly snipped -->
RFC2822 - Internet Message Format
2.2.3. Long Header Fields

Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a multiple
line representation; this is called "folding". The general rule is

that wherever this standard allows for folding white space (not
simply WSP characters), a CRLF may be inserted before any WSP.
example, the header field:

Subject: This
is a test
</quote>

But that doesn't talk about blank lines anywhere.

<quote>
3.2.3. Folding white space and comments

White space characters, including white space used in folding
(described in section 2.2.3), may appear between many elements in
header field bodies. Also, strings of characters that are treated as
comments may be included in structured field bodies as characters
enclosed in parentheses. The following defines the folding white
space (FWS) and comment constructs.
[snip]
There are several places in this standard where comments and FWS may
be freely inserted. To accommodate that syntax, an additional token
for "CFWS" is defined for places where comments and/or FWS can occur.
However, where CFWS occurs in this standard, it MUST NOT be inserted
in such a way that any line of a folded header field is made up
entirely of WSP characters and nothing else.
[snip]
Throughout this standard, where FWS (the folding white space token)
appears, it indicates a place where header folding, as discussed in
section 2.2.3, may take place. Wherever header folding appears in a
message (that is, a header field body containing a CRLF followed by
any WSP), header unfolding (removal of the CRLF) is performed before
any further lexical analysis is performed on that header field
according to this standard. That is to say, any CRLF that appears in
FWS is semantically "invisible."
</quote>

So.. if I'm reading this right (gee this almost reminds me of reading a
bible.. hope there aren't any RFC fanatics out there.. that idea brings some
really strange images to mind of computer geeks bashing the plebbs over the
head with bundled RFC's).. er ok.

So, if I'm reading this right, the entire rest of the message will be
considered part of the header because there's a WSP character followed by a
CRLF. When unfolding occurs, the header absorbs the rest of the email and
there's nothing left. Exim is in the right to stick the header at the bottom
of the headers and whoever wrote this particular spam program is an idiot.

Why do you want the message anyway? Train up the spam filtering and dump it.

Ted.