Re: What is the need for 8bit -> 7bit conversion in the newest opendkim?

From: A. Schulze <>
Date: Mon, 23 May 2016 21:00:48 +0200

Am 23.05.2016 um 15:51 schrieb
> Here on the Postfix list
> Howto avoid 8BITMIME

my post :-)

> there is discussion in Postfix the conversion is still needed before you DKIM
> sign
> Use a dummy SMTP-based after-queue content filter to force 8->7
> conversion, then DKIM sign the message with the smtpd+cleanup+milter
> after the filter.

the idea Wietse Venema pointed out is to deliver the message via content_filter mechanism.
In such setup postfix will deliver the message vi smtp to a smtp server supposed to do any content modification.
This content filter finally deliver the message back to postfix.

   postfix -> queue -> smtp-client -> content-filter smtp-server -> content-filter smtp-client -> postfix smtp server -> queue -> local/remote delivery

Wietse suggest a null content-filter:

   postfix queue -> -> smtp-client -> postfix smtp server -> queue -> local/remote delivery

Just while the postfix smtp client deliver the message it could be converted to 7 bit by postfix
and that's what such setup would be good for.

An other option is to enhance OpenDKIM (or an other milter) to
  - accept message header + body via milter interface
  - convert the message body to 7-Bit
  - create a DKIM signature
  - add the signature headers
  - instruct the MTA to replace the 8-Bit body with the 7-Bit version

There are concerns about doing this for each and every message.
It sounds good to do this only for destinations known to not support 8BITMIME.
The Internet-E-Mail system is HOP-by-HOP based. To ensure DKIM signatures are not broken by 8-Bit to 7-Bit conversions
any hop is required to support 8BITMIME. In fact no sender could assume this. So it would be best to convert any submitted message to 7-Bit.

Maybe somebody on this list is able to write a simple 8to7-Bit conversion milter
that may work in front of a DKIM signer.

Received on Mon May 23 2016 - 19:02:11 PST

This archive was generated by hypermail 2.3.0 : Mon May 23 2016 - 19:09:01 PST