Re: RMAIL, MIME clean-up, coding system

[Alexander Pohoyda <alexander.pohoyda@gmx.net>]

Richard Stallman <rms@gnu.org> writes:

>     That's exactly what I have proposed: to encode them (text
>     bodyparts) back into US-ASCII stream using base64 method.
> 
> I am not really sure what that means.  Could you explain?

The basic problem is here once again:
We read emails from inbox file and store them into RMAIL file, doing
some processing on the way. This processing includes base64 and
quoted-printable decoding. Now, to export this email back to file
(rmail-output function) we have two ways:
a) write it using emacs-mule coding system;
b) encode bodyparts which need to be encoded using base64 or
quoted-printable "transfer encoding" and save the file as US-ASCII.

Solution (a) has a clear disadvantage that such a file may only be
visited by Emacs. Well, this is such a big disadvantage that I don't
buy this solution at all.

Solution (b) is more complicated and, in fact, does the action
reversed to what we did with an email in the first place.
Hopefully we don't have to do this too often.
So another question arises: does it make sence to do the initial
processing in the first place?
The fact is that we already do some processing, namely: we insert
the extra "simplified" header between the original header and the
message body.

Both solutions do not need the X-Coding-System header field, which I
mentioned before.
Do I oversee something?


> Anyway, the first idea that occurs to me is to edit the headers of
> the mime attachments to say how they are really encoded.  Why not?

Yes, this is already done.
Imagine that we have a message with two bodyparts of type text/plain.
One of them is encoded using koi8-r and another is a utf-8 text.
We know this, and we can show the message in the buffer.

The problem is here: how to export it into the file?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44