I think it's quite relevant. The assumption that this is based on is there's a need to specify because SPF data is not reliable enough for everyone. If that premise is correct (I don't agree with it, but it's a separate issue), then I think telling people that they should use DKIM because it IS reliable, when it's got its own issues isn't a great idea.
I've been mulling this whole topic over and I think I'm close to having mulled it enough to have a useful proposal. SPF bad, DKIM good is a gross over-simplification, but so is if it passed SPF, it's authorized, so go whine at the provider. Scott K On June 28, 2023 6:32:41 PM UTC, Barry Leiba <[email protected]> wrote: >I think DKIM replay is largely irrelevant to this discussion (about >the sender specifying which authentication to use), because if that's >your biggest concern with respect to DMARC, then "SPF only" is the >answer. "SPF *and* DKIM" is not any better than that. > >> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply > >(Assuming you mean "replay".) "SPF and DKIM" does not give any >benefit beyond "SPF only" in this case. > >Look, either SPF fails because the message was relayed illegitimately... >...or SPF passes because the replayer used the sender's legitimate >infrastructure to do the replay. > >Barry > >On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely <[email protected]> wrote: >> >> 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
