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?
mhfixmsg currently strips CRs out of text parts that it's decoding,
which is wrong. I'll fix that, with default behavior. But I plan
to add an option to strip/not add CRs.
mhfixmsg is becoming one of those wonderful swiss-army-knife tools
which are very powerful, and which can be confusing to figure out how
to use correctly.
i think it would be helpful for the man page to be very explicit about
what mhfixmsg does by default (it's only somewhat implicit, now),
perhaps along with some example invocations for the most common
my main goal in using it is to decode encoded parts, to make my
mail grep'able and mairix'able.
looking at my current scripts and config files, i seem to invoke it
inc "$@" && mhfixmsg unseen
mark -sequence cur $savecur
which runs mhfixmsg on everything i just inc'ed. my .mh_profile
mhfixmsg: -rmmproc mhfixbackup -noreformat
(which reminds me that i should expunge my "mhfixbackup" folder once
in a while)
i'm a little surprised to not find -decodetext in that invocation,
since your (david's) message arrived with C-T-E of base64, but is in
my inbox with a C-T-E of 8bit. am i perhaps forgetting something about
my own mh configs?
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 43.9 degrees)
Nmh-workers mailing list