1policy-spf.conf(5) File Formats Manual policy-spf.conf(5)
3
7 policyd-spf - policyd-spf python configuration parameters
8
10 3.0.2
11
14 Usage:
15 policyd-spf [/etc/policyd-spf/policyd-spf.conf]
16
19 This documentation assumes you have read Postfix's README_FILES/
20 SMTPD_POLICY_README and are generally familiar with Sender Policy
21 Framework (SPF). See RFC 7208 for details.
22 man 1 policyd-spf provides general operation documentation for this
24 package.
25 man 5 policyd-spf.peruser provides documentation on setting up and us‐
27 ing different configuration options on a per user (mail reciepient) ba‐
28 sis.
29
32 spf-engine provides both a Postfix policy server front end and a milter
33 front end that can be used with any mail server which supports the mil‐
34 ter protocol. Most options apply to both policy server and milter us‐
35 age. Options specific to the milter are listed at the end. The pack‐
36 age operates with a default installed configuration file and set of de‐
37 fault configuration options that are used if the configuration file
38 cannot be found. These options can be changed by changing the in‐
39 stalled configuration files or through giving a path to an alternate
40 configuration file.
41
44 Additionally, whitelisting certain IP addresses from SPF checks is sup‐
45 ported. This man page and the sample configuration file show the for‐
46 mat to use. These options can be adjusted on a per user (mail recipi‐
47 ent) basis. Details on per user settings can be found in policyd-
48 spf.peruser(5). Per user settings are applicable only to the policy
49 server.
50
54 "debugLevel" controls the amount of information logged by the policy
55 server.
56 The default, 1, logs no debugging messages, just basic policy results
58 and errors generated through the policy server. This value can be in‐
59 creased up to 5 (values higher than 5 will not cause an error, but will
60 not log any additional information).
61 debug level 2 adds a log message if no client address (IP address from
63 which the connection was made), Mail From address, or HELO/EHLO name is
64 received by the policy server, and logs SPF results for each Mail From
65 and HELO check.
66 debug level 3 generates a log message each time the policy server
68 starts and each time it exits, as well as logging a copy of the exact
69 header returned to Postfix to be prepended into the message. Each time
70 the policy server starts, debug level 3 also logs the configuration in‐
71 formation used by the policy server.
72 debug level 4 logs the complete data set received by Postfix via the
74 policy interface and when the end of the entry is read.
75 debug level 5 is used to debug config file processing and, for this
77 purpose, can only be set in code and not via the config file. It also
78 provides additional internal status details generally of interest only
79 to developers.
80 If debug level is 0, then the policy server logs errors only.
82 When set to -1, nothing is logged once the configuration file has been
84 read in, not even error messages. Use with caution.
85 Default:
87 debugLevel = 1
89
92 The policy server can operate in a test only mode. This allows you to
93 see the potential impact of SPF checking in your mail logs without re‐
94 jecting mail. Headers are prepended in messages, but message delivery
95 is not affected. This mode is not enabled by default. To enable it,
96 set TestOnly = 0. If you want test operation with no header added,
97 also set Header_Type = None.
98 Note: This option was previously named defaultSeedOnly. This is still
100 accepted, but logs an error.
101 Default:
103 TestOnly = 1
105
108 HELO check rejection policy options are:
109 Fail - (Default) Reject only on HELO Fail. HELO/EHLO is known first in
111 the SMTP dialogue and there is no practical reason to waste resources
112 on Mail From checks if the HELO check will already cause the message to
113 be rejected. This should not cause interoperability problems when used
114 for HELO.
115 SPF_Not_Pass - Reject if result not Pass, None, or Temperror (alterna‐
117 tively put, reject if the SPF result is Fail, Softfail, Neutral, PermE‐
118 rror). Unlike Mail From checking, there are no standard e-mail use
119 cases where a HELO check should not Pass if there is an SPF record for
120 the HELO name (transparent forwarding, for example, is not an issue).
121 HELO/EHLO is known first in the SMTP dialogue and there is no practical
122 reason to waste resources on Mail From checks if the HELO check will
123 already cause the message to be rejected. This is not consistent with
124 the RFC 7208 requirement to treat none and neutral the same, but should
125 not cause interoperability problems when used for HELO.
126 Softfail - Reject on HELO Softfail or Fail. HELO/EHLO is known first
128 in the SMTP dialogue and there is no practical reason to waste re‐
129 sources on Mail From checks if the HELO check will already cause the
130 message to be rejected. This should not cause interoperability prob‐
131 lems when used for HELO.
132 Null - Only reject HELO Fail for Null sender (SPF Classic). This is
134 the approach used by the pre-RFC 4408 reference implementation and many
135 of the pre- RFC specifications. Use of at least this option
136 (SPF_Not_Pass or Fail) are preferred) is highly recommended.
137 False - Never reject on HELO, append header only. This is useful for
139 post-SMTP spam filters such as SpamAssassin.
140 No_Check - Never check HELO. This is only recommended if you are call‐
142 ing the policy server twice (once for HELO checks and once for Mail
143 From) with two different configuration files. This approach is useful
144 to get both the HELO and Mail From headers prepended to a message.
145 Default:
147 HELO_reject = Fail
149
152 HELO Pass Restriction allows integration with other Postfix access con‐
153 trols by provding a user supplied name of a postfix access restriction
154 to be applied to a message when the HELO checking result is Pass. The
155 indicated restriction must be an action as defined for a Postfix SMTP
156 server access table access(5) and explained in the Postfix RESTRICTION
157 CLASS README. The README.per_user_whitelisting file provided with this
158 distribution provides examples. Note: A helo pass restriction will be
159 the returned result even if the mail from result would cause the mes‐
160 sage to be rejected.
161 Example:
164 HELO_pass_restriction = helo_passed_spf
166 Default:
168 None
170
173 Mail From rejection policy options are:
174 SPF_Not_Pass - Reject if result not Pass/None/Tempfail. This option is
176 not RFC 7208 compliant since the mail with an SPF Neutral result is
177 treated differently than mail with no SPF record and Softfail results
178 are not supposed to cause mail rejection. Global use of this option is
179 not recommended. Use per-domain if needed (per-domain usage described
180 below).
181 Softfail - Reject on Mail From Softfail or Fail. Global use of this
183 option is not recommended. Use per-domain if needed (per-domain usage
184 described below).
185 Fail (default) - Reject on Mail From Fail.
187 False - Never reject on Mail From, append header only. This is useful
189 for post-SMTP spam filters such as SpamAssassin.
190 No_Check - Never check Mail From/Return Path. This is only recommended
192 if you are calling the policy server twice (once for HELO checks and
193 once for Mail From) with two different configuration files. This ap‐
194 proach is useful to get both the HELO and Mail From headers prepended
195 to a message. It could also be used to do HELO checking only (because
196 HELO checking has a lower false positive risk than Mail From checking),
197 but this approach may not be fully RFC 7208 compliant since the Mail
198 From identity is mandatory if HELO checking does not reach a definitive
199 result.
200 Default:
202 Mail_From_reject = Fail
204
207 Mail From Pass Restriction allows integration with other Postfix access
208 contlols by provding a user supplied name of a postfix access restric‐
209 tion to be applied to a message when the Mail From checking result is
210 Pass. The indicated restriction must be an action as defined for a
211 Postfix SMTP server access table access(5) and explained in the Postfix
212 RESTRICTION CLASS README. The README.per_user_whitelisting file pro‐
213 vided with this distribution provides examples. Note: A mail from pass
214 restriction will be the returned result even if the helo result would
215 cause the message to be rejected.
216 Example:
218 Mail_From_pass_restriction = mfrom_passed_spf
220 Default:
222 None
224
227 No_Mail - Only reject when SPF indicates the host/domain sends no mail.
228 This option will only cause mail to be rejected if the HELO/Mail From
229 record is "v=spf1 -all". This option is useful for rejecting mail in
230 situations where the tolerance for rejecting wanted mail is very low.
231 It operates on both HELO and Mail From identities if set.
232 Default:
234 No_Mail = False
236
239 Using this option, a list of domains can be defined for special pro‐
240 cessing when messages do not Pass SPF. This can be useful for commonly
241 spoofed domains that are not yet publishing SPF records with -all.
242 Specifically, if mail from a domain in this list has a Neutral/Softfail
243 result, it will be rejected (as if it had a Fail result). If needed,
244 it is better to do it on a per-domain basis rather than globally.
245 Example:
247 Reject_Not_Pass_Domains = aol.com,hotmail.com
249 Default:
251 None
253
256 Policy for rejecting due to SPF PermError options are:
257 True - Reject the message if the SPF result (for HELO or Mail From) is
259 PermError. This has a higher short-term false positive risk, but does
260 result in senders getting feedback that they have a problem with their
261 SPF record.
262 False - Treat PermError the same as no SPF record at all. This is con‐
264 sistet with the pre-RFC usage (the pre-RFC name for this error was "Un‐
265 known").
266 This is a global option that affects both HELO and Mail From scopes
268 when checks for that scope are enabled. The only per scope setting that
269 can over-ride this is Mail_From/HELO_reject = False/
270 Default:
272 PermError_reject = False
274
277 Policy for deferring messages due to SPF TempError options are:
278 True - Defer the message if the SPF result (for HELO or Mail From) is
280 TempError. This is the traditional usage and has proven useful in re‐
281 ducing acceptance of unwanted messages. Sometimes spam senders do not
282 retry. Sometimes by the time a message is retried the sending IP has
283 made it onto a DNS RBL and can then be rejected. This is not the de‐
284 fault because it is possible for some DNS errors that are classified as
285 "Temporary" per RFC 7208 to be permanent in the sense that they require
286 operator intervention to correct.
287 This is a global option that affects both HELO and Mail From scopes
289 when checks for that scope are enabled. The only per scope setting that
290 can over-ride this is Mail_From/HELO_reject = False/
291 False - Treat TempError the same as no SPF record at all. This is the
293 default to minimize false positive risk.
294 Default:
296 TempError_Defer = False
298
301 Prospective SPF checking - Check to see if mail sent from the defined
302 IP address would pass. This is useful for outbound MTAs to avoid send‐
303 ing mail that would Fail SPF checks when received. Disable HELO check‐
304 ing when using this option. It's only potentially useful for Mail From
305 checking. SPF Received headers are not added when this option is used.
306 Prospective = 192.168.0.4
308 Default:
310 None
312
315 Do not check SPF for localhost addresses - add to skip addresses to
316 skip SPF for internal networks if desired. Defaults are standard IPv4
317 and IPv6 localhost addresses. This can also be used, to allow mail from
318 local clients submitting mail to an MTA also acting as a Mail Submis‐
319 sion Agent (MSA) to be skipped. An x-header is prepended indicating
320 SPF checks were skipped due to a local address. This is a trace header
321 only. Note the lack of spaces in the list.
322 Default:
324 skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1
326
329 A comma separated CIDR Notation list of IP addresses to skip SPF checks
330 for. Use this list to whitelist trusted relays (such as a secondary MX
331 and trusted forwarders). An x-header is prepended indicating the IP
332 was whitelisted against SPF checks. This is a trace header only. Note
333 the lack of spaces in the list.
334 Example:
336 Whitelist = 192.168.0.0/31,192.168.1.0/30
338 Default:
340 None
342
345 A comma separated HELO/EHLO host names to skip SPF checks for. Use
346 this list to whitelist trusted relays (such as a secondary MX and
347 trusted forwarders) or to work around a host with a buggy SPF record.
348 An x-header is prepended indicating the host was whitelisted against
349 SPF checks. This is a trace header only. Note the lack of spaces in
350 the list.
351 This option includes a check to ensure the connect IP address is refer‐
353 enced in an A or AAAA record by the HELO/EHLO domain that is
354 whitelisted. This is to avoid inadvertent bypass of SPF checks if
355 HELO/EHLO names are forged. If a HELO/EHLO domain is unable to pass
356 such a forward IP address match check, then use an SPF IP Whitelist for
357 the host's IP address instead.
358 Example:
360 HELO_Whitelist = relay.example.com,sender.example.org
362 Default:
364 None
366
369 Domain_Whitelist: List of domains whose sending IPs should be
370 whitelisted from SPF checks. Use this to list trusted forwarders by
371 domain name. Client IP addresses are tested against SPF records pub‐
372 lished by the listed domains. This is useful for large forwarders with
373 complex outbound infrastructures and SPF records. This option is less
374 scalable than the SPF IP Whitelist. An x-header is prepended indicat‐
375 ing the IP was whitelisted against SPF checks. This is a trace header
376 only. This option does nothing if the domain does not have an SPF
377 record. In this case use the SPF IP Whitelist described above or Do‐
378 main_Whitelist_PTR (below). Note the lack of spaces in the list.
379 Example:
381 Domain_Whitelist = pobox.com,trustedforwarder.org
383 Default:
385 None
387
390 Domain_Whitelist_PTR: List of domains (and subdomains) whose sending
391 IPs should be whitelisted from SPF checks based on PTR match of the do‐
392 main. Use this to list trusted forwarders by domain name if they do not
393 publish SPF records. Client IP addresses PTR names are tested to see
394 if they match the listed domains. This is useful for large forwarders
395 with complex outbound infrastructures, but no SPF records and predict‐
396 able host naming. Matching is done using the same rules as the SPF PTR
397 mechanism as described in RFC 7208. List the parent domain and all
398 subdomains will match. This option is less scalable than the SPF IP
399 Whitelist. An x-header is prepended indicating the IP was whitelisted
400 against SPF checks. This is a trace header only. This option does
401 nothing if the host does not have a PTR record record. In this case
402 use the SPF IP Whitelist described above. Note the lack of spaces in
403 the list.
404 Example:
406 Domain_Whitelist_PTR = yahoo.com,yahoogroups.com
408 Default:
410 None
412
415 By default, Postfix will use the 4/5.7.1 enhanced status code for de‐
416 fer/reject actions from the policy server (originally defined in RFC
417 1893, RFC 3463 is the current reference). New email authentication
418 (including SPF) specific codes were defined in RFC 7372. The policy
419 server now overrides the Postfix enhanced status codes to use the RFC
420 7372 values. This can be disabled by setting this option to "No" in
421 the event of interoperability issues.
422 Example:
424 SPF_Enhanced_Status_Codes = No
426 Default:
428 Yes
430
433 The standard method for documenting SPF results in a message (for con‐
434 sumption by downstream processes) is the Received-SPF header defined in
435 RFC 7208. This is the default header to use. Results can also be docu‐
436 mented in the Authentication-Results header, which is also covered in
437 RFC 7208. The default is Received-SPF (SPF), but inclusion of Authenti‐
438 cation-Results (AR) headers as an alternative to Received-SPF can be
439 specified.
440 If there is a requirement to prepend both Received-SPF and Authentica‐
442 tion- Results headers, then it must be done by processing the message
443 with more than one instance of the policy server using different con‐
444 figuration files with different Header_Type settings.
445 For no header at all, use Header_Type = None.
447 Examples:
449 Header_Type = SPF or Header_Type = AR
451 Default:
453 SPF
455
458 Both Received-SPF and Authentication-Results (AR) header fields include
459 the receiving (RCPT TO) host, if available. In this application, it
460 will always be the host of the first recipient sent by the sending MTA,
461 even if that recipient is a BCC recipient. This is unavoidable as nei‐
462 ther the Postfix policy interface nor the milter interface provides any
463 indication if the recipient is BCC or not (this information is not
464 available in until after SMTP DATA in the body of the message). This
465 presented a possible avenue for a privacy breach, but in version 3.0 it
466 was modified to be only the host name and not the full address.
467 Hide_Receiver can set to Yes interest of maximizing privacy. If per
469 user processing is not in use, this setting will replace the actual
470 host name with <UNKNOWN> both in header fields and SMTP responses. The
471 latter may make it more difficult for senders to troubleshoot issues
472 with their SPF deployments. As an implementation detail, currently
473 specifying any value other than No will result in the recipient being
474 hidden, but that may change in the future. If per user processing is
475 in use, this setting has no effect.
476 For the milter interface, checks are always done at the Mail From stage
478 in the SMTP protocol, so receiver data is never available. When using
479 the milter, this setting has no effect.
480 Examples:
482 Hide_Receiver = Yes or Hide_Receiver = No
484 Default:
486 No
488
491 Every Authentication-Results header field has an authentication identi‐
492 fier field ('Authserv_Id'). This is similar in syntax to a fully-quali‐
493 fied domain name. See policyd-spf.conf.5 and RFC 7001 paragraph 2.4 for
494 details. Default is HOSTNAME. The results of socket.gethostname will
495 be used unless an alternate value is specified. An Authserv-Id must be
496 provided if Header_Type 'AR' is used.
497 The authentication identifier field provides a unique identifier that
499 refers to the authenticating service within a given administrative do‐
500 main. The identifier MUST be unique to that domain. This identifier is
501 intended to be machine-readable and not necessarily meaningful to
502 users.
503 Example:
505 Authserv_Id = mx.example.com
507 Default:
509 HOSTNAME
511
514 RFC 7208 recommends an elapsed time limit for SPF checks of at least 20
515 seconds. Lookup_Time allows the maximum time (seconds) to be adjusted.
516 20 seconds is the default. This limit is applied separately to Mail
517 From and HELO/EHLO checks, so if both are performed, the lookups may
518 take up to twice Lookup_Time (plus any additional time required for
519 whitelisting related DNS lookups).
520 It is important that the combination of Lookup_Time(s) and applicable
522 Whitelist_Lookup_Time(s) be less than the smtpd_policy_service_timeout
523 defined for the service (default 100 seconds). Since HELO and Mail
524 From time limits are independent, smtpd_policy_service_timeout needs to
525 be at least double the time allowed for the SPF policy server per en‐
526 tity type.
527 Example:
529 Lookup_Time = 20
531 Default
533 20 (seconds)
535
538 Some of the available whitelisting mechanisms, i.e. Domain_Whitelist,
539 Domain_Whitelist_PTR, and HELO_Whitelist, require specific non-SPF DNS
540 lookups to determine if a connection should be white listed from SPF
541 checks. The maximum amount of time (in seconds) allocated for each of
542 these checks, when used (none are enabled by default), is controlled by
543 the Whitelist_Lookup_Time parameter. It defaults to 10 seconds and is
544 applied independently to each whitelisting method in use (e.g. if both
545 a Domain_Whitelist_PTR and HELO_Whitelist are defined, together they
546 may take up to 20 seconds). This is in addition to the time allowed
547 for SPF Lookup_Time.
548 It is important that the combination of Lookup_Time(s) and applicable
550 Whitelist_Lookup_Time(s) be less than the smtpd_policy_service_timeout
551 defined for the service (default 100 seconds). Since HELO and Mail
552 From time limits are independent, smtpd_policy_service_timeout needs to
553 be at least double the time allowed for the SPF policy server per en‐
554 tity type.
555 Example:
557 Whitelist_Lookup_Time = 10
559 Default
561 10 (seconds)
563
566 RFC 7208 adds a new processing limit called "void lookup limit" (See
567 section 4.6.4). Void lookups are DNS queries within an SPF record for
568 which DNS queries return either a positive answer (RCODE 0) with an an‐
569 swer count of 0, or a "Name Error" (RCODE 3) answer. This should not
570 need to be changed. Although new in an RFC in RFC 7208, this limit has
571 been widely deployed in the Mail::SPF perl library without issue. De‐
572 fault is 2, but it can be adjusted.
573 Example:
575 Void_Limit = 2
577 Default
579 2
581
584 In some versions of postfix, for bizarre Sendmail compatibility rea‐
585 sons, the first header field added by a policy server is not visible to
586 milters. To make this easy to work around, set the Mock value to true
587 and a fixed header field will be inserted so the actual SPF check will
588 be the second field and visible to milters such as DMARC milter.
589 To use this feature requires additional postfix configuration to exe‐
591 cute the second, mock, instance of the policy server:
592 Add a second service to /etc/postfix/master.cf:
594 policyd-spf-mock unix - n n - 0
596 spawn
597 user=nobody argv=/usr/bin/policyd-spf '/etc/pypolicyd-
598 spf/mock
599 Configure the Postfix additional policy service in /etc/postfix/main.cf
601 to run before the regular service:
602 smtpd_recipient_restrictions =
604 ...
605 reject_unauth_destination
606 check_policy_service unix:private/policyd-spf-mock
607 check_policy_service unix:private/policyd-spf
608 ...
609 Create the specified configuration file in the location indicated with
611 Mock set to True.
612 Example:
614 Mock = True
616 Default
618 False
620
623 Include Postfix Queue ID in policy server log messages. This option
624 only applies to log level 0 or 1 messages that are unique to the policy
625 server interface when configured for post-queue processing. Not used
626 for milter or common code logging. Included to assist with correlating
627 logging with specific Postfix message processing.
628 Example:
630 QueueID = True
632 Default
634 True
636
639 If a message is rejected or deferred because of the SPF policy, a rea‐
640 son is given for logging and debugging purposes. The String configured
641 supports the following format specifiers:
642 rejectdefer - either the string 'rejected' or 'deferred'
644 spf - SPF result code
646 url - Parameterized URL to http://www.openspf.net/ ex‐
648 plaining SPF
649 Example:
651 Reason_Message = Message {rejectdefer} due to: {spf}.
653 Default:
655 Reason_Message = Message {rejectdefer} due to: {spf}. Please see {url}
657
660 Socket (string)
661 Specifies the socket that should be established by the filter to
662 receive connections from postfix(1) in order to provide service.
663 socketspec is in one of two forms: local:path, which creates a
664 UNIX domain socket at the specified path, or inet:port[@host] or
665 inet6:port[@host] which creates a TCP socket on the specified
666 port and in the specified protocol family. If the host is not
667 given as either a hostname or an IP address, the socket will be
668 listening on all interfaces. A literal IP address must be en‐
669 closed in square brackets. This option is mandatory in the con‐
670 figuration file.
671 PidFile (string)
674 Specifies the path to a file that should be created at process
675 start containing the process ID. If not specified, no such file
676 will be created.
677 UserID (string)
680 Attempts to become the specified userid before starting opera‐
681 tions. The value is of the form userid[:group]. The process
682 will be assigned all of the groups and primary group ID of the
683 named userid unless an alternate group is specified.
684 UMask (integer)
687 Requests a specific permissions mask to be used for file cre‐
688 ation. This only really applies to creation of the socket when
689 Socket specifies a UNIX domain socket, and to the PidFile (if
690 any); temporary files are created by the mkstemp(3) function
691 that enforces a specific file mode on creation regardless of the
692 process umask. See umask(2) for more information.
693 InternalHosts (dataset)
696 Identifies a set internal hosts whose mail should be signed
697 rather than verified. The set should contain on each line a
698 hostname, domain name (e.g. ".example.com"), IP address, an IPv6
699 address (including an IPv4 mapped address), or a CIDR-style IP
700 specification (e.g. "192.168.1.0/24"). An entry beginning with
701 a bang ("!") character means "not", allowing exclusions of spe‐
702 cific hosts that are otherwise members of larger sets. Host and
703 domain names are matched first, then the IP or IPv6 address de‐
704 pending on the connection type. More precise entries are pre‐
705 ferred over less precise ones, i.e. "192.168.1.1" will match be‐
706 fore "!192.168.1.0/24". The text form of IPv6 addresses will be
707 forced to lowercase when queried (RFC5952), so the contents of
708 this data set should also use lowercase. The IP address portion
709 of an entry may optionally contain square brackets; both forms
710 (with and without) will be checked. If not specified, the de‐
711 fault of "127.0.0.1" is applied. Naturally, providing a value
712 here overrides the default, so if mail from 127.0.0.1 should be
713 signed, the list provided here should include that address ex‐
714 plicitly.
715 MacroList (dataset)
718 Defines a set of MTA-provided macros that should be checked to
719 see if the sender has been determined to be a local user and
720 therefore whether or not the message checked. If a value is
721 specified matching a macro name in the data set, the value of
722 the macro must match a value specified (matching is case-sensi‐
723 tive), otherwise the macro must be defined but may contain any
724 value. The set is empty by default, meaning macros are not con‐
725 sidered when making the verify decision. The general format of
726 the value is value1[|value2[|...]]; if one or more value is de‐
727 fined then the macro must be set to one of the listed values,
728 otherwise the macro must be set but can contain any value.
729 In order for the macro and its value to be available to the fil‐
731 ter for checking, the MTA must send it during the protocol ex‐
732 change. This is either accomplished via manual configuration of
733 the MTA to send the desired macros or, for MTA/filter combina‐
734 tions that support the feature, the filter can request those
735 macros that are of interest. The latter is a feature negotiated
736 at the time the filter receives a connection from the MTA and
737 its availability depends upon the version of milter used to com‐
738 pile the filter and the version of the MTA making the connec‐
739 tion.
740
743 man 1 policyd-spf, man 5 policyd-spf.peruser, python-spf,
744 <http://www.openspf.net>, RFC 7208, RFC 7001, RFC 7372
745
748 This version of policyd-spf was written by Copyright © 2007-2016, Scott
749 Kitterman <scott@kitterman.com>. It is derived from Tumgreyspf, writ‐
750 ten by Sean Reifschneider, tummy.com, ltd <jafo@tummy.com>. Portions of
751 the documentation were written by Meng Weng Wong <mengwong@pobox.com>.
752 This man-page was created by Scott Kitterman <scott@kitterman.com> and
754 is licensed under the same terms as the program.
755 policy-spf.conf(5)