Attention Charles Lindsey, PLEASE FIX YOUR DUFF digital--SIG

[Ian G Batten]

This is a multi-part message in MIME format...

------------=_953628904-9166-0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Md5: Nn8EPmXBbgSj8JmGbrqG5w==

>  I'm still confused. Is it still the case that Charles has broken
>  client software, producing broken messages, which cause myself
>  (and others?) to get error messages??  So I should ask him to
>  fix it, and then shut up???

I've addressed this in private email, but to draw a line under it in
public, I'll do it in public.

I wrote a MIME viewer and editor to bolt on to the back of MH, before I
discovered the wonders of mutt, and as part of that I implemented
Content-MD5.  The only client I initially found that was setting it was
Sun's dtmail, which is what Charles is using, and I was surprised that
my implementation didn't interwork (or at least, didn't check correctly:
dtmail generates Content-MD5, but doesn't check them).  I managed to
prove mine interworked with exmh and someone else's personal code, so I
investigated what dtmail was doing.  I use my code still to do
standalone multipart MIME signatures, like this, and I believe I get the
Content-MD5 correct.  However, I'm using it to protect a
quoted-printable bodypart which is, as a component of a multipart,
delimited by known tags.

RFC1864 points out that

   Finally, as discussed in Appendix B of [1], textual data is regularly
   altered in the normal delivery of mail.  Because the addition or
   deletion of trailing white space will result in a different digest,
   either the quoted-printable or base64 algorithm should be employed as
   a content-transfer-encoding when the Content-MD5 field is used.

so using Content-MD5 to protect a non-encoded, non-delimited piece of
mail is questionable.  It transpires that dtmail _always_ appends a
newline to the message you send, even if there is a newline present
already, and it does this after it has generated Content-MD5, which is
totally broken.  You can prove this by using dtmail to send a message
which consists of one line of text and exactly one newline: you'll find
it arrives with _two_ newlines.  Only dtmail does this.  If you feel up
to writing the code, you'll find the Content-MD5 is correct, if you
delete the extra newline.

I raised this as a bug under the auspices of our Solaris Platinum Beta
status on 29 Jun 1998.  I've to'd and fro'd on occasions, but it's never
got to the point of being fixed, and I've never cared enough to push it
hard.  I can't offhand find the Sun bug number: 4108636 is related, but
not the same.  I don't think it's entirely clear why Content-MD5 was
implemented in single-part messages anyway, and as very little actually
checks it the bug's just festered.

This isn't configurable, so Charles cannot turn it off without stopping
using dtmail (or doing something hairy with sendmail to suppress the
line as the mail is sent).  If people have applications that check
Content-MD5, they will unfortunately register a failure unless their
code can be modified to try again with the trailing newline deleted.

Coming next:  ``how to get uuencoded documents correctly through the
WISCVM Bitnet gateway''.=20

ian

------------=_953628904-9166-0
Content-Type: application/pgp-signature
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Description: PGP Information

-----BEGIN PGP MESSAGE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: xiFhyNh9DWPbu3EHWdPtQyiIfyoeS4On

iQB1AwUBONc46Moy0yij3IvtAQFUgAL+N+ZzbZtW7/c/rgvbruXIRLi1mmJs17DH
xEzhxJpj4Amj3ZOzicwRfNi7fW1LPRFd9KRZ5dGlcuEYGPG0WQ3y1HNPnV2nK9er
HdyLR6/9QZDerHoCNKyCk21+LOq8xa8F
=l12k
-----END PGP MESSAGE-----
------------=_953628904-9166-0--