From: Wietse Venema (wietseporcupine.org)
Date: Wed Sep 19 2007 - 08:47:14 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Victor Duchovni:
> On Tue, Sep 18, 2007 at 08:38:35PM -0700, Bill Landry wrote:
>
> > The problem I am experiencing with this is that when mail is sent via
> > SquirrelMail, it is sent as "Content-Transfer-Encoding: 8bit", however, it
> > appears that since the relay service is not announcing 8BITMIME, Postfix
> > is sending the message with "Content-Transfer-Encoding: quoted-printable".
> > And since the message has already been signed with both DK and DKIM,
> > and the "Content-Transfer-Encoding" is included in the signing as 8bit,
> > the signatures fail verification on the receiving end.
>
> IMHO, systems doing content signing, should first down-convert from 8-bit,
> to QP if necessary. It is not enough to not sign the CTE header, the
> downgrade radically changes the message content, so you cannot work around
> this quite so simply, nor is it a good idea to not sign MIME headers.
>
> As for Postfix, it currently believes "CTE: 8bit" without checking. In
> practice lots of content is labeled "8bit" that is actually entirely
> "7bit". While it would be unpleasant to implement a 2-pass algorithm and
> update misleading CTE headers, it is perhaps not unreasonable to update
> Postfix's final notion of the message encoding domain (7bit or 8bit)
> as the message streams by, and thus avoid unnecessary downgrades on
> delivery (delivery agents see the message after "cleanup", so they could
> benefit from information found by "cleanup" as it stores the message in
> the queue file).
>
> For efficiency, such scanning can be skipped for body parts with a "QP"
> or "base64" CTE (really anything other than 7bit or 8bit) because these
> must be 7bit and will not be downgraded even if they are not. So large
> base64 attachments should not impose a CPU penalty for inspecting the
> high bit of every octet.
>
> Is this reasonable?

Only if the workaround can be implemented without imposing an
unreasonable burden on Postfix itself. Reasonable means that the
workaround's impact is clearly confined to a small section of code.

Good examples are discard_ehlo_keywords and CISCO pix workarounds.
They don't change the over-all program flow. They enable/disable
little pieces of behavior without impacting other code.

A bad example is the "handle disconnect before sending end-of-data",
which works around appliances that don't implement RFC2821 correctly.
It changes error handling in a non-obvious manner. This complicates
further development, and if it can't be cleaned up, people should
not be surprised if at some point it is removed.

Postfix must not degenerate into an unmaintainable mess of workarounds.
It's better to omit a workaround than to gradually erode integrity.

        Wietse

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]