On Wed 03/Aug/2022 21:52:21 +0200 John Levine wrote:
Yesterday on the NANOG list someone (names elided to protect the sort
of innocent) was complaining that he was getting DMARC failure reports
for his domain with a p=none DMARC record.
He insists that the failure reports mean something is wrong, the list needs
to make them go away, which of course means rewriting headers to make it harder
to tell who each message was from. I suggested that if he doesn't want the
reports he's asking for he should not ask for them, or perhaps use a three
line procmail script to sort the obviously benign list ones, but he's sure
it's the list's fault.
That's the reason people set p=quarantine; pct=0; t=y. Indeed, if there is
a failure, one would want to fix something.
This morning on Twitter @mnot noted with alarm that failure reports
about list messages give you a pretty good idea about who some of the
list subscribers are, which is true, and that it's something a list
operator can turn on or off, which is not.
List operators can (should? must?) rewrite From:.
Aggregate report leak some info too, especially for personal domains.
I don't think there's anything to change in the way failure reports work,
but we need to say a lot more about what they mean and how they're used.
- Failure reports will leak info about sender and recipient, even if you redact
them
- Most recipients don't send them. Are you sure you want to?
- Many reports have entirely innocent causes such as courtesy forwards and
mailing lists.
These are not a problem; there is nothing to fix unless, I suppose, your domain
isn't
supposed to be sending to forwards and mailing lists.
The best keyword to prevent use of DMARC by domains attending mailing lists
would be "MUST (BUT WE KNOW YOU WON'T)" from RFC6919 ;-)
- There's a whole lot of false alarms. Are you SURE you want to?
- Many reports ignore the spec and send random formats so you have to be
prepared for that.
In part, the format is difficult because it is not described in the
document, but in RFC6591, which in turn refers to RFC5965. Perhaps adding
a complete example might help.
- Are you REALLY sure you want to send them?
Explicitly discouraging implementations?
Looking at my reports for the past week, there's a bunch from Linkedin
and ISC, a fair number from mailspamprotection.com, which appears to
be hosting provider Siteground, in an invalid format, and from
antispamcloud.com, in the same invalid format, and a sprinkle from
what look like one-person mail servers running the OpenDMARC milter.
The main document seems to be close to done so I'd be happy to help with the
failure reporting one.
You're welcome to send contributions.
I'm off the office for a few days, but perhaps Steven can access Github?
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
