[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Could someone please explain the nature of the problem that
would exist
when these (financial) institutions can't selectively add DKIM
signatures to outbound email? Engineering is about balance, but I
haven't heard enough to make the trade off yet.
I think the alleged problem that putatively needs to be
solved is that bigbank.com somehow manages to get signing in
place for their employees whose names start with A through M,
but hasn't get gotten around to doing so for N through Z and
wants to tell the world that it signs all ofthe A through M.
I have to admit that I don't see this as a problem worth
solving, either.
As I pointed out earlier, it is possible to define the policy scheme in such a
way that per user policy is a backwards compatible upgrade that can be added in
later if it is found to be useful.
Achieving such a situation is a good way to strip out questionable features.
There are certainly use cases but whether those use cases are compelling is
another issue. Per user keys are not the same thing as per user policy.
I think it is entirely likely that bigbank.com would have a situation where the
mail servers for its east coast offices were adding signatures but the ones for
the west coast were not. The part that is less easy to see is whether there is
value to the short term fix. It is probably easier to just do the deployment.
But it is not certain that this will be the case.
Conclusion: hedge our bets, make sure we can deploy per user policy should we
need to. Reversing the priority so that the domain policy record is always the
master seems to me to be the right approach here.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html