> For #2, DKIM is most useful for positive identification, and i= would > similarly be most useful for positive identification. Whether you say > i=auntm...@bigisp.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, jo...@iecc.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
