>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 -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
