>I would think that finding two plain text files with the same MD5
>that a mail message receiver finds an acceptable read is rather
>unlikely though. (Just generally speaking. CRUX Linux for
>example uses signify for package checksums, but still generates
>MD5 checksums as a fallback. CRC32 is
Ken Hornstein wrote in
<20221228151732.bd63b1d2...@pb-smtp20.pobox.com>:
...
|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
...
I
>> 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
ralph wrote:
> Hi Paul,
>
> > > - The generation and verification of Content-MD5 headers is no
> > > longer performed. The -check and -nocheck switches to various nmh
> > > programs that would control this functionality still exist, but
> > > are non-functional
Hi Paul,
> > - The generation and verification of Content-MD5 headers is no
> > longer performed. The -check and -nocheck switches to various nmh
> > programs that would control this functionality still exist, but
> > are non-functional and will be removed in the next
ralph wrote:
> ---
> DEPRECATED FEATURES
> ---
>
> - The generation and verification of Content-MD5 headers is no
> longer performed. The -check and -nocheck switches to various nmh
> programs that would control this
Hi David,
> Greetings as we approach the new year.
Yes, hello all. Hope you've had a nice Christmas.
> What does everyone think of pushing out a 1.8 soon?
+1
> Here are changes since 1.7.1:
> https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes