Doug,
Douglas Otis wrote:
Once DKIM considers how to handle cases where the signing-domain and email-address domains are frequently different, then opportunistic techniques like those found in SSH look better than some complex array of DNS records. In the odd case where a domain is being phished, an assertion carried within the signed message can indicate the required bindings based upon a class of keys. These captured requirements would then block all cases where the requisite bindings where not found.
So you want us to define a "deny service to everyone else from this domain who doesn't have this key" field which is included in a header, and then also have an ssh like mode of operation where anyone (who can mess with the headers) can introduce new keys? No thanks. Not without it being a lot more worked out and demonstrated-safe. It is a wonderfully dangerous idea though but I think I'd prefer doing it at a lower layer, maybe using RFC 3514? :-) SSH works in part because there's a human in the loop when it matters. Such a situation doesn't arise here. S. _______________________________________________ ietf-dkim mailing list http://dkim.org
