To answer my own questions here: you are supposed to change the '-all' ending of your SPF TXT record into '~all', which means that a failure to validate results in a softfail, allowing DMARC validation to start/continue.
On 07/14/2020 12:43 PM, Adrian (Aad) Offerman wrote: > > On 07/14/2020 12:38 AM, Mike Brudenell wrote: >> >> Looking at the extract you posted, I think you are denying (rejecting) >> messages for which either SPF or DKIM verification fails? (For example, >> you're using *deny* used in the acl_check_mail ACL to refuse the MAIL FROM.) >> >> If so (it's late, and my tired eyes might be misreading things!), you >> may want to review and reconsider this as it is working against the >> ethos of DMARC, which passes if either SPF, DKIM or both pass. That is, >> DMARC passes even if one (bot not both) of SPF or DKIM fail. > > Nothing wrong with your tired eyes :) I think you're absolutely right > from a DMARC-only perspective: using rigid SPF and DKIM validation both > before DMARC validation will reject messages that validate on only one > of SPF and DKIM, but would be accepted under DMARC validation (assuming > the additional display name alignment checks out). > > That would plea for configurations (using switch variables) in which not > all three of SPF, DKIM and DMARC are enabled, e.g. > - SPF > - DKIM > - SPF + DKIM > - SPF + DMARC (= SPF + alignment) > - DKIM + DMARC (= DKIM + alignment) > - DMARC (directly, instead of contributing to a spam score) > > The only combination that doesn't make sense is SPF + DKIM + DMARC, like > you say, as DMARC will never be validated if SPF or DKIM is invalid (and > the message rejected already). > > >> For example, our University is very selective about which external >> service providers we add to our SPF record because of the risk changes >> they make could invalidate it. Instead we tend to rely solely on >> messages third-party service providers send out on our behalf being >> correctly DKIM-signed. That is fine and perfectly allowable under a >> DMARC policy. However I think your configuration is going to reject such >> messages because it sees SPF fail, without then going on to also check DKIM. > > Ah, so instead of aiming for the maximum possible, i.e. SPF, DKIM and > DMARC all being valid, you count on DMARC's OR-like validation and you > already know that messages sent by these external providers will fail on > SPF, as you only add their DKIM pubkeys and not the sending systems > (SPF) to your zone? > But this scheme will only work for receiving MX gateways if they > validate DMARC fully, not if they use only SPF, or SPF + DMARC -- if I > understand you correctly? > > >> On Sun, 12 Jul 2020 at 23:09, Adrian (Aad) Offerman via Exim-users >> <[email protected] <mailto:[email protected]>> wrote: >> >> I've been working on the implementation of SPF/DKIM/DMARC policies in >> the configuration of Exim on CentOS 8 (8.1). It turns out that >> everything is there (i.e. all functionality is compiled in in the >> package that comes with the repository), but there are no policies at >> all defined in '/etc/exim/exim.conf'. >> (there are some 'dkim_disable_verify' and 'dmarc_disable_verify' >> statements where DKIM/DMARC-validation should not take place, i.e. for >> local/relayed/authenticated hosts; and SPF and DKIM are validated as >> part of the (external) spam scan) >> >> Please find below the policies that I've created and tested (checking >> logs and headers of validating and non-validating messages in a test >> environment that is, not in a volume/operational environment yet). >> >> Any feedback on the polices themselves would be great. And maybe these >> would be a good starting point to get some policies into the Exim >> configuration that comes with CentOS, probably best with an on/off >> switch variable.
signature.asc
Description: OpenPGP digital signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
