DMARC session at IETF 114
Thursday, 28 July 2022
1600-1700 Philadelphia time (UTC-4)

  1. Intro and Admin
    • The purpose of the meeting is to resolve remaining issues in draft-ietf-dmarc-dmarcbis

Barry presented the Note Well.

  1. Closure on tree walk
    • Is the text in -14 right, or are there more tweaks needed?
    • Are the examples in Appendix B.4 enough?
    • Do we need another example à la B.4.3, where the domains differ?

diff between 13 and 15
https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-dmarcbis-13&url2=draft-ietf-dmarc-dmarcbis-15&difftype=--html

John L: differences in latest: PSD example made more complex
Tim W: Likes new example. Do we need a bad example?
John L: unlikely that anyone would do anything more complicated than the current example.
Barry: only way to show how NOT to do it would be putting psd=y where you shouldn’t, and we can’t really show that.
Seth: max depth of N, jump that number of labels. Complex organization use case that was motivation for tree walk should be an example. We miss the use case in some of those complex cases. Walk 1 then stop solves those, but abuse cases become a potential problem
John L: Talked about this with Scott; deepest label in the PSD is only 4 from the root so we did 5. Deep names are usually in the same org, so jump doesn’t hurt.
Murray: Is this rationale in the document?
Tim W: DNS people are paying attention to this.
Todd: Interpreted Seth’s question differently
John L: Think the rationale for jumping is in the mail archive
Ale: Perhaps we should have another round of possible changes
Barry: Please post specific text you want chnaged
Tim W: Offers to write text for shepherd writeup on the DNS aspects. Could also be the shepherd.
Barry: John L and Seth to sort out issues offline

  1. Mailing list interoperability
    • Is Section 8.5 and the reference to RFC 6377 enough?

Barry: (without hat) Doesn’t feel right putting this out as proposed standard with something that breaks a long-term protocol. Say something like p=reject is not intended for domains sending to mailing lists and such.
Murray: Generally supportive of using BCP 14 to say this. Since 6377 came out some time ago, is it still up to date?
Pete: This particular use of p=reject with mail that is not transactional WILL cause problems. Why isn’t it a MUST NOT?
John L: Concerned that because so many mailing lists have implemented hacks to accommodate DMARC, we will look stupid.
Pete: Most mailing lists have done this but not all. SHOULD NOT with no explanation isn’t a good idea.
Seth: (without hat) Strongly disagree on telling people not to. Fixing breakage is a charter requirement. Reject is important to many players. Doing a disservice telling people not to use it.
Jim F: strongly agree with Pete some folks who have mandating (DHS) an Informational was not good. MUST NOT cause compliance breakage.
Barry (without hat): Can’t in good conscience approve putting out a proposed standard that breaks a long-standing protocol. We don’t have protocol police.
Ale: p=none not effective other than getting reports. Think mailing lists can adapt
Barry: Getting unsubscribes on mailing lists because of breakage, even with workarounds.
Bron: pathway to ARC. Need a way to tell if it is being used. Big players have deployed but few others.
John L: “mailing list interoperability” misses the point. Some mail will be lost. Town’s mail from US Census was being dropped, and it was important. Rather than implicitly insulting people should warn them that some mailing list mail will be lost.
Pete: People always misunderstand 2119 words. Nobody will actually be forced to stop. Our MUST here means if you don’t do this, damage will occur. Let’s be clear about that. If we agree with Seth, the document should say SHOULD NOT. Pete thinks it should be stronger.
Trent: Need to set context. ARC: No use cases where it’s harmful.
Viktor: Supports MUST NOT. Just publishing p=reject isn’t a silver bullet. Display name abuse is another problem.
Barry: Point is to document this.
Jim F: More operational folks breakage problem is mailing lists. Telling Origination domain don’t publish p=reject if they are sending mailing lists. Problem extends to recipient side forwarding as well.

  1. Other issues?
    • How close are we to completion

Todd: No open GitHub issues need to be addressed. Rewrite of 4.8 still needs to be done.
Viktor: Since tree walk was mentioned, goes up to .com,
John L: expect many TLDs to have records by end of the year.
Tim W: 10.4 discusses display name attacks. 10.3 on dns security

  1. Discussion of status/issues with the two reporting docs as time permits

Alex B: Holding off to see how tree walk changes, etc. will affect reporting. Still some open tickets that need discussion but not critical.
Ale: Syntax of aggregate records question
Alex: (side discussion with John L about RNG file) Document from Google had to do with this.
Ale: (minutes taker having trouble understanding)
Alex: Idea about header only version of reports. Message-id
Seth: RFC 6973 (privacy) impact of failure reports needs to be considered. No major mailbox sends failure reports, mostly from open source code.
Pete: 5322 says message-id MUST be globally unique. But there are no guarantees.
Alex: Spammers don’t care, they will reuse them
Viktor: IDNA introduces 2 or 3 additional period separating characters.
Barry/John L: that was 2003 not 2008 IDNA. IDNA punctuation is a pit of hopeless despair

Adjourned 1655 EDT