Re: Rmail/mbox new mail/coding system issue

[Eli Zaretskii]

> Date: Wed, 24 Sep 2008 10:33:18 -0400
> From: Paul Michael Reilly <address@hidden>
> 
> Currently, Rmail (and Pmail) append new mail messages to the current
> mail buffer.  With Rmail/mbox the mail buffer is unibyte.  But since
> the User can select new mail to come from a non-mbox mail file
> (especially a collection of Babyl formatted messages) it is now pretty
> clear to me that Rmail/mbox must read the new mail messages into a
> temporary buffer (with multibyte enabled) where the collection is
> converted, if necessary, to mbox format and then appended to the
> Rmail/mbox collection of messages.

That's true, but I'd only do this if you positively detect a Babyl
file, or some other sign that it's not an mbox file.

> The issue is how to handle the per-message encoding that might be
> necessary to represent the message in a unibyte buffer.  Off the top
> of my head I would be inclined to encode the message as base64 but I
> would not be surprised if that is overly simplistic.

Why base64? just encode it according to the X-Coding-System header,
generate a suitable content-transfer-encoding MIME header, and that's
it.

> First, how can I tell if a message must be encoded?

Babyl files need encoding if you want to generate an mbox file from
them.  That's because Emacs reads and writes them with no-conversion.

> Second, I confess to not knowing Babyl sufficiently well to know if it
> loses information in the process of decoding and storing the messages.
> So, is it even possible to re-encode a Babyl message?

In some rare cases, information can be lost, but you don't have any
choice but encode the message body anyway.

In any case, I wouldn't worry at this point about appending Babyl
files.  I suggest to solve first the case of appending an mbox file.
After all, this will be by far the most frequent operation with
Rmail/mbox.