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: Mon, 07 Jan 2013 19:57:36 -0800 Message-ID: <87ehhwtjgv.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 1357617473 17644 80.91.229.3 (8 Jan 2013 03:57:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2013 03:57:53 +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 Tue Jan 08 04:58:09 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 1TsQKF-0004rQ-Vl for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2013 04:58:08 +0100 Original-Received: from localhost ([::1]:36071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsQJz-0004vW-Tc for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 22:57:51 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsQJu-0004s2-9s for emacs-devel@gnu.org; Mon, 07 Jan 2013 22:57:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsQJq-0005eK-9H for emacs-devel@gnu.org; Mon, 07 Jan 2013 22:57:46 -0500 Original-Received: from alum-mailsec-scanner-2.mit.edu ([18.7.68.13]:60378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsQJl-0005dz-R0; Mon, 07 Jan 2013 22:57:37 -0500 X-AuditID: 1207440d-b7f306d0000008b7-9c-50eb9930cd13 Original-Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 68.0D.02231.0399BE05; Mon, 7 Jan 2013 22:57:36 -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 r083vXnD022101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Jan 2013 22:57:35 -0500 In-Reply-To: (message from Richard Stallman on Mon, 07 Jan 2013 21:11:30 -0500) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqGsw83WAwccdwhaPFzxhtZj68Qyb xZQlW9kdmD3+vv/A5NE2zSyAKYrbJimxpCw4Mz1P3y6BO+PT/h0sBVskK9ZtD29gXCbcxcjJ ISFgIjFxz052CFtM4sK99WwgtpDAZUaJS8siuhi5gOwrTBJtL7eDJdgENCWmP/sO1iAiwC/x cN1vRhCbWUBc4sfdPlYQW1jASmLnyw6wOKdAqcTJh4eYIIZKSSxddAKsl0VAVeJlw0+wGl4B fYn7326zQNiCEidnPmGBmCkhcfDFC+YJjHyzkKRmIUktYGRaxSiXmFOaq5ubmJlTnJqsW5yc mJeXWqRrpJebWaKXmlK6iRESaLw7GP+vkznEKMDBqMTDeynmdYAQa2JZcWXuIUZJDiYlUd6A aUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIry3UoByvCmJlVWpRfkwKWkOFiVxXrUl6n5CAumJ JanZqakFqUUwWRkODiUJXosZQI2CRanpqRVpmTklCGkmDk6Q4VxSIsWpeSmpRYmlJRnxoPiK LwZGGEiKB2hvOEg7b3FBYi5QFKL1FKMxR8PLG08ZOX6tvPmUUYglLz8vVUqcVx+kVACkNKM0 D24RLMW8YhQH+luY1xqkigeYnuDmvQJaxQS0KvXxc5BVJYkIKakGxkDutQpv6883H5aWm2y1 c3f6CvbfbKzrmqo/nezLkV1yh3NLTv2+y1pfPd7mS/31UZliG1BXaZ3SVNu7j383Q22fGdfO P+X8T4NljSM4fycJuET8mrCrZnbytxu82jpNbw4eePEltaTxylH7WafvljAG3oqe X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 18.7.68.13 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:156132 Archived-At: Richard Stallman writes: > You want to insert the undecoded but unmbox-escaped message. > > I am not sure what that means. What is "unmbox-escaped"? How > does that relate to decoding? Messages stored in mbox format have lines starting with >*From\ escaped by adding an extra > at the front. This escaping needs to be reversed to get the original message back. See bug #13329 for more details. > And why do you think this behavior is the right behavior, rather than > forwarding the message as displayed? > > The visible message is very > likely not a valid RFC message because it is missing headers and > boundary parts. It also likely is missing some of the attachments. > > Yes, but why do you think that is wrong? If f forwards whatever > is displayed, the user has the choice to type v and forward > the undecoded message, or not type v, and forward the message as > decoded with selected parts visible. Ignoring defaults for the moment, it seems like ideally we should be able to do any of three things: (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. 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. E.g., deal with its in-line multipart alternative parts appropriately, etc. If you attach an invalid message (e.g., bad MIME headers), I would expect the recipient to see garbage or an error message for the message attachment. The text here can be placed directly in the message body, possibly prefixed with "> "'s. Pretty much any email client should be able to see the included text but there's no way to include attachments or render HTML as HTML in the destination client. E.g., this method cannot be used with HTML-only messages. It also often loses formatting (e.g., colors) that is present only in HTML parts. (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 (this means handling both the text and HTML in-line parts correctly if formatting is not to be lost) and attaches all the original non-in-line attachments as well. This would be fairly tricky to do right; see my email about this in the bug discussion for bug #9766. Something like this is what Outlook does, for example. 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. - Mark