I think that problem is not $spam_score_int
2008/7/11 Phil Pennock <[EMAIL PROTECTED]>:
> 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
>
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
