Rechercher une page de manuel

Chercher une autre page de manuel:


Langue: en

Version: 2010-07-03 (fedora - 01/12/10)

Section: 1 (Commandes utilisateur)


sa-update - automate SpamAssassin rule updates


sa-update [options]


   --channel channel       Retrieve updates from this channel
                           Use multiple times for multiple channels
   --channelfile file      Retrieve updates from the channels in the file
   --checkonly             Check for update availability, do not install
   --install filename      Install updates directly from this file. Signature
                           verification will use "file.asc" and "file.sha1"
   --allowplugins          Allow updates to load plugin code
   --gpgkey key            Trust the key id to sign releases
                           Use multiple times for multiple keys
   --gpgkeyfile file       Trust the key ids in the file to sign releases
   --gpghomedir path       Store the GPG keyring in this directory
   --gpg and --nogpg       Use (or do not use) GPG to verify updates
                           (--gpg is assumed by use of the above
                           --gpgkey and --gpgkeyfile options)
   --import file           Import GPG key(s) from file into sa-update's
                           keyring. Use multiple times for multiple files
   --updatedir path        Directory to place updates, defaults to the
                           SpamAssassin site rules directory
                           (default: /var/lib/spamassassin/3.003001)
   --refreshmirrors        Force the MIRRORED.BY file to be updated
   -D, --debug [area=n,...]  Print debugging messages
   -v, --verbose           Be more verbose, like print updated channel names
   -V, --version           Print version
   -h, --help              Print usage message


sa-update automates the process of downloading and installing new rules and configuration, based on channels. The default channel is, which has updated rules since the previous release.

Update archives are verified using SHA1 hashes and GPG signatures, by default.

Note that "sa-update" will not restart "spamd" or otherwise cause a scanner to reload the now-updated ruleset automatically. Instead, "sa-update" is typically used in something like the following manner:

         sa-update && /etc/init.d/spamassassin reload

This works because "sa-update" only returns an exit status of 0 if it has successfully downloaded and installed an updated ruleset.


sa-update can update multiple channels at the same time. By default, it will only access ``'', but more channels can be specified via this option. If there are multiple additional channels, use the option multiple times, once per channel. i.e.:
         sa-update --channel --channel
Similar to the --channel option, except specify the additional channels in a file instead of on the commandline. This is useful when there are a lot of additional channels.
Only check if an update is available, don't actually download and install it. The exit code will be 0 or 1 as described below.
Install updates ``offline'', from the named tar.gz file, instead of performing DNS lookups and HTTP invocations.

Files named file.sha1 and file.asc will be used for the SHA-1 and GPG signature, respectively. The filename provided must contain a version number of at least 3 digits, which will be used as the channel's update version number.

Multiple --channel switches cannot be used with --install. To install multiple channels from tarballs, run "sa-update" multiple times with different --channel and --install switches, e.g.:

         sa-update --channel --install foo-34958.tgz
         sa-update --channel --install bar-938455.tgz
Allow downloaded updates to activate plugins. The default is not to activate plugins; any "loadplugin" or "tryplugin" lines will be commented in the downloaded update rules files.
--gpg, --nogpg
sa-update by default will verify update archives by use of a SHA1 checksum and GPG signature. SHA1 hashes can verify whether or not the downloaded archive has been corrupted, but it does not offer any form of security regarding whether or not the downloaded archive is legitimate (aka: non-modifed by evildoers). GPG verification of the archive is used to solve that problem.

If you wish to skip GPG verification, you can use the --nogpg option to disable its use. Use of the following gpgkey-related options will override --nogpg and keep GPG verification enabled.

Note: Currently, only GPG itself is supported (ie: not PGP). v1.2 has been tested, although later versions ought to work as well.

sa-update has the concept of ``release trusted'' GPG keys. When an archive is downloaded and the signature verified, sa-update requires that the signature be from one of these ``release trusted'' keys or else verification fails. This prevents third parties from manipulating the files on a mirror, for instance, and signing with their own key.

By default, sa-update trusts key id "265FA05B", which is the standard SpamAssassin release key. Use this option to trust additional keys. See the --import option for how to add keys to sa-update's keyring. For sa-update to use a key it must be in sa-update's keyring and trusted.

For multiple keys, use the option multiple times. i.e.:

         sa-update --gpgkey E580B363 --gpgkey 298BC7D0

Note: use of this option automatically enables GPG verification.

Similar to the --gpgkey option, except specify the additional keys in a file instead of on the commandline. This is extremely useful when there are a lot of additional keys that you wish to trust.
Specify a directory path to use as a storage area for the "sa-update" GPG keyring. By default, this is
Use to import GPG key(s) from a file into the sa-update keyring which is located in the directory specified by --gpghomedir. Before using channels from third party sources, you should use this option to import the GPG key(s) used by those channels. You must still use the --gpgkey or --gpgkeyfile options above to get sa-update to trust imported keys.

To import multiple keys, use the option multiple times. i.e.:

         sa-update --import channel1-GPG.KEY --import channel2-GPG.KEY

Note: use of this option automatically enables GPG verification.

Force the list of sa-update mirrors for each channel, stored in the MIRRORED.BY file, to be updated. By default, the MIRRORED.BY file will be cached for up to 7 days after each time it is downloaded.
By default, "sa-update" will use the system-wide rules update directory:

If the updates should be stored in another location, specify it here.

Note that use of this option is not recommended; if you're just using sa-update to download updated rulesets for a scanner, and sa-update is placing updates in the wrong directory, you probably need to rebuild SpamAssassin with different "Makefile.PL" arguments, instead of overriding sa-update's runtime behaviour.

-D [area,...], --debug [area,...]
Produce debugging output. If no areas are listed, all debugging information is printed. Diagnostic output can also be enabled for each area individually; area is the area of the code to instrument. For example, to produce diagnostic output on channel, gpg, and http, use:
         sa-update -D channel,gpg,http

For more information about which areas (also known as channels) are available, please see the documentation at <>.

-h, --help
Print help message and exit.
-V, --version
Print sa-update version and exit.


An exit code of 0 means an update was available, and was downloaded and installed successfully if --checkonly was not specified.

An exit code of 1 means no fresh updates were available.

An exit code of 2 means that at least one update is available but that a lint check of the site pre files failed. The site pre files must pass a lint check before any updates are attempted.

An exit code of 4 or higher, indicates that errors occurred while attempting to download and extract updates.


Mail::SpamAssassin(3) Mail::SpamAssassin::Conf(3) spamassassin(1) spamd(1) <>




See <>


The Apache SpamAssassin(tm) Project <> SpamAssassin is distributed under the Apache License, Version 2.0, as described in the file "LICENSE" included with the distribution.
> Une chose est sure si linux est toujour dans lombre c'est qu'ils ont
> refusé que les grands viennent jouer dans leur court. Le problème avec
> linux c'est que lorsque tu développes une application, t'est obligé de
> livré les sources et tous ça gratuitement. KDE étant opensource et
> étant, je crois, la seul alternative graphique sur linux. Cette état
> de chose oblige les grosses boîtes à livrer leur source(1er problème)
> et ça gratuitement.
> Prener l'exemple suivant. Corel, un fleuron canadien y a pas si
> longtemps, avait commencé à développer sous Linux(KDE) et à vendre son
> produit phare
> 700.00$ US. Bon c'est cher, ça c'est vrai, mais lorsque plus d'un
> millier d'ingénieurs et de codeurs ont élaborés le projet. Faut
> bien que quelqu'un paie la note.
> Et qui pourrait bien s'interresser ? un produit de haut niveau
> graphique?. Les graphistes sacrement. Eux ils sont prêt à payer.
> Et qui pourrait bien s'interresser à un produit comme Wordperfect ?
> Tous ceux dont leurs travails dépend d'un traitement de texte.
> Sérieusement exist-il un produit sur linux qui soit de calibre avec:
> CorelDraw ? La suite Office de Ms Photoshop ? AutoDesk et AutoCad... ?
> Mon avertissement et il est sérieux. éloigne toi de ce qui est
> OpenSource. Il se peut que tu es entre les mains un concept de Génie.
> - Fait breveté le concept et non un copyright de ton code. Il y tout
> un monde entre les deux. Le copyright empêche qq'un de ce servir de
> ton code à son propre bénifice mais cela ne l'empêche pas de créer
> un code différent et de copier le concept.
> Le brevet ça c'est différent. C'est le concept intégral que tu
> protèges pour les vingts prochaines années. Donc si qq'un élabore un
> concept similaire, tu peux l'attaquer en justice pour le
> produit(concept) et non pour le code qu'il renferme. De plus au brevet
> ce n'est pas sur le code mais sur la forme que repose le brevet. Donc
> tu peux te foutre du codre et de l'ouvrir si tu veux.
> Mais avant de ne faire quoique ce soit, prend le temps de bien
> réfléchir.
> Il existe un produit qui à créé un emgoument certaint dans la
> communauté de Palm. C'est " Developer Studio". Au fil des
> bêta, gratuite, le gars à su fideliser une grosse clientèle.
> Aujourd'hui son produit est au point et il le vend à prix d'or. 99.00$
> US pour la personelle et 350.00$ US pour la > suite professionnel.
> C'est le meilleur produit sur le marché actuelement pour programmer
> sur un Palm. Sont idé de base a été d'élaborer un produit similaire à
> Visual Studio. Alors comme des milliers de programmeurs programment
> avec Visual Studio (VC++, VB, VFP), quoi de plus naturel que de
> travailler avec Falch. Je vous jure que ça prend des mois à s'habituer
> à Code Warrior. Code Warrior est au monde d'Apple ce que VC++ et
> Borland C++ est au monde de Windows. Falch est le VC++ de Palm.
> Donc au lieu du OpenSource. Fait breveter ton produit aux Etats Unis.
> Je vois mal un européen copier et vendre ton concept en europe. Je
> crois qu'il y a des entente à ce niveau. Mais bon vérifie sur ce point
> et agit en conséquence.
> Après le brevet et seulement si tu as le brevet, fait faire un
> copyright du code que renferme ton produit. Là c'est plus "touché",
> s'il y a des bouts de codes copiés, ben oubli le copyrigth.
> Prend des entententes avec les gens qui veulent dévellopper avec toi.
> Tu vends les produits et la rénumération ce fait au prorata. Donc si
> qq'un écrit 100 lignes de codes dans une application qui en contient
> 10000 bien il touchera 100/1000 des profits générés. Comme ça chaqu'un
> recoit la juste part pour la contribution apporté.
> Les mageures pour gagner la partie.
> Un traitement de texte de qualité Un tableur de qualité Un agenda de
> qualité Un programme d'envoie et réception de fax. Une messagerie
> efficace en Intranet et et Internet. Un exploreur pour le Web.
> Et le plus important, permettre aux mageures comme IBM, COREL et
> toutes autres société de grande envergure s'installer sur ta
> plateforme sans avoir de compte à te rendre. En cela pour les
> applicatifs et non pour les plateformes de d?veloppements.
> C'est tout. Bye Eddy Maue.
> En passant l'opensource c'est pour les pauves et les étudiants non pas
> besoins de revenu pour vivre.
-- Fan de Jayce - Heureusement que je passais par là --