Minutes IETF108: dmarc
minutes-108-dmarc-00

Meeting Minutes Domain-based Message Authentication, Reporting & Conformance (dmarc) WG
Date and time 2020-07-28 13:00
Title Minutes IETF108: dmarc
State Active
Other versions markdown
Last updated 2020-08-02

minutes-108-dmarc-00

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

  • Scope of work: what is DMARCbis?
  • Document splitting - how many, etc

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.

Will be discussed on the mailing list