Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Alessandro Vesely <[e-mail]>]

On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote:
> If we consider this sort of thing, I want to push to keep one thing
> off the table:
> 
> Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
> Let's please just remove that from consideration.  It has not been in
> DMARC up to this point, and it would be really bad to add it.
> Deliverability would be worse than ever because we would get the worst
> of both: fragility of SPF when messages are relayed/forwarded, *and*
> problems caused by misconfigurations in *either* SPF *or* DKIM.


I agree it'd be an extreme setting.  It could only make sense in very extreme 
cases.  However, in those cases it might make sense.

In addition, if ARC-driven forwarding setups will gain the ability to override 
DMARC, at least for established forwarding paths, the forwarding prohibition 
would then be softened.  After all, spf-all requires a comparable behavior 
(except that SPF allows intermediate results) and many domains use it 
satisfactorily.

The conundrum is protecting users from self-injury versus unleashing the full 
power of the combined mechanisms.


> I can accept some mechanism for the sender to say "SPF only", "DKIM
> only", or "either SPF or DKIM".  I cannot except a version of DMARC
> where *both* must pass.


Frankly, I cannot imagine the usefulness of auth=spf only.  People who don't 
implement DKIM or don't like it don't bother publishing a policy to explicitly 
excluding it.  It's enough not to sign.  Excluding DKIM would be useful if keys 
have been compromised, an they have a long lifetime while, by chance, DMARC 
policy is given with TTL 3600.  It doesn't seem to be realistic.

Still, I'd allow that possibility for symmetry reasons.


Best
Ale
--