bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

Typing `f' (rmail-forward) in an Rmail buffer produces this line:

  <#part type=message/rfc822 disposition=inline raw=t>

followed by the headers and the body of the forwarded message.  This
happens because rmail-forward was changed some time ago to call
message-forward-make-body-mime (through
rmail-insert-mime-forwarded-message-function), like this:

	    (if (or rmail-enable-mime rmail-enable-mime-composing)
		(funcall rmail-insert-mime-forwarded-message-function
			 forward-buffer)
	      (insert "------- Start of forwarded message -------\n")

Q1: Where is this format documented? any RFCs or some such?  I
couldn't find any spec with this format, but I don't really know what
to look for, not being an expert on these issues.

Q2: Which MUAs support this format on reception, and can show the
forwarded message in a reasonably useful form?  Rmail certainly
doesn't; I also tried Outlook and a couple Web-based mail systems --
none of them did.  What I see is the raw message, complete with b64
encoded attachments -- entirely illegible.  If this format is not
widely supported, why does it make sense to generate it by default?
At the very least, Rmail should support that, or stop using it by
default.

The bug: The way the code invoking message-forward-make-body-mime is
written, it is impossible to customize away this "feature" without
disabling rmail-enable-mime, which disables a lot of other useful
features.  At the very least, it should be possible to disable this
"feature" alone, by customizing rmail-enable-mime-composing.  This
could be as a simple as replacing `or' with `and' in the above
condition. 


In GNU Emacs 24.0.50.81 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-08-28 on fencepost
configured using `configure  '--with-gif=no' '--with-tiff=no' '--enable-asserts' '--enable-checking' 'CFLAGS=-ggdb -g3 -O0 -DGLYPH_DEBUG=1''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: RMAIL

Minor modes in effect:
  shell-dirtrack-mode: t
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
p ESC p RET C-r ESC O A ESC O C C-x b RET C-x b r m 
a i TAB . e TAB RET ESC O B ESC O B ESC O A ESC O A 
ESC O A ESC O D ESC O D ESC O D ESC O D ESC O D ESC 
O D ESC O D ESC O D ESC O D ESC O D ESC O D ESC O D 
ESC O D ESC O D ESC O D ESC O D ESC O D ESC O D ESC 
O D ESC O D ESC O D ESC O D ESC O D ESC O D ESC O D 
ESC O D ESC O D ESC O D C-r C-w C-w C-w C-w C-r C-r 
C-x C-x ESC O D ESC O D ESC O D ESC O D ESC O D ESC 
O D ESC O D ESC O D ESC O D ESC O D ESC O D ESC O D 
ESC O D ESC O D ESC O D ESC O D ESC O D ESC O D C-r 
C-w C-w C-w C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-r C-r C-r C-r C-r C-x C-x ESC O C ESC 
O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C 
ESC O C ESC O C ESC O C ESC O C ESC O C ESC O C ESC 
O C ESC O C ESC O C ESC O C ESC O C ESC O D C-r C-w 
C-w C-w C-w C-r C-r C-r C-x C-x C-s C-s C-s C-x C-x 
C-a C-x b RET ESC x r e p o r t TAB RET

Recent messages:
Saving file /home/e/eliz/mail.n2...
Wrote /home/e/eliz/mail.n2
Getting mail from /srv/data/home/e/eliz/mail.n2...
Counting new messages...done (1)
Saving file /home/e/eliz/INBOX...
Wrote /home/e/eliz/INBOX [2 times]
Computing summary lines...done
1 new message read
scroll-down-command: Beginning of buffer
Mark saved where search started [9 times]

Load-path shadows:
None found.

Features:
(shadow emacsbug help-fns help-mode view cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
multi-isearch vc-bzr newcomment flyspell ispell sendmail shell
pcomplete comint regexp-opt ring qp rmailsum rmailmm message
format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time paren cus-start
cus-load time-date savehist saveplace tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process
dynamic-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Q1: Where is this format documented?

*Note (emacs-mime) MML Definition::

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: 9392@debbugs.gnu.org
> Date: Sun, 28 Aug 2011 23:04:32 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Q1: Where is this format documented?
> 
> *Note (emacs-mime) MML Definition::

Thanks.  So you are saying that the _actual_ bug is that rmail-forward
doesn't run the outgoing message buffer through mml-generate-mime, is
that right?

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> Date: Mon, 29 Aug 2011 05:55:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9392@debbugs.gnu.org
> 
> > *Note (emacs-mime) MML Definition::
> 
> Thanks.  So you are saying that the _actual_ bug is that rmail-forward
> doesn't run the outgoing message buffer through mml-generate-mime, is
> that right?

Actually, I should have told that the original problem happens with
mail-user-agent set to sendmail-user-agent.

So, given the above input regarding MML, I assumed that message.el
does TRT with MML before sending the forwarded message, and tried
rmail-forward in "emacs -Q".  However, with that configuration, the
code which inserts the MML "<#part ...>" tag is never executed, and in
fact the "*unsent mail*" buffer popped by message.el does not have the
text of the message being forwarded; the body of the composed message
is empty.

AFAICS, the "<#part ...>" tag is not inserted because rmail-forward
expects rmail-start-mail return a non-nil value, but with
message-user-agent it returns nil.

So it looks like message-user-agent is incompatible with
rmail-forward, or else I'm doing something terribly wrong.

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Kenichi Handa]

In article <E1QxuE7-0005rc-Vz@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > > *Note (emacs-mime) MML Definition::
> > 
> > Thanks.  So you are saying that the _actual_ bug is that rmail-forward
> > doesn't run the outgoing message buffer through mml-generate-mime, is
> > that right?

> Actually, I should have told that the original problem happens with
> mail-user-agent set to sendmail-user-agent.

> So, given the above input regarding MML, I assumed that message.el
> does TRT with MML before sending the forwarded message, and tried
> rmail-forward in "emacs -Q".  However, with that configuration, the
> code which inserts the MML #part tag is never executed, and in
> fact the "*unsent mail*" buffer popped by message.el does not have the
> text of the message being forwarded; the body of the composed message
> is empty.

I have not noticed this bug because I seldom do
rmail-forward; instead I freaquently do rmail-resend (C-u f)
which still works in the latest Emacs.

My last changes to rmail.el and rmailmm.el were before the
release of 23.3, and for 23.3, I surely tested that
rmail-forward worked with "emacs -Q" (but I must confess that I
forgot to test the other configuration).

> AFAICS, the #part tag is not inserted because rmail-forward
> expects rmail-start-mail return a non-nil value, but with
> message-user-agent it returns nil.

So, It seems that something has been changed after the
release of 23.3.

By the way, I found that if a sending mail contains "<"
followed by "#part", the following error is signaled.

forward-sexp: Scan error: "Containing expression ends prematurely", 1099, 1100

So, I'm sending this mail replacing that kind of text with "#part tag".

---
Kenichi Handa
handa@m17n.org

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 9392@debbugs.gnu.org
> Date: Tue, 30 Aug 2011 09:36:08 +0900
> 
> > So, given the above input regarding MML, I assumed that message.el
> > does TRT with MML before sending the forwarded message, and tried
> > rmail-forward in "emacs -Q".  However, with that configuration, the
> > code which inserts the MML #part tag is never executed, and in
> > fact the "*unsent mail*" buffer popped by message.el does not have the
> > text of the message being forwarded; the body of the composed message
> > is empty.
> 
> I have not noticed this bug because I seldom do
> rmail-forward; instead I freaquently do rmail-resend (C-u f)
> which still works in the latest Emacs.
> 
> My last changes to rmail.el and rmailmm.el were before the
> release of 23.3, and for 23.3, I surely tested that
> rmail-forward worked with "emacs -Q" (but I must confess that I
> forgot to test the other configuration).
> 
> > AFAICS, the #part tag is not inserted because rmail-forward
> > expects rmail-start-mail return a non-nil value, but with
> > message-user-agent it returns nil.
> 
> So, It seems that something has been changed after the
> release of 23.3.

Can some expert on message.el please help?  E.g., how is forwarding
supposed to work with message.el?

> By the way, I found that if a sending mail contains "<"
> followed by "#part", the following error is signaled.
> 
> forward-sexp: Scan error: "Containing expression ends prematurely", 1099, 1100

Is there some method of quoting/escaping <#part ...> so that MML is
left alone?

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 9392@debbugs.gnu.org
> Date: Tue, 30 Aug 2011 09:36:08 +0900
> 
> My last changes to rmail.el and rmailmm.el were before the
> release of 23.3, and for 23.3, I surely tested that
> rmail-forward worked with "emacs -Q" (but I must confess that I
> forgot to test the other configuration).
> 
> > AFAICS, the #part tag is not inserted because rmail-forward
> > expects rmail-start-mail return a non-nil value, but with
> > message-user-agent it returns nil.
> 
> So, It seems that something has been changed after the
> release of 23.3.

You are right, it works in Emacs 23.3 with message-user-agent.  So
this part (of rmail-forward not working in 'emacs -Q") is a recent
regression.

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> Date: Tue, 30 Aug 2011 01:47:06 -0400
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9392@debbugs.gnu.org
> 
> > From: Kenichi Handa <handa@m17n.org>
> > Cc: 9392@debbugs.gnu.org
> > Date: Tue, 30 Aug 2011 09:36:08 +0900
> > 
> > My last changes to rmail.el and rmailmm.el were before the
> > release of 23.3, and for 23.3, I surely tested that
> > rmail-forward worked with "emacs -Q" (but I must confess that I
> > forgot to test the other configuration).
> > 
> > > AFAICS, the #part tag is not inserted because rmail-forward
> > > expects rmail-start-mail return a non-nil value, but with
> > > message-user-agent it returns nil.
> > 
> > So, It seems that something has been changed after the
> > release of 23.3.
> 
> You are right, it works in Emacs 23.3 with message-user-agent.  So
> this part (of rmail-forward not working in 'emacs -Q") is a recent
> regression.

The reason for this regression is this change in message.el:

 2011-02-03  Julien Danjou  <julien@danjou.info>

	 * message.el (message-setup-1): Always generate References first.
	 (message-mail): Return the return value of message-setup, not always t.
	 (message-setup-1): Insert mail-header-separator with read-only and
	 intangible properties set.

I don't know what was the rationale for this change, because if
message-setup calls message-setup-1, it will still return nil, since
message-setup-1 returns nil unconditionally.  The simple patch below
fixes this particular regression.

However, rmail-forward is still broken if mail-user-agent is set to
sendmail-user-agent.  That is a separate issue.  So please do not
close this bug, even if this patch is accepted by the Gnus developers.

Here's the patch to message.el to restore the Emacs 23.3 default
behavior of rmail-forward:

=== modified file 'lisp/gnus/message.el'
--- lisp/gnus/message.el	2011-08-20 00:20:39 +0000
+++ lisp/gnus/message.el	2011-09-02 09:45:18 +0000
@@ -6530,7 +6530,9 @@ are not included."
   (message-position-point)
   ;; Allow correct handling of `message-checksum' in `message-yank-original':
   (set-buffer-modified-p nil)
-  (undo-boundary))
+  (undo-boundary)
+  ;; rmail-start-mail expects message-mail to return t (Bug#9392)
+  t)
 
 (defun message-set-auto-save-file-name ()
   "Associate the message buffer with a file in the drafts directory."

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

On Fri, Sep 02 2011, Eli Zaretskii wrote:

> I don't know what was the rationale for this change, because if
> message-setup calls message-setup-1, it will still return nil, since
> message-setup-1 returns nil unconditionally.  The simple patch below
> fixes this particular regression.

I think I was trying to fix the FIXME. :)

diff --git a/lisp/message.el b/lisp/message.el
index 28050f8..42ca73c 100644
--- a/lisp/message.el
+++ b/lisp/message.el
@@ -6582,9 +6582,7 @@ is a function used to switch to and display the mail buffer."
       (dolist (h other-headers other-headers)
        (if (stringp (car h)) (setcar h (intern (capitalize (car h)))))))
      yank-action send-actions continue switch-function
-     return-action)
-    ;; FIXME: Should return nil if failure.
-    t))
+     return-action)))
 
 ;;;###autoload
 (defun message-news (&optional newsgroups subject)



> However, rmail-forward is still broken if mail-user-agent is set to
> sendmail-user-agent.  That is a separate issue.  So please do not
> close this bug, even if this patch is accepted by the Gnus developers.
>
> Here's the patch to message.el to restore the Emacs 23.3 default
> behavior of rmail-forward:
>
> === modified file 'lisp/gnus/message.el'
> --- lisp/gnus/message.el	2011-08-20 00:20:39 +0000
> +++ lisp/gnus/message.el	2011-09-02 09:45:18 +0000
> @@ -6530,7 +6530,9 @@ are not included."
>    (message-position-point)
>    ;; Allow correct handling of `message-checksum' in `message-yank-original':
>    (set-buffer-modified-p nil)
> -  (undo-boundary))
> +  (undo-boundary)
> +  ;; rmail-start-mail expects message-mail to return t (Bug#9392)
> +  t)
>  
>  (defun message-set-auto-save-file-name ()
>    "Associate the message buffer with a file in the drafts directory."
>

From my quick understanding, this looks good.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Julien Danjou <julien@danjou.info>
> Cc: handa@m17n.org,  9392@debbugs.gnu.org
> Date: Fri, 02 Sep 2011 12:54:32 +0200
> 
> > === modified file 'lisp/gnus/message.el'
> > --- lisp/gnus/message.el	2011-08-20 00:20:39 +0000
> > +++ lisp/gnus/message.el	2011-09-02 09:45:18 +0000
> > @@ -6530,7 +6530,9 @@ are not included."
> >    (message-position-point)
> >    ;; Allow correct handling of `message-checksum' in `message-yank-original':
> >    (set-buffer-modified-p nil)
> > -  (undo-boundary))
> > +  (undo-boundary)
> > +  ;; rmail-start-mail expects message-mail to return t (Bug#9392)
> > +  t)
> >  
> >  (defun message-set-auto-save-file-name ()
> >    "Associate the message buffer with a file in the drafts directory."
> >
> 
> From my quick understanding, this looks good.

Thanks for your review.  So should I commit this, or should I wait for
it to be fixed in the Gnus repository and then merged with the Emacs
trunk?

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On Fri, Sep 02 2011, Eli Zaretskii wrote:

> Thanks for your review.  So should I commit this, or should I wait for
> it to be fixed in the Gnus repository and then merged with the Emacs
> trunk?

AFAIK the sync is bi-directionnal, so feel free to commit this in Emacs
directly.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Julien Danjou <julien@danjou.info>
> Cc: handa@m17n.org,  9392@debbugs.gnu.org
> Date: Fri, 02 Sep 2011 16:27:04 +0200
> 
> On Fri, Sep 02 2011, Eli Zaretskii wrote:
> 
> > Thanks for your review.  So should I commit this, or should I wait for
> > it to be fixed in the Gnus repository and then merged with the Emacs
> > trunk?
> 
> AFAIK the sync is bi-directionnal, so feel free to commit this in Emacs
> directly.

Done, thanks.  Now on to the original problem...

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> Date: Fri, 02 Sep 2011 20:59:10 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9392@debbugs.gnu.org
> 
> Done, thanks.  Now on to the original problem...

Is this the right way of converting MML to MIME when sendmail is used
as the MUA?

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2011-07-28 14:05:07 +0000
+++ lisp/simple.el	2011-09-02 18:15:07 +0000
@@ -5727,6 +5727,11 @@ else the end of the last line.  This fun
 	 "^\\([:\n]\\|[^: \t\n]+[ \t\n]\\)" nil 'move)
     (goto-char (match-beginning 0))))
 
+;; Used by Rmail (e.g., rmail-forward).
+(defvar mail-encode-mml nil
+  "If non-nil, mail-user-agent's `sendfunc' command should mml-encode
+the outgoing message before sending it.")
+
 (defun compose-mail (&optional to subject other-headers continue
 		     switch-function yank-action send-actions
 		     return-action)

=== modified file 'lisp/mail/rmail.el'
--- lisp/mail/rmail.el	2011-08-16 02:29:15 +0000
+++ lisp/mail/rmail.el	2011-09-02 18:41:09 +0000
@@ -91,6 +91,7 @@ its character representation and its dis
 (defvar messages-head)
 (defvar total-messages)
 (defvar tool-bar-map)
+(defvar mail-encode-mml)
 
 (defvar rmail-header-style 'normal
   "The current header display style choice, one of
@@ -642,7 +643,7 @@ unless the feature specified by `rmail-m
   :version "23.3"
   :group 'rmail)
 
-(defvar rmail-enable-mime-composing nil
+(defvar rmail-enable-mime-composing t
   "*If non-nil, RMAIL uses `rmail-insert-mime-forwarded-message-function' to forward.")
 
 ;; FIXME unused.
@@ -3794,9 +3795,17 @@ see the documentation of `rmail-resend'.
 	    ;; Insert after header separator--before signature if any.
 	    (rfc822-goto-eoh)
 	    (forward-line 1)
-	    (if (or rmail-enable-mime rmail-enable-mime-composing)
-		(funcall rmail-insert-mime-forwarded-message-function
-			 forward-buffer)
+	    (if (and rmail-enable-mime rmail-enable-mime-composing)
+		(prog1
+		    (funcall rmail-insert-mime-forwarded-message-function
+			     forward-buffer)
+		  ;; rmail-insert-mime-forwarded-message-function
+		  ;; works by inserting MML tags into forward-buffer.
+		  ;; The MUA will need to convert it to MIME before
+		  ;; sending.  mail-encode-mml tells them to do that.
+		  ;; message.el does that automagically.
+		  (or (eq mail-user-agent 'message-user-agent)
+		      (setq mail-encode-mml t)))
 	      (insert "------- Start of forwarded message -------\n")
 	      ;; Quote lines with `- ' if they start with `-'.
 	      (let ((beg (point)) end)

=== modified file 'lisp/mail/sendmail.el'
--- lisp/mail/sendmail.el	2011-08-04 00:58:07 +0000
+++ lisp/mail/sendmail.el	2011-09-02 18:46:19 +0000
@@ -31,6 +31,8 @@
 
 (require 'rfc2047)
 
+(require 'mml)
+
 (defgroup sendmail nil
   "Mail sending commands for Emacs."
   :prefix "mail-"
@@ -678,6 +680,7 @@ switching to, the `*mail*' buffer.  See 
   :options '(footnote-mode))
 
 (defvar mail-mode-abbrev-table text-mode-abbrev-table)
+(defvar mail-encode-mml)
 ;;;###autoload
 (define-derived-mode mail-mode text-mode "Mail"
   "Major mode for editing mail to be sent.
@@ -701,6 +704,8 @@ Turning on Mail mode runs the normal hoo
   (make-local-variable 'mail-reply-action)
   (make-local-variable 'mail-send-actions)
   (make-local-variable 'mail-return-action)
+  (make-local-variable 'mail-encode-mml)
+  (setq mail-encode-mml nil)
   (setq buffer-offer-save t)
   (make-local-variable 'font-lock-defaults)
   (setq font-lock-defaults '(mail-font-lock-keywords t t))
@@ -934,6 +939,9 @@ the user from the mailer."
 	      (error "Invalid header line (maybe a continuation line lacks initial whitespace)"))
 	    (forward-line 1)))
 	(goto-char opoint)
+	(when mail-encode-mml
+	  (mml-to-mime)
+	  (setq mail-encode-mml nil))
 	(run-hooks 'mail-send-hook)
 	(message "Sending...")
 	(funcall send-mail-function)

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Fri, Sep 02 2011, Eli Zaretskii wrote:

> Is this the right way of converting MML to MIME when sendmail is used
> as the MUA?

If you're asking me, this is out of my current knowledge. You should ask
Lars or ding@gnus.org directly for a more appropriate response. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Julien Danjou <julien@danjou.info>
> Cc: handa@m17n.org,  9392@debbugs.gnu.org
> Date: Fri, 02 Sep 2011 21:13:28 +0200
> 
> On Fri, Sep 02 2011, Eli Zaretskii wrote:
> 
> > Is this the right way of converting MML to MIME when sendmail is used
> > as the MUA?
> 
> If you're asking me, this is out of my current knowledge. You should ask
> Lars or ding@gnus.org directly for a more appropriate response. :)

Lars?

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Glenn Morris]

Eli Zaretskii wrote:

> --- lisp/mail/sendmail.el	2011-08-04 00:58:07 +0000
> +++ lisp/mail/sendmail.el	2011-09-02 18:46:19 +0000
[...]
> +(require 'mml)
[...]
> +	(when mail-encode-mml
> +	  (mml-to-mime)
> +	  (setq mail-encode-mml nil))


Could you autoload mml-to-mime instead, so that mml and all its
dependencies are not loaded unless they are really needed?

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 9392@debbugs.gnu.org
> Date: Fri, 02 Sep 2011 20:24:42 -0400
> 
> Could you autoload mml-to-mime instead, so that mml and all its
> dependencies are not loaded unless they are really needed?

Yes, will do.

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this the right way of converting MML to MIME when sendmail is used
> as the MUA?

Hm.  It's been so long since I looked at that code...  Let's see...
Yes, I think that's the correct top-level function to use in most
cases.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Reiner Steib]

On Tue, Aug 30 2011, Eli Zaretskii wrote:

> Is there some method of quoting/escaping <#part ...> so that MML is
> left alone?

,----[ `C-h k <menu-bar> <Attachments> <Quote MML in region>' ]
| <menu-bar> <Attachments> <Quote MML in region> runs the command
| mml-quote-region, which is an interactive compiled Lisp function in `mml.el'.
| 
| It is bound to <menu-bar> <Attachments> <Quote MML in region>, C-c RET q.
| 
| (mml-quote-region BEG END)
| 
| Quote the MML tags in the region.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: julien@danjou.info,  9392@debbugs.gnu.org
> Date: Sat, 03 Sep 2011 23:49:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is this the right way of converting MML to MIME when sendmail is used
> > as the MUA?
> 
> Hm.  It's been so long since I looked at that code...  Let's see...
> Yes, I think that's the correct top-level function to use in most
> cases.

Thanks for the review.  I installed a slightly modified version on the
trunk (revno 105694).

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Kenichi Handa]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

In article <83ipp25bmj.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Thanks for the review.  I installed a slightly modified version on the
> trunk (revno 105694).

rmail-forward still has a problem when a message has an
attachment file.  For instance, when I have a message
something like this in RMAIL:

------------------------------------------------------------
[...]
[1:text/plain Hide]

test of attachment

[2:application/pdf Show Save:temp.pdf (2kB)]
------------------------------------------------------------

typing f inserts just this in "part" part of *unsent mail to
...* buffer:

------------------------------------------------------------
From: Kenichi Handa <handa@m17n.org>
To: handa@m17n.org
Subject: test from shatin
Date: Thu, 15 Sep 2011 14:14:58 +0900
Message-ID: <87aaa6xu7h.fsf@m17n.org>
Content-Type: multipart/mixed; boundary="=-=-="


[1:text/plain Hide]

test of attachment


[2:application/pdf Show Save:temp.pdf (2kB)]
------------------------------------------------------------

It's the content of rmail-view buffer and thus the outgoing
mail doesn't contain the correct attachment.

In Emacs 23.3, the content of "part" part was the original
whole message, and thus the outgoing mail surely contains an
attachment in a correct MIME form.

I'm attaching the same sample file so that you can see what
I described by typing 'f' in RMAIL.

---
Kenichi Handa
handa@m17n.org


[-- Attachment #2: temp.pdf --]
[-- Type: application/pdf, Size: 2229 bytes --]

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 9392@debbugs.gnu.org, handa@m17n.org
> Date: Fri, 16 Sep 2011 12:41:37 +0900
> 
> rmail-forward still has a problem when a message has an
> attachment file.

Yes, I know.  But that's a different bug.  It happens because
rmail-forward simply copies the text from the buffer where the
forwarded message is displayed, which is not TRT when the message has
attachments, because rmail-mime reformats it for display and adds
buttons.

Please submit a separate bug report for this.

bug#9392: 24.0.50; rmail-forward produces messages in unsupported format that cannot be customized away

[Kenichi Handa]

In article <83sjnxug7f.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > Cc: 9392@debbugs.gnu.org, handa@m17n.org
> > Date: Fri, 16 Sep 2011 12:41:37 +0900
> > 
> > rmail-forward still has a problem when a message has an
> > attachment file.

> Yes, I know.  But that's a different bug.  It happens because
> rmail-forward simply copies the text from the buffer where the
> forwarded message is displayed, which is not TRT when the message has
> attachments, because rmail-mime reformats it for display and adds
> buttons.

Actually that copying is done by
rmail-insert-mime-resent-message
(rmail-insert-mime-resent-message-function is set to it when
rmailmm.el is loaded), and that function was changed by RMS
as this.

2011-06-22  Richard Stallman  <rms@gnu.org>

	* mail/sendmail.el (mail-bury): If Rmail is in use, return nicely
	to Rmail even if not started by a special Rmail command.

	* mail/rmailmm.el (rmail-insert-mime-forwarded-message):
	Copy the buffer currently showing just one message.

I don't know what it was going to fix.

> Please submit a separate bug report for this.

Done.

---
Kenichi Handa
handa@m17n.org