On 5/17/13 4:16 AM, Cyborg wrote:
>
> This is all you need to do (simpliest setup):
>
> spamd_address = 127.0.0.1 783
> ....
> acl_check_data:
> ...
>
> # Run SpamAssassin, but allow for it to fail or time out. Add a
> warning message
> # and accept the mail if that happens. Add an X-Spam-Flag: header if
> the SA
> # score exceeds the SA system threshold.
>
> warn condition = ${if eq{$authenticated_id}{} {1}{0}}
> spam = nobody/defer_ok
> add_header = X-Spam-Flag: YES
>
> warn add_header = X-Spam-Score: $spam_score ($spam_bar)\n\
> X-Spam-Report: $spam_report
>
> deny condition = ${if >{$spam_score_int}{${.....yourscore here.....}}
> {1}}
> message = Your message scored $spam_score SpamAssassin
> points. Report follows:\n\
> $spam_report
>
>
> It performs way better than your setup in high traffic environments,
> has more and easier options to control the spamcheck,
> gets rid of the message
> etc etc etc
>
Thanks, I just tested this setup after checking your other suggestions
re: disk space, quotas, and clearing the db, and unfortunately the
problem continues. All good suggestions, and moving spam handling to the
check_data acl might both be better for performance in the long run and
shows right now that the spamcheck router and transport I had weren't
the source of the problem.
So delivery still seems to skip the userforward router and be handled by
local_user, but the condition is sometimes corrected by a restart of
exim for a few hours.
