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
>>> <[EMAIL PROTECTED]>: 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

Reply via email to