On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] 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
