+.option dkim_sign_headers smtp string&!! "see below"
+If set, this option must expand to a colon-separated
+list of header names.
+Headers with these names, or the absence or such a header, will be included
+in the message signature.
+When unspecified, the header names listed in RFC4871 will be used,
+whether or not each header is present in the message.
+The default list is available for the expansion in the macro
+"_DKIM_SIGN_HEADERS".
+
+If a name is repeated, multiple headers by that name (or the absence thereof)
+will be signed. The textually later headers in the headers part of the
+message are signed first, if there are multiples.
+
+A name can be prefixed with either an '=' or a '+' character.
+If an '=' prefix is used, all headers that are present with this name
+will be signed.
+If a '+' prefix if used, all headers that are present with this name
+will be signed, and one signature added for a missing header with the
+name will be appended.
+
+.option dkim_timestamps smtp integer&!! unset
+This option controls the inclusion of timestamp information in the signature.
+If not set, no such information will be included.
+Otherwise, must be an unsigned number giving an offset in seconds from the current time
+for the expiry tag
+(eg. 1209600 for two weeks);
+both creation (t=) and expiry (x=) tags will be included.
+
+RFC 6376 lists these tags as RECOMMENDED.
+
+
+.section "Verifying DKIM signatures in incoming mail" "SECDKIMVFY"
+.cindex "DKIM" "verification"
+
+Verification of DKIM signatures in SMTP incoming email is done for all
+messages for which an ACL control &%dkim_disable_verify%& has not been set.
+.cindex DKIM "selecting signature algorithms"
+Individual classes of signature algorithm can be ignored by changing
+the main options &%dkim_verify_hashes%& or &%dkim_verify_keytypes%&.
+The &%dkim_verify_minimal%& option can be set to cease verification
+processing for a message once the first passing signature is found.
+
+.cindex authentication "expansion item"
+Performing verification sets up information used by the
+&%authresults%& expansion item.
+
+For most purposes the default option settings suffice and the remainder
+of this section can be ignored.
+
+The results of verification are made available to the
+&%acl_smtp_dkim%& ACL, which can examine and modify them.
+A missing ACL definition defaults to accept.
+By default, the ACL is called once for each
+syntactically(!) correct signature in the incoming message.
+If any ACL call does not accept, the message is not accepted.
+If a cutthrough delivery was in progress for the message, that is
+summarily dropped (having wasted the transmission effort).
+
+To evaluate the verification result in the ACL
+a large number of expansion variables
+containing the signature status and its details are set up during the
+runtime of the ACL.
+
+Calling the ACL only for existing signatures is not sufficient to build
+more advanced policies. For that reason, the main option
+&%dkim_verify_signers%&, and an expansion variable
+&%$dkim_signers%& exist.
+
+The main option &%dkim_verify_signers%& can be set to a colon-separated
+list of DKIM domains or identities for which the ACL &%acl_smtp_dkim%& is
+called. It is expanded when the message has been received. At this point,
+the expansion variable &%$dkim_signers%& already contains a colon-separated
+list of signer domains and identities for the message. When
+&%dkim_verify_signers%& is not specified in the main configuration,
+it defaults as:
+.code
+dkim_verify_signers = $dkim_signers
+.endd
+This leads to the default behaviour of calling &%acl_smtp_dkim%& for each
+DKIM signature in the message. Current DKIM verifiers may want to explicitly
+call the ACL for known domains or identities. This would be achieved as follows:
+.code
+dkim_verify_signers = paypal.com:ebay.com:$dkim_signers
+.endd
+This would result in &%acl_smtp_dkim%& always being called for "paypal.com"
+and "ebay.com", plus all domains and identities that have signatures in the message.
+You can also be more creative in constructing your policy. For example:
+.code
+dkim_verify_signers = $sender_address_domain:$dkim_signers
+.endd
+
+If a domain or identity is listed several times in the (expanded) value of
+&%dkim_verify_signers%&, the ACL is only called once for that domain or identity.
+
+Note that if the option is set using untrustworthy data
+(such as the From: header)
+care should be taken to force lowercase for domains
+and for the domain part if identities.
+The default setting can be regarded as trustworthy in this respect.
+
+If multiple signatures match a domain (or identity), the ACL is called once
+for each matching signature.
+
+
+Inside the DKIM ACL, the following expansion variables are
+available (from most to least important):
+
+
+.vlist
+.vitem &%$dkim_cur_signer%&
+The signer that is being evaluated in this ACL run. This can be a domain or
+an identity. This is one of the list items from the expanded main option
+&%dkim_verify_signers%& (see above).
+
+.vitem &%$dkim_verify_status%&
+Within the DKIM ACL,
+a string describing the general status of the signature. One of
+.ilist
+&%none%&: There is no signature in the message for the current domain or
+identity (as reflected by &%$dkim_cur_signer%&).
+.next
+&%invalid%&: The signature could not be verified due to a processing error.
+More detail is available in &%$dkim_verify_reason%&.
+.next
+&%fail%&: Verification of the signature failed. More detail is
+available in &%$dkim_verify_reason%&.
+.next
+&%pass%&: The signature passed verification. It is valid.
+.endlist
+
+This variable can be overwritten using an ACL 'set' modifier.
+This might, for instance, be done to enforce a policy restriction on
+hash-method or key-size:
+.code
+ warn condition = ${if eq {$dkim_verify_status}{pass}}
+ condition = ${if eq {${length_3:$dkim_algo}}{rsa}}
+ condition = ${if or {{eq {$dkim_algo}{rsa-sha1}} \
+ {< {$dkim_key_length}{1024}}}}
+ logwrite = NOTE: forcing DKIM verify fail (was pass)
+ set dkim_verify_status = fail
+ set dkim_verify_reason = hash too weak or key too short
+.endd
+
+So long as a DKIM ACL is defined (it need do no more than accept),
+after all the DKIM ACL runs have completed, the value becomes a
+colon-separated list of the values after each run.
+This is maintained for the mime, prdr and data ACLs.
+
+.vitem &%$dkim_verify_reason%&
+A string giving a little bit more detail when &%$dkim_verify_status%& is either
+"fail" or "invalid". One of
+.ilist
+&%pubkey_unavailable%& (when &%$dkim_verify_status%&="invalid"): The public
+key for the domain could not be retrieved. This may be a temporary problem.
+.next
+&%pubkey_syntax%& (when &%$dkim_verify_status%&="invalid"): The public key
+record for the domain is syntactically invalid.
+.next
+&%bodyhash_mismatch%& (when &%$dkim_verify_status%&="fail"): The calculated
+body hash does not match the one specified in the signature header. This
+means that the message body was modified in transit.
+.next
+&%signature_incorrect%& (when &%$dkim_verify_status%&="fail"): The signature
+could not be verified. This may mean that headers were modified,
+re-written or otherwise changed in a way which is incompatible with
+DKIM verification. It may of course also mean that the signature is forged.
+.endlist
+
+This variable can be overwritten, with any value, using an ACL 'set' modifier.
+
+.vitem &%$dkim_domain%&
+The signing domain. IMPORTANT: This variable is only populated if there is
+an actual signature in the message for the current domain or identity (as
+reflected by &%$dkim_cur_signer%&).
+
+.vitem &%$dkim_identity%&
+The signing identity, if present. IMPORTANT: This variable is only populated
+if there is an actual signature in the message for the current domain or
+identity (as reflected by &%$dkim_cur_signer%&).
+
+.vitem &%$dkim_selector%&
+The key record selector string.
+
+.vitem &%$dkim_algo%&
+The algorithm used. One of 'rsa-sha1' or 'rsa-sha256'.
+If running under GnuTLS 3.6.0 or OpenSSL 1.1.1 or later,
+may also be 'ed25519-sha256'.
+The "_CRYPTO_SIGN_ED25519" macro will be defined if support is present
+for EC keys.
+
+Note that RFC 8301 says:
+.code
+rsa-sha1 MUST NOT be used for signing or verifying.
+
+DKIM signatures identified as having been signed with historic
+algorithms (currently, rsa-sha1) have permanently failed evaluation
+.endd
+
+To enforce this you must either have a DKIM ACL which checks this variable
+and overwrites the &$dkim_verify_status$& variable as discussed above,
+or have set the main option &%dkim_verify_hashes%& to exclude
+processing of such signatures.
+
+.vitem &%$dkim_canon_body%&
+The body canonicalization method. One of 'relaxed' or 'simple'.
+
+.vitem &%$dkim_canon_headers%&
+The header canonicalization method. One of 'relaxed' or 'simple'.
+
+.vitem &%$dkim_copiedheaders%&
+A transcript of headers and their values which are included in the signature
+(copied from the 'z=' tag of the signature).
+Note that RFC6376 requires that verification fail if the From: header is
+not included in the signature. Exim does not enforce this; sites wishing
+strict enforcement should code the check explicitly.
+
+.vitem &%$dkim_bodylength%&
+The number of signed body bytes. If zero ("0"), the body is unsigned. If no
+limit was set by the signer, "9999999999999" is returned. This makes sure
+that this variable always expands to an integer value.
+&*Note:*& The presence of the signature tag specifying a signing body length
+is one possible route to spoofing of valid DKIM signatures.
+A paranoid implementation might wish to regard signature where this variable
+shows less than the "no limit" return as being invalid.
+
+.vitem &%$dkim_created%&
+UNIX timestamp reflecting the date and time when the signature was created.
+When this was not specified by the signer, "0" is returned.
+
+.vitem &%$dkim_expires%&
+UNIX timestamp reflecting the date and time when the signer wants the
+signature to be treated as "expired". When this was not specified by the
+signer, "9999999999999" is returned. This makes it possible to do useful
+integer size comparisons against this value.
+Note that Exim does not check this value.
+
+.vitem &%$dkim_headernames%&
+A colon-separated list of names of headers included in the signature.
+
+.vitem &%$dkim_key_testing%&
+"1" if the key record has the "testing" flag set, "0" if not.
+
+.vitem &%$dkim_key_nosubdomains%&
+"1" if the key record forbids subdomaining, "0" otherwise.
+
+.vitem &%$dkim_key_srvtype%&
+Service type (tag s=) from the key record. Defaults to "*" if not specified
+in the key record.
+
+.vitem &%$dkim_key_granularity%&
+Key granularity (tag g=) from the key record. Defaults to "*" if not specified
+in the key record.
+
+.vitem &%$dkim_key_notes%&
+Notes from the key record (tag n=).
+
+.vitem &%$dkim_key_length%&
+Number of bits in the key.
+
+Note that RFC 8301 says:
+.code
+Verifiers MUST NOT consider signatures using RSA keys of
+less than 1024 bits as valid signatures.
+.endd
+
+To enforce this you must have a DKIM ACL which checks this variable
+and overwrites the &$dkim_verify_status$& variable as discussed above.
+As EC keys are much smaller, the check should only do this for RSA keys.
+
+.endlist
+
+In addition, two ACL conditions are provided:
+
+.vlist
+.vitem &%dkim_signers%&
+ACL condition that checks a colon-separated list of domains or identities
+for a match against the domain or identity that the ACL is currently verifying
+(reflected by &%$dkim_cur_signer%&). This is typically used to restrict an ACL
+verb to a group of domains or identities. For example:
+
+.code
+# Warn when Mail purportedly from GMail has no gmail signature
+warn log_message = GMail sender without gmail.com DKIM signature
+ sender_domains = gmail.com
+ dkim_signers = gmail.com
+ dkim_status = none
+.endd
+
+Note that the above does not check for a total lack of DKIM signing;
+for that check for empty &$h_DKIM-Signature:$& in the data ACL.
+
+.vitem &%dkim_status%&
+ACL condition that checks a colon-separated list of possible DKIM verification
+results against the actual result of verification. This is typically used
+to restrict an ACL verb to a list of verification outcomes, for example:
+
+.code
+deny message = Mail from Paypal with invalid/missing signature
+ sender_domains = paypal.com:paypal.de
+ dkim_signers = paypal.com:paypal.de
+ dkim_status = none:invalid:fail
+.endd
+
+The possible status keywords are: 'none','invalid','fail' and 'pass'. Please
+see the documentation of the &%$dkim_verify_status%& expansion variable above
+for more information of what they mean.
+.endlist
+
+
+
+
+.section "SPF (Sender Policy Framework)" SECSPF
+.cindex SPF verification
+
+SPF is a mechanism whereby a domain may assert which IP addresses may transmit
+messages with its domain in the envelope from, documented by RFC 7208.
+For more information on SPF see &url(http://www.open-spf.org), a static copy of
+the &url(http://openspf.org).
+. --- 2019-10-28: still not https, open-spf.org is told to be a
+. --- web-archive copy of the now dead openspf.org site
+. --- See https://www.mail-archive.com/mailop@mailop.org/msg08019.html for a
+. --- discussion.
+
+Messages sent by a system not authorised will fail checking of such assertions.
+This includes retransmissions done by traditional forwarders.
+
+SPF verification support is built into Exim if SUPPORT_SPF=yes is set in
+&_Local/Makefile_&. The support uses the &_libspf2_& library
+&url(https://www.libspf2.org/).
+There is no Exim involvement in the transmission of messages;
+publishing certain DNS records is all that is required.
+
+For verification, an ACL condition and an expansion lookup are provided.
+.cindex authentication "expansion item"
+Performing verification sets up information used by the
+&%authresults%& expansion item.
+
+
+.cindex SPF "ACL condition"
+.cindex ACL "spf condition"
+The ACL condition "spf" can be used at or after the MAIL ACL.
+It takes as an argument a list of strings giving the outcome of the SPF check,
+and will succeed for any matching outcome.
+Valid strings are:
+.vlist
+.vitem &%pass%&
+The SPF check passed, the sending host is positively verified by SPF.
+
+.vitem &%fail%&
+The SPF check failed, the sending host is NOT allowed to send mail for the
+domain in the envelope-from address.
+
+.vitem &%softfail%&
+The SPF check failed, but the queried domain can't absolutely confirm that this
+is a forgery.
+
+.vitem &%none%&
+The queried domain does not publish SPF records.
+
+.vitem &%neutral%&
+The SPF check returned a "neutral" state. This means the queried domain has
+published a SPF record, but wants to allow outside servers to send mail under
+its domain as well. This should be treated like "none".
+
+.vitem &%permerror%&
+This indicates a syntax error in the SPF record of the queried domain.
+You may deny messages when this occurs.
+
+.vitem &%temperror%&
+This indicates a temporary error during all processing, including Exim's
+SPF processing. You may defer messages when this occurs.
+.endlist
+
+You can prefix each string with an exclamation mark to invert
+its meaning, for example "!fail" will match all results but
+"fail". The string list is evaluated left-to-right, in a
+short-circuit fashion.
+
+Example:
+.code
+deny spf = fail
+ message = $sender_host_address is not allowed to send mail from \
+ ${if def:sender_address_domain \
+ {$sender_address_domain}{$sender_helo_name}}. \
+ Please see http://www.open-spf.org/Why?scope=\
+ ${if def:sender_address_domain {mfrom}{helo}};\
+ identity=${if def:sender_address_domain \
+ {$sender_address}{$sender_helo_name}};\
+ ip=$sender_host_address
+.endd
+
+When the spf condition has run, it sets up several expansion
+variables:
+
+.cindex SPF "verification variables"
+.vlist
+.vitem &$spf_header_comment$&
+.vindex &$spf_header_comment$&
+ This contains a human-readable string describing the outcome
+ of the SPF check. You can add it to a custom header or use
+ it for logging purposes.
+
+.vitem &$spf_received$&
+.vindex &$spf_received$&
+ This contains a complete Received-SPF: header that can be
+ added to the message. Please note that according to the SPF
+ draft, this header must be added at the top of the header
+ list. Please see section 10 on how you can do this.
+
+ Note: in case of "Best-guess" (see below), the convention is
+ to put this string in a header called X-SPF-Guess: instead.
+
+.vitem &$spf_result$&
+.vindex &$spf_result$&
+ This contains the outcome of the SPF check in string form,
+ one of pass, fail, softfail, none, neutral, permerror or
+ temperror.
+
+.vitem &$spf_result_guessed$&
+.vindex &$spf_result_guessed$&
+ This boolean is true only if a best-guess operation was used
+ and required in order to obtain a result.
+
+.vitem &$spf_smtp_comment$&
+.vindex &$spf_smtp_comment$&
+ This contains a string that can be used in a SMTP response
+ to the calling party. Useful for "fail".
+.endlist
+
+
+.cindex SPF "ACL condition"
+.cindex ACL "spf_guess condition"
+.cindex SPF "best guess"
+In addition to SPF, you can also perform checks for so-called
+"Best-guess". Strictly speaking, "Best-guess" is not standard
+SPF, but it is supported by the same framework that enables SPF
+capability.
+Refer to &url(http://www.open-spf.org/FAQ/Best_guess_record)
+for a description of what it means.
+. --- 2019-10-28: still not https:
+
+To access this feature, simply use the spf_guess condition in place
+of the spf one. For example:
+
+.code
+deny spf_guess = fail
+ message = $sender_host_address doesn't look trustworthy to me
+.endd
+
+In case you decide to reject messages based on this check, you
+should note that although it uses the same framework, "Best-guess"
+is not SPF, and therefore you should not mention SPF at all in your
+reject message.
+
+When the spf_guess condition has run, it sets up the same expansion
+variables as when spf condition is run, described above.
+
+Additionally, since Best-guess is not standardized, you may redefine
+what "Best-guess" means to you by redefining the main configuration
+&%spf_guess%& option.
+For example, the following:
+
+.code
+spf_guess = v=spf1 a/16 mx/16 ptr ?all
+.endd
+
+would relax host matching rules to a broader network range.
+
+
+.cindex SPF "lookup expansion"
+.cindex lookup spf
+A lookup expansion is also available. It takes an email
+address as the key and an IP address
+(v4 or v6)
+as the database:
+
+.code
+ ${lookup {username@domain} spf {ip.ip.ip.ip}}
+.endd
+
+The lookup will return the same result strings as can appear in
+&$spf_result$& (pass,fail,softfail,neutral,none,err_perm,err_temp).
+
+
+
+
+
+.section DMARC SECDMARC
+.cindex DMARC verification
+
+DMARC combines feedback from SPF, DKIM, and header From: in order
+to attempt to provide better indicators of the authenticity of an
+email. This document does not explain the fundamentals; you
+should read and understand how it works by visiting the website at
+&url(http://www.dmarc.org/).
+
+If Exim is built with DMARC support,
+the libopendmarc library is used.
+
+For building Exim yourself, obtain the library from
+&url(http://sourceforge.net/projects/opendmarc/)
+to obtain a copy, or find it in your favorite package
+repository. You will need to attend to the local/Makefile feature
+SUPPORT_DMARC and the associated LDFLAGS addition.
+This description assumes
+that headers will be in /usr/local/include, and that the libraries
+are in /usr/local/lib.
+
+. subsection
+
+There are three main-configuration options:
+.cindex DMARC "configuration options"
+
+The &%dmarc_tld_file%& option
+.oindex &%dmarc_tld_file%&
+defines the location of a text file of valid
+top level domains the opendmarc library uses
+during domain parsing. Maintained by Mozilla,
+the most current version can be downloaded
+from a link at &url(https://publicsuffix.org/list/, currently pointing
+at https://publicsuffix.org/list/public_suffix_list.dat)
+See also util/renew-opendmarc-tlds.sh script.
+.new
+The default for the option is unset.
+If not set, DMARC processing is disabled.
+.wen
+
+
+The &%dmarc_history_file%& option, if set
+.oindex &%dmarc_history_file%&
+defines the location of a file to log results
+of dmarc verification on inbound emails. The
+contents are importable by the opendmarc tools
+which will manage the data, send out DMARC
+reports, and expire the data. Make sure the
+directory of this file is writable by the user
+exim runs as.
+The default is unset.
+
+The &%dmarc_forensic_sender%& option
+.oindex &%dmarc_forensic_sender%&
+defines an alternate email address to use when sending a
+forensic report detailing alignment failures
+if a sender domain's dmarc record specifies it
+and you have configured Exim to send them.
+If set, this is expanded and used for the
+From: header line; the address is extracted
+from it and used for the envelope from.
+If not set (the default), the From: header is expanded from
+the dsn_from option, and <> is used for the
+envelope from.
+
+. I wish we had subsections...
+
+.cindex DMARC controls
+By default, the DMARC processing will run for any remote,
+non-authenticated user. It makes sense to only verify DMARC
+status of messages coming from remote, untrusted sources. You can
+use standard conditions such as hosts, senders, etc, to decide that
+DMARC verification should *not* be performed for them and disable
+DMARC with an ACL control modifier:
+.code
+ control = dmarc_disable_verify
+.endd
+A DMARC record can also specify a "forensic address", which gives
+exim an email address to submit reports about failed alignment.
+Exim does not do this by default because in certain conditions it
+results in unintended information leakage (what lists a user might
+be subscribed to, etc). You must configure exim to submit forensic
+reports to the owner of the domain. If the DMARC record contains a
+forensic address and you specify the control statement below, then
+exim will send these forensic emails. It is also advised that you
+configure a &%dmarc_forensic_sender%& because the default sender address
+construction might be inadequate.
+.code
+ control = dmarc_enable_forensic
+.endd
+(AGAIN: You can choose not to send these forensic reports by simply
+not putting the dmarc_enable_forensic control line at any point in
+your exim config. If you don't tell exim to send them, it will not
+send them.)
+
+There are no options to either control. Both must appear before
+the DATA acl.
+
+. subsection
+
+DMARC checks cam be run on incoming SMTP messages by using the
+&"dmarc_status"& ACL condition in the DATA ACL. You are required to
+call the &"spf"& condition first in the ACLs, then the &"dmarc_status"&
+condition. Putting this condition in the ACLs is required in order
+for a DMARC check to actually occur. All of the variables are set
+up before the DATA ACL, but there is no actual DMARC check that
+occurs until a &"dmarc_status"& condition is encountered in the ACLs.
+
+The &"dmarc_status"& condition takes a list of strings on its
+right-hand side. These strings describe recommended action based
+on the DMARC check. To understand what the policy recommendations
+mean, refer to the DMARC website above. Valid strings are:
+.display
+&'accept '& The DMARC check passed and the library recommends accepting the email.
+&'reject '& The DMARC check failed and the library recommends rejecting the email.
+&'quarantine '& The DMARC check failed and the library recommends keeping it for further inspection.
+&'none '& The DMARC check passed and the library recommends no specific action, neutral.
+&'norecord '& No policy section in the DMARC record for this sender domain.
+&'nofrom '& Unable to determine the domain of the sender.
+&'temperror '& Library error or dns error.
+&'off '& The DMARC check was disabled for this email.
+.endd
+You can prefix each string with an exclamation mark to invert its
+meaning, for example "!accept" will match all results but
+"accept". The string list is evaluated left-to-right in a
+short-circuit fashion. When a string matches the outcome of the
+DMARC check, the condition succeeds. If none of the listed
+strings matches the outcome of the DMARC check, the condition
+fails.
+
+Of course, you can also use any other lookup method that Exim
+supports, including LDAP, Postgres, MySQL, etc, as long as the
+result is a list of colon-separated strings.
+
+Performing the check sets up information used by the
+&%authresults%& expansion item.
+
+Several expansion variables are set before the DATA ACL is
+processed, and you can use them in this ACL. The following
+expansion variables are available:
+
+.vlist
+.vitem &$dmarc_status$&
+.vindex &$dmarc_status$&
+.cindex DMARC result
+A one word status indicating what the DMARC library
+thinks of the email. It is a combination of the results of
+DMARC record lookup and the SPF/DKIM/DMARC processing results
+(if a DMARC record was found). The actual policy declared
+in the DMARC record is in a separate expansion variable.
+
+.vitem &$dmarc_status_text$&
+.vindex &$dmarc_status_text$&
+Slightly longer, human readable status.
+
+.vitem &$dmarc_used_domain$&
+.vindex &$dmarc_used_domain$&
+The domain which DMARC used to look up the DMARC policy record.
+
+.vitem &$dmarc_domain_policy$&
+.vindex &$dmarc_domain_policy$&
+The policy declared in the DMARC record. Valid values
+are "none", "reject" and "quarantine". It is blank when there
+is any error, including no DMARC record.
+.endlist
+
+. subsection
+
+By default, Exim's DMARC configuration is intended to be
+non-intrusive and conservative. To facilitate this, Exim will not
+create any type of logging files without explicit configuration by
+you, the admin. Nor will Exim send out any emails/reports about
+DMARC issues without explicit configuration by you, the admin (other
+than typical bounce messages that may come about due to ACL
+processing or failure delivery issues).
+
+In order to log statistics suitable to be imported by the opendmarc
+tools, you need to:
+.ilist
+Configure the global option &%dmarc_history_file%&
+.next
+Configure cron jobs to call the appropriate opendmarc history
+import scripts and truncating the dmarc_history_file
+.endlist
+
+In order to send forensic reports, you need to:
+.ilist
+Configure the global option &%dmarc_forensic_sender%&
+.next
+Configure, somewhere before the DATA ACL, the control option to
+enable sending DMARC forensic reports
+.endlist
+
+. subsection
+
+Example usage:
+.code
+(RCPT ACL)
+ warn domains = +local_domains
+ hosts = +local_hosts
+ control = dmarc_disable_verify
+
+ warn !domains = +screwed_up_dmarc_records
+ control = dmarc_enable_forensic
+
+ warn condition = (lookup if destined to mailing list)
+ set acl_m_mailing_list = 1
+
+(DATA ACL)
+ warn dmarc_status = accept : none : off
+ !authenticated = *
+ log_message = DMARC DEBUG: $dmarc_status $dmarc_used_domain
+
+ warn dmarc_status = !accept
+ !authenticated = *
+ log_message = DMARC DEBUG: '$dmarc_status' for $dmarc_used_domain
+
+ warn dmarc_status = quarantine
+ !authenticated = *
+ set $acl_m_quarantine = 1
+ # Do something in a transport with this flag variable
+
+ deny condition = ${if eq{$dmarc_domain_policy}{reject}}
+ condition = ${if eq{$acl_m_mailing_list}{1}}
+ message = Messages from $dmarc_used_domain break mailing lists
+
+ deny dmarc_status = reject
+ !authenticated = *
+ message = Message from $dmarc_used_domain failed sender's DMARC policy, REJECT
+
+ warn add_header = :at_start:${authresults {$primary_hostname}}
+.endd
+
+
git://git.exim.org / users / heiko / exim.git / blobdiff