Re: [fetchmail-devel] Re: r3948 - trunk

[Matthias A. <ma...@dt...>]

Graham Wilson <gr...@mk...> writes:

> On Tue, Oct 19, 2004 at 05:51:19PM -0500, sv...@de... wrote:
>> Added:
>>    trunk/rfc2047e.c
>> Modified:
>>    trunk/Makefile.am
>>    trunk/fetchmail.h
>> Log:
>> Add RFC-2047 encoder for internationalized mail warnings.
>
> Shouldn't we be adding this stuff on a branch? Or have we decided that
> the next release will definitely support correctly encoded warning
> messages? Even then, shouldn't the code be on a branch until we're sure
> it's good?

The issue at hand is that fetchmail warnings, if translated, are usually
in violation of RFC-2822, by stuffing national characters (8-bit data)
into headers and bodies unencoded and without markup. I've chosen the
trivial approach of just listing the charset of the body and specifying
it's 8-bit data (which may fail on ancient MTAs, but I don't care).

Practical consequence: if you're using strict mail server settings,
SpamAssassin or similar, all fetchmail warnings are either rejected or
filtered out as spam, with the user not seeing the warning. Whoops.

I hadn't heard contradictions last time I posted my progress indicator
WRT the warning message fixes I deemed critical, so I'm a bit surprised
by your comments now.

I may need to change the integration though, we should interpolate
variables before encoding and not just assume the interpolated stuff is
US-ASCII, as we're still doing.

-- 
Matthias Andree