Re: [nmh-workers] mhbuild(1)'s `-check' Belongs to Another.

[Ken Hornstein]

>mhbuild(1)'s `-check' adds a `Content-MD5' header to each part.
>Consider it's run by whatnow(1) due to `mime', and that's followed by an
>`edit', allowing the user to actually edit what's covered by the digest.
>
>I think the addition of `Content-MD5' should be in the outgoing pipeline
>once the content is committed, so presumably post(8) as everything
>passes through that?

Ralph, I have to ask ... why do you want to generate Content-MD5
headers, exactly?  I think at this point possibly you're the only one
generating them and/or checking them.  I know I asked you last time this
came up, and you said:

>I figure it helps spot buggy corruption by something that handled the
>bytes along the way, and I need all the help.

Which, I mean ... if nobody checks it, how could this possibly work?
I don't get it, I DON'T GET IT.  It's one of those things that my mind
has trouble wrapping itself around, like Morris dancing.

Okay, fine.  Content-MD5 headers aren't the end of the world.  I just
feel that they're kind of silly and pointless in this day and age.  Lots
of things are silly and pointless.  But we're talking about something
that is cluttering up the nmh codebase, and I haven't heard a compelling
reason to keep support for Content-MD5.  If you want to make that case
that we should keep it, then please do!

Honestly, if I ever get around to doing a rewrite of the MIME handling
I'm certainly wasn't planning on keeping support for it so we should
really decide if Content-MD5 is something we want to invest time and
energy into.

However, regarding your point about moving Content-MD5 generation to
post(8) ... well, I have some issues there.

In my mind at least, we've kind of divided up the tasks in terms
of message composition, formattting, and sending relatively well.
comp(1)/repl(1) and friends take care of the parts where a human does
the typing to produce a "mh draft file". send(1) takes draft file and
uses mhbuild(1) to turn it into a RFC 5322 format file, and then calls
post(8) to send it out on the wire.  With a few exceptions, post(8)
doesn't really change the RFC 5322 formatted file, and it sends it out
on the wire unmodified.  This all seems logical to me.

Now yes, you CAN run "mime" at the WhatNow? prompt and edit the
resulting file before sending it.  You CAN do lots of things; I have to
say that if you really want to use Content-MD5 AND you want to edit the
contents of a MIME message after the MIME headers have been generated,
you're kind of asking for trouble and probably deserve whatever happens
to you :-) (but, on the flip side, I don't think anyone will notice that
your Content-MD5 checksum is wrong, because nobody uses it! :-)). But
anyway, I think that changing post(8) to modify the MIME content of a
message is breaking the current architecture and I don't think that's
a good idea.  I'd be open to hearing arguments about why the current
architecture should change.

Now, regarding those exceptions to post(8) modifying the message that is
given to it ... the ones I am aware of are:

- post will regenerate email headers; specifically, it will make sure they
  are wrapped at an appropriate length (adjustable with the -width flag).
- post will always add a Date: header and optionally add a Message-ID header
  (well, unless you're using dist(1), then it will add a Resent-Date
  header and a Resent-Message-ID header, but you get the idea).

These are pretty limited and are only in the message header, so again I
think changing post(8) to change the MIME content of a message is a big
change and we only should do it if there is a very good reason (and,
obviously, I do not think Content-MD5 is a good enough reason).

--Ken