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