I want to add in a bit here as well.
In doing the crypto/security parts of DKIM, we had two goals in tension with
each other. One was to provide accountability for a message for all the obvious
But in the other direction, we didn't want DKIM to accidentally turn email into
an always-on-the-record tracking system with severe negative privacy
We wanted to maximize the effectiveness of authentication while minimizing the
tracking and privacy-loss aspects of authentication.
(Side notes -- by "we," I mean me, but I know that I wasn't alone. Also, we
know full well that unencrypted email has horrible privacy characteristics all
on its own.)
That's why, for example, there's an emphasis on DKIM being about the
intentionally vague term "administrative domain."
Now on the other hand, if an administrative domain wanted to go to the trouble
to authenticate down to the user level, we didn't want to prevent that, either.
The primary audience for DKIM includes regulated industries, after all.
I also add that some of the working group *wanted* to push i= into mandatory
user-level accountability, as well. Some wanted user-level as a MUST, and the
result was it being a MAY.
That means that we tried to:
* Maximize the domain-level accountability.
* Minimize the user-level metadata and privacy damage
* Permit user-level accountability for domains that want to add it on.
And this is a good deal of why i= is the weird beast that it is.
NOTE WELL: This list operates according to