It makes no sense for people who despise DMARC, for its damage to mailing lists, to sign off on a document that ratifies everything that is problematic about RFC7489.
The engineering issues are abundantly clear, but have been ignored for too long. - The most information that a domain owner can assert is that his messages can be authenticated at origination. - Some domain owners make mistakes, and as a result, their messages have less authentication at origination than they expect. - Messages can lose (and gain) credentials in transit. The domain owner has no control over this process and minimal visibility into it. - Some Internet participants willfully originate messages that are beneficial impersonations on behalf of network participants. Therefore, the most that can be said about authentication failure is that: - An unauthenticated message MAY be an impersonation; - IF it is an impersonation, it MAY be malicious or otherwise unwanted. - Evaluators MUST do due diligence to resolve these ambiguities. - This ambiguity exists regardless of the DMARC disposition policy. This problem is no different than the problems with content filtering. If a message that trips one of my content filtering rules, it means that the message MAY be unwanted, but the heuristic is imperfect and some messages may be wanted and even necessary. That is why we have whitelisting. If we stop pretending that DMARC tells us more than can be known, stop misleading our readers, then we can hope to obtain the benefits of DMARC without the collateral damage. It is not our job to give Gmail the automated system that they want, is it our job to give the community the truth about what is possible. Doug Foster On Wed, Oct 23, 2024 at 7:35 PM Murray S. Kucherawy <[email protected]> wrote: > On Wed, Oct 23, 2024 at 11:55 AM Jim Fenton <[email protected]> > wrote: > >> It hardly seems like the agreement was tacit when it’s quite explicit in >> the WG charter. >> > > Fair enough; let me rephrase: > > The charter is explicit (twice, by my count) that addressing the problems > with indirect mail flows is in scope for the working group. What it > doesn't make clear (hence "tacit") is the understanding, at least at the > time of chartering, that it's not only in scope, it's required. > > DMARCbis appears to address this via the text of Section 7.4, which in > essence tells senders to be careful about using "p=reject" if their users > might use lists, and tells receivers not to honor "p=reject" without doing > a lot of other analysis first and folding that into an acceptance calculus > of some kind; absent such analysis, downgrade the handling to match > "p=quarantine". The completion of WGLC with no further discussion suggests > that the WG believes that this is satisfactory. That's fine if so, but I > claim it falls short of what I imagine was anticipated, that being a > protocol solution, and I'm suggesting we should say something in the > document that reconciles or explains this. > > Someone please feel free to correct me if any of my understanding is wrong. > > To reiterate something I said earlier: I'm not obstructing the progress of > the document even though I disagree with a couple of the decisions made, > but I think those decisions -- especially this one -- need to be explained > or face scrutiny and delay during Last Call and/or IESG Evaluation. > > -MSK > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
