DMARC at IETF 123
Note well Noted.
Barry: we can finish failure reporting, or abandon it which would
require taking it out of the base document.
John: he doesn't think it's useful but it's harmless so just finish it.
Seth: problem that reports go to the wrong place, e.g. IT rather than
the department that sends mail. Tree walk fixes that. Also used for
threat hunting unrelated to DMARC, not a reason to keep it. Experience
says it causes severe PII leaks, e.g., calendar invites that reveal
activities, against IETF privacy best practice.
Barry: would warnings in document mitigate PII issues?
Seth: not really
Mike Hammer: disagrees with "don't do it because people get it wrong."
People get all sorts of stuff wrong, not unique here. Knows people using
reports privately to address abuse.
Barry: has the need waned since DMARC was new
Mike: still provides useful anti-abuse info. Doc is largely done.
Murray: more interested in where we are now
Seth: failure reporting was useful early on, not useful now for DMARC.
Aggregate is adequate, forensic is a risk.
Barry: could you live with warnings? Yes but would rather not.
Al Iverson: OK with deprecating, worry that people will assume that if
it's in the skip it's a good idea
Mike: people adopt DMARC to mitigate abuse. It's not about
deliverability but that's why people adopt it.
Dealt with mass forgery like the storm worm.
Mauro: write Stalwart mail server, has failure reporting. Failure
reports confuse people, are not useful to most users, but OK for him.
Murray: deliverability vs anti-abuse doesn't affect the document, just
document privacy concerns and ship it
Barry: proceed and add thorough privacy warnings and see if we can live
with it. Any strong objections.
Seth: objects but knows he's in the rough
Murray: what does Mike plan to add?
Mike: no large issues, reviewed the document, want to review section by
section
Seth: privacy needs a lot of work
Barry: agree, done other than privacy
Seth: lots of people haven't shown up, can we engage them
Is it essentially ready?
Needs the privacy stuff
What are the open issues?
Privacy
Trent Adams: we used reports at Paypal even though there weren't
many, but we understood that privacy issues pushed the industry away
from them. At Proofpoint, we have found other data to be useful in
filling in the gaps.
Let's plan a schedule and get aggressive about it.
Barry: plan to finish by 124 in Montreal
John: need specific deadlines
Seth: offers to take pen on privacy
Barry: Murray first, then pass to Seth
Murray: will also ask Trent for help
Mike: asks Trent if publicly available forensic reports would be useful
Trent: if they existed in a privacy protecting way, sure
Seth: would it add value for DMARC
Trent: hard to say, we would use them if they existed, but we have
proxies for what they provide, though we also understand that big
companies have large scale data that small companies do not
Barry: Murray and Trent will work on text for the privacy concerns
Murray: mid August, prefer overall review to a week per section
Seth: it's been reviewed, we're not going to change a lot
Mike and Seth: please shut down off topic list traffic