DMARC (Domain-based Message Authentication, Reporting, and Conformance) WG

#

Chairs

Documents:

https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/?includetext=1 https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/?includetext=1 https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/?include_text=1

MINUTES

Todd Herr: google groups required p=quarantine;pct=0 to get reports in the past.

Autumn Tyr-Salvia: p=quarantine mailing list munging happens but not p=none. Large customers very risk averse without pct=0.

Alexey: Could be addressed with more text?

Autumn: Yes.

Alwin de Bruin: Practical cases moving from quarantine to reject

Jim Fenton: deprecate may not be the right term here. Could just leave out.

Alexey: Will still explain reasoning.

Jim: Autumn in the chat p=none reports w/out header munging.

What kind of extensions should be allowed? What’s needed for future authentication mechanisms to be folded into DMARC? Extending reports for arbitrary authentication mechanisms to be reported makes it easy to collect data and run experiments without modifying the spec

Autumn: gmail including dkim selecters in aggregate reports, but not common. Would love to see more. Very useful for tracking down usage in large orgs.

Murray Kucherawy: 8601 add header s most common use case.

Todd: Ticket 57 on making dkim selectors required.

John Levine: add them into the reporting XML, advice on ignoring during parsing.

John: Both seem reasonable, suggest folks send suggested XML

Murray: Is question what must be included or might be included or some mix?

Alexey: Both - reasons to include or not include more, and privacy considerations.

Todd: Jesse @ Wisconsin strawman failure reporting to find problems.

Autumn: Some pieces we are less in need of. don't need full dkim header; don't need full date/time stamp; do use From addresses. Message-Id helpful at times. what specific fields people objecting to?

Michael Hammer: failure reports useful in getting rid of the baddness, not just arbitrary failures.

John: Not sure of problem solving itself. Most won't send failure reports, others will redact for legal reasons.

Alexey: Should have text on what should be included for useful failure report.

John: Talking to lawyers here about failure reports. People will report what they report.

Dave Crocker: Messy, unpleasant topic making do with solution. Different solutions, one may work. Having the spec state what it wants as a result does make sense. How it gets the info is a problem. Suggested text was clean and simple by whom? (Murray https://mailarchive.ietf.org/arch/msg/dmarc/Zw0KjyrNfHMQ5S8TpoBRNvnfVRc/)

John: Almost agree with Dave! when we split out into another document, different result.

Murray: Produce an org domain document from 7489 into new document. Can also add tree walk into same document or a new document.

Kurt Andersen: talk policy discovery first, before org domain is needed. On the fence on a separate document.

Autumn: Seen in higher ed. example of grad.univ.edu and multiple sub domains. univ.edu was not interested in doing dmarc. also seen in governments. one or two levels would be useful.

John: Asked DNSOP, wasn't concerned. CAA specifies a tree walk, and CAs do this. 5 levels, use the resolver cache to catch NXDOMAINs.

Jim: Discussed tree walk with ADSP, was very toxic at the time.

Wes Hardaker: CAA was used as an example but CAA queries much different than mail server.
The latter can produce more traffic. Provide guidance some reference to another dmarc record.

Alexey: Will take discussions to mailing list.