On Sun, 03 Sep 2006 17:34:04 +0200 Philippe <sphinx@???> wrote:
> Hi there,
>
> Since a few weeks, I receive some warnings which look like this :
>
> Message 1GJpyf-0002qL-4W has been frozen (delivery error message).
> The sender is <>.
> The following address(es) have yet to be delivered:
> %mailboxforspam%@%domain%.com <%user%@???>: LMTP error after
> end of data: 554 5.6.0 Message contains invalid header
>
> Do I have to use your system to filter 8-bits headers ?
> Isn't it a little bit too strict ? (I mean, have you ever had false
> positives with that rule)
>
> I did not change anything in Exim's configuration. Does anybody has an
> idea why I suddenly get such messages ?
>
> Many thanks.
>
> Cheers
I take it that you are delivering to cyrus, given the error message you quoted.
The following assumes that.
Note that there are two possible problems with 8-bit in headers:
If the header field name contains 8-bit then cyrus will reject the message. In
that case it is better that exim rejects the message rather than cyrus.
If the content of a header field contains 8-bit then cyrus normally substitutes
"X" and allows it in. This can be stopped using cyrus's "reject8bit" option.
Having run my code to detect 8-bit in header field names for several days I hit
no false-positives and changed it to do a deny.
I presume these messages have started because a new piece of spamming software
has been put int acction and it has bugs in it.
Finally, the ACL I am using now is:
deny message = The message header contains an invalid field name
condition = ${if match{$message_headers} \
{\N(?m)^[^:\s]*[\x80-\xFF]+[^:]*:\N} \
{yes}{no}}
I have started another thread with a subject of "8-bit in headers" which talks
about the problem of detecting 8-bit in the non-field-name part of headers.
Phil.
---------------------------------------
Phil Chambers (postmaster@???)
University of Exeter
