Well, using RFC 4155 parse rules for From_ lines can lead to
different message boundary detection.
Sigh. I don't view that RFC as particularly relevant now, as it has
some serious problems (like only 7-bit data, for one). Also, it explicitly
says there is no escaping mechanism; I guess the idea was to define other
formats, but that never happened.
I removed that from the MUA i maintain, because you never know for
sure: for that you would need to scan the entire message first,
check if several From_ lines occur and have been quoted alike,
before you start to remove what you think is a superficial From_
quote.
It seems to me that the safest bet would be to default to mboxo, and
if the user knew he was dealing with mboxrd they could add the appropriate
switch to do the dequoting. That seems like a system parameter; either
your local MTA is doing mboxo or mboxrd, you shouldn't need to perform
any automatic detection.
And then ezml i think it was (what unicode.org had before
the switch to i think mailman) simply placed a space in the first
column... Any non truly-reversible change changes the original
content, applying a MIME content-encoding is standardized, there
you go.
I don't think that's relevant to nmh? If mailing list software is changing
things en-route that's nothing we should be concerned with.
mutt actively manages these header lines, at least.
Also, not relevant to nmh, I think.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers