CentOS 7のpostfixにSPF(Sender Policy Framework)を組込んでみました｡
IAjapan 財団法人インターネット協会 – Internet Association Japan
SPF（Sender Policy Framework）
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/
余談ですが財団法人インターネット協会はまだhttps化されていないのですね｡
以前はpostfix-policyd-spf-perlを組込んで使用していました｡
今回はepel repoにpypolicyd-spfがあったのでこちらを使うことにしました｡
SPF認証のためのPostfixポリシーエンジンって言うぐらいだから最適化されているのかな｡
なお､送信側設定(DNS設定)は上記サイトと同じなので省略します｡
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
# yum install epel-release # yum info pypolicyd-spf Available Packages Name : pypolicyd-spf Arch : noarch Version : 1.3.2 Release : 1.el7 Size : 44 k Repo : epel/x86_64 Summary : SPF Policy Server for Postfix (Python implementation) URL : https://launchpad.net/pypolicyd-spf License : ASL 2.0 Description : pypolicyd-spf is a Postfix policy engine for Sender Policy Framework (SPF) : checking. It is implemented in pure Python and uses the python-spf (pyspf) : module. : : This SPF policy server implementation provides flexible options for different : receiver policies and sender whitelisting to enable it to support a very wide : range of requirements. # repoquery --list pypolicyd-spf /etc/python-policyd-spf /etc/python-policyd-spf/policyd-spf.conf /usr/lib/python2.7/site-packages/policydspfsupp.py /usr/lib/python2.7/site-packages/policydspfsupp.pyc /usr/lib/python2.7/site-packages/policydspfsupp.pyo /usr/lib/python2.7/site-packages/policydspfuser.py /usr/lib/python2.7/site-packages/policydspfuser.pyc /usr/lib/python2.7/site-packages/policydspfuser.pyo /usr/lib/python2.7/site-packages/pypolicyd_spf-1.3.2-py2.7.egg-info /usr/libexec/postfix/policyd-spf /usr/share/doc/pypolicyd-spf-1.3.2 /usr/share/doc/pypolicyd-spf-1.3.2/CHANGES /usr/share/doc/pypolicyd-spf-1.3.2/COPYING /usr/share/doc/pypolicyd-spf-1.3.2/README /usr/share/doc/pypolicyd-spf-1.3.2/README.per_user_whitelisting /usr/share/doc/pypolicyd-spf-1.3.2/policyd-spf.conf.commented /usr/share/man/man1/policyd-spf.1.gz /usr/share/man/man5/policyd-spf.conf.5.gz /usr/share/man/man5/policyd-spf.peruser.5.gz |
- インストール
- master.cfの設定
- main.cfの設定
- policyd-spf.confの設定
- postfix再起動
|
1 2 3 4 5 6 7 8 9 |
# yum -y install pypolicyd-spf (snip) Installed: pypolicyd-spf.noarch 0:1.3.2-1.el7 Dependency Installed: python-ipaddr.noarch 0:2.1.9-5.el7 python-pydns.noarch 0:2.3.6-1.el7 python-pyspf.noarch 0:2.0.11-1.el7 Complete! |
/etc/postfix/master.cfに下記の行を追加します｡
|
1 2 3 |
# Sender Policy Framework(pypolicyd-spf) policy-spf unix - n n - 0 spawn user=nobody argv=/usr/libexec/postfix/policyd-spf |
/etc/postfix/main.cfに下記の行を追加します｡
|
1 2 3 4 5 6 |
smtpd_recipient_restrictions = permit_mynetworks, ................., reject_unauth_destination, check_policy_service unix:private/policy-spf policy-spf_time_limit = 3600 |
SPF認証のステータスコードでメール受信の判断をする設定ファイルです｡
デフォルトは下記になっています｡有効にする場合はしっかりドキュメントを読んで設定しないと必要なメールを受信拒否になりそうでちょっと怖いですね｡
なお､SPF認証結果は下記のものがあります｡
(上記IAjapanのサイトから引用しました)
6. SPF認証結果
認証結果は次のものが存在する。
認証結果: 意味
None: SPFレコードが公開されていない
Neutral: SPFレコードが“?”として公開されている条件にマッチした
Pass: 認証処理に成功した
Fail: SPFレコードが公開されているが、認証に失敗した
SoftFail: SPFレコードが“~”として公開されている条件にマッチした
TempError: 一時的な障害で認証処理が失敗した
PermError: SPFレコードの記述に誤りがあるなどで認証処理に失敗した
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# cat /etc/python-policyd-spf/policyd-spf.conf # For a fully commented sample config file see policyd-spf.conf.commented debugLevel = 1 defaultSeedOnly = 1 HELO_reject = Fail Mail_From_reject = Fail PermError_reject = False TempError_Defer = False skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1 |
manから抜粋
|
1 2 3 4 5 6 |
LOGGING "debugLevel" controls the amount of information logged by the policy server. The default, 1, logs no debugging messages, just basic SPF results and errors generated through the policy server. This value can be increased up to 5 (values higher than 5 will not cause an error, but will not log any additional information). |
debugLevel=1は基本的なSPF認証結果を記録します｡ログレベルは1～5まであり5が最も詳細に記録します｡
|
1 2 3 4 5 6 7 |
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. Default: defaultSeedOnly = 1 |
defaultSeedOnlyはテストオプションの指定で1はSPF認証の結果にかかわらずすべて受信し､認証結果をログに記録します｡これがデフォルトです｡
SPF認証によって受信可否を実行する場合はdefaultSeedOnly = 0に変更します｡
|
1 2 |
# postfix check # systemctl restart postfix |
取り敢えずここまで｡英語ができないからmanを読んでいてpolicyd-spf.confの情報が怪しいけどまいっか(^^;
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 |
policy-spf(1) General Commands Manual policy-spf(1) NAME python-policyd-spf - pure-Python Postfix policy daemon for SPF checking VERSION 1.3 USAGE NOTE: Depending on the packaging and distribution, the exact path to the executable may vary. $ policyd-spf (Start using installed config file) $ policyd-spf -h (Display usage message) $ policyd-spf /etc/policyd-spf/policyd-spf.conf (Config file name to use) Configuration options are described in the sample configuration file provided with the package (poli- cyd-spf.conf.commented) and in policyd-spf.conf(5). The provided setup.py installs an uncommented con- figuration file in /etc/policyd-spf/. Additionally, whitelisting certain IP addresses or IP addresses used by listed domains from SPF checks is supported. Skipping SPF checks for local submission or trusted relays is also provided. The sample configuration file and policyd-spf.conf(5) shows the format to use. 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. See man 5 policyd-spf.conf for configuration file information. man 5 policyd-spf.peruser provides documentation on setting up and using different configuration options on a per user (mail reciepient) basis. SYNOPSIS python-policyd-spf is a Postfix SMTPd policy daemon for SPF checking. It is implemented in pure Python and uses the pyspf module. The SPF web site is http://www.openspf.org/. The Postfix configuration must be changed to check SPF. DESCRIPTION Logging is sent to syslogd. Each time a Postfix SMTP server process is started it connects to the policy service socket and Postfix runs one instance of this Python script. By default, a Postfix SMTP server process terminates after 100 seconds of idle time, or after serving 100 clients. Thus, the cost of starting this Python script is smoothed over time The default policy_time_limit is 1000 seconds. This may be too short for some SMTP transactions to complete. As recommended in SMTPD_POLICY_README, this should be extended to 3600 seconds. To do so, set "policy_time_limit = 3600" in /etc/postfix/main.cf. Messages that get a Fail SPF result will be rejected. Messages that get a Permerror are, by default, treated as if they had no SPF record. Messages that get a Temperror result are, by default, treated as if they had no SPF record, but can (and probably should) be deferred if otherwise permitted. Messages that get other SPF results (Pass, None, Neutral, Softfail) will have the SPF Received header prepended. Note: Spamasassisn 3.2 and follow will use this header for spam scoring so there is no need to config- ure a separate SPF check in these Spamassassin versions. See Spamassassin documentation for details. Default Mail From rejection/deferal criteria are, by design, conservative. Default HELO check actions are to reject mail with other than Pass/None. HELO records are much simpler than Mail From records and rejecting based on HELO checking does not present a false positive risk. These settings are a matter of local policy and should be adjusted to meet the requirements of site administrators. See policyd- spf.conf(5) for configuration file details. LOGGING Policyd-spf will log messages to syslog about it's activities. The "debugLevel" value in "policyd- spf.conf" can be increased to get additional information to be logged. When set to a value of "0", only test results (SPF hits/misses) are logged. Results will be returned to Postfix and logged as a warning by Postfix also. For logging by this policy server, look for "policyd-spf" in your mail log files. TESTING THE POLICY DAEMON Testing the policy daemon To test the policy daemon by hand, execute: policyd-spf Each query is a bunch of attributes. Order does not matter, and the daemon uses only a few of all the attributes shown below: request=smtpd_access_policy protocol_state=RCPT protocol_name=SMTP helo_name=some.domain.tld queue_id=8045F2AB23 instance=12345.6789 sender=foo@bar.tld recipient=bar@foo.tld client_address=1.2.3.4 client_name=another.domain.tld [empty line] The policy daemon will answer in the same style, with an attribute list followed by a empty line: action=dunno [empty line] POSTFIX INTEGRATION 1. Add the following to /etc/postfix/master.cf: policyd-spf unix - n n - 0 spawn user=nobody argv=/usr/bin/policyd-spf NOTE: Check the path to both the installed Python interpreter and policyd-spf. These vary from system to system. To use non-default settings, you must also add the config file (see above and policyd-spf.conf(5) for details). If you run other services with user nobody, create a dedicated user for this policy server and use that instead. 2. Configure the Postfix policy service in /etc/postfix/main.cf: smtpd_recipient_restrictions = ... reject_unauth_destination check_policy_service unix:private/policyd-spf ... policyd-spf_time_limit = 3600 NOTE: Specify check_policy_service AFTER reject_unauth_destination or else your system can become an open relay. 3. Reload Postfix. SEE ALSO policyd-spf.conf(5), policyd-spf.peruser(5), python-spf, <http://www.openspf.org>, RFC 7208 AUTHORS This version of python-policyd-spf was written by Copyright (C) 2007-2012 Scott Kitterman <scott@kit- terman.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 policy-spf(1) |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 |
policy-spf.conf(5) File Formats Manual policy-spf.conf(5) NAME python-policyd-spf - pure-Python Postfix policy daemon for SPF checking VERSION 1.3 USAGE Usage: policyd-spf [/etc/policyd-spf/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. man 1 policyd-spf provides general operation documentation for this package. man 5 policyd-spf.peruser provides documentation on setting up and using different configuration options on a per user (mail reciepient) basis. SYNOPSIS python-policyd-spf operates with a default installed configuration file and set of default configura- tion 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/policyd-spf/. Additionally, whitelisting certain IP addresses from SPF checks is supported. This man page and the sample configuration file show the format to use. These options can be adjusted on a per user (mail recipient) basis. Details on per user settings can be found in policyd-spf.peruser(5). OPTIONS LOGGING "debugLevel" controls the amount of information logged by the policy server. The default, 1, logs no debugging messages, just basic SPF results and errors generated through the policy server. This value can be increased up to 5 (values higher than 5 will not cause an error, but will not log any additional information). debug level 2 adds a log message if no client address (IP address from which the connection was made), Mail From addresss, or HELO/EHLO name is received by the policy server, and logs SPF results for each Mail From and HELO check. debug level 3 generates a log message each time the policy server starts and each time it exits, as well as logging a copy of the exact header returned to Postfix to be prepended into the message. Each time the policy server starts, debug level 3 also logs the configuration information used by the policy server. debug level 4 logs the complete data set received by Postfix via the policy interface and when the end of the entry is read. debug level 5 is used to debug config file processing and can only be set in code and not via the con- fig file. If debug level is 0, then the policy server logs errors only. Default: debugLevel = 1 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. Default: defaultSeedOnly = 1 HELO/EHLO CHECKING HELO check rejection policy options are: SPF_Not_Pass (default) - Reject if result not Pass, None, or Temperror (alternatively put, reject if the SPF result is Fail, Softfail, Neutral, PermError). Unlike Mail From checking, there are no standard e-mail use cases where a HELO check should not Pass if there is an SPF record for the HELO name (trans- parent forwarding, for example, is not an issue). HELO/EHLO is known first in the SMTP dialogue and there is no practical reason to waste resources on Mail From checks if the HELO check will already cause the message to be rejected. This should not cause interoperability problems when used for HELO. Softfail - Reject on HELO Softfail or Fail. HELO/EHLO is known first in the SMTP dialogue and there is no practical reason to waste resources on Mail From checks if the HELO check will already cause the message to be rejected. This should not cause interoperability problems when used for HELO. Fail - Reject only on HELO Fail. HELO/EHLO is known first in the SMTP dialogue and there is no practi- cal reason to waste resources on Mail From checks if the HELO check will already cause the message to be rejected. This should not cause interoperability problems when used for HELO. Null - Only reject HELO Fail for Null sender (SPF Classic). This is the approach used by the pre-RFC 4408 reference implementation and many of the pre- RFC specifications. Use of at least this option (SPF_Not_Pass or Fail) are preferred) is highly recommended. False - Never reject on HELO, append header only. This is useful for post-SMTP spam filters such as SpamAssassin. No_Check - Never check HELO. This is only recommended if you are calling the policy server twice (once for HELO checks and once for Mail From) with two different configuration files. This approach is use- ful to get both the HELO and Mail From headers prepended to a message. Default: HELO_reject = SPF_Not_Pass 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. Example: HELO_pass_restriction = helo_passed_spf Default: None Mail From CHECKING Mail From rejection policy options are: SPF_Not_Pass - Reject if result not Pass/None/Tempfail. This option is not RFC 7208 compliant since the mail with an SPF Neutral result is treated differently than mail with no SPF record and Softfail results are not supposed to cause mail rejection. Global use of this option is not recommended. Use per-domain if needed (per-domain usage described below). Softfail - Reject on Mail From Softfail or Fail. Global use of this option is not recommended. Use per-domain if needed (per-domain usage described below). Fail (default) - Reject on Mail From Fail. False - Never reject on Mail From, append header only. This is useful for post-SMTP spam filters such as SpamAssassin. No_Check - Never check Mail From/Return Path. This is only recommended if you are calling the policy server twice (once for HELO checks and once for Mail From) with two different configuration files. This approach is useful to get both the HELO and Mail From headers prepended to a message. It could also be used to do HELO checking only (because HELO checking has a lower false positive risk than Mail From checking), but this approach may not be fully RFC 7208 compliant since the Mail From identity is mandatory if HELO checking does not reach a definitive result. Default: Mail_From_reject = Fail 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. Example: mail_from_pass_restriction = mfrom_passed_spf Default: None 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. Default: No_Mail = False 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. Example: Reject_Not_Pass_Domains = aol.com,hotmail.com Default: None Permanent Error Processing Policy for rejecting due to SPF PermError options are: True - Reject the message if the SPF result (for HELO or Mail From) is PermError. This has a higher short-term false positive risk, but does result in senders getting feedback that they have a problem with their SPF record. False - Treat PermError the same as no SPF record at all. This is consistet with the pre-RFC usage (the pre-RFC name for this error was "Unknown"). This is a global option that affects both HELO and Mail From scopes when checks for that scope are enabled. The only per scope setting that can over-ride this is Mail_From/HELO_reject = False/ Default: PermError_reject = False Temporary Error Processing Policy for deferring messages due to SPF TempError options are: True - Defer the message if the SPF result (for HELO or Mail From) is TempError. This is the tradi- tional usage and has proven useful in reducing acceptance of unwanted messages. Sometimes spam senders do not retry. Sometimes by the time a message is retried the sending IP has made it onto a DNS RBL and can then be rejected. This is not the default because it is possible for some DNS errors that are classified as "Temporary" per RFC 7208 to be permanent in the sense that they require operator inter- vention to correct. This is a global option that affects both HELO and Mail From scopes when checks for that scope are enabled. The only per scope setting that can over-ride this is Mail_From/HELO_reject = False/ False - Treat TempError the same as no SPF record at all. This is the default to minimize false posi- tive risk. Default: TempError_Defer = False 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. Prospective = 192.168.0.4 Default: None 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. Default: skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1 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. Example: Whitelist = 192.168.0.0/31,192.168.1.0/30 Default: None 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 indi- cating the IP was whitelisted against SPF checks. This is a trace header only. This option does noth- ing 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. Example: Domain_Whitelist = pobox.com,trustedforwarder.org Default: None 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 scal- able 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. Example: Domain_Whitelist_PTR = yahoo.com,yahoogroups.com Default: None 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. If there is a requirement to prepend both Received-SPF and Authentication- Results headers, then it must be done by processing the message with more than one instance of the policy server using different configuration files with different Header_Type settings. Examples: Header_Type = SPF or Header_Type = AR Default: SPF 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. The authentication identifier field provides a unique identifier that refers to the authenticating ser- vice within a given administrative domain. The identifier MUST be unique to that domain. This identi- fier is intended to be machine-readable and not necessarily meaningful to users. Example: Authserv_Id = mx.example.com 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. Example: Lookup_Time = 20 Default 20 (seconds) 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. Example: Void_Limit = 2 Default 2 SEE ALSO man 1 policyd-spf, man 5 policyd-spf.peruser, python-spf, <http://www.openspf.net>, RFC 7208, RFC 7001 AUTHORS This version of pypolicyd-spf was written by Copyright (C) 2007-2012, Scott Kitterman <scott@kitter- man.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 policy-spf.conf(5) |