Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32) Standard preamble: ========================================================================
NAMEMail::SpamAssassin::Plugin::SPF - perform SPF verification tests
DESCRIPTIONThis plugin checks a message against Sender Policy Framework (
- whitelist_from_spf firstname.lastname@example.org
Works similarly to whitelist_from, except that in addition to matching
a sender address, a check against the domain's SPFrecord must pass. The first parameter is an address to whitelist, and the second is a string to match the relay's rDNS.
Just like whitelist_from, multiple addresses per line, separated by spaces, areOK.Multiple "whitelist_from_spf" lines are alsoOK.
The headers checked for whitelist_from_spf addresses are the same headers used forSPFchecks (Envelope-From, Return-Path, X-Envelope-From, etc).
Since this whitelist requires anSPFcheck to be made, network tests must be enabled. It is also required that your trust path be correctly configured. See the section on "trusted_networks" for more info on trust paths.
whitelist_from_spf email@example.com firstname.lastname@example.org whitelist_from_spf *@example.com
- def_whitelist_from_spf email@example.com
- Same as "whitelist_from_spf", but used for the default whitelist entries in the SpamAssassin distribution. The whitelist score is lower, because these are often targets for spammer spoofing.
- spf_timeout n (default: 5)
How many seconds to wait for an SPFquery to complete, before scanning
continues without theSPFresult. A numeric value is optionally suffixed by a time unit (s, m, h, d, w, indicating seconds (default), minutes, hours, days, weeks).
- do_not_use_mail_spf (0|1) (default: 0)
By default the plugin will try to use the Mail::SPF module for SPFchecks if
it can be loaded. If Mail::SPF cannot be used the plugin will fall back to using the legacy Mail::SPF::Query module if it can be loaded.
Use this option to stop the plugin from using Mail::SPF and cause it to try to use Mail::SPF::Query instead.
- do_not_use_mail_spf_query (0|1) (default: 0)
As above, but instead stop the plugin from trying to use Mail::SPF::Query and
cause it to only try to use Mail::SPF.
- ignore_received_spf_header (0|1) (default: 0)
By default, to avoid unnecessary DNSlookups, the plugin will try to use the
SPFresults found in any "Received-SPF" headers it finds in the message that could only have been added by an internal relay.
Set this option to 1 to ignore any "Received-SPF" headers present and to have the plugin perform theSPFcheck itself.
Note that unless the plugin finds an "identity=helo", or some unsupported identity, it will assume that the result is a mfromSPFcheck result. The only identities supported are "mfrom", "mailfrom" and "helo".
- use_newest_received_spf_header (0|1) (default: 0)
By default, when using "Received-SPF" headers, the plugin will attempt to use
the oldest (bottom most) "Received-SPF" headers, that were added by internal relays, that it can parse results from since they are the most likely to be accurate. This is done so that if you have an incoming mail setup where one of your primary MXes doesn't know about a secondaryMX(or your MXes don't know about some sort of forwarding relay thatSAconsiders trusted+internal) butSAis aware of the actual domain boundary (internal_networks setting)SAwill use the results that are most accurate.
Use this option to start with the newest (top most) "Received-SPF" headers, working downwards until results are successfully parsed.
Adds capability check for ``if can()'' for check_for_spf_permerror, check_for_spf_temperror, check_for_spf_helo_permerror and check_for_spf_helo_permerror