malformed send of a postponed message with attachment

[John Hein]

rev 1239 on trunk, emacs-23.3

If I postpone a message with an attachment, the resulting email loses the proper content boundary markers.

I will attach a simple test case.

[John Hein (xpqheqdvq4)]

Attached is the contents of a simple postponed message with text/plain attachment before actually sending it with vm-continue-postponed-message and vm-mail-send-and-exit.

[John Hein (xpqheqdvq4)]

Attached here is the contents of the message as I received it after sending the attachment in the previous comment.

Notice the bogus content boundary markers.

Note: this has slightly different domain info than the attachment in the previous comment which I forgot to sanitize for actual domain info.

[Uday Reddy (reddyuday)]

Hi John, the trunk is now at revision 1242. Can you pull the latest revision and try it?

Your second attachment looks like the VM presentation of the message. But can you attach the message itself?

Also, the exact sequence of VM commands you used in each case. I don't use this functionality all that much. Note that it is part of vm-pine, which is Rob F's add-on, not part of VM itself.

Cheers,
Uday

[John Hein (xpqheqdvq4)]

The second attachment contains the received message I saved to a new file using vm-save-message. I attached the contents of that file.

Re: the sequence of commands, here is what I did...

==========================
emacs -Q -nw --eval '(autoload '"'"'vm "vm" "View Mail" t)'
M-x vm
m
<enter email with some text and a text attachment; see attachment in comment #1>
M-x vm-postpone-message
<visit postponed message folder using vm-visit-folder - default location is ~/postponed>
<navigate to the postponed message>
M-x vm-continue-postponed-message
C-c C-c
x ;; exit postponed folder; don't save the changes
M-x vm ;; back to inbox
g
<navigate to the message>
s ;; save to a folder (this is what I attached in comment #2)
==========================

I'll update to the latest rev and try again.

[Uday Reddy (reddyuday)]

Yeah, the problem is that vm-continue-postponed-message copies the text from
the VM Presentation buffer. If an attachment has been inlined there, it
will appear as normal text in the composition. This is flaw in the design
of vm-pine. I don't know of any simple way of fixing it.

I have added a section in the info manual on vm-pine and included a line on
the problem.

Cheers,
Uday

[John Hein (xpqheqdvq4)]

Rev 1242 has the same issue. No surprise in light of comment #5.

[John Hein (xpqheqdvq4)]

I will add that it's not quite an exact copy of what I _see_ in the presentation buffer. There is a stray content boundary marker at the bottom that I don't see in the visible presentation (before hitting C-c C-c).

[Uday Reddy (reddyuday)]

Revision 1244 tweaks the vm-postponed-message so that all the MIME objects are converted to "attachments". That will typically ensure that they are not opened in the Presentation buffer and so will remain attachments in the message composition as well.

[Uday Reddy (reddyuday)]

I don't get the extra MIME boundary with the current revision. (There might have been a bug in recent updates before 1242).

The message in the postponed folder is multipart/mixed. But when it is sent using vm-continue-postponed-message, it is getting sent as text/plain. In your case, it got sent as multipart/mixed. I will leave it to you investigate that.

[Uday Reddy (reddyuday)]

Converted to a 'Wish List' issue:

        Redo vm-pine, generating a new copy of the message for the composition buffer, instead of copying it from the Presentation buffer.

[Alan Wehmann (alan-wehmann)]

A similar problem occurs when forwarding a message, but postponing it before actually sending it--when vm-forwarding-digest-type is "mime". One winds up with a Content-Type: multipart/mixed; header that specifies a boundary, but none of the matching MIME marker lines is present (e.g. there are no matching MIME boundary lines).