DMARC WG [virtual] meeting

Domain-based Message Authentication, Reporting & Conformance (DMARC)

dmarc-ietf108-agenda

#

Chairs

IESG Overlord

Agenda

Agenda Bashing, Blue Sheets 5min

DMARC-bis 10min, Chairs

Dave's Header Field Discussion

Murray's DKIM-transform draft

ABNF (tickets #7, #26, #37 and more) - time permitting

Lots of little ABNF nits, and no one's even really sure if you pull the ABNF from DMARC and everything it inherits, if it really parses. As part of standards track DMARC, is this worth digging into and cleaning up?

Notes:

Document split:

Jim Fenton: should we separate DMARC policy to the 4th document? Seth: policy layer is very thin, not worth splitting. But take it to the mailing list.

Dave's Author header field:

Pete: are both documents a set or completely independent? Dave: independent Jim: are these to be folded into DMARCbis or do you see them as being published as separate RFCs? Dave: ... Michael: What is the value of Author for DMARC? Dave: the intent of Author header field is to preserve the author information end-to-end. Seth: Is this replacing the need for ARC? Dave: don't want to state relationship to ARC. Pete: I have concerns about Author document: we create a new element in UI and then some protocol like DMARC will abuse it and use it as an identifier. (X-Sender and X-X-Sender sad story) Dave: this deconflates semantics between uses of From. Pete: we have bad experience with X-Sender, I am not convinced. John L: Agreeing with Pete. It is an interesting thought experiment, but I don't think people will make effort to implement this in MUAs. Michael: I am not sure this creates value (agreeing with John L). Now I need to validate 2 domains and possibly deal with them being different. Bron: I represent a MUA. Spammers will attack the new Author header field. It might have some value, I am not as negative as other people.

Dave's Sender draft presentation:

Dave: recent version has changed significantly. Originally it was suggesting to use Sender's domain instead of From domain. The current version just adds Sender alignment "in addition to, not instead of" From alignment. So another data point to use by recipients. This will make it easier to deploy incrementally. Alessandro: it is not difficult to implement domain verification for multiple domains. John L: I like this draft a little bit better than the Author header field draft. It doesn't need any MUA changes. It will solve the mailing list problem. Technically this is quite sound. Todd H: I don't see in the document how to handle DMARC policy conflicts ("reject" versa "none" for Sender domain versa the From domain) Dave: Yes, this is an issue that should be mentioned in the document.

Murray's DKIM transformations presentation:

Bron: even a short change like adding "unsibscribe link" pointing to spammer site becomes serious Murray: right, this can be abused Jim: I see lots of simularities to l= tag problems. This needs to be vetted to make sure that there are no vulnerabilities. Is the intent for the recipient to receive it in the original form ? Murray: you can substitute received version with the author's version, but it is not clear whether this is the right thing to do. John L: I have 1.5 comments. The whole idea of "acceptable" make it tricky. I also think that transformations in real world are more complicated than the document defines. Murray: yes. MIME implementations might differ in how they format things, which might make it unreliable. Michael: I have mixed feelings. I would like to experiment more with it.

ABNF related issues

Will be discussed on the mailing list