Subject: Re: [ietf-dkim] Postfix: change of Content-Transfer-Encoding breaks DKIM signature / RFC recommendation

From: Florian Sager <[email-masked]>
Date: Wed, 25 Mar 2009 20:03:53 +0100

Hi,

no matter which process will be chosen next the following small
correction should be considered:

According to the mails below the RFC compliant change of content
encoding in MTA-forwarding may break signatures that follow the RFC 4871
recommendation to include header "Content-Transfer-Encoding" in the
signature. This header should be removed from section 5.5. Recommended
Signature Content (The following header fields SHOULD be included in the
signature ...).

Regards,
Florian

Wietse Venema schrieb:
> Florian Sager:
>   
>> Hi Wietse,
>>
>> I'd like to get your evaluation of the following aspect before
>> discussing this on the DKIM mailing list, maybe:
>>
>> In the context of testing DKM monitoring services in
>> http://www.dkim-reputation.org we experienced that postfix changed
>>
>> an incoming Content-Transfer-Encoding: 7bit
>> to
>> an outgoing Content-Transfer-Encoding: quoted-printable
>>     
>
> See RFC 1652 section 3.
>
> When sending 8BITMIME into a software that does not support 8BITMIME,
> the sending mail system must convert to 7bit or return the mail.
>
> You can turn this off in YOUR Postfix, but that really does not
> prevent other RFC-compliant mail systems from converting to 7bit.
>
> See also: http://www.postfix.org/FILTER_README.html section "
> Advanced content filter: sending unfiltered mail to the content
> filter" for how to avoid conversions with stupid content filters.
>
> 	Wietse
>
>   
>> The DKIM signature in the mail was broken afterwards, 'cause the Content-T
>> -ransfer-Encoding header was included like it's proposed in http://www.ietf.o
>> -rg/rfc/rfc4871.txt, 5.5.  Recommended Signature Content (The following heade
>> -r fields SHOULD be included in the signature ...).
>>
>> I guess that changes in the encoding are allowed in forwarding mail so the
>> - DKIM header inclusion recommendation might be erroneous?
>>
>> Regards,
>> Florian
>>
>>
>> ===
>>
>> Agitos Websolutions
>> Florian Sager, Bernhard Heindl und Christian Heindl GbR
>> Stifterstrasse 16, 83026 Rosenheim
>>
>> Telefon: 089/45867554
>> Telefax: 089/45867555
>> Support: [email-masked]
>> http://www.agitos.de
>>
>>
>>
>>     
>
>   

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Wed, 25 Mar 2009 17:10:23 -0400 (EDT)

> Signature Content (The following header fields SHOULD be included in the

Unfortunately, this does not solve the problem.  The 8bit-MIME to
7bit conversion as required(*) in RFC 1652 replaces the entire
message body, and therefore it invalidates DKIM signatures even
when the Content-Transfer-Encoding header is not signed.

Just like other MTAs that implement 8bit-MIME according to the rules,
the Postfix SMTP client has an option to ignore the rules and send
8bit-MIME anyway.

	Wietse

(*) Either convert the body, or return the message as undeliverable.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Florian Sager <[email-masked]>
Date: Wed, 25 Mar 2009 22:55:48 +0100

> when the Content-Transfer-Encoding header is not signed.
Well, I thought the canonicalization would reduce the encoding problems
but I didn't check this.
I expect if a redesign of DKIM would take place an improved
canonicalization method could solve this problem?

Florian

---

From: SM <[email-masked]>
Date: Wed, 25 Mar 2009 15:13:49 -0700

Hi Florian,
>Signature Content (The following header fields SHOULD be included in the

Won't the change in content-transfer-encoding (not the header field) 
performed by an MTA affect the body part and by extension break the 
DKIM signature?

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 25 Mar 2009 23:11:43 -0000

>Well, I thought the canonicalization would reduce the encoding problems

This might be a good time to reread 4871.  It's not all that long.

>canonicalization method could solve this problem?

We discussed this and basically decided that no, we're not going to
try to understand MIME.  There's all sorts of stuff a helpful MTA
might do to a message, e.g., reorder the MIME parts, and any canonical
representation that tried to deal with them would be impossibly
complex.

If you want to maximize the chances that your signed message arrives
intact, downcode it to something in seven bits before you sign it.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Wed, 25 Mar 2009 19:19:38 -0400 (EDT)

> canonicalization method could solve this problem?

DKIM does NOT replace the message body. It either signs messages,
or it verifies DKIM signatures and if successful reports whose
signature it found. The latter however remains a point of some
controversy, so don't take my word for it.

	Wietse

---

From: Tony Hansen <[email-masked]>
Date: Wed, 25 Mar 2009 21:21:38 -0400

A change of Content-Transfer-Encoding (CTE) will always be accompanied
with a change in the body content associated with that MIME section. The
change in the body content will break the signature just as much as the
change to the header. So removing CTE from the list of headers that are
signed will be ineffective.

	Tony Hansen
	[email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 26 Mar 2009 11:10:35 -0000

> canonicalization method could solve this problem?

Indeed, I pointed this out when I first joined this list, but it was too
late for inclusion in our draft at that time (though the Chair did suggest
I should write up a draft for an enhancement, and it could indeed be done
if/when we do a full -bis).

There are details of my canonicalization at
http://www.cs.man.ac.uk/~chl/uncode/uncode.html

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html