From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alexander Pohoyda Newsgroups: gmane.emacs.devel Subject: Re: RMAIL, MIME-related bug Date: Sun, 12 Oct 2003 21:47:43 +0200 (CEST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310121947.h9CJlhKH006102@oak.pohoyda.family> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1065988648 5840 80.91.224.253 (12 Oct 2003 19:57:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2003 19:57:28 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Oct 12 21:57:26 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A8mLG-00055Z-00 for ; Sun, 12 Oct 2003 21:57:26 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1A8mLF-0002l2-00 for ; Sun, 12 Oct 2003 21:57:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A8mJB-0007Ho-Mf for emacs-devel@quimby.gnus.org; Sun, 12 Oct 2003 15:55:17 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1A8mJ3-0007C1-5h for emacs-devel@gnu.org; Sun, 12 Oct 2003 15:55:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1A8mIT-0006Gv-PT for emacs-devel@gnu.org; Sun, 12 Oct 2003 15:55:04 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.24) id 1A8mIR-0006GI-JZ for emacs-devel@gnu.org; Sun, 12 Oct 2003 15:54:31 -0400 Original-Received: (qmail 7729 invoked by uid 65534); 12 Oct 2003 19:47:47 -0000 Original-Received: from p508BF1A1.dip.t-dialin.net (EHLO oak.pohoyda.family) (80.139.241.161) by mail.gmx.net (mp009) with SMTP; 12 Oct 2003 21:47:47 +0200 X-Authenticated: #14602519 Original-Received: from oak.pohoyda.family (oak.pohoyda.family [127.0.0.1]) by oak.pohoyda.family (8.12.9/8.12.9) with ESMTP id h9CJlkR4006105; Sun, 12 Oct 2003 21:47:46 +0200 (CEST) (envelope-from apog@oak.pohoyda.family) Original-Received: (from apog@localhost) by oak.pohoyda.family (8.12.9/8.12.9/Submit) id h9CJlhKH006102; Sun, 12 Oct 2003 21:47:43 +0200 (CEST) (envelope-from apog) Original-To: Eli Zaretskii In-Reply-To: "eliz@elta.co.il"'s message of Wed, 08 Oct 2003 00:54:01 +0200 Original-References: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17046 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17046 > > 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 PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44