Charles Lindsey:
> That was quite some time ago, so to refresh your memories, I had been
> claiming that DKIM-base would fail to verify if some message had its
> Content-Transfer-Encoding changed en route, and that it proposed to get
> around this by saying that all messages SHOULD be sent as 7bit, or encoded
> into 7bit. In these days when 8BITMIME is now almost universally supported
> and widely used (with BINARYMIME coming along as well), that seemed to be
> a very backward step. So I proposed a canonicalization that would reverse
> all those encodings before hashing.
...
> So it was an issue of whether such a canonicalization really would be
> "orders of magnitude more complicated". Anyway, I have been working off
> and on on this since then, and I have written a demonstration
> implementation, as promised, of what it would take, which you can find at
> <http://www.cs.man.ac.uk/~chl/uncode/uncode.html>.
>
> It is less that 140 lines of Perl (excluding comments and empty lines).
> Hardly any "orders of magnitude" in evidence there.
Actually, it's 128 lines. But that's a minor detail.
With real production MTAs such as Sendmail and Postfix, the MIME
processor takes about 900 lines of C code (sans comments, formatted
in the K&R coding style). That's 900 lines of opportunity for error.
My concern is about interoperabilitity. With the present design,
senders and recipients who exchange QP or Base64 content only need
bug-compatible MIME processors in their respective MUAs.
When DKIM signers and verifiers are requird to up-convert QP or
Base64 content before computing signatures, we also require that
all DKIM signers and verifiers have bug-compatible MIME processors.
That is, bug-compatible with every MUA.
Introducing this extra requirement is unlikely to help with the
successful adoption of DKIM.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
