NAME

       Mail::SpamAssassin::Plugin::SPF - perform SPF verification tests

SYNOPSIS

         loadplugin     Mail::SpamAssassin::Plugin::SPF

DESCRIPTION

       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 and/or Authentication-Results header results as is.  Otherwise
       throughput could suffer, DNS lookups done by this plugin are not asynchronous.  Those
       headers will also help when SpamAssassin is not able to correctly detect EnvelopeFrom.

USER SETTINGS

       welcomelist_from_spf user@example.com
           Previously whitelist_from_spf which will work interchangeably until 4.1.

           Works similarly to welcomelist_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 welcomelist, and the second is a string to match the relay's rDNS.

           Just like welcomelist_from, multiple addresses per line, separated by spaces, are OK.
           Multiple "welcomelist_from_spf" lines are also OK.

           The headers checked for welcomelist_from_spf addresses are the same headers used for
           SPF checks (Envelope-From, Return-Path, X-Envelope-From, etc).

           Since this welcomelist 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.

             welcomelist_from_spf joe@example.com fred@example.com
             welcomelist_from_spf *@example.com

       def_welcomelist_from_spf user@example.com
           Previously def_whitelist_from_spf which will work interchangeably until 4.1.

           Same as "welcomelist_from_spf", but used for the default welcomelist entries in the
           SpamAssassin distribution.  The welcomelist score is lower, because these are often
           targets for spammer spoofing.

       unwelcomelist_from_spf user@example.com
           Previously unwhitelist_from_spf which will work interchangeably until 4.1.

           Used to remove a "welcomelist_from_spf" or "def_welcomelist_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".

ADMINISTRATOR OPTIONS

       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

       has_check_spf_skipped_noenvfrom
           Adds capability check for "if can()" for check_spf_skipped_noenvfrom

           check_spf_skipped_noenvfrom
               Checks if SPF checks have been skipped because EnvelopeFrom cannot be determined.