From: Wietse Venema (wietseporcupine.org)
Date: Wed Sep 19 2007 - 11:11:07 CDT

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

Victor Duchovni:
> On Wed, Sep 19, 2007 at 09:47:14AM -0400, Wietse Venema wrote:
>
> > > 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.
>
> I take that as a very qualified yes. The code in question would I think be
> confined to the mime_state engine, which given a new flag (optionally, but
> by default enabled in cleanup) would look for "true" 8bit octets in the
> bodies of MIME entities with a CTE of "8bit". If no such octets are found,
> the message-level encoding is 7bit, even if the sender (via BODY=8BITMIME
> in MAIL FROM:) or CTE headers in one or more non-composite MIME parts
> signaled possible 8bit content.

I forgot to mention performance - if a workaround impacts performance,
then it should not be enabled by default.

> This is somewhat comparable in cost to a regexp check on each line of
> body content, except that base64 and QP content is always uninspected
> (cheaper) while 8bit content is inspected in its entirety (not just the
> first $body_checks_size_limit octets, more expensive).

Postfix by default disables features such as header/body_checks,
8strict_8bitmime, message_strip_characters, message_reject_characters
and so on because they increase the cost of handling mail for
everyone.

        Wietse

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