You know in eudora when you get an attachment how it will auto save it in a folder, well how about giving messenger the cabability to do this as an alternative to have the attachment as part of the message. This way the size of the inbox file for example will be smaller, especially if you get a lot of attachments. Of couse the option would also allow the user to interpret attachments as normal (part of message). Also for mail filters how about the ability to delete spam from the server without downloading it or even the ability to bounce it back to the sender of the spam , making them think that your e-mail addressis invalid (or do a message rejected thing). To make it fool proof (I assume it would be part of filters and could easily be turned off or on), if a message meets the requirments of do not download from server, when it's about to download it, it would ask you "A message on the server with "subject yada yada yada" "from: soandso" meets the requirments to not be downloading, what do you want to do?" and it could give you the option, to download it anyway , leave on server , delete off server or bounce back to it's originator with standard rejection message. Such a feature could be quite usefull in the war against spammers.
Summary: [feature request] option to have attachments auto saved to chosen loaction → [HELP WANTED] option to have attachments auto saved to chosen loaction
Target Milestone: M12 → M15
Add [help wanted] to summary, so this RFE will be on the radar for mozilla contributors. Moved to M15, with the rest of the RFEs.
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 firstname.lastname@example.org
Put HELP WANTED in the Status Whiteboard so the mozilla.org bug query finds them
Changing qa assigned to email@example.com
Summary: [HELP WANTED] option to have attachments auto saved to chosen loaction → option to have attachments auto saved to chosen loaction
Whiteboard: HELP WANTED
Mozilla tries to make it difficult to predict the location of untrusted files on the user's hard drive (for example, cached webpages). This makes it so that if there's a security hole that lets an attacker run an arbitrary file on your computer (but not give it any command-line parameters), the attacker will have a hard time doing anything destructive. See http://www.peacefire.org/security/stealthattach/explanation.html for an example of a Eudora exploit based on being able to guess the location of attachment files. So.. the "auto-saved attachments" directory would probably have to be inside the profile directory, which is already set up to be hard to guess. Would that make the feature harder to use?
*** Bug 60774 has been marked as a duplicate of this bug. ***
Change QA-assigned to fenella
QA Contact: fenella → esther
better would be a feature to *delete attachments* from a mail (after saving it to disk) - bug# ???
Target Milestone: --- → Future
People from qualcomm found an option to avoid this security hole. I believe that this option (save attachments) separatly should be a VERY important argument for my company to adopt a mozilla flavor. PPl here are thinking on *buying* Eudore, only for this reason !!
This autosaving stuff sounds a bit scary. The *delete attachment* bug sound much more "controllable" --> bug 2920
QA Contact: trix → stephend
Summary: option to have attachments auto saved to chosen loaction → option to have attachments auto saved to chosen location
I disagree with the "auto save" attachment function. I'd rather manually choose to save an attachment and where it goes. But, I strongly feel that there should be a manual "Delete attachemnt" function so that I can receive a big word doc, or powerpoint file, save it, then delete the attachment without losing my original message. The inbox grows too big otherwise.
re: Comment 15 > I strongly feel that there should be a manual "Delete attachemnt" function so that I can receive a big word doc, or powerpoint file, save it, then delete the attachment without losing my original message. The inbox grows too big otherwise. See bug 2920, "Delete attachment from msg in folder". At present the only option is to delete the attachment by hand (by editing the mailbox file in a text editor) (not a feasible option for most users), or using a rigged-up separate utility (like some Perl script) to remove the attachment semi-automatically.
*** Bug 189392 has been marked as a duplicate of this bug. ***
Voted for this. I reckon the security question is addressed by making auto-save optional, leaving it to the user who activates it to trade off the hard-to-guess-ness of the directory name they pick against being able to find it themself :-) That's how I worked it with Eudora... Propose that default behaviour should be to strip the encoded attachment from the mail folder when saving the decode. Reason (reinforcing others' comments): I depend on having a record in my mail archive *that* someone sent me an attachment, so I can ask for it again if I later find I need it. Especially if it was a 20M PowerPoint presentation :-(
*** Bug 252028 has been marked as a duplicate of this bug. ***
Voting for this. It's important this is addressed, I personally think it's a big blocker for corporate mass-deployments, at least in regards to 116443 . In light of upcoming changes to Bugzilla, it would be nice if everyone interested in this bug checks to make sure it won't be dropped... See: http://weblogs.mozillazine.org/gerv/archives/006577.html
I'm joining this. I love thunderbird but the size of my mail archive is becoming monstruous... and I want to keep al attachments... and I don't want to save them manually. I guess that the performance of thunderbird will be better if the mail archive is mutch little... ¿good guess? I think Mike Holderness made a good point. The security concerns dissapear if it is optional. ¿Someone working on this? ¿Any hope for 1.1?
Ok, this is basically a duplicate of bug 2920, comment 382. That bug is too long anyway: "I have a proposal for a new feature in TB. How about adding a filter action to detach\delete attachments in incoming mail? One could set the default location to detach attachments to (via a pref) and forget about manually detaching all files or set the location for each filter individually ('email contains @ detach to "path"' should work). It could also be used for old mail (manually Run Filters in folders)."
(In reply to comment #22) > Ok, this is basically a duplicate of bug 2920, comment 382. That bug is too long > anyway: > "I have a proposal for a new feature in TB. How about adding a > filter action to detach\delete attachments in incoming mail? One could set the > default location to detach attachments to (via a pref) and forget about manually > detaching all files or set the location for each filter individually ('email > contains @ detach to "path"' should work). It could also be used for old > mail (manually Run Filters in folders)." While this is discussed, do not forget the Sent mail, where the attached files are from your own system most of the time. You do need to have a trace of the detached files in both cases - this should be an attachment of its own, with a standard name (eg 'Detached Attachments').
(In reply to comment #23) ... > While this is discussed, do not forget the Sent mail, where the attached files > are from your own system most of the time. There the point is slightly different in my opinion - what I would _love_ to see is _not_ to include the attachment into the eMail at all, but instead place a link. In this case, even all the necessary information is present: File name, location, ... Maybe controllable per Preferences: place link instead of file in Sent-Mail attachemnts...
Thunderbird Attachment Tools v0.4.9 actually provide this functionality. Or at least what I was looking for when this was opened up many moons ago. http://www.supportware.net/mozilla/#ext9 Granted, the attachment performs a little strangely, and seems to have a limit of how many messages you can mark to detach at once, but it does a fairly good job of saving multiple attachments from multiple messages in a batch mode. And also stripping them from the message. If we can use an extension to do the dunctionality, do we need it natively? If not, let's close this.
(In reply to comment #25): 1. IIRC Attachment Tools can not be run automatically for incoming mail. 2. We already have delete\save\detach functionality in trunk builds, so AT should be obsolete from now on.
I think that Simon Bock is right. We need to detach the attachment from the mail placing a link instead so u can click on the link-as-attachment as if you were clicking in the link make the rest. It cold be great to have that option in the Attachments section of the Options menu.
I secvond this. better attachment managing is something that would really improve TB.
*** Bug 283450 has been marked as a duplicate of this bug. ***
*** Bug 316371 has been marked as a duplicate of this bug. ***
*** Bug 316735 has been marked as a duplicate of this bug. ***
*** Bug 319951 has been marked as a duplicate of this bug. ***
*** Bug 241523 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > I second this. > better attachment managing is something that would really improve TB. ************************************************************************ I don't want it to "Save" the attachments elsware. All I would like is the ability to "deal" with Thunderbird Mail Box Files larger than 2GB (Much Larger if poss). OR The Thunderbird could actually store each email and its attachment in its own uniquely identified file like "Proxy Plus" does. This way, emails don't get split up from their attachments and you dont need to deal with large inbox files and you dont need to COMPACT folders!!!! *******************************************************************************
The funktion I really need is, as prompted by Victor and some others, the ability to automaticly save(detach) attachments to a specific folder.. A funtion in filters would be nice. That is better for security I guess.. to only autodetach attachments from specific known emailadresses. I really must have this funktion to get my work-life working, so sadly I need to buy eudora and use that untill this bug/missing feature is fixed. Im looking farward to beeing able to change to Thunderbird at my office!
There is a bug associated with this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=369634 Usually the user is not interested to store attachments in the sent message folder. Therefore they should be (optionally) automatically stripped. This might use the same routines.
Is this the oldest open item? There is <at least one> addin that provides this functionality http://www.eviljeff.com/ attachment extractor. Maybe we should close this?
I agree, we should close this. The extension seems useful enough.
I disagree. It's just like saying that the tab extension for Firefox is useful enough so we won't implement tab support natively. Having attachments inline kills performance for no good reason. Handling it internally would benefit all users users. The vast majority of the users aren't aware of all the extensions around, or maybe even any extensions. Marc
EvilJeff's extension looks useful, but it doesn't do automatic detachment. Even if it did, I second Marc E's comment. I'm hopeful that this will be fixed by a Penelope developer, assuming they will want native detachment capability.
An extension is sufficient to close a bug report only if all three of the following criteria are met: (1) The extension is automatically installed for all users whenever the affected product is installed, without any user action. (2) The extension has undergone testing with the same rigor as the affected product. (3) The extension is under the same configuration management as the affected product. I don't know of any extension meeting any one of these three criteria, let alone all three. Therefore, extensions should not be used as justification for closing bug reports.
Autosaving attachments is actually a kind of "filter".
Component: MailNews: MIME → MailNews: Filters
QA Contact: stephend → filters
Product: Core → MailNews Core
Please, programmers, remember, bug 286094 contains already some solution in contrast to this discussion, that merely describes a problem. The details of that solution can be found in bug 446291. Please, don't overlook, while addressing this bug 9309.
andreas.fischlin: please, do not mix two independent issues: bug 446291 has nothing to do with this bug: here we have the need for a filter action to autosave attachments to a individually specified location when the message meets the filter criteria (see also comments #43 and my bug 262481), and there you discuss ui features (right and double klick behaviour) and default save folder on user interaction - not even any hint of a solution to this long standing bug ...
Sure, I don't wanna mix things, but Magnus Melin has marked bug 286094 as a duplicate of this bug. My response was triggered by this. Perhaps you ought to rethink that? Andreas
If you read bug 286094 comment 0, it's this bug. (Or the reporter thought this was implemented and not working.)
I see there is urgent need to distinguish the two issues very clearly. The one thing is a possibility to AUTOMATICALLY save attachments WITHOUT USER INTERACTION to specified locations. This is what this bug (see reporters comment 0) and my bug 262481 are originally about. It apparently requires a new FILTER ACTION. The other thing is equivalent to the DOWNLOAD feature of mozilla/firefox/seamonkey, but here the wording instead of "download ..." is "save ...". Related are: the setting "save attatchments to" ask vs. specified folder, the double click behaviour, the wording and sort order of the right click menu, everything that REQUIRES USER INTERACTION. I do believe that _this_ bug is about the first and not the second issue, even though there seems to be a lot of confusion. And no, I do _not_ believe that bug 286094 is a duplicate of this one.
The filter action required should be within the capability of a custom filter action in an extension, once bug 419356 lands.
I vote for this, mainly for mailbox file's size, that, purged from attachments, would greatly encrease TB speed and reliability with large mailbox archives. It should be done automatically, through a preference setup, and attachment should remain selectable from the message (same as Detach function). This would also decrease login and logout times with roaming profiles, and dimensions of incremental backups; actually adding a 2kB message means that the entire mailbox file (sometimes 2GB or even larger file) needs backup. The last can also be achieved with Maildir, but with more disk space (~33% of base64 encoding). Bye. Matteo
Regarding Comment 7 and the security issue: Eudora has the location of the attachments directory as a configurable item. The directory can be placed anywhere, with any name.
As an update to this, since there was a recent comment: The custom filter actions mentioned in comment 51 are implemented in TB 3.0 In TB 3.1 there was a new backend feature added that allows filters to silently detach messages. The combined functionality is available in my FiltaQuilla extension as a custom filter action, so the suggestion in comment 51 is now a reality.
The last version of Eudora that I tried was 8.0 Beta 9. Disassociating the attachments from the email was real hassle, so I returned to Eudora 184.108.40.206 that I paid for years ago. The only thing keeping me from using the latest version of Eudora is the attachment hassle. I receive in excess of 150 documents a month that need to be placed in specific folders, depending upon content and client, and without them automatically being detached and put in something like the Eudora Attachments folder where I can easily find and move them to their proper folder, any email program is not worth a damn. Just my 2cents worth.
Regarding comment #55: Will this detach entire messages or only attachments? I'm interested in having the latter, not the former.
Regarding comment 55 & 57 Detach messages? Sorry, I do not understand what detaching a message means. Detaching a message from what? Do I have a misunderstanding that each email is a unique message unto itself? Please explain this "detach message" feature
Charley: "detach attachments" is the UI name for a function in Thunderbird that takes an attachment, copies it to a file, then rewrites the message to replace the MIME section containing the attachment with an alternate sectiion which points to the new file. So the message still appears to have attachments, but the actual storage for the message no longer has the body of the file, only a pointer to it. Just to be clear, for mbox local files (which is the only currently available local storage option in mailnews) the process of "detaching" the attachment actually leaves the existing mail message (including the attachment) intact in the file, flags the message as expunged, then writes a new message without the attachment. So temporarily, this increases the disk space required. That space is recovered when the folder is compacted. David, Charley: I confused you guys when I used the term "detach messages". All I meant was to detach attachments from messages.
This feature is a dealbreaker for various corporate environments I manage. My network users need to be able to access attachments as soon as they come in to a generic email address. They do not have access (physical or remote) to the machine with eudora installed, they just see the attachments folder as a network share. Unfortunately I have to stick with 6.x Eudora until this can be worked out.
Matt, if you're willing to install an addon to do this, FiltaQuilla has a message filter action to save any attachments to a directory. You could run that filter on all incoming mail.  http://mesquilla.com/extensions/filtaquilla/
Jim and Matt, FiltaQuilla only really does the right thing on T'Bird 3.1...not clear how many months it will be before Eudora moves to that code line. NOTE: if you are using Lightning for your calendar, do NOT move to T'Bird 3.1 on a "trial" basis, as your calendars will be irrevocably altered and no longer be readable on current Eudora. Take it from someone who lost his calendar that way...either stay with Eudora, or move off of Eudora to T'Bird 3.1 until Eudora catches up.
(In reply to comment #62) > Jim and Matt, > FiltaQuilla only really does the right thing on T'Bird 3.1...not clear how many > months it will be before Eudora moves to that code line. Jim and Matt and David Filtaquilla has worked perfectly for me in Eudora OSE 1.0, for over 650 attachments, in 2 months. POP. See http://eudorabb.qualcomm.com/showpost.php?p=48513&postcount=5 For other comments, see the entire thread containing the linked comment.
Well, when I follow Lester's directions, the only option I have is to *save* the attachments to a directory. That's not the desired behavior from Eudora of old...what's needed is the *detach* attachments to a directory, which strips them out of the message file. This option is built into FiltaQuilla, but it's not enabled until T'Bird 3.1
FTR, even the existing option to save attachments into a preselected one-for-all folder *manually* has all but disappeared, it's so hard to use it rightly and so easy to fail using it that it's practically non-existent.
I would like to keep the attachments in my mail but zip them inside my IMAP folder automatically 1. detach it 2. zip it 3. re-attach it to the original email -> Bug 852095
I would like to have following option: A hardlink to every attached file is saved to chosen location (a folder only containing detached attachments maybe with subfolders for every year) and then the file path to that hardlink is saved in the message. By using a hardlink in a special folder you can rename or remove the original file and are still able to open the file from within the message it was attached to. And you don't have duplicated files.
You need to log in before you can comment on or make changes to this bug.