Hi Matt, Thanks a lot for your clarifications. Everything is clearer now :)
ddaas Matt Kettler wrote: > ddaasd wrote: > >>Hi, >>I have a problem with SpamAssassin. I would appreciate if someone could >>help me. >> >> My setup is: >> >>I’ve upgraded to SpamAssassin version 3.0.3 running on Perl version >>5.8.0. I am using in conjunction with spamass-milter - Version 0.3.0 and >>Sendmail 8.12.11. The OS is RHEL 3. > > <snip> > >>1) It seams that my customized scores from >>/etc/mail/spamassasssin/local.cf don’t work. > > > > Did you restart spamd after editing this file? In order to avoid wasting CPU > time, spamd only reads /etc/mail/spamassassin/*.cf when it starts up. It only > reads user_prefs files when it's scanning a message. > > The spamassassin command line on the other hand, parses everything from > scratch > as it's a new instance. > >>The problem is that DEAR_SOMETHING, DEAR_FRIEND etc have no effect as >>they weren’t there. Is this a parse error or I miss something? How can I >>customize my score for different tests? >> >> >>2 ) The result of #spamassasin -d --lint: >> >> Net::DNS version is 0.31, but need 0.34dnsavailable-1 at >>/usr/lib/perl5/vendor_perl/5.8.0/Mail/SpamAssassin/Dns.pm line 1230. >> >> What is this DNS? I think it has nothing to do with BIND…. Should I >>upgrade something? > > > Erm, It's DNS.. Domain Name System.. It's how names get resolved to IP > addresses, a very fundamental basic of the Internet. > > SA uses a DNS module to do various RBL lookups. If you don't want to bother > with > those rules you can ignore these warnings, otherwise you should try to get a > newer version of the Net::DNS perl module. > > >> >>3) I can’t use user_prefs from /home/user/.spamassassin/user_prefs >> >> >> >>From the logs I see that SpamAssassin wants to write/read from >> /root/.spamassassin/user_prefs. Why root? >> >>I found out that the problem is that nobody has no home directory. I >>understand that. But when I run SA as root it reads from >>/root/.spamassassin/user_prefs. Shoudn’t SA read the user_prefs file of >>the recipient? > > > No, it shouldn't use the recipient automatically. > > Consider the following: > > 1) SpamAssassin doesn't always know who the recipient is, as it can only guess > based on the To: header. However, what about a message that's To: > users@spamassassin.apache.org but was remailed to you by the list? There's not > always header saying who the recipient is, since the list effectively remails > it > to you as a Bcc. > > 2) There might be multiple recipients (think Cc:, etc). > > 3) The recipient might not have an account on the local box (think relaying > mailserver, or even outbound mail you sent) > > > SpamAssassin uses the userid that *executes* it. > > Spamd uses the userid that executed spamc, or the user passed to the -u > command > line of either app. > > If it finds it's going to scan mail as root, it falls back to nobody for > safety. > > > >>Isn’t this the point here, to customize for every recipient different >>rules? So, why is SA stucked to /root/.spamassassin/user_prefs? > > > Because that's who called SA. > >> >>How can I customize rules for every user? > > > Ditch spamass-milter. You generally can't do this with a MTA layer filter. > Instead you'll want to do it at the MDA layer (i.e. procmail)and pass the > envelope recipient to -u. Some milters might be able to do this, but they > often > run into the "what to do when there's multiple recipients for the same > message" > problem. > > There's drawbacks and advantages to each different layer of calling SA, so > while > a milter has several advantages, per-user customization is one of it's > weaknesses. > > Some generalities about the trade-offs of calling SA at different parts of the > mail chain. Yes there's some exceptions and variation among tools, but baring > some considerable coding cleverness, these are the limits of a straightforward > implementation at a given layer: > > 1) smtp-time in the MTA: (ie: milters, qmail-scanner, etc) > +can reject (properly) > +scanning is done once per message not per recipient > -inbound mail rate must be limited by a number of processes, or else system > load > will explode if a rush of mail comes in all at once. (most do this using spamd > which has built-in child limiting) > -usually have very limited per-user flexibility > > 2) mta-queue layer (mailscanner is the only one I'm aware of): > +inbound mail can be queued quickly without waiting for SA to scan it. > +scanning can done per-message or per recipient (with some MTA queuing > options) > +bursts of high volume have little impact on system load > -sustained high volume can cause mail queue to get large (Mailscanner does > shift > to emergency mode to alleviate this, but that bypasses scanning) > -somewhat limited per-user flexibility (better than with milter, but still one > SA user_prefs) > -can't reject, can only generate post-delivery bounces (bad idea), quarantine, > delete, or deliver. > > 3) MDA layer (ie: procmail) > +high degree of per-user flexibility, as passing -u to spamc allows separate > user_prefs > -multi-recipient messages must be re-scanned > -can't reject... > > 4) MUA layer (ie: called from within kmail) > +complete end-user control of scanning > -isn't site-wide, must be installed on each client machine > -no centralized scanner, thus no central statistics > -messages must be downloaded to client before they can be scanned. > -can't reject... > >
