Re: 8bit encoding in mail header by SpamAssassin

[Justin Mason <jm...@jmason.org>]

Per Jessen writes:
> Lars Ippich wrote:
> 
> > I actually have problems with mails coming from a server where they
> > already have been checked by SpamAssassin and have been added headers.
> > Amavisd, which I am running on my server, rejects these messages
> > because they are not obeying RFC 2822, which forbids 8bit encoding in
> > mails:
> > 
> > Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from
> > <ma...@host>: Non-encoded 8-bit data (char FC hex) in message header
> > 'X-Spam-Report'\n  X-Spam-Report: ...       Nachricht wurde nur
> > \\374ber
> > vertrauensw...\n                                               ^
> > 
> > So what can the sender's mailserver's administrator do to make
> > SpamAssassin adding reports 7bit encoded?
> 
> Interesting problem.  My first thought was RFC2046, but that won't work
> as nobody decodes the spamassassin headers, so they need to readable
> without decoding.
> 
> I think the answer is for spamassassin to avoid using 8bit chars when
> adding email headers.  Otherwise you could perhaps adjust your amavis
> settings and allow 8-bit chars in the header? 

Upgrade SpamAssassin -- we fixed that bug a good while ago.

--j.

Re: 8bit encoding in mail header by SpamAssassin

[Lars Ippich <la...@speicherplatz4you.de>]

Mark,

>>>>> Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from
>>>>> <ma...@host>: Non-encoded 8-bit data (char FC hex) in message header
>>>>> 'X-Spam-Report'\n  X-Spam-Report: ...       Nachricht wurde nur
>>>>> \\374bervertrauensw...\n
> 
>> The administrator claims to be using version 3.2.3 and that is as well
>> what it says in all mails I am getting from this host.
> 
> Most likely these header fields were inserted by some remote mailer
> running SpamAssassin, over which you may not have any control.
> Amavisd would not see or check X-Spam-* header fields added by itself
> (or from SpamAssassin invoked from it).

There are two instances of SpamAssassin running: One on the sending
mailserver which administrator claims to use v3.2.3 and one on my
recieving mailserver on which I am running v3.0.3. The sending
mailserver is adding the headers I mentioned above.

>> Amavisd, which I am running on my server, rejects these messages
>> because they are not obeying RFC 2822, which forbids 8bit encoding...
> 
> This is not a default behaviour, normally such errors in header are only
> flagged/logged as a warning, but a message is delivered nevertheless.
> There is no particularly good reason to block such messages,
> but you can if you want to.

I do not specifically want to block these messages, I would prefer a
warning only policy. But I did not change any amavisd settings beside
the normal configuration stuff. So do you know where these settings are
done and where I can change them?

Thanks,
Lars

Re: 8bit encoding in mail header by SpamAssassin

[mouss <mo...@netoyen.net>]

Mark Martinec wrote:
> This is not a default behaviour, normally such errors in header are only
> flagged/logged as a warning, but a message is delivered nevertheless.
> There is no particularly good reason to block such messages,
> but you can if you want to.
>   

In countries like here, that would block "some" mail (subject not
encoded), mostly from broken webmail implementations (Roundcube used to
have this bug). I guess similar problems are seen in other countries
with accented letters...

Re: 8bit encoding in mail header by SpamAssassin

[Mark Martinec <Ma...@ijs.si>]

Lars,

> >>> Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from
> >>> <ma...@host>: Non-encoded 8-bit data (char FC hex) in message header
> >>> 'X-Spam-Report'\n  X-Spam-Report: ...       Nachricht wurde nur
> >>> \\374bervertrauensw...\n

> The administrator claims to be using version 3.2.3 and that is as well
> what it says in all mails I am getting from this host.

Most likely these header fields were inserted by some remote mailer
running SpamAssassin, over which you may not have any control.
Amavisd would not see or check X-Spam-* header fields added by itself
(or from SpamAssassin invoked from it).

> Amavisd, which I am running on my server, rejects these messages
> because they are not obeying RFC 2822, which forbids 8bit encoding...

This is not a default behaviour, normally such errors in header are only
flagged/logged as a warning, but a message is delivered nevertheless.
There is no particularly good reason to block such messages,
but you can if you want to.

  Mark

Re: 8bit encoding in mail header by SpamAssassin

[Lars Ippich <la...@speicherplatz4you.de>]

Justin Mason wrote:
> Per Jessen writes:
>> Lars Ippich wrote:
>>
>>> I actually have problems with mails coming from a server where they
>>> already have been checked by SpamAssassin and have been added headers.
>>> Amavisd, which I am running on my server, rejects these messages
>>> because they are not obeying RFC 2822, which forbids 8bit encoding in
>>> mails:
>>>
>>> Oct 10 09:17:05 www amavis[2981]: (02981-06) BAD HEADER from
>>> <ma...@host>: Non-encoded 8-bit data (char FC hex) in message header
>>> 'X-Spam-Report'\n  X-Spam-Report: ...       Nachricht wurde nur
>>> \\374ber
>>> vertrauensw...\n                                               ^
>>>
>>> So what can the sender's mailserver's administrator do to make
>>> SpamAssassin adding reports 7bit encoded?
>> Interesting problem.  My first thought was RFC2046, but that won't work
>> as nobody decodes the spamassassin headers, so they need to readable
>> without decoding.
>>
>> I think the answer is for spamassassin to avoid using 8bit chars when
>> adding email headers.  Otherwise you could perhaps adjust your amavis
>> settings and allow 8-bit chars in the header? 
> 
> Upgrade SpamAssassin -- we fixed that bug a good while ago.
> 
> --j.

The administrator claims to be using version 3.2.3 and that is as well
what it says in all mails I am getting from this host.

Lars Ippich