Excuse me
I think that problem is $spam_score_int
2008/7/13 Alexandre Busquets Triola <abusquets@???>:
> I think that problem is not $spam_score_int
>
>
> 2008/7/11 Phil Pennock <exim-users@???>:
>
>> On 2008-07-11 at 23:13 +0200, Alexandre Busquets Triola wrote:
>>
>> > I have problems with emails with sender spamassassin headers
>>
>> > X-Spam-Score: -0.9 (/)
>>
>> Before these ACL checks, have:
>>
>> warn set acl_m_is_spam = 0
>>
>> > warn message = X-Spam-Flag:YES
>> > !authenticated = *
>> > condition = ${if <{$message_size}{1200k}{1}{0}}
>> > spam = spamd:true
>> > condition = ${if >{$spam_score_int}{50}{1}{0}}
>>
>> Add to this: set acl_m_is_spam = 1
>>
>> Hereafter, $acl_m_is_spam is either 1 or 0 and is unaffected by
>> anything other than your own spam score. You've separated out the
>> security-sensitive data to a different namespace which can't be directly
>> added to by the remote untrusted data source.
>>
>> > virtual_delivery:
>> > driver = appendfile
>> > mode = 0600
>> > maildir_format = true
>> > delivery_date_add
>> > envelope_to_add
>> > return_path_add
>> > create_directory = true
>> > headers_remove = Subject : X-Spam-Flag
>> > headers_add = Subject: ${if eq{$h_X-Spam-Flag:}{YES} {*****SPAM*****
>> > $h_Subject:}{$h_Subject:}}
>>
>> ${if >{$acl_m_is_spam}{0} {*****SPAM***** $rh_Subject:}{$rh_Subject:}}
>>
>> Note that this is preserving any needed MIME mangling in the original
>> "Subject:" header by using the raw form. There's a slight risk that the
>> first line will end up overlong, but it's less wrong than putting
>> decoded data in.
>>
>> -Phil
>>
>
>
