On Wed, 06 Dec 2006 16:36:32 -0000, Wietse Venema <wietse(_at_)porcupine(_dot_)org>
wrote:
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,....
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.
Hmmm! I actually counted 138 :-( .
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.
I have little sympathy with implementations that don't adhere to standards.
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.
However, it is not as bad there as you suggest. Provided the c14n is
correctly implemented at both ends (and there is never any room for
incorrectly implemented c14n), it does not matter if some buggy MUA
produces bad Q-P or Base64, because the c14n will treat it the same way at
both ends. But the specification of the c14n has to be very tightly drawn.
It *does* matter if some MTA that downgrades 8BITMIME en route gets it
wrong. And I need to look into that (I have the source code of sendmail to
hand). Fortunately, RFC 2045 defines pretty exactly how Q-P and Base 64 is
to be done, especially as regards which CRLFs belong to the text being
(en/de)coded, and which to the structure of the multipart.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html