The notes are in the etherpad and also uploaded to the meeting materials page here: https://datatracker.ietf.org/meeting/interim-2021-dmarc-01/session/dmarc
For convenience, I'll paste the content below as well. Thanks to everyone who participated in a very productive meeting, and thanks especially to Kurt and Todd for taking detailed notes. Barry ------------------------------------------------- DMARC working group interim meeting 16:00-18:00 UTC, 27 March 2021 The purpose of the meeting will be to discuss the design team recommendations and remaining open issues in the following documents: https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ Agenda: 1. Introduction and agenda bashing 2. Discussion of draft-ietf-dmarc-dmarcbis * [Ticket 4](https://trac.ietf.org/trac/dmarc/ticket/4) - Definition of "fo" tag * [Ticket 47](https://trac.ietf.org/trac/dmarc/ticket/47) - Remove "pct" tag * [Ticket 50](https://trac.ietf.org/trac/dmarc/ticket/50) - Remove "ri" tag * [Ticket 52](https://trac.ietf.org/trac/dmarc/ticket/52) - Remove strict alignment and "adkim" and "aspf" tags * [Ticket 53](https://trac.ietf.org/trac/dmarc/ticket/53) - Remove message size chunking * [Ticket 54](https://trac.ietf.org/trac/dmarc/ticket/54) - Remove limit on report recipients * [Ticket 82](https://trac.ietf.org/trac/dmarc/ticket/82) - Deprecate "rf" tag 3. Discussion of draft-ietf-dmarc-aggregate-reporting 4. What would we have to do in order to bring this project (DMARCbis) to closure? * and possible timeline 5. AOB ------------------------------------------------- Note-takers (https://codimd.ietf.org/notes-ietf-interim-2021-dmarc-01-dmarc): 1. Kurt Andersen 2. Todd Herr # Notes: ## Introduction and agenda bashing [technical problems with screen share] * high-level review of current situation (see slide) * would like to have regular interim meetings to drive tickets to closure * all items will be confirmed on the list - focus on the text and tickets * review of charter constraints - operational experience ## Discussion of draft-ietf-dmarc-dmarcbis * [Ticket 4](https://trac.ietf.org/trac/dmarc/ticket/4) - Definition of "fo" tag * clarify the tag value to eliminate non-sensical combinations (see proposed text) * John Levine: seems reasonable * Autumn: in favor * Kurt: what about handling illegal combinations? * Alex: maybe senders will be more careful if they know what will happen * John L: if they don't follow the spec, it should be undefined * Kurt: should this just invalidate failure reporting? * Michael: at this point, most failure reports are only being done within the scope of contractual arrangements * Seth: concurs, but don't just hedge on the basis of failure reports are "rare" * John L: don't worry about what happens if someone does the record wrong * Dave C: simplifies the spec if we only focus on what is correct * Michael: agrees about the spec only talking about happy path * Seth: focus on these tags, have a separate ticket to rationalize any changes to tags * Sense of the room: in favor * [Ticket 47](https://trac.ietf.org/trac/dmarc/ticket/47) - Remove "pct" tag * see stats on the slide and in the ticket for usage * Autumn: it is being used outside of the intent in order to drive reporting conformance; is there another way to get that done? "pct=0" is really the only meaningful flag * Steve: very important for onboarding - supposed to be temporary, those use cases would not always be visible after 6-18 months * business decision makers need to feel like they are in control * has some different numbers based on Farsight data in 2021Q1 but needs to do further analysis * 747,641 out of 2.9M records * 672,640 are at 100 * 8,078 are at 0 * 66,923 are not 0 or 100 * Michael: not a fan, but don't see a compelling reason to remove * Seth (not as chair): the way it is defined today is highly problematic - either fix or remove * only sees 3 meaningful levels for ramping but may interact with SP/NP tags * what steps are really needed * consider discussing in the next interim meeting based on some proposed text changes * Autumn: people report that they don't understand how it would work too * who / how many are using something <100 and how long will they take to get to 100 * Alex: what about removing the extremes (0,100)? * Seth (as chair): defer to future meeting based on specific text * Michael: can we get rough consensus on this specific question? * Todd: there was an issue with Google groups at one point in time in order to get agg reports * John L: also used '0' to test mailing list hacks with rewriting * Consensus: keep the tag but rewrite (Todd will tackle) * [Ticket 50](https://trac.ietf.org/trac/dmarc/ticket/50) - Remove "ri" tag * Not currently being honored - text allows * Options: keep, deprecate * Steve: Quick pull from Farsight 1Q2021 data again: * 391,861 policies with ri= tag * 273,098 ri=86,400 * 102,344 ri=3600 * 4,075 ri=84600 * Ale: The report producer is responsible to implement the "ri" timing. It is also connected to the report size chunking (as a function of time). Have not seen data about the sizing/timing question... * Alex: not aware of any reporter who honors the tag * Alex: also not sure what the interaction with the chunking size setting * Seth: chunking size seems to generally break reports as a whole * Seth: some reporters charge based on report frequency (but seems like a non-IETF consideration) * Kurt: suggests removal * Seth: the result of this should not affect how DMARC works * Michael: maybe deprecated is the right approach * Todd: some problem with purists who harp on "you're not doing it right" * Seth: when moving to proposed standard, do we have to worry about the past (informational)? * Dave: strong "yes" to removal; don't use "deprecated" * Michael: there is a fair amount of existing code in production? Will any of that be changed? * Seth: should not make any difference * Dave: maybe some specific text pointing back to the informational version would be appropriate * Michael: sounds good * Dave: maybe in the intro or background * Steve: A supporting document can have detail/history about "things you might find" * Tim: notes in chat that IANA registry cites "ri" - will have to be cleaned out * Consensus: remove the tag, update the registry * [Ticket 52](https://trac.ietf.org/trac/dmarc/ticket/52) - Remove strict alignment and "adkim" and "aspf" tags * Todd (from slide): Usage of these tags is in the 2-5% range "s" value * Seth: should this be rolled into the "ratchet"/onboarding conversation? * Autumn: agree that basically no one uses it, but some banks think that it is valueable * some of the people who use it are confused about what it really delivers * but are highly committed to being "strict" * Dave: only supporting relaxed might be better at setting expectations * Seth (not chair): should get rid of this, but might trigger interop justification * Alex: some entities were going to be enforcing strict alignment regardless of the spec and published records * Dave: might be worth considering special communities who might want to extend the core spec; don't keep these pieces in the core spec; move it to an ancillary spec * Michael: does having it in, break interop? * Dave: it raises unrealistic expectations * Seth: it confuses *everyone* - does harm to adoption of the spec * Michael: most people don't even bother to read the spec * Seth: what value does this actually deliver? * Michael: it allows people to segregate different mail streams into subdomain streams * Seth: sounds like we need some more data * Consensus: table this for further investigation and later discussion * [Ticket 53](https://trac.ietf.org/trac/dmarc/ticket/53) - Remove message size chunking * Todd (from slide): <2.3% usage across records * Seth: some major report providers not only ignore this, but use it as an invalidation for the DMARC record as a whole * Ale: if you pass this limit, what "should" you do? * Seth (not chair): much easier to remove than worry about the edge case * Michael: this was put in to deal with the hypothetical risk of too large reports * Seth: has not turned out to be a real problem * Alex: kill it * +1 - Kurt, Michael, Seth * Consensus: remove it and update registry * [Ticket 54](https://trac.ietf.org/trac/dmarc/ticket/54) - Remove limit on report recipients * No known limits currently enforced * Seth (as report receiver): what happens if there are "too" many - related to mandated centralized reporting - never seen this be an issue * Autumn: curious to know how many people use large numbers; some use distribution lists * Steve: See aliases/DLs used to mask report processor as well as numbers. I'll try to get data for number of mailto: URIs. * Seth: Limit is intrinsic to the DNS record size * Hypothetical risk earlier on had to do with indirect mail bombing. * Kurt: should say they need to handle >1 * Seth: why not avoid the normative language * Kurt: adjust proposed language to use "SHOULD" and remove "in the order" * Autumn: if someone does specify 15 or 50 addresses, then systems will probably treat it as a misconfig * Seth: what if a reporter screws it up? don't worry about that * Michael: agrees with Kurt's changes * Consensus: proposed language as modified * [Ticket 82](https://trac.ietf.org/trac/dmarc/ticket/82) - Deprecate "rf" tag * There is only one format, and rf is not widely supported, is there any value in keeping it? * Seth: consider proposals coming from Steve/Ale if no alternate versions, then drop the tag * Alex: what about X-ARF format? * John L: hard to imagine anyone doing anything more - suggests removing the rf tag * Autumn: if something else is put forward, would it necessarily be a different format? * Dave: simple rule, if there's a clear need for variability, support it. If it's hypothetical for future need, they tend not to work out. Adds complexity, not utility. * Seth: Expectation was that there would be different ways in future. That hasn't panned out. * Mike: At the time, we didn't know, so we put the flexibility in. I get the argument for simplicity, but removing something like this sets a higher barrier if there's a need in future. * Seth: We can add it in future if that's the case * Mike: More than just adding to the registry, you'd need to update the standard. * Dave: is the doc processing the most important or is it the systems implementation cost? * making a standard based on "what if" is a really bad idea - not-useful complexity * makes a messier spec with problems * Seth: getting rid of the "whatifs" from the early work is where we will get real value * Michael: in the wild, we do see people stripping stuff from ARF reports (based on GDPR); how do we provide a standard way that will be endorsed by the EU privacy folks? * how do you get meaningful, privacy-preserving reports that are usable? * Dave: this is all theoretical * Michael: this is not just a theoretical issue * Dave: the issue is real, the actions are theoretical * Seth (as chair): seems like consensus to remove it with future potential concern * maybe move this tag into the failure report spec, out of the core * Michael: OK * Steve: still available if the failure report work finds a need? * Seth: yes, but not in core spec ## Discussion of draft-ietf-dmarc-aggregate-reporting * Alex: do we need to preserve compatibility with 7489 report processing? * do we need a method for the domain owner to specify version of report to be created? * Seth: over time, the report has already varied; first let's design what we *want* to create, then discuss details and implications * Alex: is it excessive to *require* the version specifier to be part of the report? * Seth: start with what we agree to be desired * Alex: sounds like "keep going, change as needed, discuss" * Seth: any other concerns with this approach? * no responses ## Reporting Questions (Alex) * Alex: there have been some asks for additional information * can a standards track doc normatively refer to an experimental? * reference yes; rely/depend on requires additional approval - try to avoid * Suggested core spec with extensions to cover more information * Barry: that should be easy - can be done with informative reference * Murray: could also republish the other specs as PS but that stretches out the timeline * Alex: how to best refer to the known extensions? * Barry: just refer to them informationally (non normative) * Dave: question of directionality - having the core spec refer to extensions is not a good approach; the extensions should refer back to the core for referential integrity * Seth: the generic reporting mechanism in the core spec should define the framework for the information, the extensions provide the details on how said framework gets filled in for the details of the protocol * Ale: makes sense, can do a generic extension * Alex: wants to be clear - other auth methods should be entirely part of the extensions [Seth had to leave] * Kurt: would like to see details * Alex: trying to avoid breaking the base part of the report * Michael: as long as we provide for extensions, then it is just defined within the XML * Alex: any XSD definition could be OK for an extension * Kurt: seems like some data might fit better at the row level, some separate * Ale: can we have a registry of extensions? * Alex: would like to be able to give receivers a chance to provide other data * Michael: creating a general reporting tool seems like it is too large in scope * Alex: is there value in making this super general * Michael: various providers have various other data available, narrow is better, keep close ties to auth * Kurt: seems like a repeat of the general/overly complex/hypothetical discussion * Laura: if you give people a chance to do this, then they probably will - even if it isn't useful * problems with standards "semi-compliance" by big providers will probably lead to complications handling the reports * Alex: if we limit this to official IETF extensions, does that help? * Laura: these reports are about auth failures, not general email stuff; for that, maybe abuse X-ARF * Laura: don't give them free-form extension capabilites * Laura: most senders rely on report processors to consume the reports and make them meaningful; the extra details will probably not get back to the senders * Alex: will start a new thread to the list (Next week) * Steve: seems like there are deeper existential issues to be resolved ## Failure reporting (Steve) * [Ticket 55] - may have been addressed * [Ticket 28] - report driven mail loops - thought it was closed, but then looked like Murray re-opened it * Ale: liked the proposal from John L (on the list) * Steve: will review the mail thread * John L: mail loop thing was deep in the "don't do that" category - out of scope to solve in the spec ## What would we have to do in order to bring this project (DMARCbis) to closure? and possible timeline Barry: was this productive? Should we do more? Generally: yes Dave: need to beware of having sync meetings become primary - only use interims for complicated/intractable issues Barry: the chairs are aware and things will be kept in line Michael: this does keep things moving forward Barry: need to make sure that we are actually having discussions on the mailing list and using the teleconferences to follow up on that, not just using the mailing list to rubber-stamp the teleconferences ## AOB * Next steps - Todd will open individual threads on the ML about each item for general consensus * Murray - congratulations on getting PSD published * Is anyone tracking the progress of the "experiments"? * Having data will really help down the road ------------------------------------------------- Attendees (name, affiliation): 1. Barry Leiba, Futurewei Technologies, chair 2. Seth Blank, Valimail, chair 3. Murray Kucherawy, Facebook, AD 4. Todd Herr, Valimail, DMARCbis editor 5. Autumn Tyr-Salvia, Agari 6. Kurt Andersen, Blameless 7. Tim Wicinski 8. Alex Brotman, Comcast 9. Laura Atkins, Word to the Wise 10. John Levine, Taughannock 11. Michael Hammer, AugTagger, Inc. 12. Alessandro Vesely, tana 13. Dave Crocker, Brandenberg InternetWorking 14. Matthäus Wander, bsi.bund.de 15. Doug Foster 16. Michael Richardson, Sandelman Software Works Inc 17. Steve Jones, DMARC.org ------------------------------------------------- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
