Ale, here is an attempt at a formal model. Application to the current question is at the very end.
Any test (DKIM, SPF, ARC) has these result possibilities: - Pass - No data or uncertain result - Fail The test results are imperfect, so we have to consider these probabilities Probability that PASS is a correct result Probability that a false PASS will be whitelisted or not blocked in content filtering Net result that a false PASS is delivered to the user Probability that a NoData / Uncertain result is correct (presumed 100%). Probability that an Uncertain message is wanted or unwanted. Probability that an unwanted message is or is not blocked by content filtering Net probability that an unauthenticated and unwanted message is delivered to the user Probability that FAIL is a correct result Probability that a FAIL result is blocked by local policy (presumed 100%) Probability that a false FAIL is actually wanted Net probability that false FAIL blocks a wanted message My strategy is documented in my "Best Practices" draft submission. To summarize my experience: - The frequency of a true PASS is high, so the probability of a false PASS is low - The probability of a false PASS being detected by content filtering is pretty good. - The frequency of a true FAIL is low, so the probability of a false FAIL is high. - Uncertain messages have a high percentage of unwanted messages, but also a non-trivial volume of wanted messages. My conclusions: - FAIL messages should be submitted to content filtering to collect more data - Blocking on FAIL alone, despite content filtering PASS, has always caused me more harm than good. - Treating UNCERTAIN as equivalent to PASS is harmful. Uncertain messages can be as unwanted as FAIL. - FAIL and UNCERTAIN messages need to be reviewed and confirmed. When confirmed, the message is allowed or blocked based on local policies which are informed but not controlled by the sender's published policies. - Quarantine on FAIL or UNCERTAIN is superior to Block, because it allows for ambiguity to be removed and policy rules to be updated - When FAIL and UNCERTAIN volumes are too high, an arbitrary disposition can be applied immediately, but statistical sampling should be used to review the disposition decision after the fact, so that local policies can be updated. Application to the current AUTH proposal: - I expect SPF AND DKIM will cause sender policies to be less believable, because a high rate of FAIL will occur on wanted messages, so I expect to treat SPF AND DKIM as SPF OR DKIM by local policy. - I trust DKIM more than SPF so I see no reason to honor SPF ONLY. I will continue to apply SPF OR DKIM . - I see the advantages of DKIM ONLY and will honor that policy when it is detected. Doug Foster On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely <ves...@tana.it> 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc