For #2, DKIM is most useful for positive identification, and i= would
similarly be most useful for positive identification. Whether you say
i=auntmary(_at_)bigisp(_dot_)com or d=auntmary.bigisp.net, that provides
useful
information beyond the d=bigisp.com (or i=@bigisp.com).
Is this really true? My signatures all have an i= that tells you in a
fairly easy to decode way which user sent the mail. Does anyone use it?
Do people really want to use DKIM to do per-user sorting of mail from
senders who can't manage their own users?
Flip that around: I want to give positive warm fuzzies to mail from the
users that are authenticated by bigisp.com and are on my positive list.
I believe that's what we call "human shields." Um, no. This whole model
of bigisp sending a mixture of legit and forged mail, and using i= to
assert nice things about the legit mail seems awfully strained. In my
experience, if I get a message with a credible signature, one of the
things that "credible" means is that the From: address is real enough to
use for message sorting.
Perhaps the thing to do *is* to remove i= and then really work on what
those secondary pieces of information should be. These can all be noted
by separate extension keywords connected together by the DNS entry and
the signature.
We're clearly long past the point where i= can have any useful semantics
other than as an auditing token for the sender (and, presumably, his
friends with private knowledge of what his tokens mean.)
I wouldn't be opposed to a strawman proposal of putatively useful sender
assertions, so long as there's also an explanation of how you decide when
the assertions are credible. Lacking private knowledge, the only self
assertions that should be useful are negative ones, which is more or less
what ADSP is supposed to be, but you also have the competence issue of
guessing whether the person making the assertions understands what he's
saying.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html