Re: [exim] Problem since upgrading spamassassin

Top Page
Delete this message
Reply to this message
Author: Richard Hobbs
Date:  
To: exim-users
Subject: Re: [exim] Problem since upgrading spamassassin
Hello,

Here is a snippet from my troubleshooting on the spamassassin mailing list:

> > > > In my experience each new version of SA is a little
> > > > more resource intensive than the last. This
> > > > generally means that scan times increase. If some
> > > > work and some don't I suspect this could possibly
> > > > be a timeout issue. Is there some sort of time limit
> > > > involved where once that amount of time has passed
> > > > the process errors out?
> > >
> > > As for crashing out due to a possible time limit, how
> > > could i check this? surely such a feature would be
> > > built into spamassassin, right?
> >
> > I'm guessing here (because I have never used EXIM) but
> > does EXIM set a default time limit on sa_router: or
> > sa_spamcheck: ?
>
> Not sure... i'll find out from the exim mailing list.


So here i am... could this be a possible explanation, and how could i
find out?

Thanks again,
Richard.


Arthur Hagen wrote:
> On Wed, 2007-02-28 at 20:15 +0100, Renaud Allard wrote:
>> For the moment, you are using routers and transports to scan for spam.
>> This means you cannot deny mails at SMTP time. It is much better to use
>> the built in spam and antivirus scan functions.
>
> The problem with not using routers at all is that different recipients
> have different definitions of spam, and it seems quite tough to set up
> something that allows for scanning at SMTP time, while still allowing
> individual users' whitelists and special considerations.
>
> The best I've come up with is far from perfect:
>
> ...
> acl_smtp-rcpt = acl_check_rcpt
> acl_smtp_data = acl_check_data
> spamd_address = 127.0.0.1 783
> ...
> begin acl
> acl_check_rcpt:
> ...
>   accept  domains       = +local_domains
>           endpass
>           verify        = recipient
>           # Allow for user-anything@ addresses
>           set acl_m0    = ${sg{$local_part}{-.*}{}}
>           set acl_m0    = ${lookup{$acl_m0}dbm{/etc/aliases.db}}
>           set acl_m0    = ${if eq {}{$acl_m0}{nobody}{$acl_m0}}

>
>   accept  domains       = +relay_to_domains
>           endpass
>           verify        = recipient
>           set acl_m0    = nobody
> ...
> acl_check_data:
> ...
>   # Reject spam messages with score over 15
>   deny  message = Spam is not wanted here
>         spam = $acl_m0:true
>         condition = ${if >{$spam_score_int}{150}{1}{0}}

>
>   warn  spam = $acl_m0
>         message = X-Spam-Flag: YES\n\
>                   X-Spam-Score: $spam_score ($spam_bar)\n\
>                   X-Spam-Report: $spam_report\n\
>                   X-Spam-Scanned-By: $acl_m0
> ...
> (router section)
> dnslookup:
>   driver = dnslookup
>   domains = ! +local_domains
>   transport = remote_smtp
>   ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
>   headers_remove =
> X-Spam-Status:X-Spam-Flag:X-Spam-Score:X-Spam-Report:X-Spam-Scanned-By:X-Is-A-Bounce
>   no_more

>
>
> The idea is that local incoming mail gets scanned by the recipient,
> while relayed mail or mail where the recipient can't be determined gets
> scanned by the "nobody" user.
> This is far from perfect, as it will not handle aliases pointing to
> other aliases. The main problem is that when there /is/ a local
> recipient, but the above acl_m0 rules fail to determine it, the uid will
> be incorrect, and spamassassin fails to access the user's rules:
>
> Feb 27 23:55:11 myhost spamd[2382]: auto-whitelist: open of
> auto-whitelist file failed: locker: safe_lock: cannot create tmp
> lockfile /home/username/.spamassassin/auto-whitelist.lock.myhost.mydomain.com.2382 for /home/username/.spamassassin/auto-whitelist.lock: Permission denied
>
> Anyone know how to fix this, or better yet, have an alternative approach
> that does allow for per-user scanning before the mail is accepted?
>
> I already know that there is a logistical problem when there's more than
> one local recipient. It would be acceptable, but far from perfect, to
> have that kind of email scanned by just one of the users (as is what
> happens with the above) or "nobody".
>
> Regards,


-- 
Richard Hobbs (Systems Administrator)
Toshiba Research Europe Ltd. - Speech Technology Group
Email: richard.hobbs@???
Web: http://www.toshiba-europe.com/research/
Tel: +44 1223 376964        Mobile: +44 7811 803377