Harald wrote:
I like this scheme for the ease to find the original to any given
message. The downside seems to be, that originals aren't easily
accessible from nmh tools like pick.
Backup (,) message files aren't, either, and I view
the originals as similar in that respect. With the Message-ID
files, the original can be found with an easy grep.
To put a transformed message into a different folder, I'd use
-outfile - | rcvstore +folder.
That's a lot to type for what would be my most common usage, but
trivial to customize, so I think it is nice anyway.
I'll think about this some more.
I'm also undecided on whether "preferred form" includes
headers to properly mark the message as 8bit as if it was
actually sent that way.
I hadn't thought about keeping the old C-T-E header when
decoding base64 or Q-P, but I suppose it could. At this point,
I don't see the value in that, as noted in my message earlier
today about Valdis's observation.
My reasoning was along the line of "what would happen if I packf
a bunch of messages in preferred form and open the resulting
mbox in some external program". I don't know.
The C-T-E header must always match the actual content, so
mhfixmsg adjusts it as necessary. Messages can still be
handled by external programs (and nmh programs, of course).
Maybe I misunderstood your original comment about properly
marking the message as it was actually sent. I'm not aware
of any standard header mechanism to indicate a prior
encoding. (And we only have what we received; we don't know
how the message was originally sent, but I don't think
that's the concern here.)
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers