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