fetchmail-users

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

[jdebert <jd...@ga...>]

Hi,

I'm trying to track down what's causing mail received via IMAP4 using
fetchmail have mangled Subject lines when the Subject is not ASCII.

This appears in the ISP mailbox:
Subject: [opensuse-ja]
=?ISO-2022-JP?B?UmU6IFtvcGVuc3VzZS1qYV0gTGlicmVvZmZpY2Ugd3JpdGUgGyRCSUEyaExkQmobKEI=?=

and it is received locally like this:

Subject: [opensuse-ja] Re: [opensuse-ja] Libreoffice write $BIA2hLdBj(B

Is it the IMAP protocol doing the mangling?

If so, is there a fetchmail option to resolve this?

Any help would be most appreciated!

jd

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

[grarpamp <gra...@gm...>]

> I'm trying to track down what's causing mail received via IMAP4 using
> fetchmail have mangled Subject lines when the Subject is not ASCII.

You may have switched the above description around as

> This appears in the ISP mailbox:
> ISO-2022-JP

this was garbage to me and

> and it is received locally like this:

this was rendered ok.

> Is it the IMAP protocol doing the mangling?

The protocol spec is binary and not involved.
If your locale is US and you prefer to see rendered chars
instead of various codings and escapes, you might try setting
your viewing environment to LANG=en_us.UTF-8 .
Also, update and recompile old systems/libraries/apps
because some are still evolving language support.

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

[<ro...@ri...>]

On Mon, Mar 17, 2014 at 01:49:47AM -0400, grarpamp wrote:
> > I'm trying to track down what's causing mail received via IMAP4 using
> > fetchmail have mangled Subject lines when the Subject is not ASCII.
> 
> You may have switched the above description around as
> 
> > This appears in the ISP mailbox:
> > ISO-2022-JP
> 
> this was garbage to me and

Er, no, it wasn't garbage, it was a MIME-encoded Subject field; this is
the way it should be transferred, this is the way it should be received
in the end-user's mailbox.  It is the job of the end-user's MUA to
decode it before *displaying* it to the user.

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.

G'luck,
Peter

-- 
Peter Pentchev	ro...@ri... ro...@Fr... p.p...@st...
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
Do you think anybody has ever had *precisely this thought* before?

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

[grarpamp <gra...@gm...>]

> Er, no, it wasn't garbage, it was a MIME-encoded Subject field; this is

I meant their appearance as pasted into the body of the op's msg,
and should have known the context you mentioned.

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

[jdebert <jd...@ga...>]

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.

Go figure. (^_^)

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

Thanks!

jd

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.

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

[grarpamp <gra...@gm...>]

> 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.

The default is off which nicely follows the principle of just passing
mail through unaltered towards the final destination/processor.
I don't use it or pass8bits. Others would be better suited to speak
on removal.

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

I sent a test note out...

Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
ZXhjdXNlIHRoZSB0ZXN0DQrQv9GA0LjQstGW0YINCg==