Re: nmh 1.8?

[Ken Hornstein]

>> Seems like they should maybe emit warnings for a release
>
>Yes, i.e. be deprecated.  But that ship has sailed and I don't think Ken
>would be pleased if I added them back in so they could be deprecated.

Sigh.  Ralph, you and I don't agree on Content-MD5, which is fine.  But
I have to point out that as far as I can tell nmh is (was) the only
MUA that generates that header or checks it.  I'm not even sure we
calculate the digest correct for text types, it was a mess in terms
of implementation, _and_ MD5 is Officially Considered Broken.  Calling
the removal of it a security flaw seems ... well, inaccurate at best.
Also, that header specified a hash algorithm, not an HMAC, so even if
the algorithm wasn't broken it wasn't keyed so an attacker could simply
modify the header to match the modified content.  From my perspective
making -check/-nocheck a NOP has roughly the same security properties as
implementing Content-MD5.  I'm fine with removing the flags completely
so people are forced to remove those flags from config files, or leaving
them as NOPs.

As I've said before, if there are arguments FOR Content-MD5, I'm willing
to hear them.  But here's what I said when I removed it and I think
everything in there still stands:

https://lists.nongnu.org/archive/html/nmh-workers/2019-07/msg00106.html

Ralph, I know you said that you think it's useful to check to see if
messages get mangled or corrupted, but if you're the only one who
generates or checks that header then I don't see how that will work.
I think Content-MD5 was just something that wasn't thought out very well
when it was created.

(I do want to implement S/MIME and real GPG support at some point,
which would actually be useful and have some real security properties,
but ... sigh, lack of time).

--Ken