[leafnode-list] Re: Base64 coding in list messages

[Matthias Andree]

Whiskers schrieb:

>> Generally speaking, quoted-printable or base64 will usually happen
>> whenever umlauts are involved - or other characters that don't fit into
>> 7bit (I'm avoiding them in this message). In the message you sent it was
>> the German oe umlaut in the greeting that you had quoted from Torsten's
>> message.
> 
> But it only happens occasionally even in that case; Torsten's messages 
> don't get converted to Base64 - but in that thread, both Peter J Ross's 
> reply and mine, did.

Well, software is free to choose either quoted-printable or base64.

> Torsten's messages get to me with
> 
>     Content-Type: text/plain; charset="iso-8859-1"
>     Content-Transfer-Encoding: quoted-printable

That's what I observed too.

Torsten's messages arrived at the list server with CTE: 8bit, I received
them in quoted-printable CTE.

Peter J. Ross's and your second message already arrived in quoted-printable
CTE with UTF-8 charset.

The paths from the list to my account as well as to @operamail.com are
8-bit-clean, all advertise 8BITMIME, so no reencoding takes place. AFAIK,
Postfix never reencodes to base64, only to quoted-printable, if at all.

I don't know who re-encoded them; I presume it was Mailman or Python's SMTP
library. Base64 encoding might then happen behind the scenes at
outblaze.com/operamail.com.

> so perhaps it isn't the actual characters, so much as the sender's 
> character set - I used UTF-8 (automatic setting by my software when I use 
> non-US-ASCII characters); perhaps Peter did too?  If the messages go 
> through a system that can't handle UTF-8 I can see that causing a problem.

The charset is only of interest to systems actually presenting the message,
i. e. my mailer such as Evolution, KMail, Thunderbird, mutt, or a webmailer
such as SquirrelMail or Horde IMP or custom systems.

>> I stand by my former point that the problem is with the interaction of
>> Operamail and FreePOP. The latter fetches the header and the decoded
>> body, but does not rewrite the Content-Transfer-Encoding from "base64"
>> to either "8bit" or "binary".  
> 
> It's just as reasonable to suggest that Claws-Mail should be able to react 
> better when the body doesn't match the coding claimed in the headers.  

I beg to differ:

If it's declared as base64 but isn't actually encoded as such, the message
is corrupted. Fix the system that corrupts it, and that leaves us with:

>> Since you said switching service were no
>> option for you, it's probably best to have FreePOP fixed.
> 
> I can submit suggestions or reports to the maintainers of both FreePOPs
> and Claws-Mail, but it's beyond me to actually re-write those tools
> myself.

The first option. Please report this problem to the FreePOPs maintainers only.

> I have in fact migrated my subscription to this list to a new free email 
> account with GMX's new 'beta testing' service , which includes POP and IMAP
> access, so the immediate difficulty for me should be solved.  But the 
> curious changing of the encoding of messages remains.

I'm quite confident it's outside of the list server and the paths which I
can influence, since I've set up the list server.

HTH
MA

-- 
Matthias Andree