Authenticated sender header is mangled

[Florian Effenberger]

Normally, my Postfix SMTPD creates a header like this:

Received: from [192.168.x.y] (myhost.dip0.t-ipconnect.de [91.45.x.y])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 (Authenticated sender: myuser)
 by myhost.mymail.org (Postfix) with ESMTP id 91D31E10010
 for <email address hidden>; Mon, 17 Nov 2008 16:11:48 +0100 (CET)

As soon as Mailman is involved, it seems the "Authenticated sender" line gets mangled, a line break is removed:

 Received: from [192.168.x.y] (myhost.dip0.t-ipconnect.de [91.45.x.y])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested) (Authenticated sender: myuser)
 by myhost.mymail.org (Postfix) with ESMTP id 91D31E10010
 for <email address hidden>; Mon, 17 Nov 2008 16:11:48 +0100 (CET)

[Mark Sapiro (msapiro)]

Headers are logically a single line. In order to comply with line length requirements, headers may be "folded" for transmission over the wire by inserting <CRLF> preceding certain whitespace in the header. Headers are unfolded by the recipient by removing <CRLF> immediately preceding whitespace. See Section 2.2.3 of RFC 2822 <http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=2822&type=http&file_format=txt>.

Thus, if the second header example above actually has the Received: line not indented, but the remaining lines indented, the two headers are logically identical and the fact that the first one has a line break following "(No client certificate requested)" and the second doesn't should be irrelevant.

Does this difference in folding of the two headers actually cause a problem?

[Florian Effenberger (floeff)]

Thanks for the explanation! I'm not sure if this causes a problem, but I can think of two cases:

- signed e-mails (like DKIM), when the signing actually gets broken
- self-written filters that look for a string at the beginning of a line

I'm not sure whether this is actually an issue, but thought I report it nontheless.

[Florian Effenberger (floeff)]

As an example: SpamAssassin checks this header to avoid some false-tagging of spam. See http://wiki.apache.org/spamassassin/DynablockIssues

[Mark Sapiro (msapiro)]

I can't find a reference off hand, but I'm certain that spamassassin header checks match against the unfolded, logical header.

Signatures are an issue with email lists in general because of modifying Subject: headers, adding "headers" and/or "footers" to message bodies, etc, but DKIM can't be signing Received: headers that are added after the mail is signed. Mail list breaking of signatures is a much broader issue than can be addressed in this bug report.

Self written filters should be cognizant of RFCs and should be looking at unfolded headers and not relying on folding to occur at a particular place in the header.

[Florian Effenberger (floeff)]

I trust your experience. ;-) Thanks for letting me know.