[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[leafnode-list] Re: Base64 coding in list messages
>> 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
> 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
> 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
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.
leafnode-list mailing list