However I notice that not only the "text/plain" part has been
modified; the "text/html" part has _also_ been modified:
originally, it was a base64 encoded HTML file with UNIX line endings
(plain LF); now it is a base64 encoded file with DOS line endings (CR
Just as a point of note ... text parts that are based-64 encoded are
supposed to have CR+LF line endings. Before we got that wrong, but the
latest release of nmh should get that right (we'll write out those with
Unix line endings when storing them, and add a CR during encoding).
Technically a base64-encoded text part with Unix line endings is wrong
according to the standard.
Oh yeah, thanks. I could see an option for mhfixmsg to not try to do the right
thing. I find the current behavior of adding the CRs when it's supposedly not
modifying a part to be a bit annoying.
Nmh-workers mailing list