On 12/9/22 4:13 PM, Dave Crocker wrote:
The concern was and is generally about the broad messaging category
called spam, and not specifically or solely the sub-category called
phishing.
The above reference to things happening in transit and some out of
band mechanism sound interesting, but don't have much to do with the
original DKIM work, which really was only about giving receivers a
noise-free basis for evaluating messages associated with an identifier.
The concern for post-delivery evaluation and some sort of follow-on
actions associated with 'taking responsibility' were not part of the
DKIM development effort. There is nothing in DKIM's development that
was intended -- nor do I recall discussion -- for post-delivery
forensics or non-repudiation. And article I cited, as well as the
replay problem, demonstrate basic problems with such a use of it.
This is completely a-historic. Considering that I was one of three
original designers and wrote the first implementation, I would suggest
you not tell me what was in my head at the time. We were very
transparent about our concerns about phishing and in particular
spear-phishing. It was not discussed at the time because nobody was
talking about cutting secondary validators out of the equation. Plus,
protocols don't need to specifically envision all of their possible uses
up front and preclude all others.
I read that article ages ago. I didn't agree with it then, I don't agree
with it now. If you want "replay protection", email is not the vehicle.
"Replay" has been a basic feature of email for more than 40 years.
Mike
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
