>1. As noted above, the use of d= means that signing by parent domains, >specifically called out in RFC 4871, doesn't result in Author >Signatures. ...
>2. It has been noted that a domain might have different reasons for >signing a message. It might, for example, sign a message on behalf of a >mailing list manager operating in that domain. ... This, along with a lot of the i=/g= stuff, all strikes me as attempting to address the same problem, overloading signing keys. The reasonable solution to both of these issues is to sign in different domains. For #1, sign with the same domain as the author, for #2, if your list software doesn't control its traffic well enough to be confident that it's not going to be spoofed, sign list mail with a different d= domain. (That's what I do.) As Steve Atkins recently pointed out, the d= domain doesn't even have to exist other than as the key records. I realize there are organizations with uncooperative DNS managers who make it hard to install the key records needed. I wouldn't be surprised if some of us even work at such organizations. But a local optimization that ends up demanding extra work from the rest of the world to work around one's DNS management is, to put it mildly, not a great idea. If DKIM is going to be deployed, part of the deployment will be to figure out how to get the required records installed. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
