bug#9766: 24.0.50; rmail-forward makes attachment that doesn't read right

[Stefan Monnier]

> For the MIME version.
>     I think what needs to be done is to copy into the buffer where mail is
>     composed the message in the original form, not in the form we put into
>     the rmail-view-buffer.
> No.  That had the bug (the one reported before),

I'm not sure which bug this refers to.  But a MIME forward should
contain an "original form" email message.  You can strip some of the
headers if you want, but it should contain non-decoded content.

> and it also is an ugly pain in the neck.

Do you say that because it makes the underlying encoded message visible?
If so, it's a presentation problem: the content of the sent message
should be "ugly" but there's no reason it should ever be displayed in
this ugly form.

> Anyway, if you want to forward the raw form, all you have to do is
> type v.  That works, too.

Not using Rmail myself, I don't know what `v' runs.

>     For the definitive answer, I suggest to start Emacs with the default
>     value of mail-user-agent, start Rmail, forward (to yourself) a message
>     with attachments, and then look at hoe message.el did it.
> But that is not conclusive.  What we need is a person who knows MIME
> well enough to look at the generated text, and tell us if it has an error.

I haven't touched MIME in a while, but back when I was hacking on the
PGP support for ExMH, I was reasonably up-to-date in MIME.  To me the
message you showed looked OK except for the "--text follows this line--"
which should be an empty line, but I think this is just the "in buffer"
text and that line is turned into an empty line when you send the
message.  Other than that it also seems to lack another part: it has
a first part of type message/rfc822 and a second one of type text/plain,
but you'll usually want to add a first part of type text/plain where you
can put some text of your own making.


        Stefan


PS: Reminds me that I think this "--text follows this line--" should be
changed: instead of actual real text in the buffer, it should be an
overlay's after-string covering the empty line.