Mail::SpamAssassin::Plugin::SPF - perform SPF verification tests
loadplugin Mail::SpamAssassin::Plugin::SPF
This plugin checks a message against Sender Policy Framework (SPF) records published by the domain owners in DNS to fight email address forgery and make it easier to identify spams.
Just like whitelist_from, multiple addresses per line, separated by spaces,
are OK. Multiple whitelist_from_spf
lines are also OK.
The headers checked for whitelist_from_spf addresses are the same headers used for SPF checks (Envelope-From, Return-Path, X-Envelope-From, etc).
Since this whitelist requires an SPF check 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.
e.g.
whitelist_from_spf joe@example.com fred@example.com whitelist_from_spf *@example.com
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.
Use this option to stop the plugin from using Mail::SPF and cause it to try to use Mail::SPF::Query instead.
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 the SPF check itself.
Note that unless the plugin finds an identity=helo
, or some unsupported
identity, it will assume that the result is a mfrom SPF check result. The
only identities supported are mfrom
, mailfrom
and helo
.
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 secondary MX (or your MXes don't
know about some sort of forwarding relay that SA considers trusted+internal)
but SA is aware of the actual domain boundary (internal_networks setting) SA
will 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.