On Sunday, June 7, 2020 5:23:12 PM EDT Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/38 > > The spec is ambiguous about which DKIM key needs to be reported. > > The real world problem here is that sometimes the DKIM key(s) which are > reported in a row of an aggregate report have nothing to do with the DKIM > key used to evaluate the DMARC status within the same row. > > In https://tools.ietf.org/html/rfc7489#section-7.2, it says: > > The report SHOULD include the following data: > > o The identifier evaluated by DKIM and the DKIM result, > > Elizabeth Zwicky previously wrote: > > https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/ > "is genuinely unclear. Often there are multiple identifiers. Does this mean > I can pick any one of them? (That does not actually provide sufficient > interoperability.) If there’s a specific one I should pick, which is it?" > > https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/ > "I believe they MUST contain any aligned DKIM signature regardless of > validity and SHOULD contain an entry for each domain, selector, result > triple." > > Is it desirable to clarify this language, such that it is clear which DKIM > keys are required to include in a report, and if so, how should the > appropriate keys be determined?
In DKIM, I would have thought that the 'identifier' is the d= domain. Just based on that text, there's no need to provide the selector. Looking through the rest of the list, I don't see anything that indicates the DKIM selector should be included in an aggregate report. That said, the selector is pretty useful. I'd suggest it's essential for troubleshooting failures. Maybe there's two things here: 1. identifier needs a better definition. 2. Is there a backward compatible way to specify inclusion of the selector. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
