From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010526 BuildID: 2001052620 Not really a bug, rather a feature request (difference?) -- also had to identify component. When I send an attachment then in Mozilla the whole attachment is stored with the email. Likewise when I receive one. Since I keep all (ish) of my mail this can be irritating since I normally deal with the attachments and then am done with them -- even more so with attachments that I send. Maybe adding options to: delete the attachment from the email; not store the attachment with sent mail; store a filestore pointer with the sent mail could be useful (This is one of the irritations in Netscape that kept me using Eudora). Reproducible: Always

This is not going to happen in the next release or so. The only thing that's possible would be not to put the attachment in the sent folder at all; removing it after the fact is not really doable. Reassigning to JF -

Marking NEW.

Here here! Where I can still see that it might be useful to store the attachment if I am really the originator of the mail, especially when I'm forwarding a mail to someone else it should be possible to suppress any attachments to the original mail from being stored in the Sent folder.

There's some common ground between bug 83040 (storing sent messages without the attachments) and bug 2920 (deleting attachments from existing messages). In both cases text info of some sort needs to be added to the message to indicate that attachments have been removed, and possibly to provide some info about what the attachments were. In the case of bug 83040, it's simpler to implement this since the message hasn't been stored yet (other than a rough version of it saved in the drafts folder). Either bug 2920 or 83040, or a design discussion that partly covers both, could serve as the basis for establishing the text info that needs to be added. Work is underway for bug 2920. It's in the initial design discussion stage right now. A thread has been created on n.p.m.mail-news with the subject "[Bug 2920] Discussion about deleting attachments", in addition to the comments posted to bugzilla for bug 2920. Some of this discussion may be of interest and relevance to any future work on bug 83040. [Bug 2920] Discussion about deleting attachments ------------------------------------------------ news://news.mozilla.org/netscape.public.mozilla.mail-news http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=ajqpn3%24ctb1%40ripley.netscape.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dnetscape.public.mozilla.mail-news Whether or not it turns out to be feasible to implement bug 2920, there may enough details thrashed out from the design discussion to help later efforts on bug 83040. It might even turn out to be best to implement 83040 before 2920, since it'd be a simpler way to field test this sort of functionality. Re: <a href="#c1">Comment 1</a>, David Bienvenu > The only thing that's possible would be not to put the attachment in the sent folder at all; removing it after the fact is not really doable. David, since I'm working on bug 2920, which by nature requires removing attachments after the fact, I'd be very interested in knowing any general and specific thoughts you have about the perils/pitfalls/difficulties of attempting to do this (removing attachments after the fact). My observations so far are: There's a sizeable knowledge barrier to implementing it - adequately understanding the code base, the layers of abstraction, and the typical glitches and work-arounds. Nothing in the existing architecture (AFAICT so far) seems to support something of this sort - altering an existing message without losing the header info (i.e. without using "Edit as new"). Adding any new sort of architectural behavior would tend to involve an inherently higher degree of difficulty, in creating and reworking the code to ensure that it coexists reasonably well with the existing architecture. The fact that nothing in the existing architecture (?) supports this sort of behavior suggests the possibility of it being deliberately left out for good reason (i.e. maybe earlier engineers decided it was not reasonable to alter a message in any way without also altering the message id). I have no reason to assume that's the case, but it's still a thought that comes to mind. It'd be important to ensure that it's acceptable to add this type of behavior, as far as architecture and standards-compliance. There's a good deal of question about whether even a small change to a message would be allowable, given the usage of RFC822 for storing messages (this has already been discussed somewhat at length in the aforementioned newsgroup thread). Some people have argued that a minor change would be reasonable, while at least one person has stated that nothing less than creating a new RFC to act as a superset of RFC822 would be acceptable if any change is to be made. Introducing functionality to alter existing messages would likely need to have a pretty clear level of support and approval from a number of high-level Mozilla engineers (super-super review of the intended design?). Are there any other concerns, especially specific ones, that you (or someone else) could add? For any really-lengthy replies, it may be best to post them to the aforementioned newsgroup thread, rather than attempting to have a threaded discussion in bugzilla. If it would be helpful I could create a new thread in n.p.m.mail-news covering the discussion as it relates to bug 83040 (I may wind up doing this anyways if it seems like it'd be helpful enough). Matt

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

changing qa contact to yulian

Sorry to add another trash-comment - but is there still activity in this ? Anyone working on this ? Please don't start big discussions like many of the Bug 2920 people did but simply implement something. I mean, what the heck with RFC violation: If other well-known MUAs do it as well do it in the same way and don't ponder about the graveness of life. Of course I should do it myself (I'm not a programmer) or hire someone to do it (I'm a student with limited funds)... I just would like to know if anyone except me is extremely interested in it or if this topic is simply dead... Best Regards Simon

(In reply to comment #7) > Sorry to add another trash-comment - but is there still activity in this ? > Anyone working on this ? Actually bug 2920 is currently heavily worked on and one of the higher level enhancements. There is an option of detaching and deletion of attachments (detatch should leave a link) I guess the "detatchment process" would be the most appropriate version for sent file filtering, since the user wants to know what has been sent, but does not have to copy the file.

For info: I use Gnus for email, there's an option to do this, and I find it simply great. When I send a message with an attachment, the message and the attachment get send, and the message with a link to the attachment on the filesystem gets saved in my mailbox. As long as the attached file stays on disk, it's just transparent for me.

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

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

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

In fact, exactly this missing feature is the reason, why we did not leave the old Pegasus Mail. When all users' sent mail contain all attachments, our IMAP folders would be muuuuch bigger. Second reason - when we are connected over slow link and send a message, it takes double time to send it in Thunderbird (because it sends it, and then it stores the message with attachments to sent-mail).

Won't block tb3.

Wow - this bug/feature request is almost a decade old - can we party about TBs inability to be storage-efficent next year? Is there anyone out there with enough expertise to understand why the attachment removal code is not applicable for the sent box?

Wow, this feature request is over 15 years old, dating from Mozilla. It seems that the detach code is now implemented, so that part if it is working. For the philosophy of it : pine, pegasus mail, Gnus are all doing it this way. Well, seeing for how long this has been around this is probably a lost cause, but also seeing how rapidly my IMAP copyself folder is getting huge (compared to Pmail), I don't know where this is leading to. And as there is also no way to retrospectively detach attachments from a large number of emails ...

This is included in the AttachExtraTools extension, so it is possible. Or has been as it seems that this does not work anymore in recent versions and with a sentto folder on IMAP (one get three copies, two without attachments, one with). It still seems to work with local folder. The plugin is not maintained anymore. So programming wise this seems possible. Cheers Oliver

This looks like an easy win, since code exists that might make it work.