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
