Next: Spam Statistics Package, Previous: Spam Back Ends, Up: Spam Package

#### 9.18.7 Extending the Spam package

Say you want to add a new back end called blackbox. For filtering incoming mail, provide the following:

1. Code

                 (defvar spam-use-blackbox nil
                   "True if blackbox should be used.")

   Write `spam-check-blackbox` if Blackbox can check incoming mail.

   Write `spam-blackbox-register-routine` and `spam-blackbox-unregister-routine` using the bogofilter register/unregister routines as a start, or other restister/unregister routines more appropriate to Blackbox, if Blackbox can register/unregister spam and ham.

2. Functionality

   The `spam-check-blackbox` function should return ‘`nil`’ or `spam-split-group`, observing the other conventions. See the existing `spam-check-*` functions for examples of what you can do, and stick to the template unless you fully understand the reasons why you aren't.

For processing spam and ham messages, provide the following:

1. Code

   Note you don't have to provide a spam or a ham processor. Only provide them if Blackbox supports spam or ham processing.

   Also, ham and spam processors are being phased out as single variables. Instead the form `(spam spam-use-blackbox)` or `(ham spam-use-blackbox)` is favored. For now, spam/ham processor variables are still around but they won't be for long.

                 (defvar gnus-group-spam-exit-processor-blackbox "blackbox-spam"
                   "The Blackbox summary exit spam processor.
                 Only applicable to spam groups.")

                 (defvar gnus-group-ham-exit-processor-blackbox "blackbox-ham"
                   "The whitelist summary exit ham processor.
                 Only applicable to non-spam (unclassified and ham) groups.")

2. Gnus parameters

   Add

                 (const :tag "Spam: Blackbox" (spam spam-use-blackbox))
                 (const :tag "Ham: Blackbox"  (ham spam-use-blackbox))

   to the `spam-process` group parameter in `gnus.el`. Make sure you do it twice, once for the parameter and once for the variable customization.

   Add

                 (variable-item spam-use-blackbox)

   to the `spam-autodetect-methods` group parameter in `gnus.el` if Blackbox can check incoming mail for spam contents.

   Finally, use the appropriate `spam-install-*-backend` function in `spam.el`. Here are the available functions.

   1. `spam-install-backend-alias`

      This function will simply install an alias for a back end that does everything like the original back end. It is currently only used to make `spam-use-BBDB-exclusive` act like `spam-use-BBDB`.

   2. `spam-install-nocheck-backend`

      This function installs a back end that has no check function, but can register/unregister ham or spam. The `spam-use-gmane` back end is such a back end.

   3. `spam-install-checkonly-backend`

      This function will install a back end that can only check incoming mail for spam contents. It can't register or unregister messages. `spam-use-blackholes` and `spam-use-hashcash` are such back ends.

   4. `spam-install-statistical-checkonly-backend`

      This function installs a statistical back end (one which requires the full body of a message to check it) that can only check incoming mail for contents. `spam-use-regex-body` is such a filter.

   5. `spam-install-statistical-backend`

      This function install a statistical back end with incoming checks and registration/unregistration routines. `spam-use-bogofilter` is set up this way.

   6. `spam-install-backend`

      This is the most normal back end installation, where a back end that can check and register/unregister messages is set up without statistical abilities. The `spam-use-BBDB` is such a back end.

   7. `spam-install-mover-backend`

      Mover back ends are internal to `spam.el` and specifically move articles around when the summary is exited. You will very probably never install such a back end.