Quoting Matt Kettler <[EMAIL PROTECTED]>:

> Well, as I said above no updates have been published since Jan 14th. So 
> I would not expect any.
> 
> However, sa-update's don't go in /usr/share/spamassassin. You'll *NEVER* 
> see updates if you keep looking there. Feb 7th should be the date of 
> your install.
> 
> Updates go into /var/lib/spamassassin/<version 
> number>/updates_spamassassin_org/
> 
> If you look there, there should be files that are newer than 
> /usr/share/spamassassin, but you'll only have found an update once since 
> install. You won't find any again until a dev chooses to push rules to 
> 3.2 That could be tomorrow, it could be a year from now.
> 
> Don't expect daily updates. SpamAssassin is not an anti-virus product. 
> We don't need new rules for each and every spam message, we only need 
> them when there's a very significant mutation.

Thanks Matt for your patience in explaining all that. I really appreciate it.


Quoting Mike Jackson <[EMAIL PROTECTED]>:

> > 00 * * * *      /usr/bin/sa-update --gpgkey 6C6191E3 --channel
> sought.rules.yerp.org --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10
> --channel saupdates.openprotect.com --channel updates.spamassassin.org
> --allowplugins
> > 
> > Am I missing anything?
> 
> Beside the other comments, throw something like "&& 
> /etc/init.d/spamassassin restart" onto the end of your cron job. You're 
> going to want SA to restart if the rules actually change. sa-update sets 
> the exit code to 0 only when it updates the rules, so if no updates, no 
> restart.
> 

So my cron would look like this then?

00 * * * *      /usr/bin/sa-update --gpgkey 6C6191E3 --channel 
sought.rules.yerp.org --gpgkey D1C035168C1EBC08464946DA258CDB3ABDE9DC10 
--channel saupdates.openprotect.com --channel updates.spamassassin.org 
--allowplugins && /etc/init.d/spamd restart



Quoting Matthias Leisi <[EMAIL PROTECTED]>:

> As a courtesy to server operators, please refrain from running your cron
> jobs at x:00, and especially at 00:00 -- moving back and forth a couple
> of minutes reduces load peaks on the remote servers (and also on your
> own machines, since other jobs may run at the same time).
> 
> - -- Matthias

Thanks Matthias, will do that.

--
Roger


---------------------------------------------------
Sign Up for free Email at http://ureg.home.net.my/
---------------------------------------------------

Reply via email to