> > But if it is done by the MUA, the problem is that fully comformant SUBMIT > > agents or various sorts of other conforming intermediaries can and often > > will > > wreck the signature.
> Yup. > But, then, I view that as merely an exemplar of the question of surviving > transit through intermediaries. That the SUBMIT "intermediary" typically > makes > significant changes merely makes this scenario more interesting to explore. And dangerous to condone. > > And this says nothing about non-conforming intermediaries, > > which aren't exactly unheard of. > They are the core issue in deciding canonicalization trade-offs and I am > certainly not making light of the concerns. However I do not believe I've > suggested anything that lessens or increases them as an issue for DKIM > utility. You specifically raised the point that DKIM could be applied prior to submission. To the extent we suggest that this and other "internal" uses of DKIM are feasible, my fear is that we raise expectations to an unreasonable degree. What happens when users attempt to use DKIM this way, only to find that the verification fails a significant fraction of the time? > Again, MUA-based signing provides a more challenging example of the issue, but > this is a difference in degree, not in kind, IMO. > > If you want another example, how about RFC 4141? You're a coauthor of that > > one. > I think that content conversion *must* be viewed as a gateway function, and > that > surviving gateways is already a challenge for DKIM. True content conversion, sure. But the problem is there's an essentially continuous range of actions from "convert this audio clip from stereo to mono" or to "add a disclaimer" to "convert from 8bit to quoted-printable" to "fix up these headers". It is hard to know where to draw the line. > Since you raise this example and I think it is interesting, let's explore it a > bit: > The only way that I can think of surviving is to have the signature > evaluation be done before the conversion. This means that conversion must > take > place within the trusted AdMD in which the result of signature validation gets > used. This can occur after content conversion, or the like, but must be > within > the same trust boundary, so that the mechanism for communicating the > validation > result -- such as with an Auth-Results header field -- can itself be trusted. > Thoughts? 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. Ned _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html