Closed Bug 2920 (delete-attachment) Opened 26 years ago Closed 20 years ago

Delete attachment from mail message in folder (remove/strip attached files from email messages)

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: lchiang, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted)

Attachments

(12 files, 8 obsolete files)

(deleted), text/plain
Details
(deleted), text/plain
Details
(deleted), text/plain
Details
(deleted), application/zip
Details
(deleted), application/octet-stream
Details
(deleted), application/x-zip-compressed
Details
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
mscott
: superreview+
Details | Diff | Splinter Review
(deleted), patch
Bienvenu
: superreview+
Details | Diff | Splinter Review
(deleted), text/plain
Details
<transferring from Netscape Internal bug system, bugsplat 331226. Commented out the information on the enterprise customer name. If you want this info, go back to the bugsplat bug report. 2/4/99> RFE - need ability to save email without attachment The client wants to be able to save an email without the attachment. Message/Edit Message as New is not an option because the FROM address is lost ------- Additional Comments From granrose 10/26/98 10:47 ------- yoel - need more details. how about a test case with an example of what the customer is doing, what is happening, and what they want it to do instead. also, for customer-related bugs we have to put the customer name in the Summary so we can see what customers have filed which bugs. Once we have this info, reassign this to q_dse_client and we can send this to engineering. thx. ------- Additional Comments From yoel 10/29/98 6:41 ------- Customer is not using 4.5, but since 4.5 does not provide this fuunctionality either I've used it as an example What the customer is doing currently: 1. Mail is in Inbox with attachment 2 [review]. MESSAGE|Edit as New 3. Delete attachement and Save 4. Move from Drafts folder to custom folder Problems with this current proccess: 1. Sender address is lost 2. Date & Time lost 3. Message-ID changed What Customer wants: The ability to delete the attachement from a message while in the inbox without losing any of the existing attributes of the message(i.e. sender, date & time, message-ID). ------- Additional Comments From marek 01/25/99 22:22 ------- mass-setting to TFV 5.0 all enhancement requests against Communicator 4.5
QA Contact: 4080 → 4495
QA Contact: 4495 → 4080
Assignee: phil → putterman
This sounds like a local mail feature. Dunno if it's feasible, but it's low priority (read: laterable) for Seamonkey. Reassigning to Scott Putterman.
Status: NEW → ASSIGNED
Target Milestone: M9
I'm not sure what to do with low priority bugs. I'd hate to later this now and forget about it. So I'm going to pick some future milestone and see what happens. How about M11? But M11 doesn't exist. So let's try M9.
Outlook provides this function now
Assignee: putterman → jefft
Status: ASSIGNED → NEW
reassigning to jefft. Feel free to change the target milestone.
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
This enhancement would be nice to have, but I don't think we need this for PR1
Summary: RFE - need ability to save email without attachment → [HELP WANTED] eed ability to save email without attachment
Target Milestone: M10 → 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.
Whiteboard: HELP WANTED
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 nobody@mozilla.org
Would you need to edit the message for this? I'd say no, and hence "Delete Attachment" is a better desc. Either way, I'm hoping this delete would leave a stub, so that the attachment shows up, but you get an error when you open it.
Changing qa assigned to pmock@netscape.com
QA Contact: lchiang → pmock
I wish I could send you guys a copy of "E-Mail Connection", but I no longer have a copy of it. It handled this deletion of attachments beautifully. If it had gone 32-bit I might still have it around! Anyhow, I thought there may be some value in my describing how it did it's thing. I hate to even approach this line of thought, but part of the elegance of "EMC" was the user preference you could set up. You could set up one of 3 ways to deal with an attachment when clicked on. 1. Save attachment, keep with message. 2. Save attachment, delete from message. 3. Save attachment, ask what to do. I would further recommend looking into a 4th option, as to how Eudora handles attachments. 4. Save attachments to folder upon download. I'm not a big fan of Eudora, but I sure know a bunch of folks that are and love this feature. Seems to me that this would have all kinds of security issues involved, but I guess there's no accounting for taste. Another thing that could be done in addition to the above is have a drag and drop action move the attachment out of the message, where holding the CTRL key down would simply copy it out of the message. CMD key for Macs of course :) Hope this note provides an additional perspective into this.
I think of the ability of: 1.- Delete option when you rigth click on the attachment. 2.- Be able to apply a "strip attachment" filter when moving messages. Number one should be completed with a "do you want to keep the attachment in the message" question when you save it, or a checkbox to automatically delete it when you click on OK (Save).
I agree with the 1st point about having a right click delete option. I think the 2nd point concerning a pop up screen would start to get old real quick for folks dealing with a lot of mail. For what it's worth.
adding myself to cclist
Keywords: helpwanted
Summary: [HELP WANTED] eed ability to save email without attachment → Need ability to save email without attachment
Whiteboard: HELP WANTED
Target Milestone: M15
Many people want this? Mozilla 1.2?
Keywords: mozilla1.2
i've seen this request in some newsgroups here and there. it would be a very useful feature, maybe not a flashy one, but useful. i often see people who keep interesting emails in some folder. they want to keep a copy of the text because it's important to them but they forget about the attachments. which add up until the disk is full... and then they realize they have dozens of pictures, movie clips, word document... in their inbox, which sums to hundreds of MB ! if Mozilla could warn them that once read they can delete the attachment(s) to save disk space, i think it would be smart ! now, please implement this before Outlook engineers do ;-)
Adding keyword.
Keywords: mail2
spam: adding self to cc list. i've always wanted this feature...
marking nsbeta1- (I recognize that the owner is nobody@mozilla.org, but it got nominated and the Netscape mailnews team will not be fixing this in the near future).
Keywords: nsbeta1-
Change QA from pmock to fenella
QA Contact: pmock → fenella
To Esther..
QA Contact: fenella → esther
Adding [RFE], removing "need ability to" from summary.
Summary: Need ability to save email without attachment → [RFE] save email without attachment
*** Bug 72395 has been marked as a duplicate of this bug. ***
I thought i'd look into this bug which is over *two* years old and has *13* votes. Ahh, it's so quiet and peaceful here - too bad.
once an attachment has been detached/deleted, it would be nice if a *note* were placed at the end of the message saying something like: "This message used to have an attachment, which was deleted to save space."
I believe that not changing the message ID violates the RFC, as such the last few comments should be ignored. However, that leaves a big problem, because it looks like yoel@netscape.com (10/29/98 6:41) wanted us to violate the rfc. iirc there was a similar discussion about bounce or some other feature where we debated changing the messageid/from fields. Perhaps we need to rethink the idea of never marking an RFE as Invalid... an rfe that violates the RFC w/o being a proposal to write a superseeding RFC is about as close to invalid as you can come.
OS: other → All
Whiteboard: INVALID? ILLEGAL? RFC-VIOLATION?
Timeless@mac.com - which RFC and why? It'd only violate an RFC IF Mozilla was acting as an MTA with respect to stored mail - if it was sending it on to another person. Since it isn't, (we've already received the message) IMHO this doesn't violate any RFC's.
I think, timeless refers to RFC822. I agree with Curtis Jewell - RFC822 talks about communication, not storage. Since there is no way to send a stored msg verbatim, the rfc strictly doesn't apply here. timeless has a point, since store in mbox format, and mbox seems to require msgs to be in RFC822-format. See <http://www.qmail.org/qmail-manual-html/man5/mbox.html> - if somebody has a more authorative definition, please cite here. But, considering the utility of this feature and the many user requests, I'd suggest that we take the freedom to minimally violate the mbox definition - we have not much obligation to follow it. Altering the msg-id is IMO not a real alternative, because it would break threading.
Whiteboard: INVALID? ILLEGAL? RFC-VIOLATION? → mbox-violation?
There have been several requests on n.p.m.wishlist for an ability to delete attachments from messages. That may be a more flexible solution to the same problem. I'm sure there was a bug filed for it, but I can't find it anywhere...
Garth Wallace, I'm confused. From my understanding, this is exactly what this bug is about.
I thought this was about an option to save a message without the attachments, rather than deleting attachments from it while in a folder.. I could be wrong though, it's been known to happen. :)
Garth, oh, you mean "save" = "save in a file, that is not in the Mozilla msg store"? I think, we mean (at least I do) "save" = "store the msg in a folder", which can be in the local Mozilla msg store (Local Folders or folders for POP accounts) or on an IMAP server.
This confusion is why i would suggest changing the subject to: "Remove/delete attachment(s) from message in local folders" The "save as" is not only ambiguous, but it also implies that one must decide to delete the attachment *during* the save operation. The removal should, however, be possible at *any* time.
Summary: [RFE] save email without attachment → Delete attachment from msg in folder
Now that we have a little submenu when clicking the attachments icon in a message, would it make sense to add "Delete this Attachment" to that menu?
only if somebody implemented this.
*** Bug 91132 has been marked as a duplicate of this bug. ***
*** Bug 101582 has been marked as a duplicate of this bug. ***
Has someone been assigned this? I'm willing to do the interface work if that will help it along.
*** Bug 105331 has been marked as a duplicate of this bug. ***
Hello. I was the submitter of the last dup of this bug, sorry but I didn't find it before. The comments I put on my dup were: From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5) Gecko/20011011 BuildID: 2001101117 It happens often that when we receive an e-mail with files attached, we save the files on our hard drive and we store the message because we do not want to lose the reference to the email received. However, the files attached are now on two locations on our hard drive, and I consider this a real waste of space. My RFE's objective is to add a feature to the context menu (right click) activated when selecting attached files from store messages. It would be named "Delete Data" or something like that. We could then keep the text information that belongs to the message, without wasting disk space with the attachments which we do not need more. (The names of the files attached that are deleted could remain on the message as grayed items, so as to know that the message had contained attachments.) Reproducible: Always Steps to Reproduce: 1.Open a message with attachments. 2.Select an attachment. 3.Right click so as to see the context menu. Actual Results: We can see the features "Open", "Save As..." and "Save All...". Expected Results: We could see one additional feature: "Delete". I hope you are agree with me in all senses.
The response I got on my (erroneously duped) bug 115909 was not very promising on the "doability" of this RFE =(
I'd love to see this implemented, even though doing it is waaay beyond me. But can I offer someone a six-pack (or better) to help out on this?!
*** Bug 117746 has been marked as a duplicate of this bug. ***
I sumbitted DUP 101582 More information is that Mutt supports against IMAP by, deleting the origonal mail and resubmitting the mail with the following extra MIME info which it interprets: --------------010309060602090402010004 Content-Type: message/external-body; access-type=x-mutt-deleted; expiration="Fri, 4 Jan 2002 15:58:38 +0000"; length=1060539 Content-Type: video/mpeg; name="25097-3566.mpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="25097-3566.mpg" --------------010309060602090402010004--
QA Contact: esther → trix
This feature will allow mailboxes across my company to be reduced from averaging 500MB, to maybe 5 or ten MB. Most of what I see filling peoples email boxes have been saved externally on the users drive, and backed up to the server and re-emailed all over the company, and archived to tape. Plus of course the encoding into mime is an expansion encoding, wasting more space than the removed file has in unencoded format. Once permanently removed, the file would exist as the original on disk, and the normal disk search would have a good chance of finding the search text. Part of the solution is to do exactly what the original bug writer suggested: remove the attachment from the message file on disk, as a right click on attach menu. This should add a comment of some sort on the message that shows the original filename, the filesize, the saved file/name path and the date of extraction (since this would be the date of the file created on disk). Each would provide good search terms to try when the removed attachment is "lost" within the company's storage space. It could leave a link that could be clicked to open the attachment (is there security risks with this?). Additional prefs.js or Edit|Preferences could be to default to removing attachments on all received mails, or asking on first read, or never. Also the location to place the removed attachment in would be good, so that user does not need to keep specifying same path at each remove. This shouldn't be limited to within the mail store subdirs, nor to the local disk, i.e straight to the users home directory/attachments or something similar an an external server. Anyways, looking forward to this feature soon, and just my two-bobs-worth.
Just to add on to what DaveT said, it would be nice (not must-have but nice) to include a pref to "add structure" so that if you are detaching an attachment within your carefully created folder heirarchy, that it saves into a similar folder structure with the default save location as a root. So an attachment in an email that is in the mail folder Archives\Big Customer\Software, will save the attachment by default to <save root>\Archives\Big Customer\Software.
That's a good idea. This also makes it possible to edit the document (by just hitting the "save" button) and being able to resend the edited document by forwarding the original email. One of my users had been asking to be able to do this in Netscape Communicator so she could use the email as a "communications desktop", an orginational tool structured around messages where attachments can live (change) as the communication takes place. The interesting part is how do you track multiple attachments with the same name - you may want to not only save the attachments into a save folder with the same structure as the email folders (to reduce duplicate attachment names), but to also refer to the attachments with index names (perhaps based on the original name) rather than their actual name (so the first "mail.txt" file would link to a file called "mail.txt" but the second would have a link to a file that might actually be called "mail.txt~1" or "~1il.txt" to get around character limitations on some OSs but renamed back to "mail.txt" when it is saved/launched/etc. via the mail client).
sounds like this drifting away from Delete attachment from msg in folder but rather about a request for enhancement. How about one of you two write up an RFE bug and carry on the discussion there? The features you're talking about would be dependant on this bug, but there's no reason for fixing this bug to be dependant on implementing what you're talking about. I know I'd *very* much appreciate being able to delete attachmnts, and I don't really care one way or the other about a magical save behavior (so long as it isn't on by default). -matt
Blocks: 121728
I created Bug 121728 to keep 2920 clean(er) for edit/detachment capabilities within mail. ;-)
No longer blocks: 121728
Blocks: 121728
*** Bug 128293 has been marked as a duplicate of this bug. ***
I just have to state that this is amazing. This feature is so simple, mutt has had it for as long as I have used it. All you need is to delete an attachment from the message. If the code is too difficult, please just rip it off from mutt, which has an Open Source license. As a UI suggestion, just add "Delete" to the attachment popup menu and File -> Attachments version of same menu. Also, when an attachment is selected, hitting "del" should delete the attachment, not the email. If this is NOT a coding difficulty (which it can't be, as mbox is very old and this feature is not complex) then what is holding this bug up? If no one is working on it, please just tell me which files define the Attachment menu and the mbox handling code and I'll try it, though I haven't touched the Mozilla code before so it would take forever.
I know this is not a user forum, nor do I wish to be a "me too"-er, but still have to agree with both Seth (#51) and Matt (#48). This request is literally taking years (it was posted in 1998 and as I can see, there are quite a lot of us wanting it quite *badly*)! PLEASE implement some means to delete attachments in the simplest way possible, and worry about fancy features later. (Or if you worry about some RFC or another, you can mask it as some "field-test feature" and allow it to be enabled only if user manually edits prefs file. Or whatever. Just DO it, please.) I'm getting sick and tired with the everyday routine: "Edit as new", deleting attachments (which, surprise, surprise, can be easily done within "Edit as new") and sending mail back to myself, only to lose the original mail header (along with correct sort-by-date order)... BTW: I'm still using the ancient Netscape 4.7 mailer, just because Mozmail (IMHO) hasn't got any THAT important new features to make me switch to it. But, attachement deletion would be THE feature which would persuade me, and probably not just me (in spite of all the Mozmail bugs). Teddy
I use Microsoft Outlook only because it can delete attachments of recieved messages. As soon as Mozilla gets this capability, I promise to switch to mozilla. I do not think that such enanchments requires much new code: deleting an attachment is already possible for messages in Draft folder and in many other ways. I strongly suggest to add this feature and I vote for this bug !!!
Blocks: advocacybugs
Save as Draft works on a high level and creates a new message from our in-memory data structures (I think). I'd prefer Delete Attachment to work much more low-level, so that *everything* in the message is presenved (original headers and all) apart from the attachment.
*** Bug 131878 has been marked as a duplicate of this bug. ***
I would also need ability to delete parts of multipart/alternative messages. For example if I get multipart/alternative containing "text/plain" and "text/html" I'd like to delete text/html copy to save space. It's possible with mutt. Maybe it would be nice to have an option to automaticly delete parts if there is one that I prefer. And ability to set my preference order, for example "text/plain" then "text/html" then "text/richtext". Best wishes Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... [Winnie the Pooh]
I would love to have this feature, too. Pegasus Mail 4.01, from which I just migrated, can delete attachments too (even though only while they are in the new mail folder)
As a corporate user, my comments are similar to Comment #45 From Dave T 2002-01-24 05:14. Many gigabytes of IMAP user mail store would be freed up by allowing large attachments to be eliminated from the user's Saved folders. Attachments are almost always saved elsewhere on the network. Disk space is cheap, but ever lengthening backup windows cause headaches! Why is a bug of this age (approaching three years) with this many votes (77 currently) not being worked on?
I'd like to migrate from Eudora to the Mozilla mail client, but I can't do so until it's possible to delete attachments. I backup my e-mail through a 100 MB parallel port Zip drive; because of speed and size constraints with the Zip drive, it's just not practical to backup mailboxes that contain large attachments. From reading through the other comments, as well as posts in netscape.public.mozilla.mail-news, there seems to be a reasonable demand for the removal of attachments.
In the interest of time, a relatively simple change that addresses the core demand of reducing the size of the mailboxes, with a minimal impact on issues such as mailbox integrity and portability, anti-virus e-mail scanning, signed documents, etc, would help to move things along considerably. Afterwards, while people are pursuing a more comprehensive, convenient, and flexible change (that might overlap with or replace the initial change), the users would be able to start reducing the size of their mailboxes or migrating away from their previous e-mail client. I have some interest in making this change myself, if it looks do-able. --------------------------------------- Suggestion for an initial change: 1. No automatic external storage of attachments when they're first downloaded (forget about this for now). This opens up too-ugly a can of worms to be resolved in a timely fashion, as far as AV scanning, and e-mail integrity (preserving the filenames of the received attachments, some of which may have the same name). And it may raise concerns about the portability of the mailboxes (if the user migrates to a different e-mail client, would they still be able to access their external attachments directly from the e-mail? If not, this might be perceived as a user lock-in feature, which would discourage users from migrating to Mozilla). These issues would have to be adequately addressed before this feature could be potentially added (later on). 2. Add UI options for deleting one or all attachments from the current message, comparable to the existing UI options for saving attachments. Nothing fancy. Consistent with the existing UI options for saving attachments. "Delete all" could be left out if it posed too much of a problem. 3. Keep the code for deleting attachments separate from the code for saving attachments. Basically, leave the code for saving attachments as-is, and simply add separate code specific to deleting attachments. Not having pop-up windows or menus that allow the user to both save and delete attachments in one action. Not attempting to alter any of the existing functionality related to attachments (if possible). It's less convenient than a one-step or automatic save-and-delete, but it's more convenient than not being able to delete attachments at all. 4. Delete the requested attachment(s) from the current message by replacing the attachment data with text that identifies the name of the deleted attachment. This way the user will still have a record of which files were sent in the e-mail, for future reference. At the very least, this would be just as useful as, and much easier than, manually removing the attachment data with a text editor. And it would provide the non-techies with a way to achieve this. One issue is if there is an adequately reliable and portable way (WRT the mbox format) to do this, an approach that won't corrupt the mailbox in some cases or on some platforms. Another issue is e-mail integrity. Would the deletion of the attachment be too much of a violation of the integrity of the e-mail? Of course, users can still manually delete the attachment if they want to, and they may want to decide for themselves if it's acceptable to alter an e-mail by deleting the attachment; if they decide it's not acceptable, then they don't have to do it. The users might not like being deprived of the choice of deleting attachments. Another related issue is if it should be possible to delete signed documents. I don't know anything about signed documents / certificates personally, but I've heard other people voicing concerns about this. As long as there's a reliable way to detect if an attachment or e-mail is signed, it should be easy to disable the "delete attachment" functionality for that message or e-mail, if needed. A possible modification here is that text info could be added specifying the external location of the attachment, allowing the user to open the attachment by clicking on the text info (not sure yet if Mozilla supports this type of a hyperlink to a local file); however, doing so raises some issues about e-mail integrity (if the user saves the file with a different name, would additional info need to be added specifying the original name of the attachment?), and e-mail portability (avoiding possible user lock-in, if other mail clients don't support this hyperlink approach), as well as the general issue of relying on hyperlinks that can be so easily broken (if the user moves the files). It might be best to skip this modification (linking to external attachments) for now. AV e-mail scanning shouldn't be an issue here, since the only new functionality would be deleting an attachment from the mailbox (that's got to be a pretty safe thing to do as far as AV software goes, I'd imagine). --------------------------------------- Three cases where someone would want to remove an attachment from the mailbox file: 1. They don't need the attachment. 2. They don't need to access the attachment directly from the e-mail; they've already saved the attachment, and they don't want it taking up space in the mailbox. 3. They need to access the attachment directly from the e-mail, but they don't want it taking up space in the mailbox (text info specifying the location would accomplish this, if a hyperlink to a local file is supported). The suggested change would satisify cases 1 and 2. A more comprehensive change (which could be done later) would be needed to satisfy the third case. Does this change, or some variation of it, seem like a reasonable step in the right direction? Glad to hear any feedback, Matt
As long as attachments can be removed, without losing original header information (that is, I don't have to forward the mail [minus the attachments] back to myself and thus create a new header) IMHO *anything* is a reasonable first step (if not leap) forward. Don't know about others, but really I don't care much for the "link to file" feature if that means delaying the basic feature any further. Wouldn't hurt to have it, but not that much useful anyway, since quite a lot of people tend to send attachments with filenames containing blanks, national chars and the like (since Word introduced the "feature" of constructing default filename from the first line of text, this gets even worse), so before storing them, I have to rename them anyway. And that probably means "Delete attachment" should be somehow integrated in "Save as" dialog. So let's just forget about that for now, if it presents any additional problems.
As long as I can delete attachments without using a text editor, it's ok for me. Eudora's autosaving attachments function? I don't know if this is a good idea nowadays. For example, one of the e-Mags I subscribed to has images attached to it. Even though there are not many images, if Mozilla autosaves those images, that would be quite annoyed in the long term. On the other hand, if ever autosave is adopted by Mozilla, I would still want attached images to be displayed in-line -- I don't want to click, click, click to a folder just to see what images I've received.
I'm working on a patch for this. I posted a rough design overview for it here recently. I've done the initial work for the UI changes; next up is removing the attachment data from the mailbox. However, I'm new to Mozilla, and I have a couple questions about working on bugs: 1. Should I assign the bug to myself? Is that the usual first step when someone starts working on a bug, when no one else is already assigned to it? 2. What's the best way to get feedback - discussion, review, and such - about a planned change before a patch is actually submitted? Using IRC (#mozmail)? Newsgroups (netscape.public.mozilla.mail-news)? Posting comments on bugzilla? Sending e-mails to the owner and peers of mailnews? It'd be helpful to get some early feedback, before going much farther with the work, to increase the chances of the patch being useable and useful. (I can supply more info about the planned patch as needed.) Matt
Status: NEW → ASSIGNED
> 1. Should I assign the bug to myself? Is that the usual first step when > someone starts working on a bug, when no one else is already assigned to it? Yes. Doing so, in case you don't have the necessary bugzilla rights. > 2. What's the best way to get feedback - discussion, review, and such - > about a planned change before a patch is actually submitted? On the bug. Make sure the relevant Mailnews developers are on the cc list of the bug. See also <http://www.mozilla.org/hacking>. If you have a larger change that either influences a lot of code or changes existing behaviour of the app significantly (e.g. implement Eudora's method of automatically storing all attachments as separate files), the post to the newsgroup. > It'd be helpful to get some early feedback, before going much farther with the > work, to increase the chances of the patch being useable and useful. Agreed.
Assignee: nobody → dev
Status: ASSIGNED → NEW
Here are some of the design plans for the patch, and related questions. I could use plenty of feedback :) User Interface Right clicking on an item in the attachments list Open Save As... Delete ----------- Save All... Delete All Main Menu File | Attachments | <attachment item> | Open ---------- | Save As... | Delete ----------------- File | Attachments | Save All... | Delete All The letter "D" seems like the natural choice for the access key for "Delete"; however, I'm not sure if there's a clearly-best choice for "Delete All" ("A" is already used by "Save All..."). "E" and "L" seem to be the only real choices. Seems like a coin toss...? ------------ Is it reasonable to leave the context menu for the displayed attachments as-is? (when you right click on a displayed attachment.) I get the feeling it would be inappropriate and clumsy to add the delete-attachment option to this menu. This menu is a subset of the context menu for when you right click on an image on a web page. There aren't currently any options on it that are specific to e-mail attachments. ---------------------------------------------------------------------------- Confirmation Window I don't see any confirmation windows for deleting an e-mail (unless I'm missing something), but then again there's the safety net of the trash folder and the undo command, so maybe it's not needed there. Is a confirmation window needed for deleting attachments? If so should "OK" or "Cancel" be the default choice? (It might be too annoying if "Cancel" is the default, though it would also be a little safer.) Is something else needed instead of or in addition to the confirmation window, something along the lines of a trash folder or an undo command? (Not sure yet if it'd be practical to implement either of these. It may depend on what approach is used for the deletion of the attachment data from the mailbox.) ---------------------------------------------------------------------------- mbox Format Is deleting the attachment data an mbox violation? (The isolated action of removing the attachment data, ignoring for now whether any new data gets added to the e-mail in place of the attachment.) If so, does it have a minimal-enough impact to where it's still reasonable and acceptable to do so? Is there a need to disable attachment-deletion by default? (If it's deemed to be too much of an mbox violation to have it enabled by default) If so, should the preference option for this be easily changeable through the GUI or should it require manual editing of the preferences file. (I'd rather not add a GUI-changeable preference option unless it's really necessary; no point needlessly cluttering the GUI.) Does the mbox format require that data be added to the e-mail indicating that an attachment was deleted? (I haven't heard any reason to think so, but I thought I'd ask.) Or does the mbox format require that if such data is added, it has to be in a certain specific format? (Comment 44 lists sample data that mutt adds for doing this.) Would the added data be portable? (Would some other e-mail clients be able to make use of the data?) If mbox data needs to be added indicating that an attachment was deleted, does the data have to be localized? Or does the internal (non-displayed) mbox data never get localized? (i.e. "Content-Type: image/png;") ---------------------------------------------------------------------------- Deleting the Attachment Data I haven't gotten to this yet (perhaps where the real work will be), but I wanted to go ahead and ask in general if anyone can point to existing functionality in Mozilla that's related to this. Is there any existing code with which you can reassemble a received e-mail using only some of the data sections, and without losing any of the header info? I'd like to introduce as little new code for this as is feasibly possible. Comment 51 suggests taking the code for doing this from mutt, if needed. Would this be a feasible option (if needed)? (As far as the similarity of the open-source licenses and the similarity of the code bases.) ---------------------------------------------------------------------------- Displayed Record of Deleted Attachment How much of the following info is minimally necessary? * original filename (i.e. "Attachment deleted: <filename>") * original filesize (possibly size of externally saved file) * date of deletion (possibly date of externally saved file) * saved filename (non-portable info, possible hyperlink) * saved path (non-portable info, possible hyperlink) (Note that the last two require a combined save-delete operation, similar to the "autosave attachments externally" feature described in bug 9309, and often referred to in this bug. This functionality is outside the scope of the planned patch, and perhaps more relevant to bug 9309 anyways, but the items were listed for completeness. A further discussion of this might be more appropriate for the n.p.m.mail-news newsgroup, since it's a broad issue that spans multiple bug entries.) Is it reasonable, or less of a possible mbox violation, to only state the original name of the deleted attachment? (i.e. "Attachment deleted: <filename>") Is it reasonable, or perhaps better, to not add any info about the deleted attachment? Depending on how difficult it turns out to be to reliably add some of the above info to a received e-mail, it may be necessary to consider not adding any such info. Once the amount of info has been decided upon, the exact phrasing of the info can be established. ---------------------------------------------------------------------------- I'll stop here for now. Some other existing issues can be presented for discussion later. For large Bugzilla comments like this one, is it better to post the info as an attachment, rather than posting it as a comment? Or are attachments really just for patches and testcases, and not for discussion? phewww... gotta take a break from the questions to catch my breath and post the comment :)
> Open > Save As... > Delete > ----------- > Save All... > Delete All Maybe a move action is useful: this action would save the attachment and delete from the original message. The action could be called "detach" (the inverse of attach). I'd prefer to have the maximum information about the file I detached, so the proposal to leave in the message teh name of the original file, the size, the path where it has beeen saved and so on, is very fine for me. It may be useful to be able to display this information (where, I do not know). Having the name of the original file + " dettached" in the attachements panel of the message (with save disabled) may be nice (but confusing and at this stage it is not necessary) Matt, vey appreciated your work!
Wow, seems that you really dug into this patch. Well, I surely hope someday it'll be regarded (by the rest of Mozmail devellopers) as a "feature", not just a "patch". :-) Keep up the good work. (And I hope my two cents below will be of any help) > The letter "D" seems like the natural choice for the access key for "Delete"; > however, I'm not sure if there's a clearly-best choice for "Delete All" ("A" is > already used by "Save All..."). "E" and "L" seem to be the only real choices. > Seems like a coin toss...? "L" seems a bit better, since it's the last letter and reminds (me) to "All" more than "E" does. But not that important really. > Is it reasonable to leave the context menu for the displayed attachments > as-is? (when you right click on a displayed attachment.) If you mean the pop-up menu in the list box, listing all attachments (the one with options: Open, Save As, Save All), I believe that would be *the* most intuitive place to add the Delete (or Detach in case of Save/Delete operation). Other (esp. more general) context sensitive menus IMHO don't need such options. > Is a confirmation window needed for deleting attachments? If so should "OK" or > "Cancel" be the default choice? (It might be too annoying if "Cancel" is the > default, though it would also be a little safer.) I think a confirmation would be nice. With OK as default choice. With such confirmation dialog, I don't believe any more complications such as separate Trash would be necessary. > Does the mbox format require that data be added to the e-mail indicating that > an attachment was deleted? I really don't have a clue about mbox format -- however, some indication that attachment existed, should be included. If anything else is not feasible for whatever reason, I wouldn't mind if it's included at the bottom as part of the msg body itself (perhaps with a line of minuses above it, for visual separation). The least information should be the original file name and size. Though (if Detach is implemented) the complete file path/name, indicating where the file was saved, would be nice too. Even better if hyperlinked, but not necessary.
It's wonderful to see this moving along! I have a thought about the info to be added in the mbox file in lieu of the attachment: I think that it would be great to replace the file with a plain text mime attachment that displays inline in the mailnews reader and includes a file:// url and a note saying the time and date the file was "moved." This way, when you look at the message a year later (barring a major reorg of your hard drive) you just click on the link in the message to get to the file again.
*** Bug 161272 has been marked as a duplicate of this bug. ***
>Maybe a move action is useful: this action would save the attachment and delete from the original message. The action could be called "detach" (the inverse of attach). At this point I'm not considering a "detach" option for this patch. I think it would hold up the work on bug 2920 too much to attempt it now, and it may also be better to handle this later as a separate bug that's addressed in a way consistent with bug 9309 (autosaving attachments externally) since they'd share a common mechanism. Detach & autosave touch on some significant issues (like mbox portability, and perceived user lock-in), and need to be thoroughly and cohesively thought out before being implemented. I'm looking to make a relatively small change. I don't mind if this work winds up being partly or totally replaced later on; I'd just like to get some delete-attachment functionality in place soon. In the big-picture, it may be best to view this as a two-stage fix, with the first stage providing users a way to reduce the mailbox size by removing unneeded attachments, and the second stage adding the "detach" and "external autosave" features (unless people decide against those features). And once the first [and second] stage is in place, it may be feasible to create a user-activated filter that goes through a mailbox and deletes or detaches attachments based on the specified criteria. This could be viewed as a third stage for the overall work (with it's own separate bug entry). (Don't know if I'd attempt any of the second- or third-stage work myself.) >I'd prefer to have the maximum information about the file I detached... I could use a lot of feedback from people about which type of file info is really essential and which is more optional at this point. I'd like the e-mail to look clean - not excessively cluttered with info about the deleted attachment. I'm a little wary of adding the sort of info that's subject to change or that's non-portable. The filesize and the date of deletion can become invalid (as far as searches to locate the file) if the file winds up getting edited (though it's useful up until that time). Saved filename and path are non-portable and even more subject to change, but I'm not considering those anyways at present (see above info about "detach"). Just realized... It wouldn't be possible to have the date of deletion exactly match the date of the saved file (and if the user saved the file on an earlier day, it wouldn't even be close), unless there's a combined save-delete action ("detach"). Would date of deletion be useful enough at present, even without a detach action being available? I'd like to add the original filename, unless there's some major difficulty with adding any info to a received e-mail. And I'd consider adding the filesize and date of deletion if it's thought to be important enough, if it's easy enough to generate this info, and if it doesn't visibly clutter the e-mail too much. >"L" seems a bit better, since it's the last letter and reminds (me) to "All" more than "E" does. But not that important really. Oh yeah, hadn't thought of that. That seems like a good reason to lean slightly towards "L". >>Is it reasonable to leave the context menu for the displayed attachments as-is? (when you right click on a displayed attachment.) >If you mean the pop-up menu in the list box, listing all attachments (the one with options: Open, Save As, Save All)... Actually, that's not the one I meant. I wasn't quite sure how to refer to the different menus. I mean the context menu you get if you right-click on the displayed image of an attachment (not the entry in the attachment list), just as if you were viewing a web page and you wanted to right-click on a displayed image so you could save the image. Thanks for the feedback so far. Keep up the flow of ideas; it can do nothing but help, in the long run :)
Re Comment 65 > User Interface > Right clicking on an item in the attachments list Open Save As... Delete ----------- Select All There is no need for Delete All or Save All. Anyone interesting in acting like that can select all and then open, save or delete. > Main Menu > File | Attachments | <attachment item> | Open > ---------- > | Save As... > | Delete > ----------------- > File | Attachments | Save All... > | Delete All I don't like having delete all here either. In a well designed object oriented menu system this whole problem wouldn't exist since the object menu would change from "message" to "attachment" when you focussed the attachments area. Unfortunately most of our target platforms don't have that, instead we have a silly file menu. > The letter "D" seems like the natural choice for the access key for "Delete"; This matches windows. > I'm not sure if there's a clearly-best choice for "Delete All" ("A" is already used by "Save All..."). > "E" and "L" seem to be the only real choices. You aren't required to assign an access key to every menu. In this case i'd suggest not assigning one. I'd actually like to propose for consideration using "Remove" instead of "Delete" you are removing the attachment from the message. > Is it reasonable to leave the context menu for the displayed attachments > as-is? (when you right click on a displayed attachment.) imo yes Confirmation Window > I don't see any confirmation windows for deleting an e-mail (unless I'm > missing something), but then again there's the safety net of the trash folder > and the undo command, so maybe it's not needed there. > Is a confirmation window needed for deleting attachments? If so should "OK" > or "Cancel" be the default choice? (It might be too annoying if "Cancel" is > the default, though it would also be a little safer.) If you have to ask a question like this, then mpt will tell you that the dialog is silly. > Is something else needed instead of or in addition to the confirmation > window, something along the lines of a trash folder or an undo command? Just make sure undo works, although the alterrnative would be to use "Remove" and have remove stick the attachment into a folder "Disassociated Attachments" (pick a better name), then anyone actually wanting to delete them would go and manage that folder and rely on standard delete message behaviors. > (Not sure yet if it'd be practical to implement either of these. It may > depend on what approach is used for the deletion of the attachment data from > the mailbox.) Make sure undo works. > mbox Format > Is deleting the attachment data an mbox violation? I still believe it is. > The isolated action of removing the attachment data, ignoring for now > whether any new data gets added to the e-mail in place of the attachment. Are you sure you can ignore this? > If so, does it have a minimal-enough impact to where it's still reasonable > and acceptable to do so? No. If it's a violation then figure out how not to violate it, don't ask is it ok for me to rob a bank so long as i'm only taking 10$. > Is there a need to disable attachment-deletion by default? The only way to do this IMO would be to have Attachment deletion be provided as an XPI, but you'd never actually have the option to .. Actually. I suppose a corporation could set a policy prohibitting people from deleting attachments :-). ok ... so maybe you do need to allow it to be disabled. w/o that argument I would have said you shouldn't provide the option to disable it. > If it's deemed to be too much of an mbox violation to have it enabled by > default If so, should the preference option for this be easily changeable > through the GUI or should it require manual editing of the preferences file. No visible pref, and no violating the rules, figure out how not to break the rules. > I'd rather not add a GUI-changeable preference option unless it's really > necessary; > no point needlessly cluttering the GUI. this stands alone. > Does the mbox format require that data be added to the e-mail indicating that > an attachment was deleted? If you've been working on this then you should have done some reading, it shouldn't be my job to play bad cop learn all the laws and prosecute you for rampantly breaking them. Please spend some time reading the specs. > I haven't heard any reason to think so, but I thought I'd ask. mbox requires that messages be stored in rfc822 format. The issue isn't really mbox, it's rfc822. By removing the attachment data you are making a new message which is missing data from the original message, and by retaining the message id you have caused your message to be different from the message that all other recipients and the sender. <q title="rfc822" src="ftp://ftp.isi.edu/in-notes/rfc822.txt#4.6.1"> 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should August 13, 1982 - 23 - RFC #822 Standard for ARPA Internet Text Messages each receive new message identifiers. </q> <q title="rfc2822" src="ftp://ftp.isi.edu/in-notes/rfc2822.txt#3.6.4"> 3.6.4. Identification fields Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below. The "Message-ID:" field contains a single unique message identifier. The "References:" and "In-Reply-To:" field each contain one or more unique message identifiers, optionally separated by CFWS. The message identifier (msg-id) is similar in syntax to an angle-addr construct without the internal CFWS. message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] id-left = dot-atom-text / no-fold-quote / obs-id-left id-right = dot-atom-text / no-fold-literal / obs-id-right no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE Resnick Standards Track [Page 23] RFC 2822 Internet Message Format April 2001 no-fold-literal = "[" *(dtext / quoted-pair) "]" The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it (see below). This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers. Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields such as trace fields (described in section 3.6.7) and resent fields (described in section 3.6.6). The addition of such header fields does not change the identity of the message and therefore the original "Message-ID:" field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. </q> This last paragraph defining changes is probably key, if i'm the sender and i mean to send you a picture and you decide to remove my picture from my message, you have changed what I intended to convey, and therefor by the rfc you are obligated to use a new unique message id. Why this matters. My potential landlord sends me as an email message in three parts text/plain message body application/fdf contract application/pdf addendum the addendum is a list of additional terms which i am accepting, it may either be pdf or fdf, it doesn't matter. I decide to delete the addendum (for whatever reason). [in fact, i probably wanted to convert landlord's message/rfc822 into a message/partial (see rfc1341), but mbox stores message/rfc822 and there doesn't appear to be a way to annotate what we want in mbox - it's your job to figure out how to do this. Notet that BeFS used by BeOS tags all objects with mime types, including messages, as such a BeOS mail reader could of change a message from message/rfc822 into message/partial if it was asked to remove an attachment. ] At some later date, I get in trouble with my landlord for violating the terms of the addendum. We go to court and the judge asks me to produce the contract I accepted. I provide the email which has: Message-ID: X text/plain application/fdf Judge, this is the contract my landlord sent me and this is the contract I accepted. (there's also a second message [Message-ID: Y] lying around in my outbox from which I also removed the application/pdf addendum) My landlord provides to the judge the original message (Message-ID: X) and the complete response (Message-ID: Y) each containing three parts. The judge stares at me and declares that I've committed perjury and fines me for being in contempt of court. The judge explains that my message-ids while claiming to uniquely identify messages in fact does not (they don't, for some reason i removed the addendum). domain: law.timeless. (<- that trailing dot is significant) > Or does the mbox format require that if such data is added, > it has to be in a certain specific format? Do your homework and find a solution that makes people happy (preferably me) > Comment 44 lists sample data that mutt adds for doing this. > Would the added data be portable? Do your homework > If mbox data needs to be added indicating that an attachment was deleted, > does the data have to be localized? mbox is supposed to store rfc822 messages in general there are some people who like the idea of replying Subject: SV: Foo But many people (including me) would prefer that everyone use RE: Foo instead since it's globally recognized. Someday English speakers might start receiving chinese characters preceding Foo one might mean Re, one Fwd, one Attn, one something else, but there's no guarantee that our email clients will be able to correctly interpret the chinese characters (or the klingon ones or ...) and certainly we ourselves may be unable to interpret them. -- Localizing things is fun. Personally I'd suggest that you make your code localizable and mark the text as "do not translate". If at some future point someone decides they want to make things harder on the world, they can translate it w/o much effort (you've done your job by making it localizable) even though some of us don't really want them to localize it. > Or does the internal (non-displayed) mbox data never get localized? > (i.e. "Content-Type: image/png;") It's never supposed to be munged. If I send you an image/gif and you store an rfc822 image/png then i expect that it will have a different Message-ID. > Deleting the Attachment Data > I haven't gotten to this yet heh > perhaps where the real work will be, perhaps > but I wanted to go ahead and ask in general if anyone can point to existing > functionality in Mozilla that's related to this. Questions like this should probably be sent to npm.mail-news > Is there any existing code with which you can reassemble a received e-mail > using only some of the data sections, and without losing any of the header > info? There's an entire bugzilla component MailNews: MIME and a cvs area: mozilla/mailnews/mime/ which presumably can do whatever you need > I'd like to introduce as little new code for this as is feasibly possible. > Comment 51 suggests taking the code for doing this from mutt, if needed. Don't. > Would this be a feasible option? No. Take ideas for behaviors, but don't take code. > As far as the similarity of the open-source licenses and the similarity of > the code bases. (from freshmeat) License :: OSI Approved :: GNU General Public License (GPL) Mozilla is MPL at its core, and mozilla.org requires contributions to be licensed under MPL and others. GPL is not compatible with MPL (hence the others bit), so you can't take GPL code and stick it into cvs.mozilla.org > Displayed Record of Deleted Attachment > How much of the following info is minimally necessary? > * original filename (i.e. "Attachment deleted: <filename>") > * original filesize (possibly size of externally saved file) > * date of deletion (possibly date of externally saved file) > * saved filename (non-portable info, possible hyperlink) > * saved path (non-portable info, possible hyperlink) This question and probably the entire post belonged in npm.mail-news, not bugzilla. > Note that the last two require a combined save-delete operation, similar to > the "autosave attachments externally" feature described in bug 9309, and > often referred to in this bug. This functionality is outside the scope of > the planned patch, and perhaps more relevant to bug 9309 anyways, but the > items were listed for completeness. A further discussion of this might be > more appropriate for the n.p.m.mail-news newsgroup, since it's a broad issue > that spans multiple bug entries.) > Is it reasonable, or less of a possible mbox violation, to only state the > original name of the deleted attachment? (i.e. "Attachment deleted: > <filename>") IMO it is not. > Is it reasonable, or perhaps better, to not add any info about the deleted > attachment? doubtful. Imagine rfc822 as an envelope (see rfc822 1.1), mbox stores it and magically allows you to examine its contents without violating the seal (Message-ID), what you are doing is taking an envelope and breaking its seal, removing pieces from it and then sealing it up again and claiming you haven't violated the sanctity of the seal -- which clearly you have. > Depending on how difficult it turns out to be to reliably add some > of the above info to a received e-mail, it may be necessary to consider not > adding any such info. once you've broken the seal, it should be trivial for you to add extra contents, the issue is with the seal. Change the Message-ID and do whatever damage you need to do. > For large Bugzilla comments like this one, > is it better to post the info as an attachment, No > rather than posting it as a comment? No > Or are attachments really just for patches and testcases, and not for discussion? No for large comments which will require threaded conversations and quoting (which yours clearly did) you should use a newsgroup. Re Comment 66 a move option is clearly well beyond the scope of this bug. Re Comment 67 > when you right click on a displayed attachment. A displayed attachment is a thing shown either in the body of the message (display: inline) or in its own window, not in the attachments pane. Re Comment 68 This bug isn't moving, no one has suggested a way to resolve the mbox violation. In fact the person offering to do work has only thought about the general interface issues and hasn't even looked into mailnews/mime cc: jglick (mailnews ui owner), mpt (uid def assignee) for ui input. This bug is going to get geometrically longer and not usefully. It should not have grown past comment 28 until people found a valid solution. And the correct way to have a discussion in search of a solution would have been to start one in npm.mail-news
> The filesize and the date of deletion can become invalid (as far as searches to > locate the file) if the file winds up getting edited (though it's useful up > until that time). Saved filename and path are non-portable and even more > subject to change, but I'm not considering those anyways at present (see above > info about "detach"). Perhaps, but this is still useful information. The invalidity can be accomodated for by noting "originally saved as xxx/yyy", which doesn't necessarily imply the information is still current. > Just realized... It wouldn't be possible to have the date of deletion exactly > match the date of the saved file (and if the user saved the file on an earlier > day, it wouldn't even be close), unless there's a combined save-delete action > ("detach"). Would date of deletion be useful enough at present, even without a > detach action being available? How about having a check box on the save dialog which says "delete attachment from message?" This would allow the date of saving and deletion to match, and be functionally comparable to a "Move" menu entry.
>> User Interface >> Right clicking on an item in the attachments list > Open > Save As... > Delete > ----------- > Select All > > There is no need for Delete All or Save All. Anyone interesting in acting like > that can select all and then open, save or delete. The 'Save All...' command already exists. As for all this business about changing the content of the message, would it be viable to add an X-Mozilla header indicating that the message has been changed from its original form? Something like: X-Mozilla-Altered: Attachment addendum (application/pdf) Removed (Tue, 6 Aug 2003 20:24:15 +0100) Or am just talking impractical nonsense?
that save all exists in a context menu is a bug, if you like we can adress it elsewhere. i'd prefer (while we're desecrating messages) that we change the third entry from application/pdf to message/external-body (rfc 1873, rfc 1521 7.3.3) (it was referenced in rfc 1341) -- I don't know much about that mimetype, but it seems appropriate. Then at least you can tell that there were 2 attachments beyond the text/plain message. And external-body appears to have enough structure to satisfy most of the fields people want to have for a removed attachment.
Sorry about the oversized discussion being held here in Bugzilla. I reposted my discussion comments to the n.p.m.mail-news newsgroup, in the hope of shifting this discussion over there. Please feel free to repost any existing comments there and to continue this stage of the discussion there. The subject of the thread is: [Bug 2920] Discussion about deleting attachments. (This has been a comedy of errors so far trying to learn where to initiate discussions and ask questions :)
I just now posted an assessment of this bug to an existing thread on the following newsgroup: netscape.public.mozilla.mail-news (found at news.mozilla.org) subject thread: [Bug 2920] Discussion about deleting attachments date of post: 2002-08-09 This post sums up how the situation looks, based on what I've seen so far. In the interest of not cluttering up Bugzilla (more than I have already), I decided not to post it as a comment here, but I'd encourage anyone interested in a patch for bug 2920 to read the newsgroup post and consider how they might be able to contribute to an eventual patch for this bug.
Blocks: majorbugs
*really* want this bug -- Matt, what's the ETA? Need any help with the coding?
I'd really like to see a patch for this too, but there are some pretty steep learning curves to go through, and plenty of details to work out. See the discussion of bug 2920 on n.p.m.mail-news, subject "[Bug 2920] Discussion about deleting attachments". news://news.mozilla.org/netscape.public.mozilla.mail-news I'm hoping to have an initial patch by early 2003. That's about the soonest I can see this getting done unless someone with experience in the relevant parts of the code base winds up doing a large part of the coding. Even then, it might take at least a few more months to iron out most of the details. The work is in the initial design-discussion stage at present. I can use any help or feedback people can offer. In fact, a generous amount of both is essential for this patch to move along. Right now I'm having trouble getting set up to use gdb. I posted a message to n.p.m.unix, subject "Unable to access source files in gdb". news://news.mozilla.org/netscape.public.mozilla.unix
*** Bug 121728 has been marked as a duplicate of this bug. ***
adding myself to the cc list
Attached file Architectural Review (deleted) —
Please add my "pretty please" request for this function. Russel
*** Bug 178700 has been marked as a duplicate of this bug. ***
changing qa contact to yulian
QA Contact: trix → yulian
I madly need this feature too (gigabytes of attachements), with, of course, a slight modification in the message to keep track of the deletion (mentionning filename, mime-type, date, etc.) cannot help you to develop it, i'm a user ... Thanx
Not much progress to report so far. Things have been moving at an even slower pace than expected - due to very little time being available for working on it. The work so far has mostly been high-level discussions - weighing the different options. The underlying architectural question of whether it's acceptable to alter an existing e-mail (without also changing the message ID) has not been resolved yet; that question is at the top of the agenda right now. The only effort on it so far has been posting the above architectural review as an attachment to bug 2920. (btw, when I view the text file of the architectural review in Mozilla 1.1 the lines don't wrap around. Do I need to format it differently, or is Mozilla limited at displaying text files? I read through the newsgroups, but wasn't able to find the answer.) I may have some time soon to pursue the arch'l review. Does anyone have some detailed advice about how exactly to get someone to review this? I've had some difficulty following the available documentation for working on bugs, and I'm still totally new to working on Mozilla. Any help that people can offer with things like this may considerably speed up the effort on this bug. And if someone could just load me into the Matrix and upload an expert knowledge program about working on Mozilla, that'd sure save a lot of time ;-) Now and then I'll post messages to the existing thread in n.p.m.mail-news, "[Bug 2920] Discussion about deleting attachments", for anyone who's interested in the following the work or helping out. The last such post was on Oct 16. More than ever before I'm leaning towards the simplest solution possible (as discussed somewhat in the last post to the above thread). If some solution is implemented, however simple it may be initially, it should be relatively easy for others to build upon it and add a greater variety of features. I'm also toying with a design approach similar to how a folder is compacted, that would allow for a lot of future flexibility (for instance, using filters to automatically delete specified attachments from existing messages).
My 2c worth - don't believe this has been put as I find it.... I am considerably stuck without this fix WRT emails I've SENT, that include attachments. I don't want to delete the msg, but do want to lose the attachments, which are otherwise redundant (I have them already!:). Regarding how to leave the email after the deletion - I would be happy if a text message was left at the bottom of the message with some details of the attachments that are now deleted. Perhaps deletion could trigger a dialog to suggest first saving the attachment, which could also result in an appropriate text message left at the bottom of the email. sTu.
I think it may be better to add lines to the _header_ of the message which inform of the removal of attachments. This would allow the Mozilla mail client to know which attachments had existed (and perhaps to display them in the normal 'attachments' box on the upper-right, only greyed-out, signifying the fact that you can't get to them), while the message itself will not be cluttered with more text. As for a dialog box, I think that's not such a good idea because I don't want to answer questions whenever I delete e-mail. Perhaps there should be a preference regarding saving attachments, something like "Never delete/Always delete/Always ask/delete above [text box] kbytes and ask otherwise/Save under [text box] kbytes and ask otherwise/etc."
Re: comment #87 >I am considerably stuck without this fix WRT emails I've SENT, that include attachments. I don't want to delete the msg, but do want to lose the attachments, which are otherwise redundant (I have them already!:). See: [Bug 83040] Attachments stored in Sent mail >Regarding how to leave the email after the deletion - I would be happy if a text message was left at the bottom of the message with some details of the attachments that are now deleted. It might be reasonable to use an approach like this for new messages that Mozilla itself just created (Bug 83040), but for existing messages (Bug 2920), much of which would have been created by other e-mail clients, or even by future versions of Mozilla. It would be virtually impossible to adequately predict and parse the format of the body, to where text info can safely be appended. Re: comment 88 >I think it may be better to add lines to the _header_ of the message which inform of the removal of attachments. This would allow the Mozilla mail client to know which attachments had existed (and perhaps to display them in the normal 'attachments' box on the upper-right, only greyed-out, signifying the fact that you can't get to them), while the message itself will not be cluttered with more text. I expect it'd be reasonable to add new headers, with some info about the deleted attachments, so that's there's at least some record or evidence of an alteration having been made, and in what way the message was altered. Whether Mozilla should then use that info so that the user can easily, visually tell which messages were altered and which attachments were deleted, that's a different matter. That quickly gets into issues of user lock-in - if there's Mozilla-specific behavior that the user becomes dependent on, for visually keeping track of alterations to messages. Granted, this is a very borderline case. The current three priorities for bug 2920 are: (1) making the simplest change possible. (2) avoiding user lock-in. (3) making a change that's of personal interest. Personal interest may sound selfish, but on the whole it's what keeps people motivated and enthusiastic enough to volunteer their time (for free). It's what drives open-source development in general (everyone scratching their own unique itches). In this case, a UI that helps the user visually keep track of altered messages fails all three criteria. It adds an awkward level of complexity to the UI, it introduces user lock-in (gut feeling), and it's not something I'm interested in using. I might not mind if someone else adds such a feature, but attempting to add it myself would just cause a loss of interest in working on the bug (which actually happened earlier, before I realized that and quickly found renewed enthusiasm). I'm intending to make a minimal change that's totally free of bells and whistles, nothing fancy. Ideally, others could use it as a building block for additional features - deleting attachments from sent messages, adding a visual indication of altered messages, using a filter to automatically delete certain attachments from one or more folders, deleting and saving attachments (possibly with a link to the saved location), etc. But a fundamental starting point has to be in place first - establishing that it's acceptable and possible to alter an existing message in Mozilla, which is no small thing. This bug has the potential be much longer-term than people have likely guessed. Worst case, it might first require that a new mail format be created and implemented in Mozilla, perhaps a superset of RFC822. Or it might have to be on hold until the next major rewrite of the underlying architecture of Mozilla/Netscape. Both are real possibilities. It's also possible that it'd take one or more years (of gradual spare time effort) to learn the existing architecture well enough to begin adding such a change (for me at least). In the mean time, maybe someone can make a relatively easy-to-use hack tool for deleting message attachments outside of Mozilla. Maybe even something that can visually list the messages and related attachments for a given folder, letting you select which ones you want to delete. For a hack tool, it wouldn't be necessary to deal with the architecture and theoretical standards-compliance of Mozilla, which is where the real difficulty is. After all, the difficulty with bug 2920 isn't understanding the mbox format, that part is pretty simple. Hey, it'd be a hack, just like if you edit an mbox file by hand. As long as it works, doesn't corrupt the data, and meets your needs, anything is fair game. It's your data after all (as far as home usage of e-mail, at least). I'm sure there'd be plenty of people (myself included) that could use such a tool in the short term. I know there are perl scripts and such that people have put together, someone just e-mailed me one a few days ago (haven't looked at it yet). But I'm not sure if there's anything out there that's easy enough for a non-hacker to use. Any thoughts about short-term hack solutions?
Matt, I understand and respect your comments about motivation. So, please don't let my comments stop you. Summary: I do think that it is both relatively easy to implement and valuable to just replace the mime part with the file with a mime part of another mimetype, which contains hint about the missing attachment. Longer explanation: Attachments are usually multipart/mixed MIME containers, sometimes multipart/related etc.. In order to completely remove all attachments, you'd have to change the MIME structure of the message (possibly removing the MIME container altogether), which (I assume) is non-trivial, because there are many cases (n attachments, m of them should be deleted, determining the "body" etc.). Each MIME part (one content part of a MIME container, e.g. of type text/html or image/tiff) has its own headers to determine the mimetype, maybe original filename etc., then the body (content of the mime part) follows. I suggest you simple do the following: You replace the MIME part with the attachement (e.g. image/tiff part inside a m/mixed container) with a completely different, generated part of another type. For example, 1. you make up a mime type for deleted attachments and store the original mimetype and filename in the headers or body *or* 2. you create a text/plain part and store the original mimetype and filename in the header and then generate a simple text message which contains the same information in human language. In the 2. case, you'd have all information available in structured, machine-readable format and you also have some information, which Mozilla will automatically display (no special display code needed). In the 1. case, you could relatively easily create another MIME type handler to libmime, which could then add a generated text at display time or it could show the attachment in the attachments box as "<filename> [deleted]" or something. I think that writing this MIME type handler is not hard and I could give you hints how to do it. I believe that this way, namely replacing the attachment MIME part with another part of another type, which hints at the deleted attachment, is both easier to implement than completely removing the attachment and also more future-proof, because that's where we should go in the long term IMHO. IMHO, deleting attachments completely from existing mails, without any hint of the former attachment, is not a good idea and not something most users would want. I hope my comment was not too confused and not too obvious. Of course, you are free to do what you want. I am not a Mailnews module owner, though, and they decide what goes into Mozilla eventually.
Re: comment #90 Hmmm... Although it wouldn't be the ideal solution to me, I'd consider using plain text attachments, if that'd be much simpler to implement than totally removing the attachments (especially in the case of removing all attachments, something I hadn't really looked into yet).. There'd still be some awkward issues with the UI. If I were to use this approach, I'd want to avoid adding any special functionality that would treat the deletion-record attachments any differently than regular attachments (such special functionality would contribute to user lock-in in my view, to some extent). Though without the special functionality, or in other e-mail clients if the user migrates away from Mozilla later, there'd be some confusion caused anytime the user deleted (or later on deleted and linked) a deletion-record attachment. The user would lose the special deletion info if they accidently re-deleted an attachment. In particular, consider if a user deletes some of the attachments from a message, and then later goes back and selects to delete all attachments from the message. Either they lose the earlier deletion info, or there's special functionality to preserve the earlier info, functionality that may add to user lock-in more than I'd be comfortable with. I really have no idea how much of a factor avoiding user lock-in is to everyone else, but it's pretty much the top priority to me. Past and present difficulty with migrating away from software made by a certain very large company has made me very wary of lock-in, even when it's purely incidental. However, a possible compromise solution (programmatically speaking anyways), might be to use empty (or nearly empty) attachments with no useful info, that are just empty placeholders for where an attachment used to be. It'd be a way to avoid having special info that has to be treated differently - by just not adding the info in the first place. And then if the attachment gets deleted a second time, there's no loss of info. I only mention this approach on the slight (or miniscule) chance that it'd be less problematic to users (if they'd prefer not having any special info, rather than having but sometimes losing special info) (i.e. you don't miss what you never had). May be way out in left field on this line of thought ;-) I'd really like a "set it and forget it" approach, where there's no special maintenance required afterwards, if at all possible. That's the ideal I'm aiming for anyways. If I were to totally remove the attachments, I'd still add headers that specify some info about each deleted attachment, though I wouldn't add any visible indication of a message being altered (unless you count viewing the source of a message and looking at the headers). Maybe there's not a really clean way to implement this bug 2920, even on paper. Well, it's not like I'm committed to a certain approach yet. So all options are still open. >IMHO, deleting attachments completely from existing mails, without any hint of the former attachment, is not a good idea and not something most users would want. I understand that it's a bad solution in many situations and for many people. For me, it's just fine, and anything more than that would be overkill and would clutter things up. Therein lies the dilemma about personal interest and not losing motivation. I may need to aim for a "bad" solution (at least in most people's eyes), in order to be motivated enough to work on bug 2920 at all. But... here's the kicker: If I implement even a "bad" solution, most of the hurdles would likely be cleared for someone else to come along and change it in a way that suits more people's needs. Open-source development tends to be effective as long as enough people pursue what's of interest to them. Anyways, the only way to minimize the difficulty of the patch, is to aim for the simplest solution possible, which is bound to not please most of the people. But I really think that's unavoidable, and actually best in the long run. Start out with something simple and somewhat manageable and build from there. One of the major things I learned in the past half year was to get past trying to please everyone. Ironically, by being selfish, I can help benefit the group the most in the long run. It's really weird how that works out. It took a while to get to that realization. Just the same, I'll keep the options open for now.
I'm speaking strictly from user's point of view, and have no idea what implementation problems that could mean, so I can just speculate (but hey, considering user's needs is what Bugzilla is all about, isn't it?): > Hmmm... Although it wouldn't be the ideal solution to me, I'd consider using > plain text attachments, I believe that *would* be the best compromise if changing the message text itself presents too many other problems, as you already illustrated (RFC compliance, IDs etc.) > There'd still be some awkward issues with the UI. If I were to use this > approach, I'd want to avoid adding any special functionality that would treat > the deletion-record attachments any differently than regular attachments (such > special functionality would contribute to user lock-in in my view, to some > extent). IMHO you can avoid that simple enough: if original attachment is smaller than the maximum length of new attachment you would generate instead (or smaller than some pre-set constant, for example 300 bytes or whatever - e.g. you can make it user definable), Mozilla can refuse to delete it, displaying an error that deletion wouldn't (noticeably) reduce the overall message length. Or alternatively: display a warning and ask if user really wants to delete it anyway. (IMHO error would suffice.) This can be done for any attachment, regardless of it's content, hence no need for any special code. Of course, if you use your own attachment type, you can treat "delete supplements" (or whatever the "instead-of attachment" would be called) differently. But then you do need extra code for check (simple enough to do, I suppose) plus extra code to display special attachment (a bit harder, I believe). Or if you stick to text attachments, you could put some text in it, by which you will recognize it as "delete supplement". Doesn't need to be any fancy stuff. If you just write "Delete supplement" (or whatever) at the top of the new attachment, you can simply deny to delete any attachment which contains it. And don't worry too much about "What if that was already part of the first attachment?". Then Mozilla just won't delete it - no harm done. IMHO most people rarely need to delete text attachments anyway. It's the pics, movies, audios, ZIPs and other large files, that are the problem. And it's because of these disk GB consumers, I beg you not to let such problems stop you! Regards, Teddy
A little idea to respect the mbox RFC822 format : - create a new message (so get a new message ID) - Clone everything except the message id and the attachment to delete. - Add to the new message text and reference (original message ID for example) to indicate the attachment deletion. - remove the cloned message (or better, move it to a specific folder so the user can remove it at later time). I think also that all these operations can be done with high-level commands from the Front-End. BTW: I'm not going to program this !
Re: comment 92 > IMHO you can avoid that simple enough: if original attachment is smaller than the maximum length of new attachment you would generate instead (or smaller than some pre-set constant, for example 300 bytes or whatever - e.g. you can make it user definable), Mozilla can refuse to delete it, displaying an error that deletion wouldn't (noticeably) reduce the overall message length. I could maybe see a minimum size restriction or simply skipping text attachments, as a reasonable compromise, with a user pref setting in either case to control the behavior. That might be a simple enough approach. I'll keep that in mind. Re: comment 93 > A little idea to respect the mbox RFC822 format : - create a new message (so get a new message ID) - Clone everything except the message id and the attachment to delete. - Add to the new message text and reference (original message ID for example) to indicate the attachment deletion. - remove the cloned message (or better, move it to a specific folder so the user can remove it at later time). There's already something available that allows the end-user to accomplish that (or pretty close to it): "Edit as New". The user can go and delete attachments from the new copy of the message, just like when they're creating a new message. But... the point of bug 2920 is how to accomplish that without losing the message ID or other useful info (which is needed for threading, and to easily keep track of what message came from whom on what date). The following significant info is lost when someone selects "Edit as New": Message-ID: From: Return-Path: Date:
> But... the point of bug 2920 is how to accomplish that without losing the > message ID or other useful info (which is needed for threading, This is exactly what I said ! Keep all the informations *except* the Message-ID because you *need* to preserve RFC822 format. I talk about "cloning" so From:, Return-Path: and Date: for example are preserved and functionalities such as threading will work. My second point is to use high level already implemented functions from the Front End.
*** Bug 185420 has been marked as a duplicate of this bug. ***
*** Bug 188334 has been marked as a duplicate of this bug. ***
QA Contact: yulian → stephend
I'm out. Don't have the energy or ability for a task of this scale and complexity, even working at a very gradual pace. Made some progress at initiating and moderating design discussions; unable to continue from there to the next step. Level of enthusiasm and interest greatly exceeded actual ability in this case, regrettably. If it's of help to anyone, I just posted a rough overview of how to delete attachments by hand, to the oft-referenced discussion thread on n.p.m.mail-news: "[Bug 2920] Discussion about deleting attachments"
Assignee: dev → nobody
No longer blocks: 121728
Keywords: mozilla1.2
Priority: P3 → --
About his overview of how to delete attachments by hand, I think Matt is referring to the following message (see the link) from a Mozilla newsgroup thread (with 42 articles currently): From: Matt Coughlin Subject: Re: [Bug 2920] Discussion about deleting attachments Newsgroups: netscape.public.mozilla.mail-news Date: 2003-01-14 11:35:24 PST http://groups.google.com/groups?selm=b01o2c%24ds83%40ripley.netscape.com This article explains how to edit carefully the mailbox files in a text editor to delete attachments, of course after making a backup copy for safety. This slow way seems to be the only way right now, until a "Delete" option will appear in Mozilla News (hopefully). 140 people is voting up to now for this bug 2920 to be corrected.
Given the quality of Mozilla, it's surprising that, while well-known email clients like Eudora, Outlook, The Bat, etc., offer options to delete attachments or for separate storage of attachments, the current versions of Mozilla Mail cannot do it yet. As many users and testers complain, in the cases of big or numerous attachments, this can be a real trouble. Reading the discussions on this point, it seems that the only problem is to know if this is allowed or not by the Internet mail standards. Like many others I think that, indeed, the RFCs clearly not only don't prohibit the deletion of attachments by the receivers, they also give standard ways to allow this option. As already pointed out by Garth Wallace in the discussion at netscape.public.mozilla.mail-news (http://groups.google.com/groups?selm=akr6pb%24buo2%40ripley.netscape.com), the MIME RFCs have a standard option to separate attachments from the rest of the message as local files in computer folders, keeping a reference in the email message. (Content-Type: message/external-body; access-type=local-file). This way, the mailboxes can be much smaller. And, naturally, if the user chooses this option (for one, some or even all attachments), as a receiver may delete any separate files on the own computer later. This works in a similar way to the old paper and parcel mail. The following example comes from: RFC 2046: Multipurpose Internet Mail Extensions (MIME), Part Two 5.2.3. External-Body Subtype http://www.zvon.org/tmRFC/RFC2046/Output/chapter5.html#sub2sub3 This MIME RFC says: "The external-body subtype indicates that the actual body data are not included, but merely referenced." "5.2.3.4. The 'local-file' Access-Type" "An access-type of 'local-file' indicates that the actual body is accessible as a file on the local machine." That is to say, for instance, attachments as separate files are allowed by the Internet mail standards. Adapting a simple example from the RFC, a message with an attachment can be similar to the following: From: Whomever To: Someone Date: Whenever Subject: whatever MIME-Version: 1.0 Message-ID: <id1@host.com> Content-Type: multipart/mixed; boundary=42 Content-ID: <id001@guppylake.bellcore.com> --42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Here, text of email message... --42 Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> --42-- The previous is an optional standard format to store attachments as separate local files. On the other hand, for transport through the Internet, the current format used by Mozilla Mail is right and also standard (of course, more headers are used in emails). For this example: From: Whomever To: Someone Date: Whenever Subject: whatever MIME-Version: 1.0 Message-ID: <id1@host.com> Content-Type: multipart/mixed; boundary=42 --42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Here, text of email message... --42 Content-Type: application/postscript; name="RFC-MIME.ps" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RFC-MIME.ps" Here, the complete attached file as some screens of very long code, like this: ROfUeles6IlonhC1iFuAY4QFAwO59BXnP7RNtHrnwa8S6UTlG0q4SaMLk4MT57enoa 3o0otRm0o6rTXvs7XOyN3H3dfk/8j+V3xVqmpeOPiBqet38kk9zeXryfu7ZSzkt8oCDHbHQZ74Nd rY+GL3QNBtrm98SwozXLqQkj+Wyh9qpEwwZctvU7NqgA4YlyKqeEvhR4i8TfFKbRdMiDXQMtzdRR yDbZ24O4tKxO0DZg85HOCCeK+v8A4I/sO6n4w1CK41kose4x3GoXOQ0gxIxSMkkwRAdRjzDtO7nC r7+NqwhKXLCLSbV9N3dx0totk21frZnq0qcFTTnJJ9munXTQ5T9ir4aXmk+Novipe6Ld282j6xDN pVnqd8Yo5GX5o2Ma4xGHCsd4JI6Bga+kv2qNB+Jv7RNpd/Er49fEia8vy5nhMgkeJWw3EW8ruTt8 pKjp2rR0zVfhx8E9c+w6JqC7tPlAZ+GWRwcggk4B/wBn5s15D+3B8cdU8X+Dn+ztbRxPgW9pczET OuW+6AwKD2... (and so on) --42-- In Mozilla Mail, you can see this second format for attachements in messages with the menu View / Message Source, or Ctrl+U. About the "Message-ID:" question, the optional conversion from the second format into the first one for storage can be done without any change of the Message-ID, according to the Internet mail standards, RFC 822 and RFC 2822. RFC 2822 says: "There are many instances when messages are 'changed', but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields (...). The addition of such header fields does not change the identity of the message and therefore the original 'Message-ID:' field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the 'Message-ID:' field changes, not any particular syntactic difference that appears (or does not appear) in the message." (RFC 2822: Internet Message Format; 3.6.4. Identification fields) http://www.zvon.org/tmRFC/RFC2822/Output/chapter3.html#sub6sub4 Since this optional conversion of formats for storage does not change the message contents but only the archiving and reference method, and adds the few standard headers used for this reference (Content-Type: message/external-body; access-type=local-file), a Message-ID change does not seem necessary. That is to say, a standard possibility would be to use the current second format to send and receive, and optionally the users can separate messages from attachments if they wish with a Mozilla option to convert into the first format (Content-Type: message/external-body; access-type=local-file) that may say something like "Save and remove attachment from message", or as an option for all attachments "Store attachments in folder...". Users may delete any separate attachment files later, out of the Mozilla Mail program. Naturally, this would be just an option. Part of the users can decide to keep attachments stored in the current way, in the message files, and others can use the other option, to delete some separate attachments without need to delete the messages. For example, options in some well-known email clients: Eudora has separate attachment storage, Outlook a Delete Attachment option, and The Bat has the two possibilities to choose. There is also a program, DBXtend, that can remove attachments from messages in Outlook Express. According to the comments and the votes in Bugzilla, I think that possibly a great part of the Mozilla Mail users would choose the separate storage option for attachments, not only to keep mailboxes small, but to prevent problems like the bug 116443 ("Deleted inbox after receiving virus infected mail"): Sometimes anti-virus software detects viruses and deletes the complete Inbox, where the attachments are stored together with the email messages, which are of course lost. This is a related very serious bug. In summary, since separating attachments by changing received messages to this format is a completely standard possibility that each user can choose or not (by menus, or filters, or options), in my opinion there is not any obstacle to implement in Mozilla Mail a standard so demanded by testers and users. Currently, this bug 2920 is the 11th most voted bug in all Mozilla, and the 3rd for Mozilla MailNews.
> it seems that the only problem is to know if this is allowed or not by the > Internet mail standards No, the main problem is having somebody work on the feature. Please do not add comments about how important the bug is. It doesn't really help. Either - vote and hope that somebody implements it (which doesn't really help either, but is better than a comment) or - hire somebody (e.g. me) to work on it.
OK, Ben. Sorry, I'm really a newcomer here as user and tester. I've been looking at the interesting link that you provided (http://www.mozilla.org/hacking/), but it seems that the Mozilla source code (http://lxr.mozilla.org/seamonkey/source/mailnews/) is mostly C++ and some JavaScript, and I can only program in Perl. Anyway, surely other people will contribute soon or later to implement some option in Mozilla Mail in order to solve this enhancement or bug 2920, given the high demand. For the moment, we may search and share possible ideas and solutions. There have been many interesting contributions in these discussions. I agree with Ben (from http://www.beonex.com , a browser and mail/news client based on Mozilla) when he says: "I believe that this way, namely replacing the attachment MIME part with another part of another type, which hints at the deleted attachment, is both easier to implement than completely removing the attachment and also more future-proof, because that's where we should go in the long term IMHO. IMHO, deleting attachments completely from existing mails, without any hint of the former attachment, is not a good idea and not something most users would want." (Comment 90). This involves the use of "Content-Type: multipart/mixed" for the structure of the stored message (if there are attachments), a well-known and flexible MIME structure used already in Mozilla, but with messages and attachments in the same file in the case of Mozilla. In my opinion, for separate attachment storage, the most suitable MIME part inside this "Content-Type: multipart/mixed" message structure would be the standard "Content-Type: message/external-body; access-type=local-file" (as already explained in my comment 100). By the way, just for the record, I forgot a detail. When I said that, in netscape.public.mozilla.mail-news, Garth pointed out the possible solution for attachments of using a standard MIME type (Content-Type: message/external-body; access-type=local-file), I forgot to mention that as well Timeless proposed this same MIME solution (message/external-body) in the comment 74 of this bug 2920. Besides, the example given by Padraig in the comment 44 shows that the email program Mutt also uses message/external-body in some way for attachments. There are other different but less standard solutions. To see some details of different possibilities in email clients, for example, for separarte storage of attachments, Eudora uses in the Out mailbox (sent messages) a custom "X-Attachments" directly in the general headers of the message (not in a part), for internal use of Eudora: X-Attachments: C:\My Documents\file.ext; And, in the In mailbox, just a note at the end of the body of the received message: Attachment Converted: "C:\Program Files\Qualcomm\Eudora\Attach\file.ext" This is in the mailbox file. In the Eudora program, the user sees a clickable icon and the file name. (Any attachments directory can be selected by the user from the options). This is only for storage. For Internet transport, I think Eudora and other email programs probably send and receive with the same standard format that Mozilla Mail uses. Eudora adds a custom header "X-Attachments" for storage, but anyway the RFCs refer mainly to communication standards, rather than storage. Naturally, many email programs like Mozilla Mail or Eudora use the standards for communication (Internet transport) also for storage purposes (mbox format). This has good advantages, like easier import/export of mail archives, etc. Another example of alternative solution for separate attachment storage is the option implemented by the well-known email client The Bat. It uses for both Inbox and Outbox the usual "Content-Type: multipart/mixed", like in the standard solution of the comment 100, but with a custom header "X-Content-File" in the attachment part of the message. For example, The Bat uses the following message part as reference of an attached file separated from the message file: --boundary X-Content-File: C:\Program Files\The Bat!\Mail\User\Attach\RFC-MIME.ps Content-Type: application/postscript; name="RFC-MIME.ps" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RFC-MIME.ps" --boundary-- instead of the MIME standard reference (Content-Type: message/external-body; access-type=local-file), also suitable to be used in the attachment part: --boundary Content-Type: message/external-body; access-type=local-file; name="C:\Path\Attach\RFC-MIME.ps" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> --boundary-- This kind of custom header fields "X-" for internal use of mail clients ("X-Attachments" in Eudora, "X-Content-File" in The Bat) are allowed but not encouraged by several RFCs. For instance, RFC 2046 says: "The only header fields that have defined meaning for body parts are those the names of which begin with 'Content-'. All other header fields may be ignored in body parts. Although they should generally be retained if at all possible, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but must not be depended on. 'X-' fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways." RFC 2046. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 5.1. Multipart Media Type http://www.zvon.org/tmRFC/RFC2046/Output/chapter5.html#sub1 http://www.faqs.org/rfcs/rfc2046.html Therefore, to detach attachment files from message files, making possible in this way a later deletion of attachments by the user, the "X-" headers for internal use (used in well-known email clients) are allowed only for private purposes by the RFCs, and they are indeed a possible solution for this bug 2920. But surely the standard MIME type (see comment 100: Content-Type: message/external-body; access-type=local-file), although also mainly for internal client use in the case of attachments (without any change of the present send-receive message format for Internet transport, and adding only the optional conversion of messages with attachments into the separate storage format), would be in my opinion the best solution to implement, as an option for users, in Mozilla Mail.
If my just posted comment 102 is a bit long, a short summary is the following: For an option of separate attachment storage (to allow later deletion of attachments by users and testers), although custom "X-" headers are used in well-known email clients and tolerated by the RFCs, and are indeed one of the possible solutions for this bug 2920, the MIME type "Content-Type: message/external-body; access-type=local-file" (to be used inside the usual "Content-Type: multipart/mixed" message structure) is completely standard and therefore, in my opinion, the most suitable solution to implement this option in Mozilla Mail.
I forgot about comment 74 (message/external-body) when writing comment 90. It might be interesting that we do have code for that in libmime, our MIME processor for reading mails, namely mailnews/mime/src/mimeebod.cpp|h. I don't know, in which state it is, though, I have never tried it. I think it just displays some info and a clickable URL in the body view.
I've looked a bit around the source to try and work out where to implement this DeleteAttachment thing but I'm not sure. Could somebody who knows maybe suggest the simplest way to add a method that would delete / replace a given attachment? Where should such a method go? Actual details of UI and so on could be sorted out later.
Re Comment 105: You may already realize that, but just in case; it is already possible to right-click on an attachment of a message in a DRAFT folder and delete it. I am not sure of the function involved, but if it can be used here, one must only add the text stub at the end of the message with deleted attachment details (name, type, maybe size and date deleted, etc. if this is the way to preserve the original attachment details). Hope this helps.
Re comment 106: /mailnews/mime/src/mimedrft.cpp contains this code. It looks like it has an array of attachments (nsMsgAttachedFile *) that it keeps track of. There is also stuff called nsMsgAttachmentData. mime_draft_process_attachments seems to read out a mime_draft_data object which contains an array of msgAttachedFiles and return a nsMsgAttachmentData array. mime_parse_stream_complete calls mime_draft_process_attachments to do this, the comment is "Now, process the attachments that we have gathered from the message on disk". So basically it constructs a message in a compose window by reading the message of disk and parsing the attachments into a kind of structure that it can use in the compose window to delete messages etc... A later comment from mime_parse_stream_complete: "At this point, we need to create a message compose window or editor window via XP-COM with the information that we have retrieved from the message store." The only other file with a comparable result for grep -ic attach in this directory is mimemoz2.cpp. mimemoz2.h contains the mime_draft_data object, and it looks like mimemoz2.cpp has general functions for handling attachments etc. from the point of view of reading a message and displaying it. So it seems like Mozilla gets the attachment into a different kind of structure if its going to edit it instead of just viewing it, which is what allows the adding/deleting of attachments - that makes sense. So if we're going to remove an attachment from a message that would normally only be viewed, we need to do some work to either get it into this structure, delete the message and save it, or find another way to do it. To test this out, I did the following: moved a message with an attachment from Inbox to Drafts, selected the message, said "Edit Draft", deleted the attachment, moved it back to Inbox - voila, it has the attachment deleted! Unfortunately it also does all kinds of things like changing the date, etc. So what we need is a quicker/slicker means of doing this straight within the Inbox, that avoids these problems. Later we could add a method to add an attachment/message to say there was a deletion (but I really don't think loads of comments about this are helpful until we can at least delete attachments). Am I on the right track?
There is an additional discussion on this bug at the Mozilla Mail newsgroup, with the thread subject "[Bug 2920] Discussion about deleting attachments" (44 articles currently). Newsgroup: news://news.mozilla.org/netscape.public.mozilla.mail-news Web archive: http://groups.google.com/groups?group=netscape.public.mozilla.mail-news
I just posted a message to the newsgroup thread mentioned in Comment 108, about some of the design approaches that came to mind over the last half year (too lengthy a message to post it here). re: Comment 100 > Reading the discussions on this point, it seems that the only problem > is to know if this is allowed or not by the Internet mail standards. That looks like the key issue right now, as well as for the past couple years. However, there's still the matter of finding a reasonable design approach, writing the actual patch, and getting the patch eventually accepted, none of which are trivial tasks. > message/external-body One question with this is, can it be used for deletion of attachments, or is it only useful for external storage of attachments? (offhand I don't remember.) External storage of attachments is an issue of significantly greater complexity, and is outside the scope of bug 2920 (I believe bug 9309 is the appropriate bug for external storage of attachments). I don't personally mind the discussion of external storage, since there is some overlap with deletion of attachments; I'm just pointing this out so people don't expect that external storage will be or should be resolved by bug 2920. re: Comment 107 > /mailnews/mime/src/mimedrft.cpp contains this code. > It looks like it has an array of attachments (nsMsgAttachedFile *) > that it keeps track of. I'm not sure if there's any useful common ground between the code and data structures for editing drafts of messages, and the code and data structures for viewing existing messages. Drafts are inherently dynamic, but I haven't seen evidence of any functionality for treating existing messages as anything other than totally static data ("Edit as New" doesn't count because that just changes the message altogether into a draft, with a loss of header info - which is perhaps the same thing that happens when you drag a message into the "Drafts" folder). If some common ground does turn up though, I think it'd be worth looking into. Maybe it's possible to temporarily treat a message as a draft, but then sneak the original header info back in...? (though that might be a solution that would be nearly as complicated, and it wouldn't allow for substituting deletion-info in place of the attachment.)
Re: Comment 104 I've tested if that MIME type works in Mozilla just by making changes with a text editor, since the Mozilla mailboxes are text files (mbox). Unfortunately, it seems that Mozilla (version 1.2.1) does not manage well the MIME type message/external-body. For example, inside a part of a multipart/mixed message, Mozilla Mail ignores the field "name" of the MIME header: Content-Type: message/external-body; access-type=local-file; name="C:\My documents\file.ext" And if, just for testing, we use this as a general header for the complete message (instead of multipart/mixed), Mozilla cannot recognize paths, and thinks that there is a coded file inside the mailbox called "C--My documents-file.ext", and offers us to open or save it. That is to say, if I'm not wrong, Mozilla Mail 1.2.1 cannot manage the MIME type "Content-Type: message/external-body; access-type=local-file" for any of its possible uses: attachment storage, shared files inside a network, etc. I think this is a bug by itself. It is not compliant to RFC 2046 (MIME, Part Two), 5.2.3. External-Body Subtype: http://www.zvon.org/tmRFC/RFC2046/Output/chapter5.html#sub2sub3 See, in 5.2.3.7, the example: Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; Re: Comment 107 > So if we're going to remove an attachment from a message that would normally only be viewed, > we need to do some work to either get it into this structure, delete the message and save it, > or find another way to do it. If adapting the Drafts method is or isn't the solution, I don't know either. The mailbox Drafts is a mbox text file like the rest of mailboxes, so it's possible. But the 2148 lines of code of mimedrft.cpp are sincerely demanding the help of someone familiar with its structure: mimedrft.cpp hyperlinked source code: http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimedrft.cpp mimedrft.cpp Blame annotations: http://bonsai.mozilla.org/cvsblame.cgi?&file=/mozilla/mailnews/mime/src/mimedrft.cpp&root=/cvsroot mimedrft.cpp change log: http://bonsai.mozilla.org/cvslog.cgi?file=/mozilla/mailnews/mime/src/mimedrft.cpp&root=/cvsroot > So what we need is a quicker/slicker means of doing this straight within the Inbox, > that avoids these problems. Maybe a very simple new function to, optionally, save the attachment as a file in the normal way already implemented in Mozilla Mail, and then make a copy of the mailbox text file, line by line, replacing (when the program reachs the Message-ID) the attachment part with a short reference and if it's possible a MIME header. (At least in Perl this is very-very easy; I don't know how it is in C++, the main language at Mozilla). Then the funtion would delete the old mailbox and rename the new one. That's all, really. As Matt proposes, I've done this by hand, and it works perfectly. Therefore, Mozilla or an external program could do it as well. Later other improvements can be added (filters, options, better procedures, etc.). An additional possibility to test the different options (direct attachment deletion, external attachment storage...) would be a small and simple program to manage directly the mailboxes, outside the Mozilla program. It may use parts of the Mozilla code for testing purposes, and be modified until these options can be implemented in Mozilla Mail. Matt described a way to do similar things by hand (comment 98, link in comment 99). Like Matt says for the "by hand" way, just in case, this little external program would make of course backup copies of the mailboxes before editing them. Given that the mailboxes are just text files, an experimental "attachment manager" like this one is probably not very difficult to develop, specially as open source.
Re: Comment 109 >> message/external-body > One question with this is, can it be used for deletion of attachments, > or is it only useful for external storage of attachments? This standard MIME type (Content-Type: message/external-body; access-type=local-file) can be used for different things like attachments separated from the mailbox file, or to reference shared files inside a network. But, for direct deletion of attachments without the previous separation from the mailbox file, I think that probably custom "X-" headers would be the correct way (like "X-Mozilla-Deleted"). As we saw already (see link and quote from RFC 2046 in the comment 102), these "X-" headers are tolerated by several RFCs for private uses like mail storage, or communication inside a network, etc. Anyway, the RFCs recommend to use standard solutions rather than "X-" headers when possible. You can see in comment 44 that the Mutt email program uses both ways at the same time to delete attachments: Content-Type: message/external-body; access-type=x-mutt-deleted In any case, people talk about both external storage and direct deletion as solutions for this old good bug 2920 because both are ways to remove attachments from the message files. The only difference is that in the first case a copy of the removed attachment is saved in a folder, and in the second case no. We could call it "removal" instead of "external storage", so we can see that both "removal" and "deletion" of attachments are in fact the same for the message files. Like many people, I would love to have the two options to choose, to solve this bug 2920, and I hope they will be available soon or later in Mozilla Mail. Some of us have talked more about the external storage option as the currently most feasible solution for this bug because of the people's different opinions in these discussions about standards for the other way, the direct deletion. Given that, on the other hand, there is a completely standard way for external storage, this would be a good solution for removal of attachments until the direct deletion discussion becomes clearer. Like in Eudora and other mail clients, people can later delete the separated attachments as normal files, outside the Mozilla program. But this deletion is made later by the users, Mozilla doesn't delete in this option, the program just saves in two or more files (mailbox and attachments) instead of one in a standard way. Therefore, there is not discussion about standards with this MIME type (Content-Type: message/external-body; access-type=local-file). > External storage of attachments is an issue of significantly greater complexity No, in the case that only a simple function is implemented at first, just to remove and file attachments from one message at a time. Filters and an option for automatic separation of all attachments (Eudora style) can be added later. In Mozilla Mail, there are currently three options to manage attachments in a message: - Open - Save As... - Save All... We hope that at least two more options will be added, called for example: - Delete - File (or Remove) "File" (or remove, or external storage) would be exactly the same that successively clicking on "Save" (as a separate file) and then on "Delete" (removing from the mailbox file). "Save" is already implemented in Mozilla Mail. Therefore, both "Delete" and "File" have the same -great or little- technical complexity. The only problem at this moment is the agreement about standards for direct deletion. File (external storage) = Save + Delete. If it's possible, let's have the two options soon in Mozilla. If there are consensus delays about the standards for the "Delete" option, we can think let's have at least the standard "File" option for the time being, to be able to remove those big attachments from our message files. Just one point of view about possible solutions for this bug 2920. That's all, sorry if I've written too much these days. And thanks if some C++ programmers can do it. :-)
In answer to the question, "Would message/external-body [...] be useful for deleting attachments?", Garth Wallace had the following answer on the n.p.m.mail-news newsgroup: >Not with the currently defined access-types, but Mozilla could create its own "experimental" access-type to mean external-bodies that can't be retrieved. Call it X-DELETED, X-REMOVED, X-UNAVAILABLE, or something. A little weird, but legal, and it would work (to the best of my knowledge). If that's the case, message/external-body doesn't appear to have any relevancy to bug 2920 (deletion of attachments), aside from the possible overlap with the eventual code for external storage of attachments. re: Comment 110 > That is to say, if I'm not wrong, Mozilla Mail 1.2.1 cannot manage the MIME type "Content-Type: message/external-body; access-type=local-file" for any of its possible uses: attachment storage, shared files inside a network, etc. If so, that's something that would have to be fixed prior to (or while) working on a patch for external storage of attachments. I stated in an earlier comment that "external storage of attachments" is bug 9309, but apparently bug 9309 is specific to auto-detaching files (like in Eudora). There doesn't appear to be an existing bug for manually saving and detaching a file. I agree that there's a lot of common ground between the two bugs ("deleting attachments" and "external storage of attachments"). I'd disagree with trying to resolve both bugs with a single patch (not that anyone suggested that). Any of these 3 or so bugs have their own issues to deal with. I don't see the road as having been cleared for any of them yet. I suggest that a new bug entry be submitted for "external storage of attachments" (not sure if I'll get around to doing so myself). Anyone have any thoughts about whether such a separate bug is or isn't needed? Some of the various related Attachments operations: * "Save" (already available) * "Delete" (bug 2920) * "Save, delete, and link" (no bug yet) * "Save and delete" (without linking to the file) (no bug yet) * "Auto save, delete, and link when receive a message" (bug 9309) * "Auto delete after sending a message" (bug 83040) * "Apply a filter to save" (bugs 92146, 117341) * "Apply a filter to delete, and link" (no bug yet) * "Apply a filter to save, delete, and link" (no bug yet) I think the main issues for these bugs could be resolved on paper, prior to anyone even needing to start creating patches (issues such as exactly what types of changes to an e-mail would be acceptable to the mail-news reviewers, as well as what the UI should look like). That is to say, I think people (like myself) who are unable to write the patch, may still be able to help carry things much closer to a solution. Granted though, the programming work may still be a hefty chore. Worst case it might be beyond all but the most experienced Mozilla hackers (how's that for optimism? hehe). On that note, creating a separate utility for deleting or detaching attachments might be fairly simple, while trying to do so through the existing code base might be horrendously difficult and problematic. Maybe this is necessarily a task for one of the salaried Netscape employees / module owner / peers...?
Re: comment 51 Seth Delackner said: > I just have to state that this is amazing. This feature is so simple, > Mutt has had it for as long as I have used it. All you need is to > delete an attachment from the message. If the code is too difficult, > please just rip it off from Mutt, which has an Open Source license. Well, the Mutt email client (http://www.mutt.org) is a different open source outside Mozilla. But, just as an example of the many solutions out there, the attachment of this comment is a small fragment from the Mutt's code to delete attachments. It's in the file copy.c. (There are some related parts in the file handler.c). It uses "Content-Type: message/external-body; access-type=x-mutt-deleted;" as a message part to replace the deleted attachment (see Padraig's comment 44).
Re: comment 112 All right Matt, I agree that it's better to start with any very simple function that works, like direct deletion (for example via an easy copy/change/deletion line by line of message files), if there are no more difficulties about standards. Later, improvements, options, filters, and more elegant and integrated code can be added little by little. I admit that "File As..." (or "Remove As...", that is, external attachment storage removing from message file) is in reality the addition of "Save As..." + "Delete". "Save As..." is already in Mozilla. Therefore, apart from discussions on standards, the direct deletion would be the best bet for a first way to remove attachments from message files. Anyway, I think that probably most people agree at this point that nothing in the RFCs prohibits the deletion of attachments by the receivers, specially if there is a reference in the message about the former attachment. As Curtis Jewell said in the comment 27: > Which RFC and why? It'd only violate an RFC > IF Mozilla was acting as an MTA with respect > to stored mail - if it was sending it on to > another person. Since it isn't, (we've already > received the message) IMHO this doesn't violate > any RFC's. If there is any problem to accept this later, the work on "Delete" won't be lost because in this case the current "Save As..." can be added to the "Delete" function to make a completely standard "File As...", with storage of message and attachment in separated files, since there are MIME types for this.
Comment on attachment 112378 [details] Not a patch - Small example from a different open source people can we *please* not post random code bits without considering whether they might adversly affect someone considering implementing this feature for mozilla?
Attachment #112378 - Attachment description: Mutt's function to delete attachments from message files → GPL Tainted Code Stolen from Mutt
Attachment #112378 - Attachment mime type: text/plain → application/octet-stream
So um... when someone implements the bounce feature that allows you to make mozilla act as an MTA, what happens if it's used in conjunction with a proposed delete procedure that violates the message rfc (by changing the message content without changing the message id)?
Attachment #112378 - Attachment description: GPL Tainted Code Stolen from Mutt → Not a patch - Small example from a different open source program
Attachment #112378 - Attachment description: Not a patch - Small example from a different open source program → Not a patch - Small example from a different open source
Re: comment 115 Oh, sorry, my apologies, I should be more careful as a newcomer. That small attached function was of course not marked as a patch because, as I said (now also in the description), this was just a small example from another open source, not to be used in Mozilla, but only to see that this feature is easily feasible. If this can be any confusion, please remove my attachment. Thank you.
Re: comment 116 I think you are right. Any "Delete Att." function should be available for local copies only, and disabled for a future bouncing option. Anyway, I can be wrong, but probably in few cases people would like to apply a filter for deletion of attachments in automatic bouncing, so this does not seem necessary. And naturally, in the case of replies or "edit as new", the message ID is always changed, so no problem there. Sorry, I've written too much, I think. I hope more people will propose possible solutions. Thank you.
re: Commment 114 > Anyway, I think that probably most people agree at this point that nothing in the RFCs prohibits the deletion of attachments by the receivers, specially if there is a reference in the message about the former attachment. That seems to be the case. The only dissenter I'm aware of is Timeless. There's a lot of discussion on the relevant n.p.m.mail-news thread, "[Bug 2920] Discussion about deleting attachments", regarding Timeless's concerns about standards compliance, if it's of interest. re: Comment 114 > If there is any problem to accept this later, the work on "Delete" won't be lost because in this case the current "Save As..." can be added to the "Delete" function to make a completely standard "File As...", with storage of message and attachment in separated files, since there are MIME types for this. That's a good point. In any event, I'd recommend that whoever writes the code for "deletion of attachments" or "external storage of attachments" (whichever gets written first) writes it with some flexibility so that the other operation can be easily added in later. re: Comment 115 > (From update of attachment 112378 [details]) > people can we *please* not post random code bits without considering whether they might adversly affect someone considering implementing this feature for mozilla? Personally, I'm okay with people posting any code for a separate utility that they can come up with. A separate utility would at least offer a short-term solution to deleting attachments (which is what users of Mozilla need). I think it'd be advantageous to have examples of as many different approaches as possible, it might even offer some ideas for a patch. People don't have to look at them if they don't want to (as long as the posts are clearly identified as not being directly related to a patch, which this one was). My two cents worth, anyways. re: Comment 118 > I think you are right. Any "Delete Att." function should be available for local copies only, and disabled for a future bouncing option. Anyway, I can be wrong, but probably in few cases people would like to apply a filter for deletion of attachments in automatic bouncing, so this does not seem necessary. What does all this mean - MTA, bounce, automatic bouncing - in layman's terms? Does this mean that a message that's had an attachment deleted (or detached) would need to be disabled from being forwarded or replied to? Or does it only relate to some behind-the-scenes operation that the end user would never be aware of? re: Comment 118 > Sorry, I've written too much, I think. I hope more people will propose possible solutions. Thank you. I'd say no quantity of comments is too much if it helps lead to a solution. Though, if you feel like bugzilla is getting cluttered a bit too much with comments (and that's your own call, not someone else's), there's always the n.p.m.mail-news thread "[Bug 2920] Discussion about deleting attachments" (which is there to offload some of the discussion from here). Don't worry if you get someone snapping at you now and then. Programmers have never been famous for tact or social etiquette (hehe to put it mildly). Some things just have to be shrugged off (sorry if that sounds patronizing).
Whiteboard: mbox-violation? → mbox-violation?[se-radar]
Re: comment 119 >Personally, I'm okay with people posting any code for a separate utility >that they can come up with. A separate utility would at least offer >a short-term solution to deleting attachments (which is what users of >Mozilla need). I think it'd be advantageous to have examples of as >many different approaches as possible, it might even offer some ideas >for a patch. All right, Matt. I've just done it, an experimental Perl script to delete attachments in Mozilla mailboxes (mbox format, text files). I've developed and tested this script as carefully as possible, and it seems to be working fine. Given that I can only program in Perl, this initial script has no relation with C++ codes like Mozilla's, Mutt's, etc. I've written it starting from scratch, managing directly the mailbox files. Every line has comments, to understand well what the script does line by line. It's always better to make tests just with copies of the mail files, or at least make a backup copy, but this experimental script is quite safe because, in this initial testing stage, it does not try to modify the original mailbox. It only modifies a copy with name ending in "-test" that contains all the changes: deletion of attachment, and a note with some data replacing the attachment, as reference in the message. This allows a comparison between, for instance, "Inbox" and "Inbox-test". Of course, in this kind of testing, only the last attachment deletion is retained, given that the test file is rewritten every time. This behavior can change very easily with a few lines of code, but the current script is good for testing, this is its purpose. It's Perl, but I think C++ programs can use or call Perl subroutines in some way, so maybe this can be a starting point to think and test possible ideas for a Mozilla patch. So, if it's ok to post, not a patch, but only a test that works well (from outside Mozilla in this initial stage), I think I can include it here as an attachment.
See comment 120, and instructions in the text of this script.
Attachment #112378 - Attachment is obsolete: true
re: Comment 120 > It's Perl, but I think C++ programs can use or call Perl subroutines in some way, so maybe this can be a starting point to think and test possible ideas for a Mozilla patch. It looks like there are a ton of perl scripts in the Mozilla source. It seems to be possible to call a perl script using JavaScript: "PerlConnect and JS.pm allow calling Perl from JS and JS from Perl, respectively." I also came across this: "the Perl XPCOM project. An open source implementation of bindings which allow the use of XPCOM objects from Perl, as well as the ability to implement XPCOM interfaces in Perl." Anyways, I'd imagine that a Perl script would be potentially useable, for a patch (unless support for Perl is still a work in progress). Or it could serve as a model for what sort of C code to write (mimicking the functionality of the Perl script). An approach like this (rigging up a Perl script or some comparable C code, that's pretty much isolated from the rest of the code base) might be infinitely easier and less problematic than adapting the existing code base to support this sort of functionality. And it may be the only feasible option for getting this patch done, unless someone with considerable expertise with the mail-news module, and plenty of time to spare, suddenly volunteers for the work (doesn't seem like there's a remote chance of that though). So... rigging something up may be the needed approach, and might not be too much more difficult than just making a stand-alone utility (unless the usage of Perl XPCOM significantly complicates writing the Perl script). It'd essentially be a stand-alone utility, that was modified somewhat so that it could be used by Mozilla (in non-stand-alone fashion). Does anyone see any fundamental flaws with this approach, offhand?
I'm thinking about the possibility of adding a line at the end of the experimental script (delete-attachment.pl): unlink ("$mailbox_path_with_name-test\.msf"); Anyway, the script seems to be working well without that line, so probably it's unnecessary. This line would delete the old *-test.msf indexing file. External scripts can delete *.msf files when Mozilla is not open. Differently to *.msf files, mailboxes can be modified at any time. After deletion of a *.msf file, Mozilla rebuilds it when it's useful. Given that the script does not delete messages, but only replaces -inside a message- a MIME part (attachment) with another MIME part (short reference about the deleted attachment), reindexing the list of messages by rebuilding the *.msf files does not seem to make any difference, acording to my testing. Just in case, if someone have more details about *.msf files, it would be interesting.
More details. An attachment, before its deletion, looks like this in the message files: --------------080904090704040700040609 Content-Type: image/jpeg; name="one-megabyte-photo.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="one-megabyte-photo.jpg" /9j/4AAQSkZJRgABAgECWAJYAAD/7QFkUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABACWAAA AAEAAgJYAAAAAQACOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAA AAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZma AAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAA... [snip] (Here, the attachment as a very long code usually) --------------080904090704040700040609 What the script does is to replace the above MIME part (attachment) with another very short MIME part for reference, like this: --------------080904090704040700040609 Content-Type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit <html><body><center> Deleted attachment:<br> one-megabyte-photo.jpg<br> (image/jpeg) </center></body></html> --------------080904090704040700040609 This html note looks in Mozilla Mail, under the body of the message, like this: Deleted attachment: one-megabyte-photo.jpg (image/jpeg) An improvement would be to use other MIME headers like the following, when supported by Mozilla (message/external-body is standard, and x-deleted-attachment is a possible example of private header, allowed for internal use by MIME RFCs): Content-Type: message/external-body; access-type=x-deleted-attachment Content-Type: image/jpeg; name="one-megabyte-photo.jpg" But the current short reference about the deleted attachment seems enough for the moment, at least during the testing stage. So far, I'm not finding any bug in the posted script, but I hope other people will test and improve it. Thanks. :-)
Wouldn't forcing a rebuild of the .msf file cause loss of all labeling information (at least for IMAP accounts)? That would be bad.
Re: comment 125 I've just tested that (I can only do it in POP accounts), with flags, marking as unread, labeling as "Work", etc. After deleting the Inbox.msf file and rebooting the computer, all the info appears again. So, I don't know in what more places Mozilla keeps it. (?) Is it different with IMAP instead of POP? If labels are lost for other testers or for IMAP accounts (I don't know), in that case we better don't include my suggested "unlink" line of code in the experimental Perl script, which anyway seems to work well already without it.
re: Comment 123 > Given that the script does not delete messages, but only replaces -inside a message- a MIME part (attachment) with another MIME part (short reference about the deleted attachment), reindexing the list of messages by rebuilding the *.msf files does not seem to make any difference, acording to my testing. Just in case, if someone have more details about *.msf files, it would be interesting. I've always thought (not that it was based on anything) that the .msf files contain some info that tells the physical offset of the the message within the file, as well as perhaps a copy of the info that you see in the mailbox window (subject, data, sender, priority, etc). Certainly it seems like something that would reasonably speed up accessing the mailboxes. The suspected physical-offset info is why I've been talking in terms of deleting and recreating the index (the .msf file) after altering a message (as an easier alternative to modifying the contents of the existing index file). If there is such a physical-offset, then anytime you change the size of an existing message, the offsets of any message located after that one would have to be updated (there might conceivably also be a value that stores the length of the message). If the old message is simply overwritten, with some dead space left at the end of it, I'm not sure how that would affect Mozilla - whether the dead space would have to be cleaned up or removed for Mozilla to be able to reliably access the mailbox. Conversely, if there's no physical-offset or message-length info, then maybe it'd never be necessary to touch (delete and recreate) the index files. Any dead space (as described above) might still have to be dealt with though. re: Comment 125 > Wouldn't forcing a rebuild of the .msf file cause loss of all labeling information (at least for IMAP accounts)? That would be bad. The impression I've had of the .msf files (though I may have been way off on this), is that there's nothing in there that can't be obtained and recreated from the mailbox file. I've always heard them referred to as index files, and I've viewed them as being comparable to indexes for a database table for instance (i.e. no more than a summary of the table). I found the following on Mozilla.org: "Each mail folder (Inbox, Sent, etc.) is stored as two files – one with no extension (e.g. INBOX), which is the mail file itself (in ‘mbox’ format), and one with an .msf extension (e.g. INBOX.msf), which is the index (Mail Summary File) to the mail file." Right below that was this info: "If you want to transfer a mail file to another Mozilla profile or another installation of Mozilla, simply put the mail file into the other installation’s Mail folder." Unless they're using terms inconsistently ("mail file"), it sounds like if you're moving your Mozilla mail to another location, you don't even need to move the .msf files. Here's some info from a troubleshooting FAQ: > 10.12. Help! I can’t access my e-mail any more! > > The two common causes of e-mail problems in Mozilla Mail are: > [...] > 2. The mail summary files (files with the .msf extension) have become corrupted. > > In the second case: exit Mozilla (including Quick Launch), find the folders in your user profile that contain your e-mail (the Mail and, if you use IMAP, ImapMail folders). Back up your mail folders, and delete the .msf files. Do not delete files that appear without any extension – these are the files that contain your actual e-mail. Restarting Mozilla Mail should automatically generate new summary files." This doesn't mention any risk or loss of info resulting from deleting .msf files (granted, in this case the info is already corrupted, so this example holds less weight). Another bit of documentation found: "Bug related and other scenarios for POP Testing: * Message files stored locally- Verify the .msf file can be deleted and rebuilt automatically [...]". This looks roughly consistent too. The documentation cited about isn't conclusive by any means, but it seems consistent with the view of the .msf files as being simply a summary of the mailbox. Now then, short of just continuing to guess (as I've been doing), does someone know for sure if there's any special info stored in the .msf file (for IMAP accounts or otherwise) that can't be found in or recreated from the mailbox file?
Re: comment 127 >The suspected physical-offset info is why I've been talking >in terms of deleting and recreating the index (the .msf file) >after altering a message (as an easier alternative to modifying >the contents of the existing index file). If there is such a >physical-offset, then anytime you change the size of an existing >message, the offsets of any message located after that one would >have to be updated (there might conceivably also be a value that >stores the length of the message). Maybe there is something like that... Well, first bug found for the experimental script. :-) Matt, after reading your comment, I've done some related testing, and found a temporary display glitch under a special circumstance. That's why I didn't notice it before. If we delete attachments with the script when Mozilla is closed, it seems that there is not any problem later, when viewing mail with Mozilla, even if we don't delete the "mail summary files" (*.msf). Mozilla is able to manage it well. The display problem can appear if, on the contrary, we are deleting an attachment with the external script when Mozilla is running, and at the same time we are viewing messages in the mailbox for tests where the attachment is being deleted. In that case, only just after deleting, although the message with the new note "Deleted attachment" and the messages above look fine, if we try to view messages under the one of the deleted attachment, Mozilla has a momentary problem to find and display correctly those messages. Of course because, after the deletion of the attachment, the mailbox is suddenly smaller than moments before. I think Matt is very correct about this point. Anyway, after for example clicking a moment on another mailbox, like Inbox, and then coming back to the test mailbox, everithing is OK, Mozilla has managed to find the messages in the now smaller mailbox, and the display problem doesn't appear again. Unless we do again the same procedure during the deletion of attachments, naturally. If a "delete attachment" function is integrated in the message window of Mozilla, this circumstance of viewing a message and deleting attachments at the same time would be the usual, but with this integration in Mozilla the problem is easy to fix. As I said, an external script can delete or modify the *.msf files only when Mozilla is not using them. Differently to *.msf files, mailboxes can be modified at any time, without "access denied" errors. I think we need integration in Mozilla to fix this display glitch. So, in the worst case, this is a minor inconvenience during the testing stage, before integration in Mozilla, and it only requires a couple of clicks more to view certain messages, if we want to view them immediately after the deletion of attachments, and we are running Mozilla and the script at the same time. Anyway, Mozilla corrects the display very fast. In my opinion, replacing the attachments with maybe thousands of blank lines would be an ugly solution for the mailboxes and for people who will want to edit them, only to fix that little display curiosity before the (let's hope so) possible integration of a "delete attachment" function in Mozilla. :-)
re: Comment 128 > Anyway, after for example clicking a moment on another mailbox, like Inbox, and then coming back to the test mailbox, everithing is OK, Mozilla has managed to find the messages in the now smaller mailbox, and the display problem doesn't appear again. Unless we do again the same procedure during the deletion of attachments, naturally. It sounds like Mozilla is able to repair the index files on-the-fly, as if it partly or entirely recreates them everytime the user selects to view one of the mailboxes in Mozilla. I was thinking it was largely static, and only modified when a message is added, deleted, or moved, etc. But if it's much more dynamic and self-repairing, the index files may pose little or no problem for deleting attachments. That'd be one less layer of complexity to deal with :-) > I think we need integration in Mozilla to fix this display glitch. Fixing the display glitch from within Mozilla may be fairly easy, like simply requesting that Mozilla reload the mailbox window. It's pretty easy to ask Mozilla to reload the message window, for instance. I imagine one or the other would be needed, at the very least. The basic UI (the main menu, plus the context menu for the attachments list) shouldn't be much trouble. When I worked on this bug some last summer, it was reasonably easy to figure out how to add the "delete" option to the UI; it was just a matter of modeling it after the existing code for the "save" option. (btw, I still have those small source code changes for the UI (a little JavaScript, C++, and XUL) in case they turn out to be useful later on). Looking down the road a bit, at the risk of getting too far ahead of things, I'd recommend against any special UI-functionality for Mozilla to differentiate between regular attachments and the remains of deleted attachments, at least initially. It's not completely essential, and it's important to keep the initial effort as simple and as minimal as possible. Even in the long run, I'd be in favor of little or no special UI-functionality of this sort (which could be very awkward to add, and might just confuse most users). It might be reasonable though to have the Perl script itself perform a check to see if the attachment is the remains of a previously deleted attachment, and if so to leave the attachment as is. I'd probably also recommend against offering an "undo" option, initially anyways. It's likely to be one of the first concerns raised, but I think keeping the initial effort simple needs to be a high priority. I expect that in the long run, there will have to be some type of an "undo" operation available (whether or not an "undo" operation is required for a patch to be accepted). It might be adequate in the short term to just put up a confirmation window. > In my opinion, replacing the attachments with maybe thousands of blank lines would be an ugly solution for the mailboxes and for people who will want to edit them, only to fix that little display curiosity before the (let's hope so) possible integration of a "delete attachment" function in Mozilla. :-) Yeah, I don't much like the thought of leaving dead space behind, either whatever arbitrary data that was already there or filling in the dead space with blank spaces or carriage returns. Aside from making things awkward for users who like to edit the mailboxes by hand, it seems like it'd be asking for trouble; there might be occasions would it would pose a problem, like when the user selects to compact the folder, or when someone imports a mailbox into another e-mail client, for instance. To put it another way, it'd be like leaving a mess for someone else to clean up; best to avoid leaving a mess if possible. re: Comment 124 > Content-Type: text/html; charset="us-ascii" > Content-transfer-encoding: 7bit > > <html><body><center> > Deleted attachment:<br> > one-megabyte-photo.jpg<br> > (image/jpeg) > </center></body></html> I'd suggest perhaps using just plain text (rather than HTML) for the text of the attachment. In this case the richer format of HTML might not offer an advantage. And if it's in plain text, then there will likely be a wider number of e-mail clients that can display it (whenever a user migrates to a different e-mail client).
But you realize that a Perl script won't make it into Mozilla (users usually don't even have Perl installed, for a start), so all that talk about the Perl script is a bit offtopic here.
Re: comment 130 > But you realize that a Perl script won't make it into Mozilla (...) Hence the name of "experimental" script, to have a starting point so that everyone may add improvements or better solutions. Now that we have the basic functionality working, unless other better patchs appear, I think the next step would be to translate it into C++ and improve the integration into the Mozilla's way of working in order to try possible patches. C++ and Perl are of course among the most widely used languages, so we thought that possibly someone who knows both may do the translation. There are also comments in every line of the script to facilitate it. Also I'm reviewing the details of a second Perl version incorporating all Matt's suggestions, and extra safety, even redundant, to carefully protect the mailbox data making sure that strictly only the specific attachment can be deleted, even in the cases of different or erroneous mbox formats. Although this Perl script is a start for a possible Mozilla's C++ patch, for the second version I'm following the Bugzilla Developers' Guide, given that Bugzilla itself is developed in Perl. :-) Bugzilla Developers' Guide http://www.mozilla.org/projects/bugzilla/developerguide.html If someone wishes to run Perl scripts on almost any operating system (Windows, Mac, Unix, Linux, etc.), there is a long directory of different possibilities at: CPAN: Perl Ports (Binary Distributions) http://www.cpan.org/ports
While your efforts are well-intended, a Mozilla implementation will have to be tightly integrated into the existing Mozilla code, so I don't think that a Perl script is all that much of a help to get this bug fixed. I think we all know now more or less what has to be done in general, the problem is how to integrate it into Mozilla and esp. to have somebody actually do it. Before we don't have the latter, I don't see anything that could be done.
To answer questions about IMAP and labeling: I use IMAP access from at least two computers (home and work) and labeling is maintained between them so the labeling info _cannot_ be in the .msf files as they are not shared between the computers. It must be something in the x-mozilla info (much as the delete state, and other state info), or another x- header. My experience with deleting .msf files (and I've done it frequently in troubleshooting is that they can be deleted with impunity, although I don't think I've ever tried while Mozilla is using it's mail file as the "current" folder. RE: comment 132: I disagree that this isn't of much help. The perl script is a useful tool for defining and testing an algorithm for deleting attachments, even if it is not being used verbatum in the final coded solution.
Just in case it can be of any usefulness to facilitate the preparation of a C++ patch, this is the second and I hope last version of the Perl script, introducing full functionality (permanent attachment deletion), extra safety, and detailed information in the text of the script. The contents are: 1. Notes 2. Data input and use instructions 3. Optional command line arguments 4. Troubleshooting for the testing stage 5. Integration of a "delete attachment" function into Mozilla 6. Source code To test attachment deletion, it is suggested to create in Mozilla Mail a new mailbox called for example "Detach-test" (with "New Folder..."). Any messages with attachments to delete can be copied (rather than moved when testing) into this experimental folder. I think it's time for somebody proficient in C++ to try to go to the next step, if it's possible, with similar or different programming procedures. :-) Re: comment 133 > It must be something in the x-mozilla info (...) Thank you for this useful suggestion. Doing tests and changing labels, it seems that you are right and the labelling information is preserved in the message headers X-Mozilla-Status and X-Mozilla-Status2, in the mailbox main file. So probably the deletion of *.msf files is safe. Naturally, if someone finds that this is different, please say us. Re: comment 132 Well, I agree that this Perl script is not, of course, the definitive solution, but I think that we have just tried to advance a step in that direction, although the final solution can be very different from the initial. I also think that your point is the important one: integration into Mozilla, but something have to be done. Possibly step by step, trying temporary solutions, we can reach an integrated solution gradually. From the fifth point of the documentation of this Perl script, I've included what I've found about this most important side of this problem: 5. Integration of a "delete attachment" function into Mozilla Several possibilities: A) Translation of the Perl subroutine "sub delete_attachment" of this script into a C++ function, adjusting it to be used as a Mozilla patch. (For instance without the current test messages of the script like "attachment found", etc.). This translation into C++ would be an excellent solution at this stage. From this working point as a C++ patch, better integration into the Mozilla source code can be implemented gradually. B) Before the translation can be done, a temporary solution could be to embed the Perl subroutine into a C++ function, for example with the use of perl_call_argv or other perl_call_* functions, available in Perl for C and I think also for C++. Documents on this matter: perlembed - How to embed perl in your C program http://www.perl.com/doc/manual/html/pod/perlembed.html perlcall - Perl calling conventions from C http://www.perl.com/doc/manual/html/pod/perlcall.html C) An easy procedure is to convert the perl script to an *.exe file, and use it with command line arguments, maybe from Mozilla, with an utility like Perl2Exe. It converts for example this Perl script from "delete-attachment.pl" into "delete-attachment.exe", file executable without Perl installed. Perl is only required at the moment of the conversion into *.exe. (Perl2Exe and Perl itself, as IndigoPerl, are both available at http://www.indigostar.com). D) With this script working as a temporary solution, other ways can be researched for a greater integration of a "delete attachment" function into Mozilla, like adapting some of the Drafts procedures. This can take time (mimedrft.cpp has 2148 lines of code currently). E) Other promising possibility would be to look into the way that Mozilla uses already to keep the labelling information in message headers (X-Mozilla-Status, X-Mozilla-Status2), modifying the main file of the mailbox. In my opinion, probably the complete solution will be related to this mailbox modification already made by Mozilla, perhaps mixing it with the attachment deletion procedure of this script or using another more integrated way. Therefore, this script is just a temporary step towards a more complete and integrated solution to delete and/or file attachments.
Attachment #112499 - Attachment is obsolete: true
Comment #130 From Ben Bucksch 2003-01-25 17:47 ------- > But you realize that a Perl script won't make it into Mozilla (users usually don't even have Perl installed, for a start), so all that talk about the Perl script is a bit offtopic here. I was hoping that maybe Mozilla had a built-in Perl interpreter, similar to how it supports JavaScript, for instance. Are you certain that Perl scripts, at least a limited form of them, can't be included? I found well over 300 Perl scripts among the source files, even a build of Mozilla contained over 150 Perl scripts. And I found a mention in the Mozilla documentation about things like Perl XPCOM and Perl Connect. Does any usage of Perl in Mozilla require that the user have a separate stand-alone Perl interpreter? Are the Perl scripts perhaps only used for developer tasks? If it seems like I'm totally clueless about this, that's about right hehe :-) I've generally found it difficult to find much documentation about Mozilla (like about support for Perl, the format of the .msf files, and where the data structures for the contents of a message are stored). It seems like 95% of the documentation only exists in bits and pieces in different people's brains. As a side note, I've been starting to wonder lately if it's more than just a lack of interest in writing documentation, on the part of the programmers - if there may be lingering habits from past programming jobs, wherein lack of internal documentation equals higher job security. Just a random thought. Comment #132 From Ben Bucksch 2003-01-25 20:29 ------- > While your efforts are well-intended, a Mozilla implementation will have to be tightly integrated into the existing Mozilla code, so I don't think that a Perl script is all that much of a help to get this bug fixed. I think we all know now more or less what has to be done in general, the problem is how to integrate it into Mozilla and esp. to have somebody actually do it. My gut feeling is that "tightly integrated", in this case, might only be possible for someone with a good deal of experience with the relevant source code. And based on the past 4-year history of this bug, if we wait until such a person shows up, we may all be too old to even read our e-mails :-) I only see two ways for forward progress to be possible: divine intervention by a Mozilla hacker from the planet Krypton ;-) or rigging something up that interacts with the existing code base as little as possible, as at least a short-term solution. I think there's a lot of potential benefit from the current effort of putting together a Perl script. Even if all that comes of it is a separate, stand-alone utility, that's still a big improvement over having to delete attachments by hand. If using a Perl script isn't an option in Mozilla, it could be used a basis for writing some C++ code to perform the same functionality. And just having a test suite to be able to see some actual sample "before" and "after" data could be very useful too. At this point, I'd just like to see any useable solution for deleting attachments, whether it's a part of Mozilla or a stand-alone utility. re: Comment 134 > I think it's time for somebody proficient in C++ to try to go to the next step, if it's possible, with similar or different programming procedures. If it's helpful to know, I have C++ experience, but over the past half year I found the scale and complexity of this bug and of the code base to be too much to contend with (way beyond my means). Tightly integrating a patch for this into Mozilla, for instance, would be 10 to 100 times more of a task than I could do. However, if it's possible to do this without having to deal with the existing code base much, and if it's relatively simple functionality, I might (very iffy, but maybe) be able to help out (not play a lead role but help out) with writing some C++ and making some simple UI changes in Mozilla. I've been curious to learn Perl anyways, and this might be a good excuse to get more familiar with it.
re: Comment 134 > Created an attachment (id=112717) > Experimental Perl script to delete attachments in Mozilla mailboxes (v2) I'm not sure if it's worth worrying about, but consider the odd case of where someone receives a message that has two or more attachments with the same name. It's possible to create such a message in Mozilla, and it's most likely possible in a number of other e-mail clients as well. Anyways, the point is, the combination of message-id and attachment-name might not always uniquely identify the attachment in question. Again, I'm not sure if that's worth worrying about, but I thought I'd point it out. One option is to pass in the message-id and the ordinal number of the attachment (i.e. delete the first attachment, or the second one, or the fifth one). For manual usage of a stand-alone utility, it's probably safer to use the attachment name. But for something that's used by Mozilla, it might be slightly safer to use the ordinal number (or something comparable). Just a minor point.
mozilla's build system uses perl. mozilla.org has other products that use perl. mozilla the web browser/mail client does not natively use perl while running. there are xpcom bindings for perl and python and you may *NOT* require them if you want mozilla.org to include this feature as part of mailnews. the idea of prototyping a delete algorithm in perl is interesting, but i'm not sure that it is useful. the problem that needs to be solved for this bug is the correct way to implement deletion (i.e. the algorithm), not simply a way to do it. writing the code to delete an attachment is obviously not impossible and certainly can be done.
Thanks for the sincerity of the posts and mails with a variety of different opinions. I think all are interesting and useful. But now it's the time for C++ and other programmers, if they wish. Although in my opinion the version 2 of the Perl subroutine, embedded in a C++ function with perl_call_argv, etc. (see point 5-B in the script), would work well already as a temporary solution for a C++ patch, on the other hand, for those interested in start preparing now a completely integrated C++ solution (without any Perl script), I would suggest again what I said in the point 5-E: Mozilla has already a function to modify any mailbox, not only Drafts. I think the final and totally integrated solution will come some day from this way. For example, to modify the "X-Mozilla-Status" and "X-Mozilla-Status2" headers for labelling in already stored mail, I think Mozilla uses "WriteLineToMailbox", etc. Does someone know how this works exactly? Thanks. Re: comment 135 > I've been curious to learn Perl anyways, and this might be a good excuse to get more familiar with it. Well, I've just bought a couple of C++ books, including Stroustrup's. It seems that C++ is at least two times harder than Perl. :-)
Attachment #112378 - Attachment mime type: application/octet-stream → text/plain
About the attached document, I've been looking extensively into the Mozilla source code, and this is a document with detailed information to facilitate the work of any programmers interested in writing the necessary C++ functions for a patch to fix this bug or enhancement. As it's known, currently this bug 2920 is the 3rd most voted bug in Mozilla MailNews, and the 10th in all Mozilla. A summary of the table of contents: 1. Introduction 2. Labels for the user interface (dtd, properties files) 3. User interface (XUL language) 4. JavaScript, between the user interface and the C++ functions 5. Interface nsIMessenger (idl file) 6. The work to be done: Three C++ functions (nsMessenger::DeleteAttachment...) 7. Safe attachment deletion 8. Possible ideas for nsMessenger::DeleteAttachment 9. Mozilla coding: Unicode strings, file input/output 10. Useful links
*** Bug 195145 has been marked as a duplicate of this bug. ***
Me too want this feature
Steve Augart asked me to reassign this to him. Hack away ;-)
Assignee: nobody → steve+bugzilla
One request if this bug is fixed -- put a notation of some sort along the lines: Attachment "name of attachment" (Mime/Type) deleted on 4/29/2002 4:30:20 I really miss the features I used to be able to script in Outlook Express/Macintosh...
I agree with Comment #143. All message modifications should be documented.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3.1) Gecko/20030425 Perhaps a fly in the ointment: when deleting the attachment, the name of the erstwhile attachment should obviously be entered in the message as a trace. BUT, what about when the attachement is moved, or has already been "Saved As..." somewhere in the local filesystem? Is it possible/desirable to implement a notation that record not only the file name, but its new location? In unix, could a symbolic link or something be placed in the message body?
1) Why does everyone here discuss about advanced features when we don't even offer the basic functionality? Make it run, then make it better I say 2) A link to the file system wouldn't be worth 2c, once the file is moved or deleted there you can't trace it anyway. If you leave the file name and size info, you could search for it, that might make sense.
The MD5 checksum of the deleted file could also be useful. Sometimes name and size is not enough to tell which file was actually there. RFC2017 (Definition of the URL MIME External-Body Access-Type http://www.faqs.org/rfcs/rfc2017.html) provides a way to add Content-MD5 header. It also provides a way to remember where the file was saved (file: scheme URL).
This may be inaccurate (I heard it third hand, and haven't seen the functionality for myself). However, I understand that Netscape 7.02 already has the ability to delete mail attachments. I'll check up on this to see if I have accurate info.
Correct, your information is inaccurate. What it allows you to do is delete attachments from within the compose window, not the view message window.
*** Bug 209876 has been marked as a duplicate of this bug. ***
I made contact with the origin of my comments in Comment #148. And, as others have already said, I was rather inaccurate. Sorry for the spam.
Another **** hit the fan. I installed Enigmail, works fine, but there's no option to save the unencrypted mail. Am I supposed to remember all my, employers and customers passwords for whole of my life? I don't know what's the philosophy behind protecting email in Mozilla, is it protecting my email from me myself? This is my computer, I can put some garbage in any file I want to and this is not going to change. I cannot use anything on my computer as a proof to anything, unless properly digitally signed and Mozilla's stance will not change that fact. Outlook users can change their received email as they want to, and I've never seen anybody complaining, so what's the issue here if security is not? Design maybe? Why didn't Mozilla at least use some light embedded database for it's storage? I'm sorry I cannot help, but at least you get some whining to motivate those who can... Regards, Karel Miklav
*** Bug 212038 has been marked as a duplicate of this bug. ***
I just recently switched from a Unix platform to Windows and have started using Mozilla, after 13 years of using Emacs as my mail tool. A couple years ago I hacked the VM code to support deletion of attachments as a part of the save attachment operation. It replaced the mime body of the attachment with a text/plain component whose content was the location of the saved file, like so: --------------030802010002040100090704 Content-Type: text/plain; charset=us-ascii << /home/sjameson/docs/MonthlyReports/June_03.xls >> --------------030802010002040100090704-- This worked very well for me, since having saved the file I never need to retain it in the mail archive, but often wish to know where the file is saved. If I delete or move the file, too bad for me. I would recommend that the deletion occur 1 of 2 ways: -- As a one-time action ("Delete Attachment" option on right click menu) -- As a configurable behavior every time you save an attachment
*** Bug 214776 has been marked as a duplicate of this bug. ***
*** Bug 217325 has been marked as a duplicate of this bug. ***
I couldn't wait for the final solution, so I wrote a program to remove attachments in my own mail. The program will read an Mbox file (e.g. Inbox), look for interesting messages (multipart/mixed, related, report), and replace every attachment with a text/plain that contains the name of the file that was there. The program doesn't change the original file but writes its output to a new file (e.g. Inbox_Small). The user can inspect the new file with Mozilla before deciding what to do: either delete the attachments permanently by deleting the original file and renaming the new file to the old name, or keep all attachments by deleting the new file. Before running the program (or at least before deleting the original file) the user must save all interesting attachments as files in the file system. The process can of course be repeated, e.g. the new Inbox will need another treatment as time goes by and it collects new messages with attachments. The program will recognize the old attachment replacements and leave them untouched on the new run. I've tested the program on various message and header formats, but I haven't studied the RFCs, so there may still be some work to do. Some virus messages turned out to have very strange headers, and I didn't have enough time to investigate them. The user should delete those messages, anyway. If this forum is interested I can submit the code, but I don't know how to do it. I wrote the program in C++ as a console application using the Microsoft .Net IDE, but without any MS-specific features in the code (or at least I think so). In fact it was rather an exercise in using the C++ Standard Library. There is certainly room for improvement. Thanks to Juan M. Gonzalez, whose Perl script partly inspired me to take on this job. Note, however, that my approach is very brutal compared to his. Lars Staurset
Regarding comment 157 -- You seem to be on the right path with your script/program, but I beLIEve it may work a little better if it moved the attachments to seperate directory (similar to the behaviour found in Eudora 4 & 5) called attachments in the users profile (ie: /home/profilename or \document & settings\profilename\application data\mozilla)
#157 -- Very interested to see the source and I can help you improve it if need be. My mail is >700 mb and I need to clean up the attachments somehow.
> if it moved the attachments to seperate directory [...] in the users profile I disagree. IMO the profile is not a place users should have to go into an muck around looking for files. The files should ideally go to a user-selected location - even better, if they were asked the preferred location on every detach.
Attached file C++ source of attachment-removing program (obsolete) (deleted) —
Filter.zip contains the source code of my Filter program (I suppose this is the right way to submit it). I designed it for several filter-like commands, hence the name. So far there are two: /a for removing e-mail attachments, /c for copy file. The latter is only useful as a kind of command template. /h displays a help text. I wrote this program for my colleagues and myself, and I'm not sure of the consequences of releasing the code. If it is useful to the Mozilla community, fine. Feel free to improve it. If commercial use becomes an issue, I suppose I have certain rights. On the other hand I don't want to be sued by some user whose mail gets lost (mine is OK so far). Can anybody give me a clue as to what happens?
adding me to the list...
Did everybody on the copy list vote for this bug? (Click on "My Votes" on the bottom of the bug page.) By the way: Where can the vote results be seen?
Flags: blocking1.5+
if you don't understand flags, then please don't touch them
Flags: blocking1.5+
*** Bug 224712 has been marked as a duplicate of this bug. ***
I'm doing this enhancement for my final year Computer Science project. At this stage, I'm still doing some reading on Mozilla applications development and experimenting with the source code.
Re comment 166: great to hear. My advice: get something working before you get into arguments about how exactly it should be done. That can always be changed. And ask questions if you need help.
*** Bug 226725 has been marked as a duplicate of this bug. ***
I'm coming in after about 5 years of discussion has taken place. Sounds like someone is going to tackle this (good luck!). What I'd like to see is pretty simple: 1. An option of removing attachments from the copy kept of a mail message sent out (I phrase it this way as I hope someday message copies are filtered so that don't all go into the Sent folder). 2. The ability to delete an attachment in any e-mail. After trying to read the long discussion, I'm not sure if these two items are covered or no. Good luck to whoever tackles this!
Re comment #161: I have corrected a bug and a few glitches in my Filter program. I'll submit new code if requested (is anybody out there using the program?).
If you could manage to package it as a thunderbird extension I'd be happy to try it
I'll try it as soon as I can (currently buries with work), whether or not you package it as a Thunderbird extension.
Im sure many of use will try it.
re comment 170, comment 161: it seems your program is a standalone program. is this correct? if so, and someone could find a way to filter a mailbox or message through this/any program from Mozilla (see bug 18211), even if the results are appended to a new folder (may be easier), it would be very helpful
@Lars Staurset: i'm using your filter app. nice program and compiles without errors on win32/gcc. thx it would be helpfull if you could include a small readme/help/guide for n00bs. not every body is in common with mozilla/unix mailbox-files... uhm, and yes, i definitly require the new version of your app ;) @wbayer: package would be awesome @David Fraser i fully agree
I couldn't file a Makefile in your zip distribution. Can you please include it?
In summary : there apparently exists a standalone program that solves the problems that this bug is about. Or at least, that is the message I get from comment #175. So, is it possible for that code to become part of Mozilla/Thunderbird? (That question is more directed to the author of the program). Or, maybe as an "official" extension?
C++ source of standalone program to remove attachments from mbox files (Mozilla folders)
Attachment #132137 - Attachment is obsolete: true
Forget about comment #178. Here is what I meant to say: Re comment 171 and others: Sorry for this late response. You're right, Filter is a standalone program. It removes all attachments from an mbox file, i.e. a Mozilla folder. See comment #161 for some details. I wish somebody would include a similar functionality in Mozilla, but I'm not familiar with Mozilla development myself. I don't know how to make a Thunderbird. Comment #166 indicates that something is going to happen in Mozilla, but in the meantime a standalone program is better than nothing. I've now submitted the C++ code of verson 1.02. The most important change since 1.00 is a bug correction. The bug could give an obscure error message in some circumstances if a message contained a line with two hyphens (--) and nothing else. There is still room for improvement. I didn't include a makefile. In fact, I don't have any, since I use the Microsoft IDE. If somebody wants my Visual Studio project file, or even the ready-to-use exe file for Win32, I can provide it, but I don't know whether platform-dependent items are welcome here. Anyway, this is a simple program, and any of you can easily create a makefile or similar for your favourite platform. A few words on how to use Filter with Windows (I suppose it will be similar on other platforms): - Build filter.exe. - Copy filter.exe to a folder that the Path environment variable points to. - Open a command prompt window. - Type filter /h at any time to display a short help text. - Navigate to the mail folder, e.g. C:\Mail\Local Folders. - Type something like this: filter /a Inbox InboxNew (replace "Inbox" with your own folder name) - When finished: (re)start Mozilla and inspect InboxNew. - To complete the task I prefer to exit Mozilla and launch Windows Explorer: - - To delete attachments permanently: delete files Inbox, Inbox.msf, and InboxNew.msf. Rename InboxNew to Inbox. Mozilla will later rebuild Inbox.msf. - - To undo deletion and keep attachments: delete files InboxNew and InboxNew.msf. Before processing a mail folder, make sure you have saved all important attachments as normal files. (I'll add a readme with these tips next time.) When I started work on Filter I planned to put several filter-like commands in it, hence the name. So far it has a copy command (/c) which isn't useful but meant as a template for new commands.
*** Bug 228789 has been marked as a duplicate of this bug. ***
*** Bug 228858 has been marked as a duplicate of this bug. ***
*** Bug 229954 has been marked as a duplicate of this bug. ***
*** Bug 230880 has been marked as a duplicate of this bug. ***
Adding myself to the list. I hope this functionality will be added. There are add-ons for doing this in Outlook but I don't want to use Outlook for obvious reasons.
*** Bug 234884 has been marked as a duplicate of this bug. ***
Too many dupes probably hint that this bug is too hard to find. Appending "(remove/strip attached files)" in hope to minimize this problem. Prog.
Summary: Delete attachment from msg in folder → Delete attachment from msg in folder (remove/strip attached files)
Can "JSLib" at mozdev.org ( http://jslib.mozdev.org/ ) be used for batch type utilty? Since this is an extention of Mozilla, external script languages or OS dependent programs will not be required in reading and writing/updating Mozilla's mail file. If JSLib can be used, "Compact this folder" after run of JavaScript with JSLib under Mozilla can be a function or extention to remove attachment data from mail. Does someone know about or have experience on JSLib?
Why hasn't this been implemented? Delete attachment and add commented at end of email body that attachment X was deleted. As more users in corporate environments move to imap this is going to be a needed function to reduce the server disk space requirements. Regards, Dan
> Why hasn't this been implemented? Because nobody has implemented it. Are you in a corporate environment? Why not pay a programmer to implement this feature? Or implement it by yourself. Or let it do your company's IT department. Regards, Chris
This is not a flame : I agree, Dan's message was a bit unpleasant, but your answer is no way better. I don't think such a way of answering "if you need it do it yourself" is likely to increase mozilla's acceptance. What's the point in letting users requesting enhancements, if the answer they get means "do it yourself" ? With all your respect, such things should not be written, one should answer something like "Dan, please consider that mozilla is developped on a voluntary basis, therefore the feature you asked for is currently being discussed, and may be implemented as soon as workforce is found. You could be one of this workforce ;-)" (please forgive the english)
Arnaud, you're right. I apologize for my unhelpful reply. Chris
Arnaud, Perhaps it wasn't as elequently written, but it was technically correct. Mozilla, as any program has limited resources. Only so many people, and a large sum of bugs. Do a little query, and you'll end up with over a 1MB list of bugs. In fact, that will only be a fraction of the bugs. Suggestions are obviously more than welcome. In fact, they are strongly encouraged. If it were up to me, it would be mandatory as part of the license to use the software ;-). I'm big on customer feedback. But implementation comes down to resources. There are bigger fish to fry. The attachments technically work, and there is no dataloss, and it's not a showstopper. Hence it's not a high priority. Anyone who is really eager to fix this, could either contribute a patch, continue to vote and make their point heard. Or perhaps setup a purse for this bug, in hopes someone will step in and patch it. I'm personally not familiar enough with the MailDB and mail handling to even attempt such a task. There are only so many with the knowledge needed to take care of this. This is a somewhat complex bug to fix. Take a look at the early comments and see what's involved. This will take more than a few minutes to do. Please don't underestimate this as Developers blowing off ideas. The idea is here and written. It's just not a high priority, as there are other things of greater importance on the road to 1.0. For example, we still don't have all the functionality that the AppSuite had, regarding PalmSync not being reliable, no installer etc. Things most likely will happen in time. There's just to little resources, and way to many bugs ;-).
Chris Brandstetter, your suggestion was actually quite to the point. Bug 161249, for example, just received a patch, the day after a bounty was offered to fix it. I expect the same to happen here. All it takes is someone who's willing to put their money where their mouth is. Prog.
> Chris Brandstetter, your suggestion was actually quite to the point. Bug 161249, > for example, just received a patch, the day after a bounty was offered to fix it. Prog, that isn't a fair comparison. Early on, the developers rejected this bug because it arguably violated RFCs as you're not supposed to edit messages after delivery. People have submitted approaches and partial attempts to address this bug, and none have been accepted. I think there's lingering apprehension towards fixing this because the patch would get rejected for the original disinterest of the developers.
Um. Were not using a perl script to fix this bug. That's not the right solution. This needs to be done the correct way.
If it violates the RFCs, then the RFC that applies to this should be changed. It very easy to change an email body by opening it in a simple text editor. I would be willing to seek out a programmer at UW-Milwaukee or MSOE to implement this feature, but if the Gods that be won't include it, what's the point? I think my original arguement for this feature stands. We are moving to a more email dependent corporate environment and this means the mail has to held on the server and accessed via imap or webmail because it its very important to the corporation not to lose it. Especially for companies that want to ISO certified. Like I said I am sure I could find a UW-Milwaukee or MSOE programmer to do this but if it won't be accepted, I won't even bother attempting. I sincerely that not implementing this feature will push Mozilla/Netscape further out of the corporate environment and what people use at work, they usually use at home. Is there an hope. Maybe a Mozilla developer could chime in with some guidance. Kind Regards to All, Dan
Dan - If the Mozilla foundation doesn't want to include this feature, make it an extension. BTW, does anyone know if Thunderbird has plans regarding this feature?
Please read my comment 101. Since then, nothing has really changed. A good fix (in line with Mozilla architecture and coding practices) would most likely be accepted (sooner or later :/ ). > I don't think such a way of answering "if you need it > do it yourself" is likely to increase mozilla's acceptance. Please read the Bugzilla Etiquette <http://bugzilla.mozilla.org/page.cgi?id=etiquette.html>. > should answer something like > "the feature you asked for is currently being discussed" But that would be a lie. Nobody is working on this or planning to. Many people (incl. me) agree this is important, yet nobody was putting up the money or work necessary. Without this, more comments are harmful.
Anyone can make an extension. There's nothing holding someone back. There are issues regarding The RFC's. Mozilla's position typically has been to never break standards. And this is one of these cases. RFC states: ------------------------------------ 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers. ------------------------------------ This does sound like transit, rather than storage as noted in comment 27. BUT... The mbox standard is designed so that a message is stored so that it stays rather original. For example, it contains full headers. So it can be traced. By keeping the same message-id, we are essentially forging the email, as it's no longer as it originally was. By considering it a new message, and using a new message-id, we are essentially straying from the mbox standard, which is pretty much universally accepted. At a bare minimum, all emails which modified should note that they were modified. There also rises an issue of business ethics when used in the workplace. Is it OK to store modified emails, not the same as they were recieved, and call them original? IIRC, the answer is a clear no. We would be including the same headers, making it appear as if the sender actually sent that data... when in fact, they sent that data AND something else. My general feeling, after doing a little re-reading on RFC822 (the only RFC I know the number off the top of my head), I'm generally against this enhancement being included, unless all the above can be satisfied. From a pure business perspective. I don't think many businesses could ethically implement a mozilla client that has the ability to manipulate [forge] communications records. It's one thing when the user does it themselves by opening the file in notepad. But it's another when the mail client does it for them. If I were a company, I would rather buy the extra drive space (face it, storage is not nearly as expensive as it used to be, and it's getting cheaper). I wouldn't want to deal with the ethics of this if I could avoid it. Think Enron. Delete the attachments with the real accounting data. But keep the headers, so that the sender looks like they legitimately sent the email like that, and didn't attach real data. That's clearly an ethics issue. I'd seriously question the ethics these days from any IT professional who would deploy such a feature in a corporate environment. A few years ago, such a sinareo was unthinkable. Now... well, any professional would expect it. Modifying a communications record, while making it appear as if it were original is not ethical by any standard. Especially when your modifying the bulk of message (attachment), not just an envelope. Regarding comment 197, if it was in mailnews, it would most likely appear in Thunderbird. I don't see why not. Bottom line: If anything, I would urge this to become a mozdev extension. So that ones who wish to deploy this may do so, as there is clearly an audience. But I'd question if this is the right thing for the Mozilla distro to include by default. Another option is a third party application. Even an open source application. There's source attached for doing it. I admit my bias. I'm a purist. When a standard is expected to act in a specified way, I always believe in following it. Not reinventing it. You don't change a standard, if anything, you write a new standard. And if you go about that, you should make sure it encompases all the previous had, then add. I just don't really see how to go about doing this, without breaking understood standards, and opening up a pandora's box. Businesses are looking for ways to prevent an Enron with electornic data. Not cause one. It's to our advantage to offer a strong framework to build from.
Robert, please don't reopen that discussion and make people outraged needlessly - it has been discussed at length in the beginning of this bug, and we (even timeless, who originally voiced this concern) agreed that replacing the attachment with a computer-readable note about the deleted attachment would be OK. In fact, even a standard exists for the format, see e.g. comment 74 and comment 103.
So, it can be implementented as an extension? Would this be like Calendar? Please explain because if it can easily be re-installed to new versions than I will sponsor this as a project for a UW-Milwaukee student or MSOE student. I will personally put in $1K if this is doable or maybe the student can use it as a project to satify a requirement. Please enlighten me on extensions. Thx, Dan
I think doing it as extension without any app changes would involve major difficulties and would have to be done differently than in the app, compare the problems Enigmail faced. But I don't think that's necessary. I personally think that it's something most users will want and it should thus be directly in the app, but I'm not one of the owners, just a former contributor. If that's a concern, please talk with Seth Spitzer or mscott or David Bienvenu, who own Mailnews these days (I think), I'm sure they'd be glad to give a definitive answer before implementation, if somebody is willing to actually do it. They could maybe also give more code hints, apart from what has already been said here towards the beginning. (With MSOE, I guess you mean "Milwaukee School of Engineering", in case anybody else wonders - I think of Microsoft Outlook Express.)
Such a shame that the possible $1000 pledge is only for a small group of students. If it an actual general pledge then I'm sure that you would find takers for it, myself included.
If you (brofield@jellycan.com) can code this and it will be accepted into the standard code base, then I will forward you half the money and the rest when you have working code that can be included in a Mozilla release. But it first has to be approved by the Mozilla overseers. Dan
I would like to find someone else to take this bug as his or her assignment. I accepted responsibility for it in a fit of optimism (and with plenty of spare time), only to suddenly get an intense full-time consulting contract. I haven't had the time I thought I would to work with it, so I'd like to pass it on to a volunteer who might. Thanks, --Steve "Assigned To:" Augart
Assignee: steve+bugzilla → nobody
FYI Lotus Notes (the official IBM corporate email program; they made me learn it :)) has a feature for deleting attachments and leaving a note in their place.
Alias: delete-attachment
Assignee: nobody → brofield
Perhaps this feature could be enabled by an option (and if it's decided that it should be "off" by default, then so be it). (In reply to comment #199) > Think Enron. [...] > I'd seriously question the ethics these days from any IT professional who would > deploy such a feature in a corporate environment. I understand this, but I'm not running Enron - just a small business. I don't need an audit trail, I need the sanity of being able to delete unwanted attachments. Corporations hire a lot of people, but the rest of us outnumber them (yes, we do).
There seems to be a lot of demand for this functionality. To a Mozilla steerer, would the code be accepted if it had to be "turned on" via a preference setting? I certainly don't want the codebase to fork into another maybe called MailWebXpress. Someone with authority please comment as there is a willing coder. Dan
(In reply to comment #199) > From a pure business perspective. > I don't think many businesses could ethically implement a mozilla client that > has the ability to manipulate [forge] communications records. It's one thing > when the user does it themselves by opening the file in notepad. But it's > another when the mail client does it for them. Does any business use Outlook? Easy to modify messages there (not only deleting attachments, but even editing text, which I would not ask). Somehow they don't seem too troubled by it. Besides, there is no guarantee that the data has not been manipulated, someone can always modify the files. So Mozilla suggests to guarantee something it can't live up to - provide uncorrupted communication data. (Putting aside the fact that I can still delete whole messages, which in most cases will be just as effective as manipulating them). If a business really cares for the original and unchanged data, it must backup the mails on its mail server, before the user even sees them. To me this seems the only way to get any measure of security in that respect. Bottom line: If Mozilla can't guarantee for unchanged message data (and I say: How could it?) it should not be restricted by such constraints.
(In reply to comment #209) > Does any business use Outlook? Easy to modify messages there (not only deleting > attachments, but even editing text, which I would not ask). > [snipped] I agree, Outlook 2000, XP and 2003 all allow us to remove any attachement. Those who oppose to implement this function in Mozilla should know that people are getting very used to attach whatever in a whole big mail. They just don't care. They won't send the attachments in a separate mail. Or are we supposed to tell them this? "Listen, you're too naughty. I've told you to send me attachment in a separate mail but you never listen. Ok, now I'm going to delete these mails and you're going to send me again" Of course not, especially if they are our friends or customers. Please, be realistic and face the reality!
(In reply to comment #209) > Besides, there is no guarantee that the data has not been manipulated, someone > can always modify the files. So Mozilla suggests to guarantee something it > can't live up to - provide uncorrupted communication data. So because users can edit HTML files to be non-standard or not working at all, Mozilla Composer should create defective HTML code? And because one can infect an application with a virus, Microsoft Visual Studio should have an option to include a virus in the application it is building? (In reply to comment #210) > Those who oppose to implement this function in Mozilla I don't see anybody having this position. Timeless only said the fix should not violate the standards. And there is a promising proposal about replacing attachments by references to them. > people > are getting very used to attach whatever in a whole big mail. They just don't > care. They won't send the attachments in a separate mail. Or are we supposed > to tell them this? You might deliberately send them a few very large attachments to make them learn the hard way. Or - the probably more feasible alternative - as proposed many times, you might edit the mail as new and remove the attachment there. Losing a few original header fields this way might sometimes be bad, but sometimes just irrelevant. E.g. _those_ people who send me such mails are mostly computer newbies where I don't care whether a header field is changed or not. So please don't keep this bug report the discussion forum it already is... That said, I'd certainly welcome a fix for that bug. And I have a proposal that is not new at all, but maybe still 1) the easiest thing to do 2) does not violate the RFC 3) does satisfy the needs of most people commenting here: Just change the Message-ID when removing attachments (and clone everything else). That will break threading for that certain message, but you know this and can decide yourself what you consider more important: disk space or correct references for this mail.
(In reply to comment #211) > So because users can edit HTML files to be non-standard or not working at all, > Mozilla Composer should create defective HTML code? > And because one can infect an application with a virus, Microsoft Visual Studio > should have an option to include a virus in the application it is building? You've taken a valid criticism of the need for RFC compliance at the client storage state and the type of editing, and well, gone a bit overboard. And besides, arguing that Composer creates valid HTML and Microsoft tools do not spread viruses doesn't help your point. :) The recent posting quoting how this feature would fail RFC compliance did not mention which RFC the text was from. The quote was from RFC 822, and this has been superceeded by RFC 2822. Here is what has been added in RFC 2822 about what justifies creating a new message-id (this was discussed earlier in the thread but I feel should be reminded): RFC 2822 3.6.4 Note: There are many instances when messages are "changed", but those changes do not constitute a new instantiation of that message, and therefore the message would not get a new message identifier. For example, when messages are introduced into the transport system, they are often prepended with additional header fields such as trace fields (described in section 3.6.7) and resent fields (described in section 3.6.6). The addition of such header fields does not change the identity of the message and therefore the original "Message-ID:" field is retained. In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message." Does the recipient removing an attachment change the "meaning that the sender wishes to convey"? Maybe, but I would think not. Removing the attachment and replacing it with a placeholder of where the attachment was stored preserves the meaning in my mind.
(In reply to comment #209) I fully agree that the fear of "corrupting" emails by deleting attachments should not be an obstacle to adding that feature (its availability maybe controlled by some preferences setting). The only really secure way of guaranteeing the integrity of an email is a digital signature (which includes hashing over the whole message contents) by the sender. Everything else depends on the goodwill of the mail servers, transmitters, and receivers. In this respect, adding the feature or not doesn't actually make a difference. (In reply to comment #212) > Removing the attachment and replacing it with a placeholder of > where the attachment was stored preserves the meaning in my mind. Yes, because one is aware that a certain chunk of data is missing. This is much better than with deleting the whole email, where no reminder (nor "evidence") is kept that the email once was there.
Fully agree with Comment #212 From Serge Knystautas. Hesitating ad vitam eternam since 1998 (6 -six- years) to wonder if it is appropriate or not to implement this feature sounds strange to me. First in regard to the open source concept of Mozilla, two in regard to the need of this feature by today's users. Because in my mind, open source implementation should approximatively follow users needs and will. Why "today's users"? I was just wondering about the period this thread started. May be in 1998 it wasn't obvious that our mailboxes would be so polluted by spam, virus, trojan, etc, and in 1998 the RFC argument was certainly the best one. But today???? You (Mozilla team or one people in the team?) are permanently arguing about the RFC violation. Micro$oft loves to sue others but provides a deleting attachement feature and does violate RFC, ask the RFC to sue them!!! Eudora does violate RFC too, sue them too!!! May be you will gain money!!! OK, OK, I know: silly argument, bad joke... But simple question: what gain do we have, we users, from this RFC respect? When today's servers directly trash and don't even transmit infected mails without signaling it to the final recipient user!!! How is the interpretation of the RFC in this particular case? Today, the server owner should make a choice between eventually being sued for transmitting viruses by omission, and in an other hand being E-VEN-TU-AL-LY disgraced by the community for not respecting RFC??!!!!! In fact, as end-users we should made the same ethic choice: purge our unwanted attachments just in order to not spread them if we are unfortunately contaminated by a worm/spam virus, or eventually spread infected attachments because in RFC we trust????!!!! [Even if the use of Mozilla is a good prevention for this. But mail isn't the only source of worm infection.] Next to the virus point, there is certainly the most important point: the pragmactic one. If someone mail me an architectural plan joined to a technical explanation in text, and that this mail belongs to an important client/customer thread, what is vital AND LEGAL for me is to keep the text thread, not the 12Mo postscript plan! I "save as" it into another folder, but I HAVE TO keep the text and the thread as is. If I delete the whole mail, I may expose myself to a breach of contract by not complying with the security rules of the company. At the other side, if I don't delete the mail (THE ATTACHMENT), my system administrator (who like to apply rules too!!!), will blame me for keeping piece of junk in my mailbox and will alert me about my quota... I'm for respecting rules, I know Micro$oft doesn't get a sh... of respecting rules. I know that we are living in a period of waste and futility, and that old rules are still good for implementing a serene base of coding... I have the full respect for the good old fashion USENET unix network that bring us our modern internet, but... Hey! Things have changed since 1970... Mail is becoming a crucial ressource for some firms, and for us to work, or may I have missed a point? Mail is a living thing, once received its purpose is not to stay in cryogenic stasis for ever!!! So being able to manipulate it for having a correct, practical and readable workflow is essential. Since 6 years this started, I really don't get what is so blocking to implement this deleting feature. And I may guess that the accelaration of the comments those last days let suppose that the need of this feature is more and more crucial. If it's so hard to implement without breaking major lines in the main code, ok. Again, let be pragmatic: Is there someone of goodwill here able to handle what has been written as an external application and will implement it as a plug-in (like Enigmail or so)? It may be a good start. Sorry for the not always shakespearian english, hope it's still understandable!
Fully agree with Comment #212 From Serge Knystautas. Hesitating ad vitam eternam since 1998 (6 -six- years) to wonder if it is appropriate or not to implement this feature sounds strange to me. First in regard to the open source concept of Mozilla, two in regard to the need of this feature by today's users. Because in my mind, open source implementation should approximatively follow users needs and will. Why "today's users"? I was just wondering about the period this thread started. May be in 1998 it wasn't obvious that our mailboxes would be so polluted by spam, virus, trojan, etc, and in 1998 the RFC argument was certainly the best one. But today???? You (Mozilla team or one people in the team?) are permanently arguing about the RFC violation. Micro$oft loves to sue others but provides a deleting attachement feature and does violate RFC, ask the RFC to sue them!!! Eudora does violate RFC too, sue them too!!! May be you will gain money!!! OK, OK, I know: silly argument, bad joke... But simple question: what gain do we have, we users, from this RFC respect? When today's servers directly trash and don't even transmit infected mails without signaling it to the final recipient user!!! How is the interpretation of the RFC in this particular case? Today, the server owner should make a choice between eventually being sued for transmitting viruses by omission, and in an other hand being E-VEN-TU-AL-LY disgraced by the community for not respecting RFC??!!!!! In fact, as end-users we should made the same ethic choice: purge our unwanted attachments just in order to not spread them if we are unfortunately contaminated by a worm/spam virus, or eventually spread infected attachments because in RFC we trust????!!!! [Even if the use of Mozilla is a good prevention for this. But mail isn't the only source of worm infection.] Next to the virus point, there is certainly the most important point: the pragmactic one. If someone mail me an architectural plan joined to a technical explanation in text, and that this mail belongs to an important client/customer thread, what is vital AND LEGAL for me is to keep the text thread, not the 12Mo postscript plan! I "save as" it into another folder, but I HAVE TO keep the text and the thread as is. If I delete the whole mail, I may expose myself to a breach of contract by not complying with the security rules of the company. At the other side, if I don't delete the mail (THE ATTACHMENT), my system administrator (who like to apply rules too!!!), will blame me for keeping piece of junk in my mailbox and will alert me about my quota... I'm for respecting rules, I know Micro$oft doesn't get a sh... of respecting rules. I know that we are living in a period of waste and futility, and that old rules are still good for implementing a serene base of coding... I have the full respect for the good old fashion USENET unix network that bring us our modern internet, but... Hey! Things have changed since 1970... Mail is becoming a crucial ressource for some firms, and for us to work, or may I have missed a point? Mail is a living thing, once received its purpose is not to stay in cryogenic stasis for ever!!! So being able to manipulate it for having a correct, practical and readable workflow is essential. Since 6 years this started, I really don't get what is so blocking to implement this deleting feature. And I may guess that the accelaration of the comments those last days let suppose that the need of this feature is more and more crucial. If it's so hard to implement without breaking major lines in the main code, ok. Again, let be pragmatic: Is there someone of goodwill here able to handle what has been written as an external application and will implement it as a plug-in (like Enigmail or so)? It may be a good start. Sorry for the not always shakespearian english, hope it's still understandable!
Everyone, I am currently working on this RFE. It will be implemented. I'm aiming for a timescale of within 2 months (I work full-time too). There are no show stoppers, i.e. the Message-ID question will be resolved. The whole violation of RFC argument is done to death and arguing it more will not get anywhere. How the functionality will be delivered (i.e. extension or not) and the finer points of the implementation have yet to be finalized but are under discussion. Please be patient and refrain from posting anymore messages to this already too long bug. If you want to continue discussions, please move them to netscape.public.mozilla.mail-news instead of here. Regards, Brodie
Status: NEW → ASSIGNED
Keywords: helpwanted, mail2mail3
Whiteboard: mbox-violation?[se-radar]
Brodie, thanks for picking this up and thanks to those that provided the monetary incentive. Please make it an extension. If the powers to be want to merge it in the trunk after they resolve the surreal RFC controversy, let them do so at their convenience. In the meanwhile, let's all enjoy the feature as soon as possible.
Brodie, thanks for picking this up and thanks to those that provided the monetary incentive. Please make it an extension. If the powers to be want to merge it in the trunk after they resolve the surreal RFC controversy, let them do so at their convenience. In the meanwhile, let's all enjoy the feature as soon as possible.
*** Bug 235823 has been marked as a duplicate of this bug. ***
Regarding the summary of the last dupe, perhaps we could change *again* this summary to include the words "mail message", instead of just "msg".
Summary: Delete attachment from msg in folder (remove/strip attached files) → Delete attachment from msg in folder (remove/strip attached files from email messages)
Summary: Delete attachment from msg in folder (remove/strip attached files from email messages) → Delete attachment from mail message in folder (remove/strip attached files from email messages)
*** Bug 237972 has been marked as a duplicate of this bug. ***
*** Bug 238555 has been marked as a duplicate of this bug. ***
Just one user's opinion about the priority of bugs: I know that there are many real bugs in Mozilla, but in my normal usage I don't notice them (except some printing issues, but they also occur in Internet Explorer). My main reasons to stay with Outlook at the moment are: 1. I can save & delete my attachments 2. The calendar integration is better (a few mouse-clicks to communicate calendar entries with partners per email) 3. I solved the security problems by denying all TCP requests except port 25,110 for that application (personal firewall) in this priority The other features of Mozilla like Spam-Filter, Tabbed browsing and Side-Bars are nice to have, are very hungry for programmers-resources, but at least for me not very important. I know that opensource projects have very limited resources. So I would suggest the development community to think again about what is the highest priority. The attachment problem isn't solved for years now, unknown priority, unknown perspective for a target milestone. I don't know if my priorities are that of the majority, but I guess most of the people who know Outlook are missing this feature.
I almost completely agree with the last message in the sence that I very much like Mozilla and its mail and use it for years now (starting with Netscape mail) and hardly have anything left to wish, except ... remove/stripping attachments. Please, please, please make my last wishes come true!
Oh sorry, I withdraw the "no perspective". Brodie is working on in. Thanks! I hope you will get much support from the Mozilla development team. Why as extension? This is so important and elementary that it would be appropriate to have it the the core of Thunderbird/Mail.
Silly question: If you sum up all the time we used for discussing this topic in the last 6 years :-) If we used this time for programming instead, would this feature be here already ? I'm not a Mozilla programmer, but I can't believe that this is so terrible complex. Sorry that I can't contribute. I tried to compile Mozilla on Windows with the CYGWIN GCC, didn't work. The build instructions for the Windows/cygwin platform are a bit confusing. Visual Studio is too expensive, GCC works for many other software (even KDE desktop on Windows).
In re. the recent flurry of comments: 1. Enough advocacy already. Yeesh. . . . 2. Were it as simple as some people think -- and were it simply a matter of programming -- , d'you think this would still be open? And, on a slightly different note: 3. This may have already been addressed (I don't recall), but: This bug is most obviously going to be a boon to IMAP users. It will also require that the mailbox be rebuilt (compacted) once the attachment has been removed. Is compaction a) going to be automated? and b) will it refresh the original message on the IMAP server appropriately? 'Nuff said. . . .
(In reply to comment #228) > In re. the recent flurry of comments: > 3. This may have already been addressed (I don't recall), but: This bug is most > obviously going to be a boon to IMAP users. It will also require that the > mailbox be rebuilt (compacted) once the attachment has been removed. Is > compaction a) going to be automated? and b) will it refresh the original message > on the IMAP server appropriately? > > 'Nuff said. . . . Doesn't Outlook just delete the original message with the attachment from the IMAP folder and then copy a new message without the attachment into the IMAP folder. Mozilla already has the ability to do both these operations with the IMAP server.
*** Bug 239169 has been marked as a duplicate of this bug. ***
Hello all, I see this bug has already been assigned... I have been working on this attachment deletion thing (as a 3rd year computer science project) for a few months now. I've got mine mostly working for POP3 mailboxes and local folders, and I'll handle IMAP later (if it's at all possible). It hasn't gone through extensive testing yet and is quite rough... What it does right now: - it deletes only the attachments you select to be deleted - in the Attachments listbox and context menu, in addition to Save, Save All, there is now Delete, Delete All, Detach, Detach All - When the user deletes the attachment, it removes the selected attachment(s) from the listbox and context menu - The user can delete from more than one mailbox or local folder (somewhat working) - It doesn't delete on-the-fly - the actual removal of attachments occur when the user exits Mozilla mail - the mbox file(s) are read and written to at that time. - I've used diff to compare the original mbox files and the ones altered by this add-on: attachment(s) gone, but header information is preserved, and so is the message body - and when the Mail client is started again, the attachments that have been deleted are no longer there Working on: - putting a 'stub' so that the user knows if an attachment was deleted from a message, where it was saved, etc... - IMAP - I realize that this would only be useful to POP3 users out there. - Sorting out a whole lot of minor stuff and bugs... I started out by downloading the 1.4 source code and I didn't use CVS - I just found it easier that way. After reading all the discussions about RFC here, I don't think my way of doing it is strictly legit - I decided to just get on with it anyway, if it never makes it into the general Mozilla source code, I hope somebody will find it useful for his/her own personal use :-) I'm a bit hesitant about releasing the source code here, as my work is yet to be assessed (it's my 3rd year project). Any advice? Anyone here willing to test my Mozilla build? Questions? Comments? Cheers Edna ednafauziah@lycos.com
Hi Edna, I'm sure that you will find a lot of people on this bug who are wanting to test your build of mozilla. If it is at a test stage, why don't you put it on the web somewhere for download and post the link here to try and avoid a whole heap of "yes please" comments on this bug. Further, it seems that you and I have been duplicating work somewhat. I am in a similar stage of development to you, with UI completed and some of the backend working, although still very much in alpha. My focus is more on immediate update of local folders and definite support for IMAP though. Let's take the discussion to email and discuss what we can do to ensure that work isn't duplicated. Regards, Brodie
Hi Brodie, Edna I would love to hear your discussions and if they are on email no-one else can. Also to try out the code. Can I suggest discussion at netscape.mozilla.developers.general or netscape.public.mozilla.mailnews? You may find that making the code public gets you lots of bug-fixes etc... David
Hi Edna & Brodie, I would like to test your code, if I will manage to compile my Mozilla. Don't have this MS Visual Studio here, so I would like to compile it entirely on the CYGWIN GCC platform. The build instructions are very confusing, one should use the MINGW GCC instead of the builtin standard GCC. The MS Visual C compiler was recommended instead (together with cygwin). I don't want to mess up my nice Windows-Unix environment, this works for most of the Unix code (even some bigger things like Latex, LyX, Emacs ...). Did anyone managed it to compile with the standard cygwin GCC? @Edna: would be great if you could publish the source. Your credits will always stay in the source and your work will go down in history :-) I guess you should clarify it with your project supervisor. So, finally you made the Mozilla mail a good alternative to Oulook! Thanks! If in the end also the Calendar integration is done (easy exchange of calendar entries, background alarm), I don't see any advantage of Outlook any more.
*** Bug 240075 has been marked as a duplicate of this bug. ***
I need Neil's patch for bug 186999 to fix a bug with nsIMsgWindow::SelectMessage I'd appreciate if any developers here would have a look at my post in netscape.public.mozilla.mail-news, "(bug 2920) deleting attachments proposal" regarding the implementation of the actual attachment parse/removal code and give feedback. Please post replies to the newsgroup.
Depends on: 186999
*** Bug 192963 has been marked as a duplicate of this bug. ***
*** Bug 242171 has been marked as a duplicate of this bug. ***
ManageAttachments (zipped exe) provides the functionality I would like to see in Thunderbird regarding attachments. It allows to delete or detach attachments, and leaves a trace of the action - in a specific new attachment with the mail. jpg files are displayed so the user can see the pictures. The application does not alter the original mbox (Inbox/Sent) file, and creates a new mbox file (Inbox.new from inbox). The application is an advance prototype, and is not guranteed to function in all circumstances. Comment are welcome. I do not have enough knowledge in programming attachments, but can provide the C++ source code used to build the application, albeit in a now-obsolete environment (Powersoft Power++).
I created an TB extension to give users the ability to delete attachments please follow http://forums.mozillazine.org/viewtopic.php?p=525419 for info and xpi Cheers
Hi! For handling MIME-Parts you maybe should have a look at some of the available MIME-tools like ripMIME http://www.pldaniels.com/ripmime/ or VMime http://vmime.sourceforge.net/ which can parse and alter MIME-Messages. Apart from that I think that Mozilla has already code that's able to parse and alter a MIME-Message.
This is just a quick note to let people know that I am still working on a solution to this bug. It has been a long time, but I'm getting there slowly along with other things. This problem isn't as straight-forward as it might first appear. The solution I'm creating will be completely integrated within mozilla. It's great that there are now a few programs which can process the mailbox until this is completed. If you are interested in my current progress, you can find the current patches and doco that I have written at http://moz.jellycan.com/ If you wish to discuss something about what I've done or am doing, please post to the news://netscape.public.mozilla.mail- news newsgroup rather than here.
Attached file patch to date (deleted) —
I'm retiring from the bug 2920 patch camp and throwing it back into the pool for someone else to do. Sorry that I didn't finish it, I certainly had the intention to do so, but it's not as simple as everyone would like to think. At least not for someone who had never seen mailnews source before in their life. The file I have attached is all of my work to date (patch and a few notes, patches are in Gerv's Patch Maker format). The patch applies cleanly to the current source tree (1.8 trunk). I think that it's written so that conflicts will be few so hopefully it will remain useable for at least a few months until someone else steps in. Of course source code changes and it will sooner or later go stale. The UI patch is complete (within my assumptions): * all modifications to the UI to add "Delete", "Detach", "Delete All" and "Detach All" menu items * replace the icon for deleted attachments with a custom icon * properly enable/disable the menu items in context (e.g. are all attachments deleted) The source patch is incomplete but implements the following: 1. check all of the attachments selected for deletion/detaching: - sort them into the order they should appear in the message - remove child attachments from the list (once a parent is removed all children will be too) 2. copy the raw message source out of the IMAP or POP message store to a temporary file on disk 3. copy the message from the temporary file on disk back into the message store replacing the original message The step that is missing is the actual modification of the message source to remove the attachments. This should be part of step 2 which would create a stream converter and use the Mozilla mime library to modify the message. There is a fair bit of work to be done there and it will require someone willing to figure out the vagaries of the mailnews stream converters and mime library. A much simpler solution which could be fairly quickly created from my existing patch, would be to call an external program on the temporary file between steps 2 and 3 above. The external program would be passed the path to the temporary file and the list of mozilla attachment id's to be deleted, it would modify the message in the temporary file and write the modified message back to that file. The Mozilla handler would wait for the program to finish and if successful would then continue with step 3. If it failed it would delete the temp file and not bother. It would be handy to have UI like "Are you sure" in Mozilla for i18n purposes; there is already the source code to display that in my patch (although not currently used). Known problems: * copying the message back into the message store doesn't work cleanly, but it works most of the time. I had problems with the message copy service and so it is as you see it now. * otherwise not finished Once again sorry to all that got their hopes up for this. I hope that someone else will take over and at least implement the call to an external program if nothing else. As far as I know there is still bounty money available to anyone who completes it.
Assignee: brofield → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Frank (Ausdilecce) has created an extension (AttachmentTools) which does most of the things raised here. The thread is at http://forums.mozillazine.org/viewtopic.php?t=76117. Maybe his work (or at least the concepts) can be used by someone to integrate this into the Mozilla trunk?
in "Info: Parts of Mozilla source code to be fixed for bug 2920", it says: "Unfortunately, it seems that Mozilla (version 1.2.1) does not manage well the MIME type message/external-body." How true is this statement today? Perhaps this bug needs to be split in two: proper support of message/external-body with all the different access types (see http://www.zvon.org/tmRFC/RFC2046/Output/chapter5.html#sub2sub3), and the actual attachment deletion/detachment. The first part of the necessary work should depend on bug 108010 (the question to ponder is: what happens when a deleted attachment is one of the alternatives in a Content-Type: Multipart/Alternative message part).
*** Bug 249968 has been marked as a duplicate of this bug. ***
Oh poor guys, debating for almost 5 years if and how to solve this problem. Microsoft has been faster to respond to users needs... I wished Netscape would react in some way Just some thougts of a 'real user'
(In reply to comment #247) I just got two pm concerning my 'not constructive' post #247. In case somebody feels offendet: That was not my intention! So please disregard my earlier comment, keep on going - and peace on earth ;)
A small note that may help an implementer: An example of deleting and recreating mail messages while they are already downloaded: Set your size limit in "Disk space" settings for the account. Then get a message larger than that size. You get a mail with some parts of the text, then a message "this was truncated, click here to get it all". When you click, the full message is downloaded, you see it appear briefly in the folder, then the old partial message is deleted. I presume that both cases have the same message ID etc, so there is a precedent for "modifying" messages.
5 years is really a long time for a feature, that an experienced programmer could possibly do in much less than 5 weeks or days. Same for the important feature to save a complete web-page into a single multipart MIME file (IE is capable to do this). I read that there are a dozend employees in the Mozilla foundation and some full-time Mozilla developers at Sun. Can't we convince them to implement this business-critical feature? For me it's the main reason to stay with Outlook. The non-Microsoft companies should collaborate more in creating an alternative system. They will profit when Microsoft looses the market leadership on the consumer side.
The extension mentioned in comment 244 works just fine. So I don't understand the continous whining ...
(In reply to comment #251) > The extension mentioned in comment 244 works just fine. So I don't understand > the continous whining ... The extensions only works on local folders, not IMAP. Thus, it is useless in a corporate environment.
The extension did not work on my stable Mozilla 1.7/XP (and Mozilla itself did not want to start any more), just on Thunderbird. It should to be a bit more elegant, that the user does not see the temporary items in the folder list. However, it's good to see that the solution is very close. Oh yes, if this is solved, I'm still using the Outlock/Outlook solution, because it triggers also alarms when all windows are closed. The Mozilla calendar is useless for me if I can't rely on the alarm function (then it's not better than my paper calendar). It's a pity that there are only small things that annoy so much. In most other aspects Mozilla is much better than IE/Outlook.
Unless you are actually fixing this bug, please don't post comments. Bugzilla is only for fixing bugs; everything else is spam, and we all have plenty of that. If you want to discuss it, use the newsgroups or mozillazine.org forums. You can slso vote for it here (click "Vote for this bug" at the top).
Please guanxi, flames don't help, you're not fixing the bug either. This is a serious issue to be solved. On the Mozilla suite, the extension from #244 didn't work. Now I switched to Firefox+Thunderbird on WinXP and installed this one: Thunderbird Attachment Tools v0.4.7 (TB 0.7ok) http://www.supportware.net/mozilla/ From the preview pane it works to zap and delete attachments. Didn't notice any side-effects. Wonderful, one argument less for MS Outbreak. However, in the opened message window nothing happens. I can live with that for now. For the future it would be nice to integrate such a basic feature into the core of Thunderbird. So I wouldn't close this Bug 2920 already now. How can we communicate the extension to the users ? The official list at http://update.mozilla.org/ suggests to file a bugzilla bug. Who's checking it ? I sent a mail to database[at]mozdev.org for their "Extension Room". Up to now it wasn't listed. Btw, on Frank DiLecce's site you will also find another extension, the "Get All Mail" Button. Very useful!
The AttachmentTools extension not only does not work with Mozilla or Netscape (and BTW, I even didn't got it working with TB either), it also does it the wrong way round, IMHO. From what I know, it first deletes the original message, and then adds the new message without attachments to the mailbox folder (it makes some copies before, however). Additionally, it tries to force an mbox compression by deleting the .msf file. The complete process seems to be unnecessarily complex to me. I think that "simply" [tm] creating a copy of the message, but without the attachments, would be a better way. Eventually the original message could additionally be marked as deleted. Compression of the folder should be left to the user (so it can be done once after several attachment deletions). I already contacted Frank Dilecce about this, hopefully he will pick up this idea.
(In reply to comment #256) > The AttachmentTools extension not only does not work with Mozilla or Netscape > (and BTW, I even didn't got it working with TB either), You're being unfair. The fact that *you* couldn't get it working on Mozilla/Netscape/TB doesn't mean it does not work. There's quite a few people (including myself) which are using this extension successfully, on a regular basis. (OT - You might not have the message pane activated - the extension seem to require this to work). Please be frank (with.. Frank) - building this extension wasn't an easy task and we must respect his work. Also, he might be using a complicate approach just because a simple one could not work. I don't think he would go and choose a complicate scenario with no reasons. Other than that, yes, I'm also a bit annoyed by the mbox compression every time a message is deleted. Takes some time when processing big folders. And yes, there still are bugs in this extension (particularly when deleting multiple attachments). And yes, it would be FAR better if this went in the core rather than as an extension... That's just my opinion, of course. Lucian
Sorry, I didn't want to appear unfair. It just seemed to me that the code of the extension was relying on something that was not too reliable. However, Frank has modified the code so it also works with the Suite (we tested with 1.6). He also mentioned that there were reasons to make it that complicated, and that compressing and deleting the msf was necessary (though I can't verify that). Hopefully, if this is stable for all Mozilla branches, we'd have at least a way to delete attachments at all. And I agree that it would be better if this function would be implemented in the core. It's long overdue.
(In reply to comment #258) [snip] > to delete attachments at all. And I agree that it would be better if this > function would be implemented in the core. It's long overdue. So when is someone with the necessary mailbox programming skills going to do this? It keeps popping into my mailbox every time someone votes, so it's pretty popular!
Hi, I have already removed my e-mail address emails@hahnebach.com from bug 2920 Delete attachment from mail message in folder. My address is not listed at http://bugzilla.mozilla.org/show_bug.cgi?id=2920. In spite of this I get e-mails from bug 2920. Could someone tell me how to remove my e-mail address or tell who should I write to? Thanks very much. I already wrote to mattyt-bugzilla@tpg.com.au (He should be the one govern for my problem) an first of september but I got no reply and still get the bug 2920 infos. Bernd Hahnebach
This bug is very important in a corporate environment. I *really* wish it could be solved. May I suggest that the code behind the feature "Edit Message as new" already behaves in a way that could easily be adapted to solve this bug. "Edit message as New" allows the attachments to be removed but the issue in relation to this bug is that the Sender & Time information of the original email is lost. It would be a great start if the "Edit message as New" code could be utilised to provide similar functionality - but when saving the copy; a)retains the original sender info, b) retains the original time info, & c) allows saving to same folder as the original came from (as opposed to drafts). I don't think it's even too much of an issue for the user to delete the original email though that would be nice. Users just want a method of deleting attachments whilst keeping the original message without having to jump through an extraordinary large number of hoops. Cheers Julian
Repeated questions about when something is going to be fixed don't add anything of value to the bug. If anything, you will dissuade potential fixers by making the bug less easy to follow via bugzilla email or reading through the comments. This is not an advocacy forum, nor is it a place to complain about the pace of development. If you have something of technical value to add to the bug, especially if it comes in the form of a patch, then feel free to make some noise. If not, please go to the forums at mozillazine.org and vent to your heart's content. Thanks.
(In reply to comment #262) Allright Asa. Then I'll just stop wasting your resources and switch to another mailer. Be well, Karel Miklav
(In reply to comment #262) > noise. If not, please go to the forums at mozillazine.org and vent to your > heart's content. Thanks. Mozdev.org has it's own Bugzilla installation where bugs of extensions which are located at mozdev.org can be handled. I think this is a better solution as any forum. Pawel could you include the page on your extension page there?
Sorry guys, please forget my last comment. I mixed up two bugs. :(
*** Bug 261703 has been marked as a duplicate of this bug. ***
*** Bug 262438 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0mac?
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0mac?
Flags: blocking-aviary1.0mac-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
As a hint here is the way I get rid of a huge attachment: I move the msg into the draft folder in my local folders, then open the draft folder with WordPad and erase the attachment part of the msg, then move back the msg into its previous place. These different operations should be easily automated by somebody having better skills than I !
Just a reminder to followers of this bug, especially Noel, that there is a functional add-in which (mostly) works OK at http://mozdev.sweetooth.org/gtl/extensions/attachmenttools/ but WHEN is someone going to put it in the core?
After listening to the discussions and possible solutions it seems to me the problem, basically, is this: Mozilla is designed around the assumption that messages will NEVER change. (Indeed, to some extent this is a design goal, to keep the message integrity). All the problems seem to stem from this; such as: - there is no efficient way to replace message data - there is no efficient way to update the .msf mail summary file - images are cached and therefore deleting them as attachments doesn't get rid of them (see the thread about the TB tool) - there aren't really any convenient classes for modifying messages The requirement to delete attachments goes fundamentally against this design, and means that any "solution" is basically going to be an ugly hack. If you started out including that requirement, you would probably not use gigantic text files for the mail store as Mozilla does, instead you would use a database design with the attachments parsed at reception into different tables, etc ... as more sophisticated mail systems do (like Exchange, Notes etc). *Personally*, this seems like a gaping flaw and encourages me to go find something else. But perhaps we are just asking too much of Mozilla mail.
It is possible to parse and modify messages in Mozilla. This is not a problem. The code in my patch at attachment 151592 [details] implements the save of a single selected message to a file and then a replacement of that message in the message database with the contents of the file. This is noted in comment 243. What is not implemented is the actual modification of the message source to remove the attachment. I have left that up to someone else. When a person with programming ability comes along and wishes to complete it (or write their own), this will get done. Before that advocacy comments just add noise to this bug report and make it harder to digest the useful information. In the meantime, please just use the existing extension or methods mentioned in previous comments.
Product: Browser → Seamonkey
*** Bug 271352 has been marked as a duplicate of this bug. ***
I think this is going to have to be my holiday project...
Assignee: nobody → bienvenu
I wonder if a more sane method than those tried so far is to simply mark attachments for deletion, and then use the Compact Folders method to do the actual deletion. (Doesn't seem like the existing approaches do this).
I don't think so. There is no mechanism for marking an attachment for deletion. Sure you could insert a custom header in the attachment, but if you do this, you have to write the whole message anyway, so you can delete the attachment at once. Technically, I don't think deleting an attachment is very difficult: Just create a new message with all the mime parts except the one you are deleting, store it in the folder and mark the original message as deleted.
(In reply to comment #275) > I don't think so. There is no mechanism for marking an attachment for deletion. > Sure you could insert a custom header in the attachment, It is not necessary to alter a message base file. Markings can be kept in .msf or whatever other auxilary file.
My understanding is that .msf files are supposed to be completely redundant. You can delete them at any time and they will be recreated from the messages. Especially with IMAP I expect that storing important information like which parts of a message is supposed to be there only in a local file would open a serious can of worms.
Instead of storing the attachment deletion information in the msf file it could be stored in a header (like the X-Mozilla-Status currently used for marking deletion). This could be done reasonably intelligently when a message with attachments was received (it could be a bit field to indicate deletion). Then as with deleting messages, only certain bytes of the file would have to be changed to indicate deletion. The disadvantages of this would be that it would require adding an extra header, and that it wouldn't work for existing messages with attachments.
People, please no more comments. David Bienvenu wrote a hell of a lot of mailnews. Unless he asks for it, I expect that he doesn't need any help in adding this functionality. In any respect, these suggestions aren't necessary. The ability to rewrite a modified message into a local and IMAP message store exists (i.e. save draft). The code to modify the message to delete an attachment doesn't.
(In reply to comment #274) > I wonder if a more sane method than those tried so far is to simply mark > attachments for deletion, and then use the Compact Folders method to do the > actual deletion. (Doesn't seem like the existing approaches do this). The problem with this approach, and several others, is the fact that they're work-arounds, around failings of the core of MailNews: inability to flexibly manipulate messages and parts of messages, and to have such changes reflected in the mailbox. That's why I think the "how about we try to mark the msf for compaction"/"make the X do the Y and that will cause Z which will have the desired effect" are not the way to go. (In reply to comment #279) > People, please no more comments. David Bienvenu wrote a hell of a lot of > mailnews. Unless he asks for it, I expect that he doesn't need any help in > adding this functionality. > You're way off here. The fact that someone owns part of the code does not imply he's the main person working on it... and David has certainly not been constantly working on this specific problem for the past 5.5 years, so as not to want/require any effort from others towards solving it. > In any respect, these suggestions aren't necessary. The ability to rewrite a > modified message into a local and IMAP message store exists (i.e. save draft). No it doesn't. Not really. See what happens when you have a draft and save it: it gets deleted completely and written again as a new message. That is not the behavior we want (at least AFAIAC), that is a mis-feature.
------- Additional Comment #273 From David Bienvenu 2004-11-23 07:59 PDT I think this is going to have to be my holiday project...
as long as we're using the berkeley mailbox format, stripping attachments will have to involve rewriting the message - that's always going to be faster then rewriting the whole mailbox. If+when we support maildir, then it will still involve rewriting the message. If someone designs and implements a format that stores attachments separately, then stripping attachments will be easy, but implementing that format would be orders of magnitude harder than it will be to strip attachments from the berkeley mailbox format by rewriting the message w/o the attachment(s).
Hiya All, Just wanted to poke my head in here and make a couple of comments if I may.. The extension I wrote is an extension for Thunderbird ( cuz that's what I use ).. It can easily be made to work with Mozilla ( as Tilmann mentioned in comment #258).. I *assume* that it can be made to work with netscape as well but I would NOT know for sure.. It does (kinda) work with IMAP.. ( more testing needed, I know ) It doesn't work with a standalone message window cuz I was lazy and didn't make the required overlays correctly. It is no longer required to do a mbox compress on each operation The reason why it's not too reliable is because it is an extension, written purely in JS. The extension needs to work within the confines of the XPCOM (or whatever).. The basic truth of it is that it is *possible*, and that is really all that I attempted to prove.. It is not elegant because the underlying api's are either unaccessible or unwritten.. The extension rewrites EVERY LINE of the message(s) for crips sake ! ( Noel, you would appreciate this since the extension does exactly what you mentioned in comment #268) Now, regarding adding this functionality to the core, I am positive David can handle it.. Just a couple of things to conside tho as I have received hundreds of comments about adding things to my extension.. Please keep in mind. People may want to save and strip attachments as they are received ( as a message filter action ) People may want to strip attachments from the copies of the messages they send ( so as to not have their Sent folder be huge ) People may want to strip and save OR delete completely, attachments for a whole folder at a time People may want a snippet of text where the attachment used to be, telling them if was saved, when, where and how big it was. People may want to strip&save or strip&nosave or delete completely ( leaving no trace that attachment(s) ever existed) Happy holidays and thanks in advance Frank
I looked at Frank's extension and it's certainly an impressive amount of work, especially to be all in js! It looks like it parses the mime message itself in order to strip out the attachment. Brodie's approach looks more like what I had in mind, using the mime parser to stream the message, though, iirc, that's not too surprising since that's the approach I suggested. I'll try to do some more investigation of this...
Sorry, one more thing.. It might have gone unnoticed, but the Attachment Tools extension also implements the fuctionality to import a .eml file ( or several at once ) into the current folder.. Meaning one could take an .eml file and (really) add it to the message store. The code to add a text file into the message store was already written so.. It was added to this extension because I did not want to write another whole extension just to be able to import .eml files. ( I know it made no sense in the context of attachments ) The most current version does NOT muck around with msf files ( cuz they had the habit of being 'locked' by some function or other in the core). Anyway - Now, it 1) copies the original to a temporary folder ... and also marks for deletion the original message 2) reads the copy, line by line, stripping the selected attachments as it goes 3) saves the plaintext of the modified message in an array 4) deletes the temporary folder ( to get rid of the msf, it contains mis-information anyway) 5) writes the array to disk, using the name of the temporary folder 6) send a notify that the folder has been 'added' ( this recreates the damn msf) 7) copy the modified message back to the original folder 8 ) reselect the original folder and modified message 9) delete the temporary folder.. In IMAP, all processing of the message is handled locally, meaning the message must be downloaded, in full - modified - then uploaded back to the IMAP store I would have liked to have used streams but could not work out how ( documentation on ther use is, ummm, lacking ).. Good luck David
I tested your extension on imap. It does detach the attachment but does not save it to the specified location. Thanks, it looks very promising.
(In reply to comment #285) I really liked your Attachment Tools and I'd love to see it implemented in Mozmail (or something similar). In case you wander about past tense above: Attachemt Tools won't install into Thunderbird 1.0 and I haven't been able to find a newer version anywhere among Moz/Fox/Tb extensions. (Almost made me believe, it's not supported anymore, until I've seen your message.) I hope it's available again soon. Keep up the good work!
(In reply to comment #285) I really liked your Attachment Tools and I'd love to see it implemented in Mozmail (or something similar). In case you wander about past tense above: Attachemt Tools won't install into Thunderbird 1.0 and I haven't been able to find a newer version anywhere among Moz/Fox/Tb extensions. (Almost made me believe, it's not supported anymore, until I've seen your message.) I hope it's available again soon. Keep up the good work!
*** Bug 274310 has been marked as a duplicate of this bug. ***
*** Bug 274610 has been marked as a duplicate of this bug. ***
First up many thanks to all the Mozilla/Firefox/Thunderbird developers - keep up the great work! I'm just a user who has been advocating the browsers for a long time, and I would really like to switch to and recommend Thunderbird as well - only it's lack of an attachment managing feature still keeps me from doing so... If you guys would be so kind and take a look at the forum discussion below where I posted a well-received suggestion of how to handle attachments similarly to Eudora: http://forums.mozillazine.org/viewtopic.php?p=901839#901839
Attached patch work in progress (obsolete) (deleted) — Splinter Review
I've adopted Brodie's patch, and extended libmime to know how to strip parts. I haven't done anything about detaching parts - that should be a fairly simple extension to what's already done...I haven't verified that this behaves well with various encoded messages, i.e., that libmime is passing through the message w/o any kinds of conversion. But this is a good start.
Attached patch work in progress (deleted) — Splinter Review
oops, that last patch was from the wrong tree...
Attachment #169324 - Attachment is obsolete: true
Flags: blocking1.8a6+
luijten@uiuc.edu, you are not in a position to change blocking flags. Please read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html (especially section #2). Thanks, Prog.
Flags: blocking1.8a6+
*** Bug 218261 has been marked as a duplicate of this bug. ***
This feature is a MUST. Just to remember, Outlook Express doesn’t do it either, Outlook (from the office package) does it manually, one by one. To migrate from Outlook Express I would need to do it on folders as a whole.
Attached patch mime changes (obsolete) (deleted) — Splinter Review
Jean-Francois, these are the mime changes I made for this. It would be great if you could look at this soon since we have a freeze coming up Tuesday night...this patch shouldn't change any of the code that runs when not stripping attachments...
Attachment #173637 - Flags: review?(ducarroz)
I'll review it later today...
Comment on attachment 173637 [details] [diff] [review] mime changes Looks good to me, R=ducarroz Good job David!
Attachment #173637 - Flags: review?(ducarroz) → review+
Comment on attachment 173637 [details] [diff] [review] mime changes this is just the libmime changes - there are lots more to follow :-)
Attachment #173637 - Flags: superreview?(mscott)
Attached patch patch for sr (deleted) — Splinter Review
a couple tweaks from the previous patch, to fix the case of stripping forwarded messages...
Attachment #173637 - Attachment is obsolete: true
Attachment #173785 - Flags: superreview?(mscott)
Attached patch non-mime backend changes (deleted) — Splinter Review
this just does delete, not detach...most of this is Brodie's patch, though I had to fix some stuff.
Attachment #173793 - Flags: superreview?(mscott)
*** Bug 281740 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0mac-
This implements detach (which is save followed by delete) and adds the front end to the attachment context menu for delete,detach,[all]. It also prompts now before deleting. The one thing that's not good is that the save dialog that pops up as a result of detach says "Save all" even if you're only detaching one attachment.
Attachment #175774 - Flags: superreview?(mscott)
Jumping in, so sorry if this has been discused: Do we really want/need "detach"? It seems redundant to "delete" and "save as", and somewhat confusing since some users might not expect it to also be a "delete" (I think Lotus Notes' "detach" doesn't delete). Maybe "Delete" and "Save as" are sufficient and UI-KISS? Yes, someone wanting to do a save *and* delete at the *same time* would be inconvenienced. It's a judgement call between UI simplicity and über-functionality. ;-)
I completely agree. "Detach" is a very engineer-oriented name for a feature. even if it was /called/ "Save and Delete Attachments" as wordy as that is, would be better. Though, I don't see any UI changes in attachment 175774 [details] [diff] [review] I think people would better understand it if we just called it "Delete Attachment" and then offered a dialog that said "Would you like to save this attachment before you delete it?"
I completely agree. "Detach" is a very engineer-oriented name for a feature. even if it was /called/ "Save and Delete Attachments" as wordy as that is, would be better. Though, I don't see any UI changes in attachment 175774 [details] [diff] [review] I think people would better understand it if we just called it "Delete Attachment" and then offered a dialog that said "Would you like to save this attachment before you delete it?"
(In reply to comment #306) > I think people would better understand it if we just called it "Delete > Attachment" and then offered a dialog that said "Would you like to save this > attachment before you delete it?" I don't particularly care one way or the other about including a "Detach" option, but I'm going to have to respectfully disagree with the above approach. Would the average user expect a "delete" function to ask you to "save" it? Probably not. Users expect a prompt to save a file when it's closed. And they expect a confirmation ("Are you sure?") when you select delete. But I bet you'd be hard pressed to find someone that expects a save dialog as part of a delete function. (In reply to comment #305) >Yes, someone wanting to do a save *and* delete at the *same time* would >be inconvenienced. It's a judgement call between UI simplicity and >über-functionality. ;-) I see the point you're making, but isn't the "save *and* delete at the *same time*" the operation that most users will want to perform 95% of the time? That's the way it would be with my business - I don't want to get rid of any attachments, I just don't want them filling up my mail space. And requiring two operations has some of the same expectation issues as I mentioned above. I'd guess that users are hesitant to click the delete button for fear of losing their attachment. The save button saves it to their hard disk, so maybe the delete button deletes it from their hard disk? And what if a user gets in a hurry and forgets to do the save before the delete? All in all, I think it's simpler to just leave "Detach". My .02
I agree that 'Detach' might not be correctly understood by some users and for myself I would like to have a 'Save as' and 'Delete' separately. I usually want to keep the attachments on the mail as long as it's necessary (since I do find a mail way quicker than any attachment saved to harddisc), but I'd like to be able to delete attachments later on (for example 'sort by size' and prune any big and old mails). A Detach would then be quite unhandy as I'd have to save them to a temporary place first to be able to remove them from the mail and afterwards delete them again from harddisc... Just my 2c Matt
I would like to be able to detach an attachment and replace it by the link to where the attachment is going to be stored. Therefore "save as" and "delete" as separate operations won't work. If the links get broken later thats the user's responsibility and should not be a concern as the user could equally do a delete without a save in the first place. In this way I can use the mail as an index to the original attachment but keep the attachment outside my mail store. This makes incremental backups much easier as well as locating attachments by any mail criteria [date, user, subject, etc.]
Sturges hits the nail on the head - detach leaves a link to the place you've saved the attachment, and double clicking on the attachment icon will open the detached attachment. We're not going to get rid of delete. Different users have different needs. I would only ever use Delete. I just implemented Detach because other people would only ever use Delete. Re the naming of the detach command, it's not synonymous with save and delete since detach leaves a link to the saved attachment. I'm open to suggestions...I'd argue that just clicking the context menu on an attachment is almost a power user feature. What do other clients use for this feature?
The idea sturges had (saving a link to the "detached" attachment") would be very nice and perfectly fit my needs.
Again, we're already doing that with Detach.
If you "detach" an attachment and then use the "edit as new" feature, will the new message contain the attachment itself, or only an external link? In the later case, I think this is a bug ... (I say that because I already sent a message with an external link to someone who couldn't read it - but this was not with mozilla)
Comment on attachment 175774 [details] [diff] [review] implement detach, front end for delete and detach david is this really the right patch you want me to review?
Comment on attachment 175774 [details] [diff] [review] implement detach, front end for delete and detach no, sorry
Attachment #175774 - Attachment is obsolete: true
Attachment #175847 - Flags: superreview?(mscott)
For what it's worth: in the context of acting on an *attachment*, I think even we non-engineers can figure out what "detach" means. ;)
Jeez, Attach = To affix or append Detach = To separate or unfasten This is from a 'normal' dictionary folks.. Is this so difficult .. wow Re comment 314, I would think the easiest way to deal with that is to replace the external link with something like <<attachment xxx removed by yyy>> where xxx is the attachment name and yyy is the address of the person who deleted it. This is so the new recipient knows that there was an attachment there at some point and who to contact to get it. This text could, obviously, be replaced with the actual attachment if the sender deems it necessary, or removed altogether.
defenestrate - v : throw through or out of the window that's from a "normal dictionary" perhaps people would understand that metaphor just as easily? :)
My two cents: Detach is a brilliant UI feature. (If I had to choose between having just detach, or just save and delete, I'd go for the former.) I'd love to see this in the trunk. When I used Outlook, I always did a save and delete together, never one without the other. And I'd edit the subject to indicate that I'd saved the attachment to the filesystem. Detach does all this for me, and it's intuitively obvious what it does! Thanks, David.
(In reply to comment #318) > For what it's worth: in the context of acting on an *attachment*, I think even > we non-engineers can figure out what "detach" means. ;) Not if you're also using Lotus Notes. However, the fact the IBM chose the wrong terminology for "Save as" shouldn't prevent us from choosing the right term. Personally, I still prefer "Save and Delete" or even "Save, then Delete" (that's right, a comma in a menu item), as they would be more easily understood by a wider audience (including non-native English speakers). The fact that this action also inserts a link is a nice bonus, but not something that significantly changes the nature of what it does, so these last two options are still valid IMHO. Prog.
(In reply to comment #319) > Jeez, > > Attach = To affix or append > Detach = To separate or unfasten > > This is from a 'normal' dictionary folks.. > Is this so difficult .. wow When one detaches something (from something else), does it necessarily mean he's going to put that thing in a save place? Not so. For me, when I detach something, most of the time, I'll throw it away. So I agree with others that "Save then delete" is a lot explicite.
(In reply to comment #309) > I agree that 'Detach' might not be correctly understood by some users and for > myself I would like to have a 'Save as' and 'Delete' separately. Yes, in my opinion that would be the best way. Lots of people do not save attachments to the harddisk but keep them with the messages (so do I) and even when they save an attachment to the harddisk in most cases it makes sense to keep the file together with the message. "Save attachment", "Save all attachments", and "Delete all attachments" (maybe "Delete one attachment") would do the job.
A I said in comment #147 detaching should leave an message/external-body MIME-type attachment in message (RFC1521) with Content-MD5 field (RFC1864). Mozilla should display a warning when viewing detached attachment if it's MD-5 sum is different - something like "This attachment was edited after detaching. Continue: Yes/No". --- example --- Content-type: message/external-body; access-type=local-file; size=580 name="/tmp/mozilla-16.png" Content-Type: image/png Content-ID: <generated@content.id> Content-MD5: af90b9ee43d0c4a1ee71bab4fbcc2e31 This attachment was saved as "/tmp/mozilla-16.png". --- example end ---
(In reply to comment #323) > (In reply to comment #319) > > Jeez, > > > > Attach = To affix or append > > Detach = To separate or unfasten > > > > This is from a 'normal' dictionary folks.. > > Is this so difficult .. wow > > When one detaches something (from something else), does it necessarily mean he's > going to put that thing in a save place? Not so. For me, when I detach > something, most of the time, I'll throw it away. > > So I agree with others that "Save then delete" is a lot explicite. Isn't this usually called "move"? Maybe "move attachment to file" is the most explicit. Anyway, thanks for the discussions and work on this important subject!
Another suggestion: if you take a look at Ausdillece's extension, you will notice that he used different terms to avoid this ambigiousness: there DELETE means "delete and link to it(*)" and ZAP means "delete without trace. I found this to be very intuitive. People will get used to the hidden "save as" very soon, so personally I don't think it's necessary to mention "save, then delete" in the menu entry, but I wouldn't bother. (*) he does not link in terms of the ability to start the attachment right away but replaces the attachment to be deleted by a plain text attachment with a short description what the attachment name, size etc. was and where it was savet to initially. The solution implpemented by bienvenu is much more advanced I think - but that is not what my comment aims to be about.
(In reply to comment #326) > Isn't this usually called "move"? > Maybe "move attachment to file" is the most explicit. When you detach an object (a physical object or a cyber object ;) ), you have to *move* it anyway. So *move* is an implied action. But the difference between detach and delete, according to some, is that detach implies leaving a trace in the original mail; delete means no trace and thus it's as if no attachment had ever been there. So to have a compromise, and thanks to your idea, how about "Detach to disk..."? This is similar to the familiar "Save to disk..."
Thanks to all for comments and great this issue is attracting so much enthusiasm. How about: Save [as] - make a copy of the attachment somewhere without any removal Delete - just remove the attachment [optionally marking, attachment removed] Archive - Save & remove the attachment whilst retaining a link to its new location. [instead of Detach]
I like Detach more. So this would be my prefered choice: Save Delete Detach
(In reply to comment #311) > Sturges hits the nail on the head - detach leaves a link to the place you've > saved the attachment, and double clicking on the attachment icon will open the > detached attachment. > > We're not going to get rid of delete. Different users have different needs. (...) That is to say, they are making all options available. Thanks, David! Therefore, the current context menu for attachments: Open Save As... ----------- Save All... is going to become something similar to this: Open Save As... Delete Detach As... ------------- Save All... Delete All Detach All... Other possible names that people mentioned for the "Detach" option have been "Move", "Archive", "Save and Delete", "Save, then Delete", "Detach to Disk"... All these names, like also "Detach", are good possibilities. If the meaning of "Detach" is not clear enough for all, how about the following context menu?: Open Save As... Delete Detach (save+delete) -------------------- Save All... Delete All Detach All... But anyway surely this is not necessary, given that "Detach" appears in the list after "Save" and "Delete", making it evident that it's a different option.
(In reply to comment #331) Concerning the context menus - It is clear that "Detach As" has a different function from the Save and Delete options so hardly needs further clarification. I don't like "Detach (Save+Delete)" as this is more misleading. It implies a "Save" and a "Delete" operation without leaving a link to the saved file, whereas "Detach" or "Detach As" has no contradictory description. Question: Will there be an "option" with the plain "Delete" to leave an indication that there was an attachment but it has been removed? I can see people needing it both with and without the indication.
Delete leaves an indication that the attachment was deleted - you'll see the attachment icon with a big red x through it (I think we need a similar icon for detached, actually), and we leave the original mime headers as documentation that the attachment was deleted.