This rings to me like something that would look like the simple/relaxed alignment option currently in DMARC. "Require aligned DKIM" being something along the lines of "rdkim=y; rspf=n;" with the not-included/default value being "n." If you agree that adding it is simple enough, the real question is what value does this really add to DMARC and/or will it improve DMARC adoption? Personally, I think it would be generally welcomed among senders who like really granular control over their authentication or who don't fully understand DMARC's "defaults" (for example, senders who use "p=reject; pct=100;").
On Mon, Jun 14, 2021 at 1:10 PM Brotman, Alex <Alex_Brotman= 40comcast....@dmarc.ietf.org> wrote: > Hello, > > I was talking to some folks about DMARC, and a question came as to suggest > as the domain holder that your messages should always pass DKIM. > Effectively, the asker wants to say "I intend to deploy SPF and DKIM, but I > will *always* sign my messages with DKIM." So the obvious answer may be > "Just only use DKIM", but I'm not sure that completely answers the > question. While discussing with someone else, "Tell me when DKIM fails, > but SPF is fully aligned". There was recently an incident at a provider > where they were allowing any sender to send as any domain (and I'm aware > that's not specifically a DMARC issue). We all know brands that have just > dumped in a pile of "include" statements without fully understanding the > implications. In this case, other users could send as other domains, but > perhaps they would not have been DKIM signed. Should there be a method by > which a domain holder can say "We want all message to have both, or be > treated as a failure", or "We'll provide both, but DKI > M is a must"? > > >From a receiver side, it makes evaluation more complex. From a sender > side, it gives them more control over what is considered pass/fail. > > How does this look in practice? Maybe > "v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;" > (pm=Policy Matrix) > > Does this make everyone cringe, or perhaps worth a larger discussion? > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > _______________________________________________ > 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
