On Sun, 2006-07-23 at 11:53 -0700, ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com
wrote:
My view is that DKIM is designed to provide a boundary service between
administrative domains. (I suppose we could up with a different term
than administative domain here, but since the two will align more
often than not I prefer to stick to existing terminology.)
A given administrative domain may elect to provide some measure
of "internal" DKIM service (or they may not), but this isn't required
for DKIM to achieve its primary goals and may lead to expectation
mismatches.
To the extent an administative domain elects to employ conversion
services (and far from becoming less common, we're seeing an upswing
in the use of such services), they need to position the use of DKIM to
take such services into account. This may mean that signatures need to
be applied some distance from where messages were injected into the
infrastructure and verification may need to occur some place prior to
verification results actually being consumed.
In any case, I'm not suggesting that we forbid extended uses of DKIM,
but I think it is big mistake to actively promote them.
Striving to allow the message to be verified at the MUA increases the
possible success of DKIM in offering the desired assurance. While there
may be problems in some cases, many of these cases could be avoidable.
Signing at the MUA offers less value and will likely see a higher level
of failure. There are many reasons to caution about signing at the MUA.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html