Mail::SpamAssassin::Plugin::SPF

Mail::SpamAssassin::PUsernContributed Perl 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-Enve-
	   lope-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 plu-
	   gin 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 inter-
	   nal 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			  2008-01-0Mail::SpamAssassin::Plugin::SPF(3)