policy-spf.conf(5)

📦
version 3.1.0 · 5 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

🌸 policy-spf.conf(5) 🌸

okay bestie, listen up 💖 you're reading the File Formats Manual page for policy-spf.conf — it's the config file for policyd-spf, and it's literally just a big pile of python configuration parameters. ngl it's long, so we're doing this in parts. this is part 1. buckle up 🎀

✨ NAME ✨

policyd-spf — the python configuration parameters for policyd-spf. that's it, that's the name. slay.

🌈 VERSION 🌈

3.1.0

💅 USAGE 💅

Usage:
  policyd-spf [/etc/postfix-policyd-spf-python/policyd-spf.conf]

📚 OTHER DOCUMENTATION 📚

okay so before you go any further, this doc is assuming you've already read Postfix's README_FILES/SMTPD_POLICY_README and that you're generally familiar with Sender Policy Framework (SPF). if you want the full deets, see RFC 7208. no cap.

man 1 policyd-spf gives you the general operation documentation for this package 🫶

man 5 policyd-spf.peruser is the one about setting up and using different configuration options on a per user (mail recipient) basis. yes, per recipient. iconic.

🦋 SYNOPSIS 🦋

spf-engine provides both a Postfix policy server front end and a milter front end, and that milter front end can be used with any mail server that supports the milter protocol. most options apply to both policy server and milter usage — the milter-specific ones are listed at the end. iykyk.

the package operates with a default installed configuration file and a set of default configuration options that get used if the config file can't be found at all. wanna change things? either edit the installed configuration files, or hand it a path to an alternate configuration file. easy.

💖 DESCRIPTION 💖

so, bonus feature: you can whitelist certain IP addresses from SPF checks. this man page and the sample configuration file both show you the format to use. ✨

these options can be adjusted on a per user (mail recipient) basis, and the details for that live in policyd-spf.peruser(5). one thing though — per user settings only apply to the policy server. the milter is not invited to that party 🙈

👑 OPTIONS 👑

🍓 LOGGING 🍓

"debugLevel" controls how much information the policy server logs.

the default, 1, logs no debugging messages — just basic policy results and errors generated through the policy server. you can bump this up to 5 (and technically values higher than 5 won't throw an error, they just won't log any additional info either, so like… why).

  • debug level 2 — adds a log message if no client address (that's the IP address the connection was made from), Mail From address, or HELO/EHLO name is received by the policy server. it also logs SPF results for each Mail From and HELO check.
  • debug level 3 — generates a log message every single time the policy server starts and every time it exits, plus it logs a copy of the exact header returned to Postfix that's meant to be prepended into the message. every time the policy server starts, debug level 3 also logs the configuration information the policy server is using.
  • debug level 4 — logs the complete data set received by Postfix via the policy interface, and logs when the end of the entry is read.
  • debug level 5 — this one is for debugging config file processing and, for that purpose, it can only be set in code and not via the config file. it also provides additional internal status details that are generally only of interest to developers.

if the debug level is 0, then the policy server logs errors only.

when it's set to -1, nothing gets logged once the configuration file has been read in — not even error messages.

⚠️ -1 is giving chaos. use with caution, bestie 💀

Default:

debugLevel = 1

🧚 TEST OPERATION 🧚

the policy server can run in a test only mode. this lets you see the potential impact of SPF checking in your mail logs without rejecting any mail. headers do get prepended into messages, but message delivery is not affected. this mode is not enabled by default.

to enable it, set TestOnly = 0. and if you want test operation with no header added, also set Header_Type = None. 🌸

📝 Note: this option was previously named defaultSeedOnly. that name is still accepted, but it logs an error. she's retired but still shows up to the party, apparently.

Default:

TestOnly = 1

🎀 HELO/EHLO CHECKING 🎀

the HELO check rejection policy options are:

  • Fail — (Default) reject only on HELO Fail. HELO/EHLO is known first in the SMTP dialogue, and there's no practical reason to waste resources on Mail From checks if the HELO check is already gonna cause the message to be rejected. this should not cause interoperability problems when used for HELO.
  • SPF_Not_Pass — reject if the result is not Pass, None, or Temperror (or, put another way: reject if the SPF result is Fail, Softfail, Neutral, or PermError). unlike Mail From checking, there are no standard e-mail use cases where a HELO check shouldn't Pass if there is an SPF record for the HELO name (transparent forwarding, for example, is not an issue here). HELO/EHLO is known first in the SMTP dialogue and there's no practical reason to waste resources on Mail From checks if the HELO check will already cause the message to be rejected. this is not consistent with the RFC 7208 requirement to treat none and neutral the same, but it shouldn't 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's 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.
  • Null — only reject HELO Fail for a Null sender (SPF Classic). this is the approach used by the pre-RFC 4408 reference implementation and many of the pre-RFC specifications. using at least this option (SPF_Not_Pass or Fail are preferred) is highly recommended.
  • False — never reject on HELO, just append the header. this is useful for post-SMTP spam filters such as SpamAssassin.
  • No_Check — never check HELO. this is only recommended if you're calling the policy server twice (once for HELO checks and once for Mail From) with two different configuration files. that approach is useful for getting both the HELO and Mail From headers prepended to a message.
📝 Note: if No_Mail is set to True, it overrides rejections in any case where the SPF record is not "v=spf1 -all".

Default:

HELO_reject = Fail

💜 HELO/EHLO PASS RESTRICTION 💜

HELO Pass Restriction lets you integrate with other Postfix access controls by providing a user supplied name of a postfix access restriction to apply 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 that ships with this distribution has examples. 🫶

📝 Note: a helo pass restriction will be the returned result even if the mail from result would cause the message to be rejected. she overrules, periodt.

Example:

HELO_pass_restriction = helo_passed_spf

Default:

None

🔥 Mail From CHECKING 🔥

the Mail From rejection policy options are:

  • SPF_Not_Pass — reject if the result is not Pass/None/Tempfail. this option is not RFC 7208 compliant, since 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 it per-domain if you need it (per-domain usage is described below).
  • Softfail — reject on Mail From Softfail or Fail. global use of this option is not recommended — use it per-domain if you need it (per-domain usage is described below).
  • Fail — (default) reject on Mail From Fail.
  • False — never reject on Mail From, just append the header. useful for post-SMTP spam filters such as SpamAssassin.
  • No_Check — never check Mail From/Return Path. this is only recommended if you're calling the policy server twice (once for HELO checks and once for Mail From) with two different configuration files. that approach is useful for getting 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.
📝 Note: if No_Mail is set to True, it overrides rejections in any case where the SPF record is not "v=spf1 -all".

Default:

Mail_From_reject = Fail

🌈 Mail From PASS RESTRICTION 🌈

Mail From Pass Restriction lets you integrate with other Postfix access controls by providing a user supplied name of a postfix access restriction to apply to a message when the Mail From 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 has examples. ✨

📝 Note: a mail from pass restriction will be the returned result even if the helo result would cause the message to be rejected. again — she wins. 💅

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". it's useful for rejecting mail in situations where your tolerance for rejecting wanted mail is very low. it operates on both HELO and Mail From identities if set. lowkey the safest little guy in the file.

Default:

No_Mail = False

🦄 Domain Specific Receiver Policy 🦄

with this option, you can define a list of domains for special processing when messages don't Pass SPF. super useful for commonly spoofed domains that aren't publishing SPF records with -all yet. specifically: if mail from a domain on this list has a Neutral/Softfail result, it will be rejected (as if it had a Fail result). and if you're gonna do it, it's better to do it per-domain rather than globally. do not be extra about it globally.

Example:

Reject_Not_Pass_Domains = aol.com,hotmail.com

Default:

None

⭐ Permanent Error Processing ⭐

the policy options for rejecting due to SPF PermError 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 it does result in senders getting feedback that they've got a problem with their SPF record.
  • False — treat PermError the same as no SPF record at all. this is consistent 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 it is Mail_From/HELO_reject = False

Default:

PermError_reject = False

🌀 Temporary Error Processing 🌀

So when SPF comes back with a TempError, do we just... defer? That's the whole vibe check here. The policy for deferring messages due to SPF TempError options is:

  • True — Defer the message if the SPF result (for HELO or Mail From) is TempError. This is the traditional usage and it has genuinely proven useful in reducing acceptance of unwanted messages. Sometimes spam senders do not retry (bestie behavior fr). Sometimes by the time a message is retried the sending IP has made it onto a DNS RBL and can then be rejected. It's 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 intervention 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 positive 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. (iykyk, don't add spaces, it will not slay 💅)

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 HELO WHITELIST 🦋

A comma separated HELO/EHLO host names to skip SPF checks for. Use this list to whitelist trusted relays (such as a secondary MX and trusted forwarders) or to work around a host with a buggy SPF record. An x-header is prepended indicating the host was whitelisted against SPF checks. This is a trace header only. Note the lack of spaces in the list.

This option includes a check to ensure the connect IP address is referenced in an A or AAAA record by the HELO/EHLO domain that is whitelisted. This is to avoid inadvertent bypass of SPF checks if HELO/EHLO names are forged. If a HELO/EHLO domain is unable to pass such a forward IP address match check, then use an SPF IP Whitelist for the host's IP address instead. 👑

Example:

HELO_Whitelist = relay.example.com,sender.example.org

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 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.

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 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.

Example:

Domain_Whitelist_PTR = yahoo.com,yahoogroups.com

Default:

None

⭐ SPF ENHANCED STATUS CODES ⭐

By default, Postfix will use the 4/5.7.1 enhanced status code for defer/reject actions from the policy server (originally defined in RFC 1893, RFC 3463 is the current reference). New email authentication (including SPF) specific codes were defined in RFC 7372. The policy server now overrides the Postfix enhanced status codes to use the RFC 7372 values. This can be disabled by setting this option to "No" in the event of interoperability issues. 🙈

Example:

SPF_Enhanced_Status_Codes = No

Default:

Yes

🎀 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. (yes bestie, you gotta run it twice, that's just the way it is ✨)

For no header at all, use Header_Type = None.

Examples:

Header_Type = SPF or Header_Type = AR

Default:

SPF

🙈 HIDE RCPT TO IN RESULTS HEADER 🙈

Both Received-SPF and Authentication-Results (AR) header fields include the receiving (RCPT TO) host, if available. In this application, it will always be the host of the first recipient sent by the sending MTA, even if that recipient is a BCC recipient. This is unavoidable as neither the Postfix policy interface nor the milter interface provides any indication if the recipient is BCC or not (this information is not available in until after SMTP DATA in the body of the message). This presented a possible avenue for a privacy breach, but in version 3.0 it was modified to be only the host name and not the full address. 😭

Hide_Receiver can set to Yes interest of maximizing privacy. If per user processing is not in use, this setting will replace the actual host name with <UNKNOWN> both in header fields and SMTP responses. The latter may make it more difficult for senders to troubleshoot issues with their SPF deployments. As an implementation detail, currently specifying any value other than No will result in the recipient being hidden, but that may change in the future. If per user processing is in use, this setting has no effect.

For the milter interface, checks are always done at the Mail From stage in the SMTP protocol, so receiver data is never available. When using the milter, this setting has no effect.

Examples:

Hide_Receiver = Yes or Hide_Receiver = No

Default:

No

👑 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 HOSTNAME. The results of socket.gethostname will be used unless an alternate value is specified. An Authserv-Id must be provided if Header_Type 'AR' is used.

The authentication identifier field provides a unique identifier that refers to the authenticating service within a given administrative domain. The identifier MUST be unique to that domain. This identifier is intended to be machine-readable and not necessarily meaningful to users.

Example:

Authserv_Id = mx.example.com

Default:

HOSTNAME

⏳ 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. This limit is applied separately to Mail From and HELO/EHLO checks, so if both are performed, the lookups may take up to twice Lookup_Time (plus any additional time required for whitelisting related DNS lookups).

It is important that the combination of Lookup_Time(s) and applicable Whitelist_Lookup_Time(s) be less than the smtpd_policy_service_timeout defined for the service (default 100 seconds). Since HELO and Mail From time limits are independent, smtpd_policy_service_timeout needs to be at least double the time allowed for the SPF policy server per entity type. ⚠️

Example:

Lookup_Time = 20

Default

20 (seconds)

🌸 Whitelist DNS Timeout Limit 🌸

Some of the available whitelisting mechanisms, i.e. Domain_Whitelist, Domain_Whitelist_PTR, and HELO_Whitelist, require specific non-SPF DNS lookups to determine if a connection should be white listed from SPF checks. The maximum amount of time (in seconds) allocated for each of these checks, when used (none are enabled by default), is controlled by the Whitelist_Lookup_Time parameter. It defaults to 10 seconds and is applied independently to each whitelisting method in use (e.g. if both a Domain_Whitelist_PTR and HELO_Whitelist are defined, together they may take up to 20 seconds). This is in addition to the time allowed for SPF Lookup_Time.

It is important that the combination of Lookup_Time(s) and applicable Whitelist_Lookup_Time(s) be less than the smtpd_policy_service_timeout defined for the service (default 100 seconds). Since HELO and Mail From time limits are independent, smtpd_policy_service_timeout needs to be at least double the time allowed for the SPF policy server per entity type. ⚠️

Example:

Whitelist_Lookup_Time = 10

Default

10 (seconds)

🕳️ DNS Void Lookup Limit

okay so RFC 7208 came in and added a whole new processing limit called the "void lookup limit" (peep section 4.6.4 bestie). And what even is a void lookup? It's a DNS query inside an SPF record where the DNS answer comes back either with a positive answer (RCODE 0) but an answer count of 0, or with a "Name Error" (RCODE 3) answer. Yeah. Void. Empty. Ghosted. 👻

lowkey you should not need to change this. Even though it's brand new in an RFC in RFC 7208, this limit has been widely deployed in the Mail::SPF perl library without a single issue, so it's giving battle-tested fr fr.

Default is 2, but it can be adjusted. ✨

Example:

Void_Limit = 2

Default

2

🎭 Mock SPF Check To Add Milter Compatibility Header Field

so in some versions of postfix, for bizarre Sendmail compatibility reasons (not me judging, but like... 👀), the first header field added by a policy server is just not visible to milters. tragic.

To make this easy to work around, set the Mock value to true and a fixed header field will be inserted so the actual SPF check becomes the second field and is visible to milters such as DMARC milter. slay. 💅

heads up: to use this feature you need additional postfix configuration to execute the second, mock, instance of the policy server.

Step one: add a second service to /etc/postfix/master.cf:

policyd-spf-mock  unix  -       n       n       -       0       spawn
    user=nobody argv=/usr/bin/policyd-spf '/etc/pypolicyd-spf/mock

Step two: configure the Postfix additional policy service in /etc/postfix/main.cf to run before the regular service:

smtpd_recipient_restrictions =
    ...
    reject_unauth_destination
    check_policy_service unix:private/policyd-spf-mock
    check_policy_service unix:private/policyd-spf
    ...

Step three: create the specified configuration file in the location indicated with Mock set to True.

Example:

Mock = True

Default

False

📋 Log Queue ID

this one's cute — it includes the Postfix Queue ID in policy server log messages. 🎀

okay but important detail: this option only applies to log level 0 or 1 messages that are unique to the policy server interface when configured for post-queue processing. It is not used for milter or common code logging. It's included to assist with correlating logging with specific Postfix message processing. iykyk. 🔍

Example:

QueueID = True

Default

True

💬 Reason Message/URL

If a message is rejected or deferred because of the SPF policy, a reason is given for logging and debugging purposes. The String configured supports the following format specifiers:

  • rejectdefer — either the string 'rejected' or 'deferred'
  • spf — SPF result code
  • url — Parameterized URL to http://www.openspf.net/ explaining SPF

The default url can be overridden by setting Reason_URL. It defaults to the defunct openspf.org URL due to a lack of a standardized alternative. 💀 This is intended for use with a web service which provides additional information to a user. The following components are supported and required:

  • {0} — SPF result type (pass, fail, etc.)
  • {1} — Result rationale provided by the SPF library
  • {2} — Connect IP address
  • {3} — Recipient address, if available
All four components must be included in your custom URL. As shown in the default and the example, = may be used in the URL. This is the only configuration setting where it is allowed. literally the one exception, periodt.

Example:

Reason_Message = Message {rejectdefer} due to: {spf}.
Reason_URL = http://www.openspf.net/Why?s={0};id={1};ip={2};r={3}

Default:

Reason_Message = Message {rejectdefer} due to: {spf}. Please see {url}
Reason_URL = http://www.openspf.net/Why?s={0};id={1};ip={2};r={3}

🌈 MILTER ONLY OPTIONS

bestie these ones are milter-exclusive, no sharing with the other modes. 💜

🔌 Socket (string)

Specifies the socket that should be established by the filter to receive connections from postfix(1) in order to provide service. socketspec is in one of two forms: local:path, which creates a UNIX domain socket at the specified path, or inet:port[@host] or inet6:port[@host] which creates a TCP socket on the specified port and in the specified protocol family. If the host is not given as either a hostname or an IP address, the socket will be listening on all interfaces. A literal IP address must be enclosed in square brackets. 🫶

This option is mandatory in the configuration file. no skipping it, it's the main character here. 👑

🆔 PidFile (string)

Specifies the path to a file that should be created at process start containing the process ID. If not specified, no such file will be created. simple as that. ✨

👤 UserID (string)

Attempts to become the specified userid before starting operations. The value is of the form userid[:group]. The process will be assigned all of the groups and primary group ID of the named userid unless an alternate group is specified. very demure, very mindful. 🎀

🔒 UMask (integer)

Requests a specific permissions mask to be used for file creation. This only really applies to creation of the socket when Socket specifies a UNIX domain socket, and to the PidFile (if any); temporary files are created by the mkstemp(3) function that enforces a specific file mode on creation regardless of the process umask. See umask(2) for more information. 📎

🏠 InternalHosts (dataset)

Identifies a set internal hosts whose mail should be signed rather than verified. The set should contain on each line a hostname, domain name (e.g. .example.com), IP address, an IPv6 address (including an IPv4 mapped address), or a CIDR-style IP specification (e.g. 192.168.1.0/24).

An entry beginning with a bang (!) character means "not", allowing exclusions of specific hosts that are otherwise members of larger sets. Host and domain names are matched first, then the IP or IPv6 address depending on the connection type. More precise entries are preferred over less precise ones, i.e. 192.168.1.1 will match before !192.168.1.0/24. 🔥

The text form of IPv6 addresses will be forced to lowercase when queried (RFC5952), so the contents of this data set should also use lowercase. The IP address portion of an entry may optionally contain square brackets; both forms (with and without) will be checked.

If not specified, the default of 127.0.0.1 is applied. Naturally, providing a value here overrides the default, so if mail from 127.0.0.1 should be signed, the list provided here should include that address explicitly. ngl this trips people up so read it twice. 🙈

🧩 MacroList (dataset)

Defines a set of MTA-provided macros that should be checked to see if the sender has been determined to be a local user and therefore whether or not the message checked. If a value is specified matching a macro name in the data set, the value of the macro must match a value specified (matching is case-sensitive), otherwise the macro must be defined but may contain any value.

The set is empty by default, meaning macros are not considered when making the verify decision. The general format of the value is value1[|value2[|...]]; if one or more value is defined then the macro must be set to one of the listed values, otherwise the macro must be set but can contain any value.

In order for the macro and its value to be available to the filter for checking, the MTA must send it during the protocol exchange. This is either accomplished via manual configuration of the MTA to send the desired macros or, for MTA/filter combinations that support the feature, the filter can request those macros that are of interest. The latter is a feature negotiated at the time the filter receives a connection from the MTA and its availability depends upon the version of milter used to compile the filter and the version of the MTA making the connection. 🌸

📚 SEE ALSO

👑 AUTHORS

This version of policyd-spf was written by Copyright © 2007-2016, 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> and is licensed under the same terms as the program.

and that's a wrap on policy-spf.conf(5) bestie!! 💖✨🎀 you made it to the very last line, so proud of you. go configure something iconic. 🦋💅🫶

📦 where this page comes from