ADC Home > Reference Library > Reference > Mac OS X > Mac OS X Man Pages

 

This document is a Mac OS X manual page. Manual pages are a command-line technology for providing documentation. You can view these manual pages locally using the man(1) command. These manual pages come from many different sources, and thus, have a variety of writing styles.

For more information about the manual page format, see the manual page for manpages(5).



Mail::SpamAssassin::Plugin::SPF(3)   User Contributed Perl Documentation  Mail::SpamAssassin::Plugin::SPF(3)



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.

USER SETTINGS
       whitelist_from_spf add@ress.com
           Use this to supplement the whitelist_from addresses with a check against the domain's SPF record.
           Aside from the name 'whitelist_from_spf', the syntax is exactly the same as the syntax for
           'whitelist_from'.

           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

       def_whitelist_from_spf add@ress.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.

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.

       do_not_use_mail_spf (0|1)          (default: 0)
           By default the plugin will try to use the Mail::SPF module for SPF checks 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_spq_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 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.



perl v5.8.8                                      2007-05-21               Mail::SpamAssassin::Plugin::SPF(3)

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.