Re: RMAIL, MIME-related bug

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

> > I have found a variable called rmail-enable-mime, and some void
> > variables of type rmail-*-mime-* which don't fit into my
> > implementation and I don't understand why they are here anyway.
> 
> IIRC, this is for add-on packages that add MIME support to RMAIL.

Do you know of such a package? I was not able to find any.
If there exist some, I don't want to break it. Otherwise I don't
believe those variables are useful.

> > 2) If I save an email to the file, I want it to be the same message
> >    as RMail read from my mailbox. I want to be able to read it from
> >    another mail client, for example.
> 
> Someone wrote code to do that, but it's currently on a separate
> branch of the Emacs CVS.  I suggest to leave this issue alone, not to
> mix it with the other changes you did.

Actually, I ment rmail-output function from rmailout.el file, but
after consideration I agree that I used that functionality so often
only because there was no better way to get attached files from the
email. Normally I don't need to export emails to files.

> > 3) I agree that some action (transfer-/charset decoding, PGP signature
> >    verification, etc.) is OK to do once in function called from
> >    rmail-convert-to-babyl-format, but some other (picture previews,
> >    big attachement hiding, etc.) should be done by every (?)
> >    rmail-show-message call.
> 
> I suggest to discuss this (on emacs-devel).  There are trade-offs here
> that IMHO are not so trivial to resolve.

OK, this is how I see it.

When we convert the email to babyl format, we can do some MIME-related
processing on it, for example: all text/* bodyparts may be
transfer-encoding (quoted-printable and base64) decoded, PGP/GPG
signatures verified, PGP/GPG decryption done, header fields of type
=?...?B?...?= decoded (RFC 2047) and unfolded (RFC 2822), etc.
This needs to be done once. No information is lost in this step. No
structure information is lost either.

When we show the message, I'm not interested in following things:
* MIME-related boundaries;
* Header fields of most entities;
* Entities of some types (multipart/alternative(text/html),
pgp-signature, etc);
* Entities of types image, audio, video, application. Instead, I would
like to see a button [Save as...] which will save an entity to file;
* Entities of types image/jpeg, image/png, etc. may be displayed right
here in the buffer.

Granted, we can delete boundaries and header field we don't want to
see, but what to do with big bodyparts like attached images? Where to
store them so that the user does not normally see them, but can
access them anytime in the future?

Also, please note that if we delete any MIME-related information, we
will not be able to parse the message again later. Well, we will need
some other parser. This way we invent another format. I don't like
this, that's why I don't agree that we should delete something we
don't want to see on the screen.
As I proposed before, I would like to hide the information using the
"invisible" property. I'm open to suggestions.


Another problem is that we currently brake the email by inserting
"simplified" header between original header and the message body (in
rmail-reformat-message function). After this is done, MIME-parsing
function does not work anymore.

I would very like to hear your ideas.
Thanks to anybody in advance.


-- 
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