table of contents
- NAME
- VERSION
- USAGE
- OTHER DOCUMENTATION
- SYNOPSIS
- DESCRIPTION
- OPTIONS
- LOGGING
- TEST OPERATION
- HELO/EHLO CHECKING
- HELO/EHLO PASS RESTRICTION
- Mail From CHECKING
- Mail From PASS RESTRICTION
- Limit Rejections To Domains That Send No Mail
- Domain Specific Receiver Policy
- Permanent Error Processing
- Temporary Error Processing
- Prospective SPF Check
- LOCAL SPF BYPASS LIST
- SPF IP WHITELIST
- SPF DOMAIN WHITELIST
- PTR DOMAIN WHITELIST
- RESULTS HEADER
- Authentications Results Authentication Identifier
- DNS Timeout Limit
- DNS Void Lookup Limit
- SEE ALSO
- AUTHORS
other versions
- wheezy 1.0-2
- wheezy-backports 1.3.1-1~bpo70+1
- jessie 1.3.1-1
- testing 2.0.1-1
- unstable 2.0.1-1
policy-spf.conf(5) | File Formats Manual | policy-spf.conf(5) |
NAME¶
python-policyd-spf - pure-Python Postfix policy daemon for SPF checkingVERSION¶
1.3USAGE¶
Usage:policyd-spf [/etc/postfix-policyd-spf-python/policyd-spf.conf]
OTHER DOCUMENTATION¶
This documentation assumes you have read Postfix's README_FILES/ SMTPD_POLICY_README and are generally familiar with Sender Policy Framework (SPF). See RFC 7208 for details.SYNOPSIS¶
python-policyd-spf operates with a default installed configuration file and set of default configuration options that are used if the configuration file cannot be found. These options can be changed by changing the installed configuration files or through giving a path to an alternate configuration file.DESCRIPTION¶
Configuration options are described here and in the configuration file provided with the package. The provided setup.py installs this configuration file in /etc/postfix-policyd-spf-python/.OPTIONS¶
LOGGING¶
"debugLevel" controls the amount of information logged by the policy server.TEST OPERATION¶
The policy server can operate in a test only mode. This allows you to see the potential impact of SPF checking in your mail logs without rejecting mail. Headers are prepended in messages, but message delivery is not affected. This mode is not enabled by default. To enable it, set defaultSeedOnly = 0.HELO/EHLO CHECKING¶
HELO check rejection policy options are:HELO/EHLO PASS RESTRICTION¶
HELO Pass Restriction allows integration with other Postfix access controls by provding a user supplied name of a postfix access restriction to be applied to a message when the HELO checking result is Pass. The indicated restriction must be an action as defined for a Postfix SMTP server access table access(5) and explained in the Postfix RESTRICTION CLASS README. The README.per_user_whitelisting file provided with this distribution provides examples. Note: A helo pass restriction will be the returned result even if the mail from result would cause the message to be rejected.Mail From CHECKING¶
Mail From rejection policy options are:Mail From PASS RESTRICTION¶
Mail From Pass Restriction allows integration with other Postfix access contlols by provding a user supplied name of a postfix access restriction to be applied to a message when the HELO checking result is Pass. The indicated restriction must be an action as defined for a Postfix SMTP server access table access(5) and explained in the Postfix RESTRICTION CLASS README. Note: A mail from pass restriction will be the returned result even if the helo result would cause the message to be rejected.Limit Rejections To Domains That Send No Mail¶
No_Mail - Only reject when SPF indicates the host/domain sends no mail. This option will only cause mail to be rejected if the HELO/Mail From record is "v=spf1 -all". This option is useful for rejecting mail in situations where the tolerance for rejecting wanted mail is very low. It operates on both HELO and Mail From identities if set.Domain Specific Receiver Policy¶
Using this option, a list of domains can be defined for special processing when messages do not Pass SPF. This can be useful for commonly spoofed domains that are not yet publishing SPF records with -all. Specifically, if mail from a domain in this list has a Neutral/Softfail result, it will be rejected (as if it had a Fail result). If needed, it is better to do it on a per-domain basis rather than globally.Permanent Error Processing¶
Policy for rejecting due to SPF PermError options are:Temporary Error Processing¶
Policy for deferring messages due to SPF TempError options are:Prospective SPF Check¶
Prospective SPF checking - Check to see if mail sent from the defined IP address would pass. This is useful for outbound MTAs to avoid sending mail that would Fail SPF checks when received. Disable HELO checking when using this option. It's only potentially useful for Mail From checking. SPF Received headers are not added when this option is used.LOCAL SPF BYPASS LIST¶
Do not check SPF for localhost addresses - add to skip addresses to skip SPF for internal networks if desired. Defaults are standard IPv4 and IPv6 localhost addresses. This can also be used, to allow mail from local clients submitting mail to an MTA also acting as a Mail Submission Agent (MSA) to be skipped. An x-header is prepended indicating SPF checks were skipped due to a local address. This is a trace header only. Note the lack of spaces in the list.SPF IP WHITELIST¶
A comma separated CIDR Notation list of IP addresses to skip SPF checks for. Use this list to whitelist trusted relays (such as a secondary MX and trusted forwarders). An x-header is prepended indicating the IP was whitelisted against SPF checks. This is a trace header only. Note the lack of spaces in the list.SPF DOMAIN WHITELIST¶
Domain_Whitelist: List of domains whose sending IPs should be whitelisted from SPF checks. Use this to list trusted forwarders by domain name. Client IP addresses are tested against SPF records published by the listed domains. This is useful for large forwarders with complex outbound infrastructures and SPF records. This option is less scalable than the SPF IP Whitelist. An x-header is prepended indicating the IP was whitelisted against SPF checks. This is a trace header only. This option does nothing if the domain does not have an SPF record. In this case use the SPF IP Whitelist described above or Domain_Whitelist_PTR (below). Note the lack of spaces in the list.PTR DOMAIN WHITELIST¶
Domain_Whitelist_PTR: List of domains (and subdomains) whose sending IPs should be whitelisted from SPF checks based on PTR match of the domain. Use this to list trusted forwarders by domain name if they do not publish SPF records. Client IP addresses PTR names are tested to see if they match the listed domains. This is useful for large forwarders with complex outbound infrastructures, but no SPF records and predictable host naming. Matching is done using the same rules as the SPF PTR mechanism as described in RFC 7208. List the parent domain and all subdomains will match. This option is less scalable than the SPF IP Whitelist. An x-header is prepended indicating the IP was whitelisted against SPF checks. This is a trace header only. This option does nothing if the host does not have a PTR record record. In this case use the SPF IP Whitelist described above. Note the lack of spaces in the list.RESULTS HEADER¶
The standard method for documenting SPF results in a message (for consumption by downstream processes) is the Received-SPF header defined in RFC 7208. This is the default header to use. Results can also be documented in the Authentication-Results header, which is also covered in RFC 7208. The default is Received-SPF (SPF), but inclusion of Authentication-Results (AR) headers as an alternative to Received-SPF can be specified.Authentications Results Authentication Identifier¶
Every Authentication-Results header field has an authentication identifier field ('Authserv_Id'). This is similar in syntax to a fully-qualified domain name. See policyd-spf.conf.5 and RFC 7001 paragraph 2.4 for details. Default is None. Authserv-Id must be provided if Header_Type 'AR' is used.DNS Timeout Limit¶
RFC 7208 recommends an elapsed time limit for SPF checks of at least 20 seconds. Lookup_Time allows the maximum time (seconds) to be adjusted. 20 seconds is the default.DNS Void Lookup Limit¶
RFC 7208 adds a new processing limit called "void lookup limit" (See section 4.6.4). Void lookups are DNS queries within an SPF record for which DNS queries return either a positive answer (RCODE 0) with an answer count of 0, or a "Name Error" (RCODE 3) answer. This should not need to be changed. Although new in an RFC in RFC 7208, this limit has been widely deployed in the Mail::SPF perl library without issue. Default is 2, but it can be adjusted. Only relevant for pyspf 2.0.9 and later. Ignored for earlier releases.SEE ALSO¶
man 1 policyd-spf, man 5 policyd-spf.peruser, python-spf, <http://www.openspf.net>, RFC 7208, RFC 7001AUTHORS¶
This version of pypolicyd-spf was written by Copyright © 2007-2012, Scott Kitterman <scott@kitterman.com>. It is derived from Tumgreyspf, written by Sean Reifschneider, tummy.com, ltd <jafo@tummy.com>. Portions of the documentation were written by Meng Weng Wong <mengwong@pobox.com>. This man-page was created by Scott Kitterman <scott@kitterman.com>.2012-03-17 |