From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Lillibridge Newsgroups: gmane.emacs.devel Subject: Re: Change in rmail-insert-mime-forwarded-message Date: Thu, 10 Jan 2013 08:53:24 -0800 Message-ID: <87sj69569n.fsf@foil.strangled.net> References: Reply-To: mdl@alum.mit.edu NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357836828 9862 80.91.229.3 (10 Jan 2013 16:53:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jan 2013 16:53:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 10 17:54:05 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TtLOB-0003tG-RX for ged-emacs-devel@m.gmane.org; Thu, 10 Jan 2013 17:54:00 +0100 Original-Received: from localhost ([::1]:38595 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtLNw-0005iz-3f for ged-emacs-devel@m.gmane.org; Thu, 10 Jan 2013 11:53:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtLNk-0005Lt-LS for emacs-devel@gnu.org; Thu, 10 Jan 2013 11:53:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtLNb-0006Mo-Lg for emacs-devel@gnu.org; Thu, 10 Jan 2013 11:53:32 -0500 Original-Received: from alum-mailsec-scanner-1.mit.edu ([18.7.68.12]:64748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtLNb-0006Mf-J4; Thu, 10 Jan 2013 11:53:23 -0500 X-AuditID: 1207440c-b7f196d0000008bc-c3-50eef20386c0 Original-Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DC.51.02236.302FEE05; Thu, 10 Jan 2013 11:53:23 -0500 (EST) Original-Received: from foil.strangled.net (c-67-188-235-212.hsd1.ca.comcast.net [67.188.235.212]) (authenticated bits=0) (User authenticated as mdl@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id r0AGrK2l017886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jan 2013 11:53:22 -0500 In-Reply-To: (message from Richard Stallman on Wed, 09 Jan 2013 11:43:15 -0500) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqMv86V2AQVM3h8XjBU9YLaZ+PMNm MWXJVnYHZo+/7z8webRNMwtgiuK2SUosKQvOTM/Tt0vgztixI6igQaXi1/6nzA2MN6W7GDk5 JARMJKauvMMGYYtJXLi3HswWErjMKPH7SXIXIxeQfZVJYtLCdWAJNgFNienPvrOD2CIC/BIP 1/1mBLGZBcQlftztYwWxhQWsJHa+7ACLcwqUSry518QMMVRKYumiE2C9LAKqEvt+LQObySug L/Fny3dGCFtQ4uTMJywQMyUkDr54wTyBkW8WktQsJKkFjEyrGOUSc0pzdXMTM3OKU5N1i5MT 8/JSi3QN9XIzS/RSU0o3MUICjWcH47d1MocYBTgYlXh4m/zfBQixJpYVV+YeYpTkYFIS5XV6 BxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwtuyACjHm5JYWZValA+TkuZgURLnVV2i7ickkJ5Y kpqdmlqQWgSTleHgUJLgFfsI1ChYlJqeWpGWmVOCkGbi4AQZziUlUpyal5JalFhakhEPiq/4 YmCEgaR4gPaagbTzFhck5gJFIVpPMRpz7H/S/pyR49fyjueMQix5+XmpUuK8CiClAiClGaV5 cItgKeYVozjQ38K8+iBVPMD0BDfvFdAqJqBVc6a+AVlVkoiQkmpglFFd1HqnUjt1wwPfyTWs 7zz+NqX71845deffr+itCWzuN1Zcz2KL7Z2oEiBk+ZbrTaNU5PQVhxP7Lp8wljdeeDi6y9Qs 90ZJs/9Nx1YBRq0tHF0Jm94+OyTson2kR3Rxk8WmZ8ZHXlbeTtvQnire2nO24IJW X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 18.7.68.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156187 Archived-At: Richard Stallman writes: > (1) forward the exact original message with all formatting and > attachments included. That pretty much has to be done via an > RFC822(sp?) attachment of the original message as received. As noted by > bug #9766, some email clients are unable to display such attachments. > > (2) include the text seen by the Rmail user at the time forward is > called. > > Both of these were possible before your change. > The first was done with v f > and the second with plain f. My wording for (2) wasn't very good and you didn't quote the relevant bits, but it was intend to require that the text be put in the message body not a message attachment, which cannot be read by users of lame message clients. Your 'f' does not actually correctly implement (2) as I meant it. I agree that your 'vf' (assuming suitable bug fixes have been applied) implements (1). > I do not think we should use RFC822(?) message attachments for > this: I haven't read all the relevant RFC's, but I assume the > destination email client will attempt to display an RFC822(sp?) message > attachment as if it was a separately received message. > > f always puts the forwarded message into mime attachment, and there is > no problem in this case. The message _as displayed in rmail_ does not > contain mime part headers. It has things like this > > [1:text/plain Hide] > > instead. Depends on how the user is viewing the message. Hitting "t" will definitely get you the MIME headers but not the correct corresponding body. (A rare case, I grant you.) Also note that the charset encoding header is likely also gone, probably causing characters to be displayed incorrectly. > (3) A smarter version of (2) that both makes the original message > body visible to the destination client even for clients that don't > handle RFC message attachments > > I can't make concrete sense of that, sorry. Let me try a concrete example. Suppose you have a message with a text part message body "this is in red", message body HTML part with the same except actually in red, and an attached (non-in-line) PDF. With (3), the forwarded message would have: * a text message body part with something like "===== forwarded message =====", the Rmail filtered headers, then "this is in red" * the equivalent as an HTML message body part (including the headers protected via 
 or the like), with the "this is in red" part
    actually in red.

  * the attached PDF as an individual attachment (same suggested file name)

Optionally, you could also attach the original message as an RFC822(?)
message attachment part.

    For even more fun, there should be an easy way for the user to add
text before the "===== forwarded message =====" that shows up in both
parts.  See what I mean about being nontrivial?


>  	At the moment, in the absence of availability of (3), I use (1) for
>      forward and use resend message to deal with people with limited mailers.
>      I don't think (2) is a reasonable default because it drops attachments,
>      formatting, and doesn't work for HTML-only messages.
>  
>  With your change, only (1) is possible.  I think (2) is the right
>  default, but in any case, it is better to have both options.
>  
>  So I think I will revert your change.

    I agree that we should have more than one option, which is what I
recommended in the relevant bug report.  Correct code for (2) or ideally
(3) needs to be written and linked to a different invocation path.   If
only one is supported, then (1) is the better choice in my opinion.  I
think users can set rmail-enable-mime-composing to nil if they want (2) for
'f' but currently this is a startup choice rather than on a forward by
forward basis.

    Hmmm.  Richard, does the behavior of "f" when
rmail-enable-mime-composing is set to nil do what you want?  If so, we
just need to figure out a good way to make that behavior and my patch
behavior for "f" available at the same time.

    I'm not really keen on using the "vf" trick; it has the side effect
of changing the display of the original message being forwarded.  It
also seems not unlikely that users might want to send the raw message
with (1) to users of lame email clients but your use of "vf" for (2)
preempts that possibility.  I can also imagine trying to forward the
same message twice and having muscle memory type "vf" twice, screwing up
the second forward.

- Mark