> 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 [email protected] 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, [email protected], 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
