On Tue, 2013-09-24 at 21:12 -0700, google_t...@curranfamilynet.net wrote:
> Greetings, List!
>
> I just installed 3.3.2 on Slackware 14. I am seeing what looks like
> duplicated effort in /var/log/mailog. Here is the log for a single
> email. You can see the same message ID is processed first by root, then
> twice as user bobo. Is this normal? I had been using SA 3.2.5 on
> the decommissioned server and i never saw this:
You will have to review the entire mail processing chain on that
machine. Here's what I can tell from your logs:
The first scan appears to be by a milter -- most likely some (changed)
default configuration of Sendmail on Slackware. It is obvious this first
scan is not intended by you (Bayes DB locking fails, and missing custom
required_score conf).
Disable the unwanted milter in your Sendmail config.
The following two scans are "identical", i.e. same user, custom config,
Bayes DB (see autolearn=ham and unavailable on the last run, since the
mail has been learned already). At some point you're calling spamc (or
similar) a second time.
Have a close look at per-user procmail recipes, site-wide procmail
recipes, and possibly Sendmail configuration.
Then there's another issue with your server -- you're using a DNS server
that is inappropriate for DNSxL queries.
You are triggering RCVD_IN_DNSWL_BLOCKED and URIBL_BLOCKED. The latter
always, the first one only in the milter-induced run without your custom
per-user conf where you disabled DNSWL rules.
The problem most likely is that you're using your ISP's DNS, who ends up
exceeding the DNSxL's query limit. The solution is to run a local
caching DNS in resolver mode (not forwarder) and using that DNS server
instead of your ISP's one.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
