> If the DMARC spec makes that clear, I think we win. And recipients > can still do what they want: if DMARCbis goes out with "use DKIM only" > and a recipient wants to use SPF anyway, they can do that... just as a > recipient that decides to use best-guess-SPF in the absence of actual > SPF records is free to make that choice.
When said that way, I believe that requires a version bump v2 which would inherently means “use DKIM only," So supporters all do a version check: bUseDKIMOnly = (DMARC[“v=“] == “DMARC2”)?1:0 And the new supporter will use the flag bUseDKIMOnly throughout its current DMARC1 evaluation accordingly. Or via “Add-on” tag extension: bUseDKIMOnly = (DMARC[“auth="] == “dkim”)?1:0 Six in one, Half Dozen of the other? The problem is that there are implementations that do check for v=DMARC1 and will not required DMARC2 as a valid record when in fact a DMARC2 record exist whose only purpose in life was to signify a relaxed DMARC1 evaluation regarding SPF. I like the tag extension instead. Make coding life easier, I think. But if v=DMARC2 is the way Levine wishes to go, I’m ok. I see issues with just changing the inherent behavior without any protocol negotiating signals. — HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
