testing Amavisd results by command-line with a source message

[Mark Martinec]

David,

> >> amavisd doesn't have a "test mode", but you can manually
> >> inject messages using a command-line SMTP tool such as
> >> mini_sendmail.

Right, I'm using mini_sendmail too for testing, as Noel is suggesting.
The benefit is that the full path is exercised.

An additional trick is to have a dedicated 'instance' subconfiguration,
so that one can play with settings for a test instance, while the production
amavisd is kept running. Something like (by the end of amavisd.conf):


if ($instance_name eq 'test') {

  $DO_SYSLOG = 0;
  $log_level = 2;
  $syslog_ident = 'amavis2';
  $max_servers = 2;
  $pid_file  = "$helpers_home/amavisd2.pid";
  $lock_file = "$helpers_home/amavisd2.lock";
  $db_home = "$MYHOME/var/db/amavis2";
  $enable_db = 1;

  $inet_socket_port = [8888,8889];
  $inet_socket_bind = '127.0.0.1';

# $final_spam_destiny = D_PASS;
# ...
}


Then:

$ mini_sendmail -ftest at example.com -s127.0.0.1 \
   -p8888 postmaster at example.com <test.msg


> > Thanks but the goal is to analyze/traps debug results in order to verify
> > rules without sending the message trough the MTA process.
> 
> If you're wanting to test spamassassin results, use the
> existing SA tools.

For testing SpamAssassin decisions:

# su vscan -c 'spamassassin -t -D <test.msg'



There is another option, rarely used. There is a small test program
in the distribution, called amavisd-submit. See its code for details.
It takes a message on stdin, feeds it to amavisd via an AM.PDP protocol
(which must be enabled in amavisd.conf), and reports the result
through exit status and debugging log. E.g.:

$ amavisd-submit test at example.com postmaster at example.com <test.msg


  Mark