  | 
 
 
 
 |  
 |  | 
 
  
    | 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 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. 
  - 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". 
   
 
  - 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).
 
  
  - 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". 
   
  
  - 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
 
 
 
 
  Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc.
  |