Re: [fetchmail-users] Mail received via IMAP4: Subject line is mangled if not in ASCII

[Matthias A. <mat...@gm...>]

Am 17.03.2014 19:21, schrieb jdebert:
> On Mon, 17 Mar 2014 10:07:49 +0200
> ro...@ri... wrote:
>>
>> To the original poster: I don't really have a straight-up solution to
>> your problem, but you might try playing with the "mimedecode" and
>> "pass8bits" options in your fetchmail configuration file.  Both of
>> them should be unset by default, and this should be fine for most
>> cases; if you have explicitly set any of them, try unsetting it, see
>> if that helps.  Otherwise, try setting them in some combination to
>> see what happens.
>>
> 
> I had pass8bits and mimedecode set because they solved this problem
> before. Now having unset them has once again seems to have solved the
> problem.

Manually decoding the header you showed in your first post renders as

| Re: [opensuse-ja] Libreoffice write 描画問題

here, which Babelfish translates to "Libreoffice write drawing problem".


> Go figure. (^_^)

Depends on where you're sending to and what your clients make of what
they get from your spool or mail server.

Quoting the fetchmail manual:

|        [...]                  The mimedecode option is off by default,
because
|        doing RFC2047 conversion on headers throws away character-set
informa‐
|        tion and can lead to bad results if the encoding of the headers
differs
|        from the body encoding.

There should be a way to declare the destination character set, but isn't.

And I am now wondering if I should kill the mimedecode option in the
next (future) fetchmail major release.  It requires tons of code for a
half-baked non-solution that used to work around MIME unawareness in
mail clients some dozen years ago.

> This is working for spam, at least. Have to wait for some non-spam to
> see if it still works.