Subject: [dmarc-ietf] Notes from DMARC interim teleconference, 27 May 2021

From: Barry Leiba <[email-masked]>
Date: Thu, 27 May 2021 15:55:08 -0400

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

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 27 May 2021 17:05:50 -0400

Thanks to all, especially note takers

One request to the chairs - can you upload the slide deck into the
datatracker also?

thanks
tim

On Thu, May 27, 2021 at 3:55 PM Barry Leiba <[email-masked]> wrote:

> Note-takers (
> https://codimd.ietf.org/notes-ietf-interim-2021-dmarc-01-dmarc):
> 1. Kurt Andersen
> 2. Todd Herr
>
> # Notes:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Todd Herr <[email-masked]>
Date: Thu, 27 May 2021 17:32:12 -0400

> One request to the chairs - can you upload the slide deck into the
I have the action to do this, and will take care of it on Friday the 28th.

--

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 May 2021 08:38:45 -0400

Todd sent me the final slides — thanks — and they are now uploaded at the
same link as the minutes.

Barry