On Sun, Jun 7, 2020 at 16:21 Scott Kitterman <[email protected]> wrote:
> 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. Selector is already there, it’s just OPTIONAL. There’s another ticket about making it required. > > Scott K > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* [email protected] *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
