>> 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
