RFC822 Attachments and .EML files cannot be moved to folders

When you send a mail message that bounces, the mailer daemon's bounce message is
generally a multipart mime message where your original message is enclosed as a
message/rfc822 attachment. It would be nice to have an easy way get at this
attachment so you can re-address, edit and resend it. Being able to drag an
attachment from the bounce message window to the Drafts folder would allow this.

Marking this RFE HELP WANTED. See http://www.mozilla.org/mailnews/jobs.html
for info on submitting features to the mail/news team. This requires drag&drop
to be implemented.(RSN i think)

This is sort of similar to Bug #3901. Bascially, I'm pushing feature requests
past B1 for now.

- rhp

marking M15.

Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey
bug tracking radar. Even though these bugs are not "open" in bugzilla, we
welcome fixes and improvements in these areas at any time. Mail/news RFEs
continue to be tracked on http://www.mozilla.org/mailnews/jobs.html

Reopen mail/news HELP WANTED bugs and reassign to <email address hidden>

changing qa assigned to <email address hidden>

Change QA-assign to fenella

To Esther..

xref bug 204612.

See also bug 204350.

Made a web page to help myself learn about mozilla programming and to think out
loud about this bug :

http://hiro-tan.org/~ekoontz/bug11013/

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

This bug applies to Thunderbird. Should it be re-registered in MailNews Core instead of Seamonkey?

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Let's move it to mn-core. (The front-end part shouldn't be that large / different.)

Has this ticket gone moribund for a new ticket covering the same general features?

*** Bug 226877 has been marked as a duplicate of this bug. ***

(In reply to Brian Murrell from comment #19)
> Has this ticket gone moribund for a new ticket covering the same general
> features?

No, this ticket is still alive in the mailnews core component shared by SeaMonkey and TB. Otherwise, I suppose *all* tickets are now moribund unless volunteers like you and me volunteer to fix them. Brian, do you have some coding skills to try this?

*** Bug 542038 has been marked as a duplicate of this bug. ***

*** Bug 232519 has been marked as a duplicate of this bug. ***

*** Bug 249750 has been marked as a duplicate of this bug. ***

*** Bug 259709 has been marked as a duplicate of this bug. ***

*** Bug 260556 has been marked as a duplicate of this bug. ***

*** Bug 347647 has been marked as a duplicate of this bug. ***

*** Bug 724771 has been marked as a duplicate of this bug. ***

And as Mozillians never got round to fix those thousands of acknowledged bugs, and some were even bold enough to declare that TB's users are happy with the status quo, nobody remembered all those age-old bugs, while the dupes gathered from all corners of the world and lived happily everafter...

Folder operations on *.eml files/attachments were activated until April 2009 (bug 489005), so they could be moved to a Thunderbird folder until then. But this introduced some errors in mail moving, etc. (bug 259522).

Workaround:
Save attached message to folder (outside Thunderbird) and import it with the addon "ImportExportTools".

Some others bugs with the same feature request, i.e. duplicates: bug 204612 (and duplicates mentioned there, but not yet here: bug 342544, bug 357105).

Using drag & drop is not the only, but quite the most intuitive, way to get the attached message into a Thunderbird folder, i.e. as a normal message. Doing by (context) menu are others and mentioned in the other bug reports. So this bug title should be aligned to this.

(In reply to Dominik from comment #30)
>
> Workaround:
> Save attached message to folder (outside Thunderbird) and import it with the
> addon "ImportExportTools".

Well, yes. I think we all understand what the "workaround" is. But I think we all agree that it's cumbersome at best. That's why we are all CC'd on this bug, hoping it will get fixed.

Sorry, I forgot: It maybe could be done with the quite old, BETA addon "Thunderbird Attachment Tools" from Frank DiLecce ( http://www.supportware.net/mozilla/#ext9 ). There is mentioned:

"'Import Attached EML into this Folder' - this will make a message attachment as a real message."

It would be nice to drag an attachment out of an email and drop in the inbox. I get an email each day from my web domain containing spam that was filtered out, and each of these is an attachment. My brother emails me at work though I ask him not to, so I forward home as an attachment. I frequently need attached emails contained in parent emails. I drag the attached email and drop on the desktop, then from the desktop drag and drop into the inbox. I would like the dropped email to be UNREAD since it defaults to read. Sometimes I want to run filters on it so it moves to the correct folder but must mark unread, first, and it is more difficult to find in my inbox because it is not unread. A change was recently made to TB. I've noticed this works better. When dropped on the desktop it would not have the extension .eml, so when I dragged back into TB it would not be recognized. I would always have to change the extension after dropping it. Have not had to do that for awhile. So, yes it would be nice to drag directly from a parent email and drop in a TB folder.

(In reply to Brian Murrell from comment #32)
> (In reply to Dominik from comment #30)
> >
> > Workaround:
> > Save attached message to folder (outside Thunderbird) and import it with the
> > addon "ImportExportTools".
>
> Well, yes. I think we all understand what the "workaround" is. But I think
> we all agree that it's cumbersome at best. That's why we are all CC'd on
> this bug, hoping it will get fixed.

(In reply to Dominik from comment #33)
> Sorry, I forgot: It maybe could be done with the quite old, BETA addon
> "Thunderbird Attachment Tools" from Frank DiLecce (
> http://www.supportware.net/mozilla/#ext9 ). There is mentioned:
>
> "'Import Attached EML into this Folder' - this will make a message
> attachment as a real message."

Can't somebody who "knows how to code", take the guts of these two extensions and make some useful code out of it, and put permanently into the mail client? No, I don't code. My role here is as a "tester" for those of you who do code. See? This is how we all work together as a team.

FWIW, d'n'd of .eml files from the file system onto a folder was implemented a long time a go back in bug 500564. Turns out to be harder for files that aren't in the filesystem.

The Thunderbird Attachment Tools file is corrupt, but if it really can do it, and someone has a working copy i'd like to take a look.

I can confirm

a) the bug is not NEW

b) the bug is still present. Thunderbird cant drag and drop .eml files in any folder inside itself. Will take a look at the code base.

Evolution, buggy and inconsistent as it is, has been able to do this since dirt was new. I keep Evolution as my primary mail client since I run a mail server with spam filtering by SpamAssassin and need to be able to drag false positive hits by SpamAssassin from their SA enclosures to my inbox, or to other users' inboxes if necessary. Can this really be so hard to implement? I've been waiting for 10 years for T-bird to make this work :)

*** Bug 1667618 has been marked as a duplicate of this bug. ***