For example, our implementation would put the username@domain into the
i= value when it was dealing with an authenticated user mail submission,
and otherwise leave it blank. If there were a way in the DNS key record
to indicate those semantics, the recipients could use that information
for additional processing.
Three questions spring to mind:
a) What does "authenticated user" mean, in general for domains you don't
know?
b) Why should I believe your authenticated user flag?
c) Even if I do believe you, so what?
If bigisp.net has i=boris(_at_)example(_dot_)com and assures you that Boris
signs in
before sending mail, what does that mean? If the goal is to give every
user his own reputation stream, the right way to do that is to use
different signing domains, e.g. d=boris-example-com.bigisp.net. If you
want the mail to have both Boris' reputation and the ISP's, sign it twice.
Since the DKIM spec ignores unknown fields in the DKIM-Signature line,
domains who know each other and want to exchange sorting hints can always
do so with a private field. The point of standardizing something like i=
is to give it useful semantics for mail from people you don't know, but if
you don't know them, you can't believe any assertions they make, so
there's no point.
Also, I really do not want to provide a way for mail systems to say, we
authenticate all our users, so you can just block mail from the ones who
are sending spam. Ugh.
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
PS: My understanding has always been that the motivation for i= was to
work around uncooperative DNS managers who refused to install enough key
records to provide a different d= for each reputation stream. I believe
that such people exist, but I don't see why it's our job to enable them.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html