On Wednesday 26 July 2006 14:14, Michael Thomas wrote: > This is a really good instance of what the base level requirements are. > On the one hand we can say that the requirement is that an ISP signing > on behalf of a customer actually sign on behalf of the customer. That > is, the d=customer.com rather than d=isp.com. > > What I see here is the desire to actually have d=isp.com with the policy > saying that that is ok. One downside of this is that you'd require a policy > lookup because the From: address would still be customer.com, not > isp.com (ie, it looks like a third party). On the other hand, it doesn't > seem like it's a very big burden on the signing software to know what > domains it signs for, but I'm not as convinced about that from an > operational standpoint. > Agreed.
I see it as a complexity tradeoff between managing multiple keys for multiple domains versus a single key for the ISP's domain and doing additional policy lookups for ISPs that sign 3rd party for their hosted domains. In the short run a single key requires simpler software to execute and has fewer management headaches. I think it is more deployable. By substituting additional policy lookups for local key management and signing software complexity, the complexity is lower for the deployer. In the long run the multiple key approach is probably more scalable since the associated complexities are within the boundary of the sending ISP and the part that has to scale to internet scale (the policy lookups) is minimized. I do not think it likely that we can tell in the next several weeks which approach is the most likely to be utilized in the long run, so we ought to see if there is a reasonable way to accomodate both rather than pick. As far as the burden associated with knowing which keys to use on a per-domain basis, I think there are two classes of burden: 1. The back end management and coordination to get and maintain keys from all the relevant customers. 2. The operation of the signing library that signs with a different key depending on the sender. As far as how hard #2 is, does anyone's implementation support this currently (I'm asking, I don't know)? Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html