About "does it reach this goal?" RFC7489 provided this outcome: "A simplistic and fully automated technique that blocks a small but insufficient subset of malicious impersonation, in exchange for blocking a small but important subset of legitimate mail."
DMARCbis has this charter: "A simplistic and fully automated technique that blocks a small but insufficient subset of malicious impersonation, without blocking any legitimate mail." Unfortunately, this goal is no more achievable than the alchemist's goal of turning straw into gold. Our document's workaround is to discourage DMARC participation, making the scope of harm smaller by making the scope of benefit smaller. So, no, the group has not achieved its goal because its has spent 10 years chasing the wrong goal. The proper use of DMARC is something that is not fully automated, and in its optimal from is not simple: "DMARC provides the starting point for a learning process which, when combined with other tools and human effort, detects malicious actors and isolates potentially-malicious impersonation to a progressively smaller subset of all mail." 100% From authentication has many benefits. It makes other forms of malice detectable (e.g. BIMI), and is achievable. Doug On Mon, Sep 30, 2024 at 3:47 PM Murray S. Kucherawy <[email protected]> wrote: > Replying to just a few of these: > > On Mon, Sep 30, 2024 at 10:58 AM Alessandro Vesely <[email protected]> wrote: > >> > In Section 2.1, under "High-Level Goals", there's a bullet that reads >> thus: >> > >> > "Minimize implementation complexity for both senders and receivers, as >> well >> > as the impact on handling and delivery of legitimate messages." >> > >> > Given the collision with indirect mail flows, which I don't think this >> > document actually improves relative to RFC 7489, do we feel like we met >> > this goal, at least the part after the comma? Should we revise this so >> we >> > don't draw fire for a failure here? >> >> I think we reached consensus on the fact that DMARC is not yet ready to >> be >> deployed out of the box (Sections 5.4 and 7.4). It's not an effective >> improvement, but at least states the problem well. >> > > OK, but are we fine saying an explicit goal of this work was X, and this > document does not meet that goal? > > >> > In Section 4.8, I think there's an ABNF ambiguity in that "dmarc-record" >> > ends with *WSP, but so does the optional "dmarc-sep" right before it. >> >> Does it have to be unambiguous? >> > > I think it's supposed to be, but I can't recall how hard of a rule that is. > > >> > Section 5.1.1, regarding SPF, says: >> > >> > "... SHOULD be constructed to ensure that only those authorized sources >> can >> > get an SPF pass verdict." >> > >> > Why is this only SHOULD when it's MUST for DKIM (Section 5.1.2)? >> >> Because SPF has many more possibilities than DKIM. Several operators >> allow /24 >> or even larger blocks of IPs, not all of which are actually legitimate >> MTAs. >> > > We need to say so. Without context, this reader at least was left > wondering. > > > Section 7.2 strikes me as something that isn't likely a novel discussion, >> > so is there any other DNS document we can think of where we can >> reference >> > the topic? >> >> Should we say that TTL SHOULD be at least _one day_, save for >> experimenting >> temporary values? Changing records during the day will likely confuse >> aggregate report generators... >> > > Rather than making up a guideline and attempting to justify it, I was > thinking that some other thing in the IETF's past must have tackled this > subject already, and we can just reference that discussion. > > >> > Section 10.8 also talks about "periodically checking the DMARC Policy >> > Records, if any, of PSDs" but doesn't talk about how one might achieve >> > knowledge of where they are. Is this just caching of the ones you've >> > discovered? >> >> Aren't there ICANN policies that (dis)allow publishing DMARC records? >> > > Maybe, maybe not; do we have to complicate this work with that discussion? > > -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]
