amavisd new and dspam

[Mark Martinec]

Ilo,

> Ive installed amavisd-new 2.6.6 aswell as dspam 3.10.1
> 
> I would like amavisd to use dspam so I have unhashed the dspam option
> in the config file..
>
> yet amavis does not find dspam, any idea why?
> 
> i was also reading in the changelog that amavis handles dspam differently
> 
> and I should specifiy it in spam_scanners () but i dont find that
> option in the config file only in the amavisd code itself?

Indeed, the dspam entry in the @spam_scanners list must be enabled.
Something like this can be added to amavisd.conf:

@spam_scanners = (
  ['SpamAssassin', 'Amavis::SpamControl::SpamAssassin' ],
  ['DSPAM', 'Amavis::SpamControl::ExtProg', '/usr/local/bin/dspam',
    [ qw(--stdout --classify --deliver=innocent,spam
         --mode=toe --feature noise --user vscan) ],
    mail_body_size_limit => 65000, score_factor => 0.1,
  ],
);


Some DSPAM-related entries from release notes:

amavisd-new-2.7.0 release notes

- if running other spam scanners besides SpamAssassin through a @spam_scanners
  mechanism (such as DSPAM or CRM114), make header fields produced by them
  visible to SpamAssassin too, so that its rules can benefit from additional
  information. Note that in order for SpamAssassin to be able to see such
  header fields from other scanners, such scanners must be listed in the
  @spam_scanners list *before* the 'SpamAssassin' entry.  Suggested by Marco.

- entries 'SpamAssassin' and 'SpamdClient' in the @spam_scanners list
  now recognize options 'mail_body_size_limit' and 'score_factor', to match
  their behaviour with 'DSPAM' and 'CRM114' entries;

amavisd-new-2.6.4 release notes

- fix parsing of a combined result from DSPAM (option --classify), as
  earlier versions of DSPAM did not include a signature with a combined
  result line; problem reported by Marijan Vidmar;

amavisd-new-2.6.3 release notes

- support for DSPAM has been removed from Amavis::SpamControl::SpamAssassin
  module, merging DSPAM scores into SpamAssassin and DSPAM autolearning
  is no longer available. Nevertheless, it is now possible to use DSPAM
  instead of SpamAssassin, or by adding results from each. See description
  below for @spam_scanners;

- a configuration variable @spam_scanners is added, along with a module
  Amavis::SpamControl::ExtProg (which is only loaded if needed).
  This is similar in concept to @av_scanners list, and allows using
  amavisd with different spam scanners, not just with SpamAssassin.
  The default setting is backward compatible:

    @spam_scanners = (
      ['SpamAssassin', 'Amavis::SpamControl::SpamAssassin'],
    );

  The first element of each tuple is a scanner name, the second is a module
  name to be invoked, it must implement a method new(). Remaining arguments
  are passed to a module as arguments in a call to its new(). The exact
  syntax and semantics of these arguments is module-specific and may change
  in future versions as more experience is gained.

  Currently supported spam scanners are:

  - SpamAssassin: backward compatible, uses the module Mail::SpamAssassin
    directly as before;

  - SpamdClient: a client to spamd, equivalent to a spamc usage; the main
    reason for existence of this module is to allow amavisd to serve as
    a test client for exercising spamd; not envisaged for production use;

  - CRM114: spawns an external program 'crm'. A well trained crm114 system
    gives good results (even with a global database). An alternative is to
    use a CRM114 plugin to SpamAssassin, with a benefit of autolearning
    and combining its results with other rules, but at some processing cost;

  - DSPAM: spawns an external program 'dspam';

  Spam score and test results from all spam scanners are added together,
  currently it makes most sense to only have one of these entries enabled
  at a time. A possible (artificial, not particularly useful) configuration
  with multiple entries is illustrated by the following setting:

  @spam_scanners = (
    ['SpamAssassin', 'Amavis::SpamControl::SpamAssassin' ],

    ['SpamdClient',  'Amavis::SpamControl::SpamdClient' ],

    ['CRM114', 'Amavis::SpamControl::ExtProg', 'crm',
      [ qw(-u /var/amavis/home/.crm114 mailreaver.crm
           --dontstore --report_only --stats_only
           --good_threshold=8 --spam_threshold=-8) ],
      mail_body_size_limit => 64000, score_factor => -0.20,
    ],
    ['DSPAM',  'Amavis::SpamControl::ExtProg', $dspam,
      [ qw(--stdout --classify --deliver=innocent,spam
           --mode=tum --tokenizer=chained,noise
           --user), $daemon_user ],
      # use option --feature instead of --tokenizer with dspam < 3.8.0
      mail_body_size_limit => 64000, score_factor => 1,
    ],
  );

  A module Amavis::SpamControl::ExtProg implements an interface to external
  spawned programs. These are expected to receive a mail message on their
  stdin, and produce a result on their stdout (and errors on stderr). The
  result typically consists of some header fields the spawned spam scanner
  wishes to report to a caller, but can also be a complete rewritten header
  section or a complete rewritten mail message. The ExtProg module just
  collects the information it needs from the output of a scanner and discards
  the rest (i.e. an external scanner can not rewrite a message), so to avoid
  unnecessary processing, it is best to configure an external scanner to
  only return what is needed.

  Currently some post-processing of CRM114 and DSPAM results is hard-wired
  into the ExtProg module. Collected header fields are typically inserted
  into a passed message, subject to a list of allowed header fields
  in %allowed_added_header_fields. Some important header fields are also
  added to a quarantined message, but a different mechanism is involved
  ($msginfo->supplementary_info, the same mechanism as used in obtaining
  tags from SpamAssassin).

  The module Amavis::SpamControl::ExtProg expects two required parameters:
  a path to a program to spawn, and a ref to a list of command line arguments.
  Following these two arguments there may be options in a form of key/value
  pairs. Unrecognized options are ignored. Currently the only two options are:

    mail_body_size_limit ... the ExtProg module only feeds up to about this
      number of bytes (or slightly more) of a message to a spam scanner;
      if unspecified or undefined a default limit is $sa_mail_body_size_limit,
      and if that is undefined, an entire message is passed regardless of
      its size;

    score_factor ... a floating point number by which a score produced by a
      spam scanner is multiplied to yield a final score (with a SpamAssassin
      semantics, values near or below 0 are ham, values near or above 5 are
      spam). Note that crm114 uses opposite sign semantics, so a score_factor
      for this scanner should be negative. The dspam scanner produces
      hard-wired score -1 (innocent) or 10 (spam), which is then multiplied
      by score_factor to yield a final score.




Mark