|
|
| |
Mail::SpamAssassin::Plugin::SPF(3) |
User Contributed Perl Documentation |
Mail::SpamAssassin::Plugin::SPF(3) |
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.
It's recommended to use MTA filter (pypolicyd-spf / spf-engine
etc), so this plugin can reuse the Received-SPF header results as is.
Otherwise throughput could suffer, DNS lookups done by this plugin are not
asynchronous.
- whitelist_from_spf user@example.com
- Works similarly to welcomelist_from (previously whitelist_from), except
that in addition to matching a sender address, a check against the
domain's SPF record must pass. The first parameter is an address to
whitelist, and the second is a string to match the relay's rDNS.
Just like welcomelist_from (previously 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
- def_whitelist_from_spf user@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.
- unwhitelist_from_spf user@example.com
- Used to remove a "whitelist_from_spf" or
"def_whitelist_from_spf" entry. The
specified email address has to match exactly the address previously used.
Useful for removing undesired default entries from a
distributed configuration by a local or site-specific configuration or
by "user_prefs".
- spf_timeout n (default: 5)
- How many seconds to wait for an SPF query to complete, before scanning
continues without the SPF result. A numeric value is optionally suffixed
by a time unit (s, m, h, d, w, indicating seconds (default), minutes,
hours, days, weeks).
- ignore_received_spf_header (0|1) (default: 0)
- By default, to avoid unnecessary DNS lookups, the plugin will try to use
the SPF results 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 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".
- 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 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.
- has_check_for_spf_errors
- 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
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc. |