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
>> <exim-users@??? <mailto:exim-users@exim.org>> 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.
