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
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
