Mail::...Plugin(3pm)

okay so bestie, welcome to the <pink>Mail::...Plugin(3pm)</pink> manual page โ€” it's giving User Contributed Perl Documentation energy, and the actual package is Mail::SpamAssassin::Plugin. This is the base class for SpamAssassin plugins, and it's lowkey the blueprint for making your own plugin. No cap. ๐Ÿ’–

โœจ NAME โœจ

Mail::SpamAssassin::Plugin โ€” SpamAssassin plugin base class. That's the whole vibe, fr fr.

๐ŸŒธ 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. Periodt.

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. So like, you're not reinventing the wheel, you're just customizing the vibe. ๐Ÿ’…

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. It's giving I got this, bestie, you can chill. ๐Ÿซถ

If you're looking to write a simple eval rule, skip straight to register_eval_rule(), below. That's the shortcut, iykyk.

๐Ÿ’– 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. So like, it's future-proofed, slay.

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. These are the main character hooks, bestie. โœจ

$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; instead this should be stored on the PerMsgStatus 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}, or as conf in the $options hash reference above. By storing it on conf, this allows per-user and system-wide configuration precedence to be dealt with correctly.

$plugin->finish_parsing_start ( { options ... } )

Signals that the system-wide configuration has been completely read, but internal data structures are not yet created. It is possible to use this hook to dynamically change the configuration already read in or add new config options.

options is a reference to a hash containing these options:

  • conf โ€” The Mail::SpamAssassin::Conf object on which the configuration data should be stored.

Note: there are no guarantees that the internal data structures of SpamAssassin will not change from release to release. In particular to this plugin hook, if you modify the rules data structures in a third-party plugin, all bets are off until such time that an API is present for modifying that configuration data.

$plugin->finish_parsing_end ( { options ... } )

Signals that the system-wide configuration parsing has just finished, and SpamAssassin is nearly ready to check messages.

options is a reference to a hash containing these options:

  • conf โ€” The Mail::SpamAssassin::Conf object on which the configuration data should be stored.

Note: there are no guarantees that the internal data structures of SpamAssassin will not change from release to release. In particular to this plugin hook, if you modify the rules data structures in a third-party plugin, all bets are off until such time that an API is present for modifying that configuration data.

$plugin->user_conf_parsing_start ( { options ... } )

Signals that the per-user configuration has been completely read, but not converted to internal data structures. It is possible to use this hook to dynamically change the configuration already read in or add new config options.

If allow_user_rules is enabled in the configuration, it is possible that additional rules have been added since the finish_parsing_start plugin hook invocation was called.

  • conf โ€” The Mail::SpamAssassin::Conf object on which the configuration data should be stored.

Note: there are no guarantees that the internal data structures of SpamAssassin will not change from release to release. In particular to this plugin hook, if you modify the rules data structures in a third-party plugin, all bets are off until such time that an API is present for modifying that configuration data.

$plugin->user_conf_parsing_end ( { options ... } )

Signals that the per-user configuration parsing has just finished, and SpamAssassin is nearly ready to check messages. If allow_user_rules is enabled in the configuration, it is possible that additional rules have been added since the finish_parsing_end plugin hook invocation was called.

options is a reference to a hash containing these options:

  • conf โ€” The Mail::SpamAssassin::Conf object on which the configuration data should be stored.

Note: there are no guarantees that the internal data structures of SpamAssassin will not change from release to release. In particular to this plugin hook, if you modify the rules data structures in a third-party plugin, all bets are off until such time that an API is present for modifying that configuration data.

$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->services_authorized_for_username ( { options ... } )

Validates that a given username is authorized to use certain services.

In order to authorize a user, the plugin should first check that it can handle any of the services passed into the method and then set the value for each allowed service to true (or any non-negative value).

The current supported services are: bayessql

  • username โ€” A username
  • services โ€” Reference to a hash containing the services you want to check.
               {

                 'bayessql' => 0

               }
  • conf โ€” The Mail::SpamAssassin::Conf object on which the configuration data should be stored.

$plugin->compile_now_start ( { options ... } )

This is called at the beginning of Mail::SpamAssassin::compile_now() so plugins can do any necessary initialization for multi-process SpamAssassin (such as spamd or mass-check -j).

  • use_user_prefs โ€” The value of $use_user_prefs option in compile_now().
  • keep_userstate โ€” The value of $keep_userstate option in compile_now().

$plugin->compile_now_finish ( { options ... } )

This is called at the end of Mail::SpamAssassin::compile_now() so plugins can do any necessary initialization for multi-process SpamAssassin (such as spamd or mass-check -j).

  • use_user_prefs โ€” The value of $use_user_prefs option in compile_now().
  • keep_userstate โ€” The value of $keep_userstate option in compile_now().

$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->check_main ( { options ... } )

Signals that a message should be checked. Note that implementations of this hook should return 1.

  • permsgstatus โ€” The Mail::SpamAssassin::PerMsgStatus context object for this scan.

๐Ÿ’ซ $plugin->check_tick ( { options ... } ) ๐Ÿ’ซ

okay so this one gets called periodically while a message check is happening. if you set a callback for it, it's lowkey the perfect spot to run through an event loop and deal with network events that got triggered in a parse_metadata method, like, for example. โœจ

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan. that's your girl, she's holding all the context.

๐ŸŒ $plugin->check_dnsbl ( { options ... } ) ๐ŸŒ

this fires when DNSBL or other network lookups are being launched, and it implies the current running priority is -100. bestie, this is the place to kick off your own asynchronously-started network lookups. go off. ๐Ÿ’…

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.

๐ŸŒพ $plugin->check_post_dnsbl ( { options ... } ) ๐ŸŒพ

called after the DNSBL results have been harvested. so if you started some async network lookups of your own? this is where you harvest them. it's giving "reaping what you sowed" energy ๐Ÿซถ

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.

๐Ÿงน $plugin->check_cleanup ( { options ... } ) ๐Ÿงน

this one runs just before message check is finishing and before possible auto-learning. and here's the tea: it is guaranteed to always be called, unlike check_tick and check_post_dnsbl. iconic behaviour, honestly. use it for cleaning up left callbacks or forked children etc. โ€” it's your last chance to make rules hit. ๐Ÿ˜ค

  • 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. note the "may or may not" โ€” no promises. if you wanna do extra learning, whether or not auto-learning actually happened, this is the spot. ๐ŸŽ€

  • 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 handed back to the caller. end of an era fr fr.

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan. the current score, names of rules that hit, etc. can all be retrieved using the public APIs on this object, so go grab 'em. ๐Ÿ‘‘

๐Ÿงผ $plugin->finish_tests ( { options ... } ) ๐Ÿงผ

called via Mail::SpamAssassin::finish. it should clear up any tests that a plugin has added to the namespace, okay? super important.

so sometimes plugins find it useful to compile perl functions from the ruleset, like, on the fly. but bestie โ€” it is important to remove these once the Mail::SpamAssassin object is deleted, and this API is what lets you do that. and no passing the buck: each plugin is responsible for its own generated perl functions. ๐Ÿ˜Œ

  • conf โ€” the Mail::SpamAssassin::Conf object on which the configuration data should be stored.
also see the register_generated_rule_method helper API, below. ๐Ÿ‘€

๐Ÿ” $plugin->extract_metadata ( { options ... } ) ๐Ÿ”

signals that a message is being mined for metadata. some plugins may wanna add their own metadata too, and this is where you do that. ๐Ÿ’Ž

  • msg โ€” the Mail::SpamAssassin::Message object for this message.
  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.

๐Ÿ—‚๏ธ $plugin->parsed_metadata ( { options ... } ) ๐Ÿ—‚๏ธ

signals that a message's metadata has been parsed, and can now be accessed by the plugin. door's open, come on in. ๐Ÿฆ‹

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.

๐ŸŽฌ $plugin->start_rules ( { options ... } ) ๐ŸŽฌ

called before testing a set of rules of a given type and priority. like a little pre-show. ๐Ÿฟ

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.
  • ruletype โ€” the type of the rules about to be performed.
  • priority โ€” the priority level of the rules about to be performed.

๐Ÿ’ฅ $plugin->hit_rule ( { options ... } ) ๐Ÿ’ฅ

called when a rule fires. yes, we love a rule that ate. ๐Ÿ”ฅ

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.
  • ruletype โ€” the type of the rule that fired.
  • rulename โ€” the name of the rule that fired.
  • score โ€” the rule's score in the active scoreset.

โœ… $plugin->ran_rule ( { options ... } ) โœ…

called after a rule has been tested, whether or not it fired. and heads up: when the rule fires, the hit_rule callback is always called before this one. that order is non-negotiable. ๐Ÿ’€

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.
  • ruletype โ€” the type of the rule that was tested.
  • rulename โ€” the name of the rule that was tested.

๐Ÿค” $plugin->autolearn_discriminator ( { options ... } ) ๐Ÿค”

this one controls whether a just-scanned message should be learned as either spam or ham. your method should return exactly one of these:

  • 1 โ€” learn the message as spam
  • 0 โ€” learn as ham
  • undef โ€” don't learn from the message at all ๐Ÿ™ˆ
  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.

๐Ÿง  $plugin->autolearn ( { options ... } ) ๐Ÿง 

signals that a message is about to be auto-learned as either ham or spam. big moment for the message honestly. โญ

  • 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 that your plugin is holding on that object should get destroyed too. cleanup era. ๐Ÿ’…

normally, any member variables on the PerMsgStatus object will be cleaned up automatically โ€” but if your plugin has made a circular reference on that object, this is the place to break them so that garbage collection can actually operate correctly. don't leave GC in the group chat with no closure. ๐Ÿ˜ญ

  • permsgstatus โ€” the Mail::SpamAssassin::PerMsgStatus context object for this scan.

โšก $plugin->have_shortcircuited ( { options ... } ) โšก

has the current scan operation 'short-circuited'? in other words โ€” can further scanning just be skipped, since the message is already definitively classified as either spam or ham?

plugins should return 0 to say that scanning should continue, or 1 to say that short-circuiting has taken effect.

  • 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. iykyk. ๐ŸŽ€

  • toksref โ€” reference to hash returned by call to tokenize. the hash takes the format of:
{
  'SHA1 Hash Value' => 'raw (original) value',
  ...
}
NOTE: this data structure has changed since it was originally introduced in version 3.0.0. the values are no longer perl anonymous hashes, they are a single string containing the raw token value. you can test for backward compatibility by checking to see if the value for a key is a reference to a perl HASH, for instance:
if (ref($toksref->{$sometokenkey}) eq 'HASH') {...

if it is, then you are using the old interface, otherwise you are using the current interface. choose your fighter. ๐Ÿ’ซ

  • 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. future-dated mail, be gone. ๐Ÿ•ฐ๏ธ

๐Ÿ—‘๏ธ $plugin->bayes_forget ( { options ... } ) ๐Ÿ—‘๏ธ

called at the end of a bayes forget operation. memory holed. โœจ

  • 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.
  • probsref โ€” reference to hash of calculated probabilities for tokens found in the database.
{
  'SHA1 Hash Value' => {
          'prob' => '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. the actual main characters of the tokenizer. ๐Ÿ‘‘

๐Ÿ“ฎ $plugin->plugin_report ( { options ... } ) ๐Ÿ“ฎ

called if the message is to be reported as spam. if the reporting system is available, the variable $options->{report}->report_available} should be set to 1; if the reporting system successfully reported the message, the variable $options->{report}->report_return} should be set to 1. ๐Ÿซถ

  • report โ€” reference to the Reporter object ($options->{report} in the paragraph above.)
  • text โ€” reference to a markup removed copy of the message in scalar string format.
  • msg โ€” reference to the original message object.

โ†ฉ๏ธ $plugin->plugin_revoke ( { options ... } ) โ†ฉ๏ธ

called if the message is to be reported as ham โ€” i.e. it revokes a spam report. the "jk bestie" of the reporting world. ๐Ÿ’… if the reporting system is available, the variable $options->{revoke}->revoke_available} should be set to 1; if the reporting system successfully revoked the message, the variable $options->{revoke}->revoke_return} should be set to 1.

  • revoke โ€” a reference to the Reporter object ($options->{revoke} in the paragraph above). ๐Ÿ’…
  • text โ€” a reference to a markup removed copy of the message, in scalar string format. โœจ
  • msg โ€” a reference to the original message object. ๐Ÿซถ

$plugin->welcomelist_address( { options ... } ) ๐Ÿ’–

Previously whitelist_address which will work interchangeably until 4.1.

Called when a request is made to add an address to a persistent address list.

  • address โ€” Address you wish to add. ๐Ÿ“ฌ
  • cli_p โ€” Indicate if the call is being made from a command line interface. ๐Ÿ’ป

$plugin->blocklist_address( { options ... } ) ๐Ÿšซ

Previously blacklist_address which will work interchangeably until 4.1.

Called when a request is made to add an address to a persistent address list.

  • address โ€” Address you wish to add. ๐Ÿ“ฌ
  • cli_p โ€” Indicate if the call is being made from a command line interface. ๐Ÿ’ป

$plugin->remove_address( { options ... } ) ๐Ÿ—‘๏ธ

Called when a request is made to remove an address to a persistent address list.

  • address โ€” Address you wish to remove. โœ‚๏ธ
  • cli_p โ€” Indicate if the call is being made from a command line interface. ๐Ÿ’ป

$plugin->spamd_child_init () ๐Ÿ‘ถ

Called in each new child process when it starts up under spamd. ๐Ÿง’

$plugin->log_scan_result ( { options ... } ) ๐Ÿ“

Called when spamd has completed scanning a message. Currently, only spamd calls this API.

$plugin->spamd_child_post_connection_close () ๐Ÿ”Œ

Called when child returns from handling a connection.

If there was an accept failure, the child will die and this code will not be called. ๐Ÿ’€

$plugin->finish () ๐Ÿงน

Called when the Mail::SpamAssassin object is destroyed. ๐Ÿ’ฅ

$plugin->learner_new () ๐Ÿง 

Used to support human-trained probabilistic classifiers like the BAYES_* ruleset. Called when a new Mail::SpamAssassin::Bayes object has been created; typically when a new user's scan is about to start. โœจ

$plugin->learn_message () ๐Ÿ“š

Train the classifier with a training message.

  • isspam โ€” 1 if the message is spam, 0 if it's non-spam. โš–๏ธ
  • msg โ€” The message's Mail::SpamAssassin::Message object. ๐Ÿ“จ
  • id โ€” An optional message-identification string, used internally to tag the message. If it is undef, one will be generated. It should be unique to that message. ๐Ÿท๏ธ

$plugin->forget_message () ๐Ÿงฝ

Tell the classifier to 'forget' its training about a specific message.

  • msg โ€” The message's Mail::SpamAssassin::Message object. ๐Ÿ“จ
  • id โ€” An optional message-identification string, used internally to tag the message. If it is undef, one will be generated. It should be unique to that message. ๐Ÿท๏ธ

$plugin->learner_sync () ๐Ÿ”„

Tell the classifier to 'sync' any pending changes against the current user's training database. This is called by sa-learn --sync.

If you do not need to implement these for your classifier, create an implementation that just contains return 1. ๐Ÿ‘

$plugin->learner_expire_old_training () โณ

Tell the classifier to perform infrequent, time-consuming cleanup of the current user's training database. This is called by sa-learn --force-expire.

If you do not need to implement these for your classifier, create an implementation that just contains return 1. ๐Ÿ‘

$plugin->learner_is_scan_available () ๐ŸŽฏ

Should return 1 if it is possible to use the current user's training data for a message-scan operation, or 0 otherwise. ๐ŸŒˆ

$plugin->learner_dump_database () ๐Ÿ“ค

Dump information about the current user's training data to stdout. This is called by sa-learn --dump.

  • magic โ€” Set to 1 if magic name-value metadata should be dumped. ๐Ÿช„
  • toks โ€” Set to 1 if the database of tokens should be dumped. ๐Ÿช™
  • regex โ€” Either undef to dump all tokens, or a value which specifies a regular expression subset of the tokens to dump. ๐Ÿ”Ž

$plugin->learner_close () ๐Ÿ”’

Close any open databases.

  • quiet โ€” Set to 1 if warning messages should be suppressed. ๐Ÿคซ

โœจ 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, $ruletype) ๐Ÿงช

Plugins that implement an eval test will need to call this, so that SpamAssassin calls into the object when that eval test is encountered. See the REGISTERING EVAL RULES section for full details.

Since 4.0, optional $ruletype can be specified to enforce that eval function cannot be called with wrong ruletype from configuration, for example user using header FOO eval:foobar() instead of body FOO eval:foobar(). Mismatch will result in lint failure. $ruletype can be one of:

$Mail::SpamAssassin::Conf::TYPE_HEAD_EVALS
$Mail::SpamAssassin::Conf::TYPE_BODY_EVALS  (allows both body and rawbody)
$Mail::SpamAssassin::Conf::TYPE_RAWBODY_EVALS
$Mail::SpamAssassin::Conf::TYPE_FULL_EVALS

$plugin->register_generated_rule_method ($nameofsub) ๐Ÿ› ๏ธ

In certain circumstances, plugins may find it useful to compile perl functions from the ruleset, on the fly. It is important to remove these once the Mail::SpamAssassin object is deleted, however, and this API allows this.

Once the method $nameofsub has been generated, call this API with the name of the method (including full package scope). This indicates that it's a temporary piece of generated code, built from the SpamAssassin ruleset, and when Mail::SpamAssassin::finish() is called, the method will be destroyed.

This API was added in SpamAssassin 3.2.0. โœจ

$plugin->register_method_priority($methodname, $priority) ๐Ÿ”ข

Indicate that the method named $methodname on the current object has a callback priority of $priority.

This is used by the plugin handler to determine the relative order of callbacks; plugins with lower-numbered priorities are called before plugins with higher-numbered priorities. Each method can have a different priority value. The default value is 0. The ordering of callbacks to methods with equal priority is undefined.

Typically, you only need to worry about this if you need to ensure your plugin's method is called before another plugin's implementation of that method. It should be called from your plugin's constructor.

This API was added in SpamAssassin 3.2.0. ๐Ÿ”ข

$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(). ๐Ÿ›‘


๐ŸŽ€ LOGGING ๐ŸŽ€

Mail::SpamAssassin::Plugin::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). ๐Ÿ›

Mail::SpamAssassin::Plugin::info($message) โ„น๏ธ

Output an informational message $message, if the SpamAssassin object is running with informational messages turned on.

NOTE: This function is not available in the package namespace of general plugins and can't be called via $self->info(). If a plugin wishes to output debug information, it should call Mail::SpamAssassin::Plugin::info($msg). ๐Ÿ“˜

In general, it is better for plugins to use the Mail::SpamAssassin::Logger module to import dbg and info directly, like so:

use Mail::SpamAssassin::Logger;
dbg("some message");
info("some other message");

๐Ÿ’– REGISTERING EVAL RULES ๐Ÿ’–

Plugins that implement an eval test must register the methods that can be called from rules in the configuration files, in the plugin class' constructor.

For example,

$plugin->register_eval_rule ('check_for_foo', $Mail::SpamAssassin::Conf::TYPE_HEAD_EVALS)

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 (miss), 1 (hit), or undef (async function)
}

The eval rule should return 1 for a hit, or 0 if the rule is not hit. Special case of return undef must be used when result is not yet ready and it will be later declared with PerMsgStatus functions got_hit() or rule_ready() - see their documentation for more info. Make sure not to return undef by mistake. โš ๏ธ

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}.

State for a single message being scanned should be stored on the $permsgstatus 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. ๐Ÿ’…

โœจ BACKWARD COMPATIBILITY โœจ

ok so here's the tea ๐Ÿซ– โ€” writing plugins means you might need to know whether a specific helper method is even supported on Mail::SpamAssassin::Plugin at the moment you're running. bestie, you don't just assume. you check. like this:

if ($self->can("name_of_method")) {
  eval {
    $self->name_of_method();        # etc.
  }
} else {
  # take fallback action
}

the $self->can("name_of_method") is giving "do you even go here" and if the answer is yes, you go for it inside an eval (safety first ๐Ÿ’…), and if the answer is no, you do the fallback thing instead. no crashing, no drama, no cap.

and this same trick? literally works everywhere โ€” same deal for the public APIs on objects of other types, like Mail::SpamAssassin::PerMsgStatus. same vibe check, different object. iykyk ๐Ÿฆ‹


๐ŸŒˆ SEE ALSO ๐ŸŒˆ


and that's the whole page, bestie!! ๐ŸŽ€ you made it to the end, iconic behavior honestly ๐Ÿ‘‘ this one's from perl v5.40.1, dated 2026-07-23, and it's the Mail::...Plugin(3pm) page in the Mail::...Plugin era of the docs โœจ go write something slay, ily, bye ๐Ÿ’–

๐Ÿ“ฆ where this page comes from