NAME
Mail::SpamAssassin::Plugin - SpamAssassin plugin base class
SYNOPSIS
SpamAssassin configuration:
loadplugin MyPlugin /path/to/myplugin.pm
Perl code:
package MyPlugin;
use Mail::SpamAssassin::Plugin;
our @ISA = qw(Mail::SpamAssassin::Plugin);
sub new {
my ($class, $mailsa) = @_;
# the usual perlobj boilerplate to create a subclass object
$class = ref($class) || $class;
my $self = $class->SUPER::new($mailsa);
bless ($self, $class);
# then register an eval rule, if desired...
$self->register_eval_rule ("check_for_foo");
# and return the new plugin object
return $self;
}
...methods...
1;
DESCRIPTION
This is the base class for SpamAssassin plugins; all plugins must be objects
that implement this class.
This class provides no-op stub methods for all the callbacks that a plugin
can receive. It is expected that your plugin will override one or more
of these stubs to perform its actions.
SpamAssassin implements a plugin chain; each callback event is passed to each
of the registered plugin objects in turn. Any plugin can call
"$self->inhibit_further_callbacks()" to block delivery of that event to
later plugins in the chain. This is useful if the plugin has handled the
event, and there will be no need for later plugins to handle it as well.
If you're looking to write a simple eval rule, skip straight to
"register_eval_rule()", below.
INTERFACE
In all the plugin APIs below,
"options" refers to a reference to a hash
containing name-value pairs. This is used to ensure future-compatibility, in
that we can add new options in future without affecting objects built to an
earlier version of the
API.
For example, here would be how to print out the "line" item in a
"parse_config()" method:
sub parse_config {
my ($self, $opts) = @_;
print "MyPlugin: parse_config got ".$opts->{line}."\n";
}
METHODS
The following methods can be overridden by subclasses to handle events
that SpamAssassin will call back to:
- $plugin = MyPluginClass->new ($mailsaobject)
-
Constructor. Plugins that need to register themselves will need to
define their own; the default super-class constructor will work fine
for plugins that just override a method.
Note that subclasses must provide the $mailsaobject to the
superclass constructor, like so:
my $self = $class->SUPER::new($mailsaobject);
Lifecycle note: plugins that will need to store per-scan state should not store
that on the Plugin object; see "check_start()" below. It is also likewise
recommended that configuration settings be stored on the Conf object; see
"parse_config()".
- $plugin->parse_config ( { options ... } )
-
Parse a configuration line that hasn't already been handled. "options"
is a reference to a hash containing these options:
-
- line
-
The line of configuration text to parse. This has leading and trailing
whitespace, and comments, removed.
- key
-
The configuration key; ie. the first ``word'' on the line.
- value
-
The configuration value; everything after the first ``word'' and
any whitespace after that.
- conf
-
The "Mail::SpamAssassin::Conf" object on which the configuration
data should be stored.
- user_config
-
A boolean: 1 if reading a user's configuration, 0 if reading the
system-wide configuration files.
-
If the configuration line was a setting that is handled by this plugin, the
method implementation should call "$self->inhibit_further_callbacks()".
If the setting is not handled by this plugin, the method should return 0 so
that a later plugin may handle it, or so that SpamAssassin can output a warning
message to the user if no plugin understands it.
Lifecycle note: it is suggested that configuration be stored on the
"Mail::SpamAssassin::Conf" object in use, instead of the plugin object itself.
That can be found as "$plugin->{main}->{conf}". This allows per-user and
system-wide configuration to be dealt with correctly, with per-user overriding
system-wide.
- $plugin->signal_user_changed ( { options ... } )
-
Signals that the current user has changed for a new one.
-
- username
-
The new user's username.
- user_dir
-
The new user's home directory. (equivalent to "~".)
- userstate_dir
-
The new user's storage directory. (equivalent to "~/.spamassassin".)
-
- $plugin->check_start ( { options ... } )
-
Signals that a message check operation is starting.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
Lifecycle note: it is recommended that rules that need to track test state on a
per-scan basis should store that state on this object, not on the plugin object
itself, since the plugin object will be shared between all active scanners.
The message being scanned is accessible through the
"$permsgstatus->get_message()" API; there are a number of other public
APIs on that object, too. See "Mail::SpamAssassin::PerMsgStatus" perldoc.
-
- $plugin->extract_metadata ( { options ... } )
-
Signals that a message is being mined for metadata. Some plugins may wish
to add their own metadata as well.
-
- msg
-
The "Mail::SpamAssassin::Message" object for this message.
-
- $plugin->parsed_metadata ( { options ... } )
-
Signals that a message's metadata has been parsed, and can now be
accessed by the plugin.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
-
- $plugin->check_tick ( { options ... } )
-
Called periodically during a message check operation. A callback set for
this method is a good place to run through an event loop dealing with
network events triggered in a "parse_metadata" method, for example.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
-
- $plugin->check_post_dnsbl ( { options ... } )
-
Called after the DNSBL results have been harvested. This is a good
place to harvest your own asynchronously-started network lookups.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
-
- $plugin->check_post_learn ( { options ... } )
-
Called after auto-learning may (or may not) have taken place. If you
wish to perform additional learning, whether or not auto-learning
happens, this is the place to do it.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
-
- $plugin->check_end ( { options ... } )
-
Signals that a message check operation has just finished, and the
results are about to be returned to the caller.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
The current score, names of rules that hit, etc. can be retrieved
using the public APIs on this object.
-
- $plugin->autolearn ( { options ... } )
-
Signals that a message is about to be auto-learned as either ham or spam.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
- isspam
-
1 if the message is spam, 0 if ham.
-
- $plugin->per_msg_finish ( { options ... } )
-
Signals that a "Mail::SpamAssassin::PerMsgStatus" object is being
destroyed, and any per-scan context held on that object by this
plugin should be destroyed as well.
-
- permsgstatus
-
The "Mail::SpamAssassin::PerMsgStatus" context object for this scan.
-
- $plugin->bayes_learn ( { options ... } )
-
Called at the end of a bayes learn operation.
This phase is the best place to map the raw (original) token value
to the SHA1 hashed value.
-
- toksref
-
Reference to hash returned by call to tokenize. The hash takes the
format of:
{
'SHA1 Hash Value' => { 'raw_token' => 'raw (original) value' }
}
- isspam
-
Boolean value stating what flavor of message the tokens represent, if
true then message was specified as spam, false is nonspam. Note, when
function is scan then isspam value is not valid.
- msgid
-
Generated message id of the message just learned.
- msgatime
-
Received date of the current message or current time if received date
could not be determined. In addition, if the receive date is more than
24 hrs into the future it will be reset to current datetime.
-
- $plugin->bayes_forget ( { options ... } )
-
Called at the end of a bayes forget operation.
-
- toksref
-
Reference to hash returned by call to tokenize. See bayes_learn
documentation for additional information on the format.
- isspam
-
Boolean value stating what flavor of message the tokens represent, if
true then message was specified as spam, false is nonspam. Note, when
function is scan then isspam value is not valid.
- msgid
-
Generated message id of the message just forgotten.
-
- $plugin->bayes_scan ( { options ... } )
-
Called at the end of a bayes scan operation. NOTE: Will not be
called in case of error or if the message is otherwise skipped.
-
- toksref
-
Reference to hash returned by call to tokenize. See bayes_learn
documentation for additional information on the format. If the token
was found in the database it will contain some additional information:
{
'SHA1 Hash Value' => { 'raw_token' => 'raw (original) value',
'pw' => 'calculated probability',
'spam_count' => 'Total number of spam msgs w/ token',
'ham_count' => 'Total number of ham msgs w/ token',
'atime' => 'Atime value for token in database'
}
}
- score
-
Score calculated for this particular message.
- msgatime
-
Calculated atime of the message just learned, note it may have been adjusted
if it was determined to be too far into the future.
- significant_tokens
-
Array ref of the tokens found to be significant in determining the score for
this message.
-
- $plugin->finish ()
-
Called when the "Mail::SpamAssassin" object is destroyed.
HELPER APIS
These methods provide an
API for plugins to register themselves
to receive specific events, or control the callback chain behaviour.
- $plugin->register_eval_rule ($nameofevalsub)
-
Plugins that implement an eval test will need to call this, so that
SpamAssassin calls into the object when that eval test is encountered.
For example,
$plugin->register_eval_rule ('check_for_foo')
will cause "$plugin->check_for_foo()" to be called for this
SpamAssassin rule:
header FOO_RULE eval:check_for_foo()
Note that eval rules are passed the following arguments:
-
- The plugin object itself
-
- The Mail::SpamAssassin::PerMsgStatus object calling the rule
-
- standard arguments for the rule type in use
-
- any and all arguments as specified in the configuration file
-
-
In other words, the eval test method should look something like this:
sub check_for_foo {
my ($self, $permsgstatus, ...arguments...) = @_;
...code returning 0 or 1
}
Note that the headers can be accessed using the "get()" method on the
"Mail::SpamAssassin::PerMsgStatus" object, and the body by
"get_decoded_stripped_body_text_array()" and other similar methods.
Similarly, the "Mail::SpamAssassin::Conf" object holding the current
configuration may be accessed through "$permsgstatus->{main}->{conf}".
The eval rule should return 1 for a hit, or 0 if the rule
is not hit.
State for a single message being scanned should be stored on the $checker
object, not on the $self object, since $self persists between scan
operations. See the 'lifecycle note' on the "check_start()" method above.
STANDARD ARGUMENTS FOR RULE TYPES
Plugins will be called with the same arguments as a standard EvalTest.
Different rule types receive different information by default:
- header tests, no extra arguments
-
- body tests, fully rendered message as array reference
-
- rawbody tests, fully decoded message as array reference
-
- full tests, pristine message as scalar reference
-
-
The configuration file arguments will be passed in after the standard
arguments.
- $plugin->inhibit_further_callbacks()
-
Tells the plugin handler to inhibit calling into other plugins in the plugin
chain for the current callback. Frequently used when parsing configuration
settings using "parse_config()".
- dbg ($message)
-
Output a debugging message $message, if the SpamAssassin object is running
with debugging turned on.
NOTE: This function is not available in the package namespace
of general plugins and can't be called via $self->dbg(). If a
plugin wishes to output debug information, it should call
"Mail::SpamAssassin::Plugin::dbg($msg)".
SEE ALSO
"Mail::SpamAssassin"
"Mail::SpamAssassin::PerMsgStatus"
http://bugzilla.spamassassin.org/show_bug.cgi?id=2163
Index
- NAME
-
- SYNOPSIS
-
- SpamAssassin configuration:
-
- Perl code:
-
- DESCRIPTION
-
- INTERFACE
-
- METHODS
-
- HELPER APIS
-
- STANDARD ARGUMENTS FOR RULE TYPES
-
- SEE ALSO
-