If you want to skim this message, at least please read the comments at
the bottom.
On 4/1/2011 9:51 PM, John R. Levine wrote:
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.
I disagree with both 1) the assertion about the right way to provide
per-user reputation streams and 2) your statement about "the point of
standardizing something like i=".
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).
For #1, the reputation still resides mostly on the bigisp.com's
reputation -- you have to trust that reputation to provide useful
per-user information before you can trust the per-user information --
the two don't stand alone. You also would need to have separate DNS
entries for each individual user.
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.
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.
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.
That's part of the problem with i=: different people had different ideas
about how it could be useful. And those notions have all gotten
conflated together into i=. Hence my initial idea of a way to specify
what information *is* being put into i= by the domain signer.
There're several pieces of secondary information that the domain signer
can potentially provide. One is information on the user associated with
the message, another is information on the stream class of the message
that's been discussed in a separate part of this thread. I'm certain
that there are a few others.
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.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html