Jon, et al, Not to distract from the primary points you are making -- and which I both agree with and am happy to see documented -- I think it worth clarification a particular issue. I am pretty sure it is actually what you meant:
> This feature has some ramifications. One of these is that the actions of > > a bad user affect the opinion receivers will have of an administrative > > domain, and this affects the good users in the same administrative > > domain. But there are ways that the managers of that system can do > > interesting things. These are allowed, but orthogonal to the basic DKIM. > > For example, a large ISP can use selectors to put "good" users under the > > aegis of different set of keys than the less good users. If the difference between the good actors and bad actors is visible to receive-side valdiation and assessment, then the distinction should be between different d= strings, not different selectors. > > Another ramification of this is that the end user has no control over > > this. This is the flip side of the above. If I put [EMAIL PROTECTED] in > > a different key than [EMAIL PROTECTED], Goofus has to lump it or pack > > up. But we want this! It is again, a *feature*. If DKIM didn't have > > this, then commercial ISPs couldn't use it. Again, I believe you mean different d= values, rather than different "keys". If the signing is done by the same entity for both types of users, then there is no benefit in using different keys, whereas there is quite a bit of benefit in having the reputation identity use different domain names. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
