Fwd: Re: [ietf-dkim] Introducing myself
Charles Lindsey
chl at clerew.man.ac.uk
Thu Dec 7 02:41:32 PST 2006
On Wed, 06 Dec 2006 16:36:32 -0000, Wietse Venema <wietse at porcupine.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.man.ac.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
More information about the ietf-dkim
mailing list