Minutes interim-2021-dmarc-01: Thu 09:00
minutes-interim-2021-dmarc-01-202105270900-00

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
-------------------------------------------------