No. Realistically, this is the last document likely to come out of this group on this subject. So I am no sure to publish it unless it fixes the coverage problem.
To state the coverage problem another way: - Content filtering creates a need for whitelisting - Any domain may require whitelisting, regardless of sender policy. - Whitelisting is only safe if it is coupled with an authentication mechanism which prevents impersonation. - Therefore, sender authentication, by a combination of local policy and sender policy, needs to be defined for all possible messages. Doug Foster On Fri, Sep 15, 2023 at 7:23 AM Alessandro Vesely <[email protected]> wrote: > On Thu 14/Sep/2023 16:39:49 +0200 Murray S. Kucherawy wrote: > > On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster wrote: > > > >> Our assumed reference model is a fully automated, by-the-spec > >> implementation of RFC 7489. In particular, this means that: > >> - when p=none, unauthenticated messages are never obstructed, for fear > of hindering a wanted message > >> - when p=reject, unauthenticated messages are never allowed, in the > blind faith that such messages are always unwanted > >> - when p=quarantine, automation will break down, so the policy is > recategorized as either none or reject. > >> > >> This raises a coverage problem. A huge volume of traffic will not be > >> protected by Sender Authentication, so the evaluator becomes entirely > >> dependent upon content filtering to protect himself from attacks that > >> impersonate unprotected domains. In the unlikely case that a content > >> filtering implementation is sufficient for non-DMARC domains, it is > likely > >> to be sufficient for DMARC domains also, making DMARC unnecessary. > > > > I don't follow the logic here. Both the DMARC verdict about a message > and > > the result of content filtering are, as I understand it, typically > weighted > > inputs to a final disposition decision, even when that DMARC result is > > effectively a shrug. > > > > If the underlying theme here is a need for ultimate determinism, I think > by > > now we've learned that's a fool's errand. The decision machine is far > too > > complex, and making it comprehensive requires enormous investment that > not > > many operators can afford to make. > > > I strongly object to that position. The magic spell that content > filtering > provides is such a nuisance that many operators gave up and turned their > service to giant providers, who are large enough to maintain a worldwide > reputation system. Domain based authentication was devised to provide an > alternative, deterministic approach. > > > >> [...] > >> > >> The problem is the reference model. DMARC is not amenable or > appropriate > >> using a fully-automated implementation. > > > > I don't believe it has ever been claimed to be such, nor do I believe > there > > is an illusion that this is even possible. > > > There is. The much discussed Interoperability Considerations section > clearly > establishes that the "only" problems are mailing lists and forwarding. > So, as > we have an ARC protocol ready, and because it is the goal of both sides > —ML and > forwarders on one side, receivers on the other— to reliably deliver > legitimate > messages, it is enough to devise how to make them meet in order to make > ARC > work as intended. I do believe it's possible. Is it an illusion? For > sure, > it is way easier than making content filtering reliable. > > > > If the issue is that the document under development claims otherwise, > > that's something that deserves attention. > > > DMARCbis doesn't make that claim. It quietly surmises it when it talks > about > authentication ecosystem becoming more mature, but it doesn't arrogate it. > > DMARC is just the reference model Doug described. Its full payoff is > p=reject, > but it cannot be universally deployed for the time being. This limitation > has > been made explicit. The sooner we finalize the documents under > development, > the sooner we can turn to fix forwarding. Trying to stuff extra problems > into > DMARCbis is counter-productive, as it actually delays tackling those > problems. > > > Best > Ale > -- > > > > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
