Neil, I am slowly embracing the position of the Mailing List advocates. If mailing lists and all other exceptional situations could be eliminated, evaluators could mindlessly apply a rule to "block on fail when p=reject". Similarly, if all evaluators would implement reliable mechanisms for domain members to request and obtain exceptions for mailing lists and other exceptional traffic, then domain owners could publish p=reject as soon as all of their traffic had signatures. Unfortunately, we have a reality that some highly valued traffic arrives without authentication, and some evaluators do not provide an effective exception process. This conundrum is aggravated by filtering products that do not provide administrators with sufficient exception configuration options. I am content with language that documents this conundrum.
The Internet will always be an environment of imperfect information, so the only viable filtering scheme is one which expects and allows for exceptions. Additionally, my defenses against impersonation should not be dependent on the domain owner's policy statement. Any allowed message is implicitly assumed to be free of impersonation, but assumptions are dangerous. It is my job to replace guesswork with certainty based on research. As indicated earlier, this can be done. Using DMARC, SPF, and local policy, I am at 100% verified for MailFrom, and 97% verified for From. Mailing lists have nothing to fear from my filtering and I have nothing to fear from p=none. In short, we need smarter filtering. Doug Foster On Tue, Apr 11, 2023 at 1:34 AM Neil Anuskiewicz <neil= 40marmot-tech....@dmarc.ietf.org> wrote: > > > > On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz <n...@marmot-tech.com> > wrote: > > > > > > > >>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman <skl...@kitterman.com> > wrote: > >>> > >>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: > >>> I’m a bit concerned that the document will discourage domain owners > from > >>> working toward an enforcing policy. I’ve seen at least one person say > that > >>> most domains don’t need to go to p=reject. I’ve seen all sorts of > domains > >>> attacked? Granted, high profile domains or perceived lucrative targets > will > >>> receive the most attention but threat actors absolutely do attack all > sorts > >>> of organizations all the time. > >>> > >>> Maybe I’ve misunderstood but I hope that no langue that could be > construed > >>> as discouraging domain owners from moving toward an enforcing policy > would > >>> be a mistake. > >> > >> It all depends on the user base of the domain and the tradeoff between > the > >> benefits of having such a policy against the interoperability risks of > having > >> such a policy. > >> > >> We absolutely should be discouraging blind adoption of policies that > result in > >> reduced utility for email. For any domain that has non-transactional > users, > >> that takes work to assess the completeness of email authentication > deployment, > >> assess aggregate reporting to understand the likely effects of either > >> p=quarantine or p=reject., and then evaluate the cost/benefit > trade-offs > >> associated with such policies. That's a non-trivial set of work to do > and > >> it's not cost effective for all domains to do it. > >> > >> Early in the deployment of SPF there was a similar push to deploy SPF > records > >> with -all (the SPF rough equivalent of p=reject). A lot of people did > it > >> without thinking it through and there were significant side effects. > The > >> community concluded that SPF Fail (due to the -all in the record > matching) was > >> not a sufficiently reliable indicator that mail should be rejected and > largely > >> stopped doing it. > > Scott, I’m also aware of what happened to SPF’s run as a policy layer. > There’s a big difference between SPF and DMARC. People deploy DMARC with > the knowledge that it is the policy layer. Many soon learn that SPF hard > fail isn’t honored much. > > There were too many costs to enforcing with SPF. DMARC’s SPF OR DKIM makes > for a more robust system that you can get your legit mail passing DMARC > consistently. SPF does was it does well but it with things like forwarding > breaking it, the presence of DKIM made up for some of SPF’s shortcomings > and vice-a-versa. I think we can agree that SPF, in retrospect, wasn’t a > good place to set policy. > > DMARC is a much stronger policy layer so I hope you are thinking that the > policy setting aspect will go the way of SPF? It won’t. > > Neil > _______________________________________________ > 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
