Thank you for your analysis. However, it doesn't touch on DKIM replay.
I know this topic belongs to the other list. Let me briefly recall it, if this
doesn't take too many cycles from core matters: It occurs when a signed
message is replayed by unauthorized hosts to recipients which were not
originally addressed. So, it is one case of your 3rd proposition: In some
scenarios, DKIM will pass when SPF fails.
You say that it is technically unnecessary to test both because DKIM should
always pass when SPF passes (1st proposition).
You claim:
But where the harm comes is in cases of mis-configuration, because now if
*either* of them is misconfigured, the whole thing fails -- neither of them
serves as a backup for the other; instead, the misconfiguration of either
one causes deliverability problems.
I agree. But what if SPF and DKIM are both configured properly? You seem to
imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your
analysis doesn't cover that case explicitly.
Perhaps there are better ways to counter that specific problem, and certainly
it's not what this WG is tasked to do. But, just to make the point, I think
it's interesting to know.
Best
Ale
On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote:
I don't understand how most of your message fits into this discussion:
you're comparing SPF's policy points with DMARC policy. we're talking
about SPF as an authentication mechanism together with DKIM (not
DMARC) as an authentication mechanism... and then using those
authentication results in DMARC policy evaluation.
But here: I've said all this before in separate places, so I'll put it
in one place, here, one more time:
Given that SPF and DKIM are both configured properly:
1. If SPF passes, DKIM will always pass.
2. If DKIM fails, SPF will always fail.
3. In some scenarios, DKIM will pass when SPF fails.
Therefore, when everything is configured properly, SPF adds no value
beyond what DKIM does, and DKIM does add value beyond what SPF does.
That's why I am (and others are) arguing that we should remove SPF
*from DMARC evaluation*. There's no argument that for now, or some,
SPF outside of DMARC still has value.
What others are arguing is that in the real world, things do get
mis-configured, and if DKIM is misconfigured and fails when it
shouldn't, SPF adds value by providing a working authentication.
(And, of course, similarly the other way around, plus DKIM covers some
cases when messages are relayed or forwarded.) That speaks for "SPF
*or* DKIM".
But "SPF *and* DKIM" -- requiring *both* to pass -- is technically
unnecessary at best, because of (1) above: DKIM should always pass
when SPF passes. But where the harm comes is in cases of
mis-configuration, because now if *either* of them is misconfigured,
the whole thing fails -- neither of them serves as a backup for the
other; instead, the misconfiguration of either one causes
deliverability problems. DMARC is damaged by requiring an
authentication situation that is unnecessary when things are properly
configured, and that is more fragile than what we've been using, more
susceptible to configuration errors than we've seen before.
And I'm afraid that people will use it preferentially, *thinking* that
it provides better "security" -- surely, double authentication is
better than single, no?
No.
Barry
On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely <[email protected]> wrote:
On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
I'm saying I don't want "and" to be an option, because I think it's
damaging to DMARC. There is no reason anyone should ever want to say
that, and providing the option asks for misconfigurations because
people think it's somehow "more secure". It's not more secure. It
would be very bad for deliverability of legitimate mail and would
provide no additional security. It would be a terrible mistake.
I've been sporting spf-all for years, and seldom experienced bounces, mostly
due to misconfigured secondary MXes. Out of 39 domains whose posts to this
list in the past year are still in my inbox, 14 have spf-all. So, while I'm
not the only one, not many published -all even though it may seem to be somehow
more secure.
I think it can be worth to compare SPF and DMARC. Another sender policy a
decade and an authentication method after. What adoption, what hype.
Both policies ask receivers to reject a domain identifier in some cases. RFC
7208 explicitly suggests to consider whitelisting (Appendix D). DMARC provides
for overrides but is less clear about how to handle exceptions. After SPF
broke forwarding, the reaction was split between some changing identifier and
turning to ~all; after DMARC broke mailing lists, between changing identifier
and not altering messages. In my limited experience, the ratio seems to be
higher for DMARC than SPF, but I may be wrong.
In theory, domains that currently have a strict DMARC policy and spf-all, 6 of
the above, should have their messages blocked when either method fails, up to
changing identifiers. Why would it be so bad for deliverability to
additionally require DMARC alignment, which is the difference between that and
the "and"?
And, it seems to me that an ESP not having a bloated SPF record could stop a
good deal of DKIM replay by resorting to auth=dkim+spf. Besides collateral
deliverability problems, why wouldn't that work?
Wht would "and" damage DMARC more than -all damaged SPF?
I hope we can discuss detailed criticism rather than vague ostracism.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
