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 -ft...@example.com -s127.0.0.1 \
-p8888 postmas...@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 t...@example.com postmas...@example.com <test.msg
Mark
