On Wed 10/Aug/2022 06:45:04 +0200 Scott Kitterman wrote:
On Tuesday, August 9, 2022 11:57:53 PM EDT Murray S. Kucherawy wrote:
On Tue, Aug 9, 2022 at 7:54 AM Dotzero <[email protected]> wrote:
When "we" (dmarc.org team) originally came up with DMARC, the goal was to
take what was in essence a private club to an open standard that anyone
could benefit from. My personal take is that validators choose not to
provide failure reporting for various reasons other than "it's a noise
generator". It requires extra effort and resources that some validators
choose not to undertake because it doesn't benefit them (from their
perspective). Another reason some validators don't implement is fear of
potential liability under GDPR or similar regimes. There are a number of
validators that provide failure reports through private channels but only
where a direct or indirect contractual relationship exists. This seems to
primarily through intermediaries that provide email authentication
services.
My recollection is similar. When DKIM was young, it was very valuable to
be able to get two implementations to cooperate when debugging validation
failures. Specifically, to debug a failed signature, you need the blobs of
data that were fed to each of the hashes from both the signer and the
verifier so they can be compared. That means the verifier has to keep
those things around, and when something fails to verify, it needs to dig
them up and send them back to the signer. RFC 6651 is the published
version of something that originally appeared as a private feature of
OpenDKIM, whose roots go all the way back to the first interoperability
event (~2005) where the ability to close these loops was hugely impactful
at working out the kinks. In essence, it allows you to include a signal in
your DKIM signatures that you want this data to be sent back to you if the
receiver is willing to participate. This same technique was useful when
developing and testing an open source ARC implementation.
I don't think there was widespread implementation of what that RFC
describes, but it is an early version of the theme that led to the forensic
reports in DMARC. For DMARC, the intent was similar: If my mail is landing
someplace and failing to validate, I would love to know why, and maybe
you're willing to help me out by providing me with that information without
me having to ask you to scrape logs and/or do other local sleuthing to find
the problem.
For an operator just experimenting with it to gauge potential impact of
turning it on fully, or to shake out the bugs in a new implementation, it's
quite valuable. But yes, it risks revealing all kinds of stuff and
ultimately shouldn't be left "on" once the thing is fully in production.
That doesn't seem to be the current usage. People seem to just set ruf= in
their record and leave it there for ever.
How about returning the full message/rfc822 of failed messages only when the
Subject: matches "This is a test"?
Back then we were more interested in getting DKIM and eventually DMARC
working, and privacy wasn't as much of a consideration as it is now.
(Note, for example, that both versions of DKIM and RFC 6651 pre-date RFC
6973, wherein the IETF formalized the idea of a Privacy Considerations
section.)
I agree with John, I think, that the amount of time we should spend
improving failure reporting should be proportional to how much it's used,
or how much the community is asking us to do so. If the consensus is to
drop it, then we should say, probably in an appendix, that original DMARC
had this, but nobody used it and it's a PII nightmare, so it's no longer
supported in the Standards Track version.
I think it would be useful to review RFC 6973 and see if we think feedback
reports as currently defined are consistent with it, but I don't think we
should spend a lot of time on revisions. I would guess there are, in general
terms, only three answers:
1. It's fine, no worries.
2. It's not fine, but can be made fine with tweaks.
4. It's not fine and needs a major overhaul, so maybe we dump it.
Given RFC 6973, I think we owe the IESG spending a little time to assess if
there is an issue or not. It would be useful, I think, for the shepherd write
up to be able to say that since the input specification was pre-RFC 6973, we
did an assessment in the working group and documented the appropriate privacy
considerations/made some tweaks as a result.
RFC 6973 deserves being referenced. Redacting all addresses (including
Received:'s for clause) can be mandated. Something like search the whole
header for '@' followed by a known domain and replace the local part.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
