What I was compaining about was that the data payload (i. e. the
text/html which was encoded) would be converted to CR/LF, i. e.
Zm9vCmJhcgo=<CR><LF>
should NOT be converted to
Zm9vDQpiYXINCg==<CR><LF>
I am sorry, but you are wrong. The latter form is 100% correct,
according to the RFCs (see RFC 2046, §4.1.1, paragraph 1).
Now, should mhfixmsg correct that? Weeelll ... good question. The
reason it is happening is because our MIME parser is now doing the
'right' thing, and essentially the whole message is being regenerated.
Fixing that would involve telling the base64 parser to not perform the
line ending translation for (some) text parts. Part of me sees the
point about not modifying parts of messages you haven't told it to, but
a (larger) part of me thinks: seriously? That message is incorrectly
formatted, and the name of the tool is "mhfixmsg". I think David has
to make this call.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers