-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDGQLCHTFM6KkFI5oRAvOBAKCbs04g9pbicJguRwVyfgS9PIHO9gCgpisY gRtcGmVNiiPCJbzomVZVpPk= =91AD -----END PGP SIGNATURE----- -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
