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