[Mailman-Developers] CTE "base64" due to UTF-8?

[Michael Heydekamp]

Björn Vermo <bv at opera.no> wrote on 19.07.04:

> On 18 Jul 2004 15:55:00 +0200, Michael Heydekamp <my at freexp.de>
> wrote:

>> we are encountering the following "problem" with Mailman 2.1.3:

>> When a subscriber sends a message to one of our lists with an UTF-8
>> encoded body and CTE "8bit", Mailman obviously recodes the body from
>> "8bit" to "base64" before distributing the mail to the subscribers
>> of the respective list.

>> Although this is perfectly legal it does not really make sense and
>> also creates sometimes hassles for users with MUAs which have
>> difficulties with base64 encoded bodies.  A qp-encoding would IMO be
>> more appropriate for text/plain bodies, but I would prefer if
>> Mailman would not recode the body at all.

> Yes, I find it quite annoying when a listserver performs that type of
> recoding.

Thanks for the support. :)

> I find it even worse when it garbles the content because it does not
> sunderstand the encoding. This is mainly a problem with people who
> reply to digests.

In our case digesting is not involved at all and the recoded and
distributed mail is technically correct.  Nonetheless we don't want to
distribute base64 encoded bodies if the original mail was correctly
produced and sent as 8bit.

It's not clear to me if this behaviour is by design (which I doubt
because due to some reason we don't see it in our non-public admin
list).

If somebody would just answer how to avoid the recoding...

> I would prefer to have a configuration option where I could set the
> outgoing encoding to utf-8 with 8bit cte. Others may want to cater to
> special local needs. In any case, the digester needs to understand
> more about encoding. It cannot just pass everything through as now,
> since it is converting headers to body text.

I've never played with digests, but doesn't Mailman produce digests of
type "multipart/digest" with subparts of type "message/rfc822" (see
RFC2046)?


        Michael