Mark Delany:
But the user does not see a bunch of bits. The user sees the combined
result of software layers that render those bits. DKIM has no
control over that rendering process.
Really? Do you mean doesn't or shouldn't or can't?
Does DKIM control text-to-voice conversion, or text-to-text language
translation? These are just two ways of presenting email to a user
that I could come up with.
Obviously these two are among the more lossy transformations. But
even text-to-screen conversion, without language translation, can
produce different results with different MUAs as discussed at the
beginning of this family of ietf-dkim threads.
Apropos layering violations: are we saying that having a UA inject
message 'A' via a DKIM layer into the mail stream, and then having
some random/malicious goop cause message 'B' to pop out of the DKIM
rabbit hole at the other end is less of a layer violation than
ensuring that message 'A' comes out that rabbit hole?
Bad guys don't have to play by the rules. For example, message A
is sent by the signer, and comes out of the verifier as A++. The
++ stands for extra content that does not break the DKIM signature,
but that changes the way the message content is presented to the
user. This is one of the problems that this family of ietf-dkim
threads is concerned with.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html