Closed Bug 2920 (delete-attachment) Opened 26 years ago Closed 19 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)

2.56 KB, text/plain
Details
25.05 KB, text/plain
Details
68.73 KB, text/plain
Details
25.93 KB, application/zip
Details
294.11 KB, application/octet-stream
Details
85.92 KB, application/x-zip-compressed
Details
83.53 KB, patch
Details | Diff | Splinter Review
19.09 KB, patch
Details | Diff | Splinter Review
30.56 KB, patch
Details | Diff | Splinter Review
29.38 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
20.25 KB, patch
Bienvenu
: superreview+
Details | Diff | Splinter Review
31.78 KB, 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
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.
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
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) — 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 progressSplinter 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) — 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 srSplinter 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)
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.
Comment on attachment 175847 [details] [diff] [review]
backend and front end changes for detach

1) Should we use a switch statement on aFunctionName now that we have so many
if/else clauses? Just wondering out loud.

2) I'd like to find a better word in the UI than Detach. What words do our
competitors use?

3) I think we may eventually want to add Options / Attachments pref UI for some
of these features to allow you to say specify a directory for attachments that
should always be used. We can try to add that after the Options re-write lands. 

3) X-Mozilla-Altered is a content type that gets set on a specific mime part
right? Or should the name somehow indicate that we are talking about a part of
an attachment..i.e. X-Mozilla-Attachment-Altered:

4) Do we have to do anything like re-compact local folders after an attachment
has been deleted or detached to see the disk space savings or is that code all
part of another patch...
Attachment #175847 - Flags: superreview?(mscott) → superreview+
Attachment #175774 - Flags: superreview?(mscott)
(In reply to comment #334)
> 2) I'd like to find a better word in the UI than Detach. What words do our
> competitors use?

I'm not sure why you want to change it. "Detach" is the converse of "attach,"
which is what is used to describe the process of attaching something to the
message. What meme makes it difficult to figure out that the opposite of attach
means to separate the attachment from the message? Or, perhaps I am missing
something here.
Attachment #173637 - Flags: superreview?(mscott)
(In reply to comment #334)
> (From update of attachment 175847 [details] [diff] [review] [edit])
> 1) Should we use a switch statement on aFunctionName now that we have so many
> if/else clauses? Just wondering out loud.
> 
Perhaps.

> 2) I'd like to find a better word in the UI than Detach. What words do our
> competitors use?
> 
I personally think "remove" is the best word.

Detach sucks because it's rather awkward.  It's definately not the best word. 
Another would be simply "delete"

I haven't looked at this patch that close, but when removed, ideally it should
do something similar to Norton AV... replace it with a text file with the same
name (different extension), that reads "This attachment has been deleted" and
perhaps the datetime.

This is rather important.  So that when someone says "I sent you that file", you
can look through your emails and still tell if an email did contain an
attachment or not.

Not sure if this was incorporated... but mentioning it anyway.

> 3) I think we may eventually want to add Options / Attachments pref UI for some
> of these features to allow you to say specify a directory for attachments that
> should always be used. We can try to add that after the Options re-write lands. 
> 
Don't forget about a button to about:config!

> 3) X-Mozilla-Altered is a content type that gets set on a specific mime part
> right? Or should the name somehow indicate that we are talking about a part of
> an attachment..i.e. X-Mozilla-Attachment-Altered:
> 
If it's not X-Mozilla-Altered... X-Mozilla-Attachment-Removed would be
better... more discriptive.
How about instead of:

-Save
-Delete
-Detach

we have

- Save
- Detach and Save
- Detach and Delete

because "delete" and "detach" both remove the attachement from the message.  One
just saves it somewhere and the other throws it away.

Does that clear anything up or make it more confusing?
(In reply to comment #337)
>
> - Detach and Save

This is gramatically awkward.

Detach by definition implies saving.... well moving to another location.  So if
anything it would be either:

- Detach
- Move

Detach doesn't infer destruction (deletion), so it automatically implies moving
it somewhere else.

If I detach a piece of chocolate from a chocolate bar, the concept of object
permanence (which develops during the 8th month of life) says the object still
exists somewhere.

Hence it's awkward wording.

Attach is correct, because it implies taking 2 things and putting them together
(Both still exist, the email and the attachment).

(In reply to comment #337)
> How about instead of:
> 
> -Save
> -Delete
> -Detach
> 
> we have
> 
> - Save
> - Detach and Save
> - Detach and Delete
> 
> because "delete" and "detach" both remove the attachement from the message.  One
> just saves it somewhere and the other throws it away.
> 
> Does that clear anything up or make it more confusing?

How about just shortening the two commands to their bare necessities?

-Save Attachment
-Save All Attachments

-Delete Attachment
-Delete All Attachments

Adding the "Detach and Save" and "Detach and Delete" will just add headaches to
new users, and even as a casual observer to this bug, I had to stop and think
what the two terms meant.  Having single option UI commands will be more
beneficial for simplicity's sake in the end.  If someone wants to save the
attachment, they save it.  If someone wants to save the attachment and then
strip it from the original email, they save, then delete.  If they don't need to
keep the attachment but they want to keep the email, they delete the attachment.
 At the most, it's two menu commands.  Why add extra options that do two things
when we trade off usability?
(In reply to comment #334)
> (From update of attachment 175847 [details] [diff] [review] [edit])
> 1) Should we use a switch statement on aFunctionName now that we have so many
> if/else clauses? Just wondering out loud.
> 
> 2) I'd like to find a better word in the UI than Detach. What words do our
> competitors use?

What is the problem with "detach," especially in the context of talking about an
attach-ment?  It's not like detach is an awkward computer science back-formation
(like prepend is of append).

But hey, what do I know?  I'm just a native English speaker.

How about:

Save (saves a copy, leaves the attachment(s) with the message)
Remove (saves a copy, removes the attachment(s) from the message)
Delete (does not save a copy, removes the attachment(s) from the message)

I definitely think there needs to be the three options, rather than just
conflating it into save and delete and requiring people who want to get their
attachments out of their mail but not out of their filesystem to continually
have to perform two operations.  This would be murder if you're on IMAP.
Remove does not imply that an attachment will be saved. If I remove something,
it doesn't necessarily still exist. If it is detached, however, it still exists.
That is just the nature of the words.

I'm having trouble understanding why so many people cannot agree to use the word
"detach" to describe the action of un-attaching an attachment ... that is
*exactly* what detach means after all.
This argument over the wording is getting a bit silly.  I think there are really
two viable options, depending on how you want to interpret "detach":

Detach
Detach and Save

or

Detach
Detach and Delete

Personally, I think the first set makes more sense - I don't really agree that
you can use the same real-world analog to describe what "detach" means in this
context.  However, the second set would seem to leave less room for a data loss
condition - that is, it makes it more clear what option actually causes data to
disappear.  "Detach" may or may not be ambiguous depending on how you think of
it, but by using the second pair of wording, misunderstanding doesn't result in
data loss.
I agree that "Detach" seems the mor natural choice, but it is clear that some
people have problems with it. How about "Move to Disk", or "Detach to Disk", or
"Detach into a File", "Move out of the Message", or may be just "Move"? In any
case, the "Delete" option should be just "Delete", because this is the most
obvious one.
David, my vote is for detach. Take an executive decision and go with your
original idea, there is no sign of convergence in this discussion :)

The meaning in English is clear, it's not obscure or technical, it's obviously
the opposite of Attach. Yes, Lotus Notes used it in place of "save", but as
someone else said that wasn't really correct. 

The argument that non-English speakers won't know it is kind of silly. We
shouldn't avoid using the right and simple word just because it's not quite as
common. That's what translations are for.

There is a natural way to learn about it if someone is confused, because it will
pop up a dialog asking you where to save to, with a help button that can be
clicked to learn more about just what is going on. 

Storm in a teacup!
As above.

Just pick something (like Detach), users will make noise if they really hate it
(but i'm guessing they'll love it).  IMO, a minimal number of words per context
menu item is definitely the right UI decision, because once you learn what the
function does, you don't want to keep rereading them.
This doesn't have to be so difficult.  How about a checkbox as part of the file
dialog when you choose "Save" or "Save as" which says "Delete attachment from
original email after save?"  You could still keep "detach", which would be the
same thing as choosing "Save as" and clicking the checkbox".  This will make the
people who don't understand Detach happy.  Optionally you could include a second
checkbox "Insert link to saved attachment in original email?", though I think
that should just be standard behavior.
look, its very simple. Detach is not a common term used in e-mail. If your mom
sat, and thought about it, perhaps looked it up in a dictionary and cross
referenced it with a to-be-updated version of the Jargon dictionary, she
might... MIGHT get the implication. 

And besides, if you really want to get picky:
de·tach (d-tch)
v. de·tached, de·tach·ing, de·tach·es

   1. To separate or unfasten; disconnect.
   2. To remove from association or union with something.

I don't see anywhere in there anything about "after unfastening, store somewhere
for easy access later" - I see "remove" and "disconnect" - sounds like "delete"
to me.
(In reply to comment #347)
> look, its very simple. Detach is not a common term used in e-mail. If your mom
> [snipped]
> I don't see anywhere in there anything about "after unfastening, store somewhere
> for easy access later" - I see "remove" and "disconnect" - sounds like "delete"
> to me.

  I agree with you, Alec.  Detaching an object A from object B doesn't
necessarily mean that object A still exist afterwards.  Just take a simple example:
Someone left a file on your table with a post-it sticked on it.  You came and
saw that the post-it just contain the word "Important".  You would of course
*detach* the post-it.  But are you going to put the post-it in a save place as a
souvenir ;) ?

First, my sincere apologies for adding to the bugspam, and for the lecturing
tone of the rest of this comment. And a huge thank you to mscott and bienvenu
for taking this on.

Second, the verb Save and the verb Detach are wrong in this UI. There are
already verbs in the UI that are appropriate in this context, and they are the
verbs we should be using: Copy, Cut, Delete.

Think about it for just one second: what would Copy do in this dialog? Exactly
what a user expects -- it would let you paste the attachment somewhere else in
the file system. It alleviates the need to even bring up a file picker. If you
want to bring up the file picker dialog anyway, make it Copy To... instead.

What would Cut do? Again, exactly what a user expects. Same as Copy, but the
original is "detached". Again, you could have Cut To... instead.

Delete is obvious.

Any other verbs would be inappropriate.

Final note: I can already drag-and-drop an attachment to my desktop. That's
great. (By the way, on Windows, the pointer changes to an empty rectangle icon,
which signifies a move instead of a copy, and that's probably a bug. On Windows,
a copy should be signified with a little plus sign instead.) As a power user, I
want to be able to shift-drag-and-drop. That'd be the perfect complement to a
Cut command.

For the record, I'm not a fan of Copy To and Cut To, but I could be persuaded of
their necessity.
I don't have a problem with Detach or not having this short cut at
all, but I'll add to the mix.

File or Archive would imply storing elsewhere for access later.
File - to arrange in order for preservation and reference
Archive - To copy or compress (a file) into an archive.

Open
Save As...
Delete...
File...
-----------
Save All...
Delete All...
File All...

Also Bill's suggestion of a checkbox control in the Save As dialog would be my
vote, but this is not as easy as it seems if already using the standard file
dialogs provided by some APIs.
By the way, the approach I suggest in comment 349 (dear sweet Jesus) also makes
it plain that Save All is unnecessary. You get a list of attachments and you can
select from it using standard selection metaphors (i.e., click and highlight,
ctrl-click and highlight multiple items), and Copy some, Cut others, and Delete
the rest.
Cut/copy/paste/whatever don't make sense for window managers that don't have a
clipboard that supports file cutting and pasting.
Detach isn't common in email because the ability to detach isn't common (duh).
It doesn't matter how much you argue that detach doesn't imply the
non-destruction of the attachment because the English language is clear. If you
have a misunderstanding of the English language, is it really the job of a UI to
address that?
(In reply to comment #342 & comment #342)
Brian Tarricone says based on designer's view, but Aleksey Nogin says based on
user's view(user's expectation, sometimes prejudice though).
I feel difference between two views is similar to one on "SMTP server
definition/Account choice of SMTP", Bug 202468. 

Main issue sounds to be wording in UI only.
Even though some UI changes/enhancements will be required, many of them on
"Detach" can easily be implemented, I think, by combination of already
implemented functions.
If these are true, I think following is sufficient for our first testing of the
feature.
  "Detach" => Ask "save" or "not save" => Save when "save" => Execute detach
I hope early shipment of the feature for our testing.
OK, option names are a minor point, and most of the (many) already suggested
names seem quite good or clear, so in a few words...

(In reply to comment #352)
> Cut/copy/paste/whatever don't make sense for window managers that don't have a
> clipboard that supports file cutting and pasting.

That's true, but for example MS Windows Explorer (apart from the well-known
buttons "Copy", "Delete", "Cut", etc.) has two optional buttons "Copy To" and
"Move To", for one-step action without clipboard. So, "Copy To" and "Move To"
are another possibility, but anything that is clear is fine.

Anyway, the first idea with the options "Save As...", "Delete", and "Detach
As..." is in my opinion really clear as well, particularly because all the
options will appear, not isolated, but available as a list in the context menu.

And, for instance, "Detach" options are used by email tools (for Outlook) such
as EZDetach and DetachPipe.

Of course, I agree that names are not the main thing here. With any names, the
truly important point is that those options together will make an outstanding
mail client for attachment management. Thank you very much to the developers for
their good work.
Re comment 351:
What does Jesus have to do with this? Jesus saves, he doesn't detach ... :-)
(In reply to comment #356)
> Re comment 351:
> What does Jesus have to do with this? Jesus saves, he doesn't detach ... :-)

No kidding.  Removing attachments sounds rather Buddhist to me.

Even tough I'm not a big fan of 'Detach' as this is just not a word commonly
found in computer programs (besides Notes which I don't use), I think it would
be fine and people would get used to it very quickly. The Problem with Detach is
probably only with non-native speakers like me...
My proposition therefore would be (I guess that shouldn't be too hard to
implement) to display a dialog after clicking, shortly explaining the results of
Detach &co and offering a '[] Do not show this message again' option. Then it
would be very clear for every user what this function exactly does.
> > Re comment 351:
> > What does Jesus have to do with this? Jesus saves, he doesn't detach ... :-) 
> No kidding.  Removing attachments sounds rather Buddhist to me.

O.K - now its really becoming religious... P-)
Actually I am so glad that this feature is available now, that I would take any
of the suggested terms.
Maybe there is still a translation for simple english, which can describe the
procedure more explicitly then "detatch". (Though I think that detatch does not
inuitively describe why a link is left. But what the hack - it is the shortest
term by now)
However selecting multiple attatchments and processing them respectively in a
bunch is a necessity.
- Thanks to all involved in the -technological progress-
(In reply to comment #357)
> (In reply to comment #356)
> > Re comment 351:
> > What does Jesus have to do with this? Jesus saves, he doesn't detach ... :-)
> 
> No kidding.  Removing attachments sounds rather Buddhist to me.

  Well, that's called Nirvana ;)
Sorry for the bugspam... Just my 2 cents:

Perhaps the English definition for Detach is not the most correct for what we
want to use it, but for me it seems fine *as long as* we end it always with the
word "to", so as to give the user the understanding that he will have to specify
a location for the file(s). I like "Detach To" rather than "Detach As". You may
say that the "as" word also fulfills this idea of the location, but "to" is more
appropiate if a link to the file is going to be present on the message.

I would agree with confirmation dialogs only for the issue of deletion: leave a
note of the removal? Yes|No. And, of course, with an option of '[] Do not show
this message again', like Matt proposed.

BTW, is planned an "Undo" option for this operations? Imagine you want to
"retach" a file to a message...
Funny that the last 5 days there's probably more time spent on naming than the
last 5 years on developing. :-)

My take on it:

1) Keep it simple, don't overdo it, so I could live very well with:

-----
Save As
Delete
-----
Save All
Delete All
-----

2) If you want to go for a detach, use a simple word like 'Detach', 'Archive',
whatever. I don't care, but not those 'Detach As (Save + Delete)' monstrosities.
That's mixing up commands and help pages.

3) I liked that suggestion for 'Detach To' (could also be 'Archive To'), the
direction is more clear.

4) Any suggestion for pop-up / confirmation boxes must be from people who
haven't done a many hour 'email clean-up at the end of th project' night :). Any
extra key-click is then a nuisance.

5) Keep #1 in mind!! :-)

I used the Thunderbird's Detach (the extension) a lot. From that experience,
here are some suggestions:

A) Don't compact the folder after detaching!! That sounds to be a good idea, but
it can take a lot of time (full minute) when the folder is big (in my case at
the end of a project upto 100MB) and is much better done by the user 'once and
for all' at the end of having processed his whole folder. And why do it for a
detach, but not for a delete of the whole message. Again, keep it simple.

B) Take care that when you detach the next attachment the file-window opens up
the same directory as before. The current implementation had a small bug with
that, resulting in each time having to go down the tree again. That's OK for one
email, a horror when you clean up a few 100.

For the rest: Great that this finally happens!! Follow your own idea's and don't
listen to us :-). We'll live with it....
(In reply to comment #362)
> Funny that the last 5 days there's probably more time spent on naming than the
> last 5 years on developing. :-)
> 
> My take on it:
> 
> 1) Keep it simple, don't overdo it, so I could live very well with:
> 
> -----
> Save As
> Delete
> -----
> Save All
> Delete All
> -----
> 

+1
fix checked in for Thunderbird only; I'll check in the corresponding seamonkey
changes later today. Then we can spin up new bugs for any remaining issues,
e.g., if someone comes up with a better label for "Detach". I like Alec's
proposal of defenestrate, but that's probably not going to fly :-) I appreciate
everyone's interest in this bug - I'm sorry that I don't have time to respond to
all the comments but I've read and considered them all and am still open to a
better label (I'm not open to removing the detach feature itself, however, since
I believe it's quite useful for some users). 

Re the cut copy paste idea, that would require a whole bunch of backend support
that's not there.
(In reply to comment #364)
> fix checked in for Thunderbird only; I'll check in the corresponding seamonkey
> changes later today. 
David, thanks a lot for your effort.

> Then we can spin up new bugs for any remaining issues
I think so too. This bug is better to be closed when release of versin 1 of
great "Detach" feature, check-in of your patch.
There are at least three issues to be resolved, as Mscott says in Comment #334,
but these are to be discussed in new bug(s), towards "Detach feature version 2".
 (A) UI for user's operation including wording of the feature
     - What is the best wording for users?
     - What is the best operation for users?
       - "Detach" => Dialog for "save" or "not save"?
       - "Save All/As" => Dialog for "detach" or "not detach"?
 (B) Required functionality to release the "Detach" feature to all users
     - When/who copact folder?
     - What should be done on detached/saved attachment
       when forward/reply/"edit as new"?
     - Implement Eudra like way on attachment?
       (== Automatic "detach" & "save" of attachment data when mail download)
 (C) Required preference and UI for (A) and (B)
And discuss more, release version 3.0, brush up it, then release 3.1.
I believe "Version 3.1" will be best-seller feature, as MS Win 3.1 was. :-)
"Detach to ..." would be an improper construction. "Detach" is a transitive verb
which means it takes a direct object. If the direct object is not supplied, it
is implied. Saying "detach" implies "detach the attachment." It would be a
grammatical error (and poor English) to say, "detach the attachment to some
location." It would be like saying, "buy the shirt to my house."
Sorry for the spam: I forgot to point out that direct objects of transitive
verbs are never part of a prepositional phrase or nor will they ever be an
adverb. That means you can't properly say "detach to ..." or "detach as ..."
I cannot stress enough how much I think we should avoid the usage of the word
"Detach" altogether.  I have gotten somewhere in the neighborhood of 30 updates
to this bug in my inbox in the last few days, all debating not the
appropriateness of the word, but rather the inherent meaning.  If those of us
who are influencing the product can't decide on the meaning of the word, how do
we expect end users to know what it even means?

Attachments already have the following context menu when you right-click on them:

Open
Save As...
--------------
Save All...

Are people really suggesting that we turn it into:

Open
Save As...
Detach and Save...
Detach and Delete...
------------------------
Save All...

In the above scenario, if that is indeed the proposal, we have added two
commands that have ambiguous meanings at best that have two actions attached to
them.

"Detach and Save" implies that the attachment will be stripped from the email
and saved elsewhere.  Could this not be accomplished by simply saving the
attachment and then deleting it?  "Detach and Delete" implies that it's stripped
from the email and deleted, but not saved.  Why not just plain old "Delete
Atatchment"?  As I stated in an above response, if you want to save an
attachment then strip it from the email, you save, then you delete.  We don't
need multiple menu commands that have two actions attached to them when the
single-use commands already exist.

For example, we don't have a "Delete and Empty Trash" command in Thunderbird--we
still have to delete a message and then empty the trash.  Neither do we have a
"Delete and Compress Mailboxes" command for messages.  Why are we even
considering automatically compressing the mailbox after deleting an attachment?
 We don't automatically compress mailboxes when a user deletes a whole message
with an attachment, and we shouldn't automatically compress the mailbox when an
attachment is deleted, either.

Please, please, PLEASE keep it simple and completely avoid the usage of the word
 "Detach" anywhere.  The connotation of "Delete Attachment" is very clear.  How
about:

Open
Save As...
Delete Attachment
--------------------
Save All...

We've added a single menu command with a clear meaning that doesn't have to be
debated as to whether it's a transitive verb or not, and it fits the
requirements of what the functionality should do perfectly.  Don't add
unnecessary commands and functionality that supercedes existing behavior.
After reviewing all the comments shouldn't the menu items be

Save
Delete
Archive

1) Save, just makes a copy.
2) Delete, detaches the attachment and destroys it.
3) Archive, does detach the attachment but saves it in a new location. The link
to that new location is saved in place of the attachment and is used as an index
for retrieving the original attachment in the future.

By not using the word "Detach" on the menu the confusion of the two types of
detach is avoided.

In any case whatever wording is chosen it would be clear if there are more than
than "Save" and "Delete" that the other options do something different. That
should be sufficient.
(In reply to comment #369)

> Save
> Delete
> Archive

I like that suggestion!
But do we also have the option to "archive on arrival" and "save links only"
when saving the sent messages?
Maybe this is something for an extension, but it would really be nice to have...
Well, looking at the code of the last patch ("backend and front end changes for
detach"), it seems that the current context menu for attachments:

Open
Save As...
-----------
Save All...

is going to become the following:

Open
Save As...
-------------
Detach ...
Delete
-------------
Save All...
Detach All...
Delete All

The File -> Attachments menu is also modified in the patch.


(In reply to comment #367)
> Sorry for the spam: I forgot to point out that direct objects of transitive
> verbs are never part of a prepositional phrase or nor will they ever be an
> adverb. That means you can't properly say "detach to ..." or "detach as ..."

In this case, we must get also rid of the "Save As..." in all the programs of
this planet. "Save" is a transitive verb. :-)

Menu items are abbreviations, not complete sentences.

My vote is to add "As..." to the word "Detach" for even greater clarity. With
"As...", there is not possible confusion in the menu. Just look at it, it's
clear that "Detach As..." is not "Delete" (unless you patent a "Delete As...").
And "Save As..." is also clearly listed as a different function in the same menu:

Save As...
Detach As...
Delete

which evidently mean:

"SAVE this attachment AS file.ext"
"DETACH this attachment AS file.ext"
"DELETE this attachment; and that's that"

-------

(BTW, how about a more suitable place than Bugzilla for so many comments, for
example a thread in the Mozillazine.org forums?). ;-)
There is something now at MozillaZine Forums:

-------
"This checkin belongs to tomorrow builds, but I can't wait - it's too cool :)

#2920 [Mozilla Application Suite] Delete attachment from mail message in folder
(remove/strip attached files from email messages) [All] [Patch: support for
deleting and detaching attachments ]"

The Official 2005-03-02 builds - MozillaZine Forums
http://forums.mozillazine.org/viewtopic.php?p=1277397#1277397
-------

Also, they have posted a link to an interesting screenshot:

-------
Enfin gérer les pièces jointes ! ;)
http://fredbezies.jexiste.fr/dotclear/index.php?2005/03/02/183-enfin-gerer-les-pieces-jointes
-------
Save is not a transitive verb ... it's just a plain verb. The object of plain
verbs may be involved in prepositional phrases or adverbs.

The only debate I see about the meaning of detach is from non-native speakers.
If non-native speakers are having trouble with the English labels, then maybe
they should use their native language for the interface?

This is a case where there aren't two sides of the debate. Detach means what it
means. There are no alternative interpretations that could possibly be construed
as correct. This isn't a "he says, I say" thing. There is a correct definition
and that is it. There is no room to debate the meaning of "detach" any more than
there is room to debate the meaning of "walk".
(In reply to comment #371)
> (BTW, how about a more suitable place than Bugzilla for so many comments, for
> example a thread in the Mozillazine.org forums?). ;-)


One of the possible places is the thread that I've just opened (or any other
threads, naturally, to help lighten Bugzilla):

New: Deleting and detaching attachments (2920 almost fixed) - MozillaZine Forums
http://forums.mozillazine.org/viewtopic.php?t=228397
"Detach" comes from the French word "détacher", but that word in French not only
means "separate", but could also mean "dispose of".  So how could you expect
French users to correctly understand the meaning since "détacher" would be a
direct translation in localized version?

As to the comment on transitive verb. Well, if we follow your reasoning, then
those "Send to", "Add to", "Copy to", "Move to", etc, are all wrong because
strictly speaking we should write "send sth to", "add sth to", "Copy sth to",
"Move sth to", etc.  But the fact that people are so used to see "Send to"
rather than "Send this object to".

Sorry for this spam
We are talking about wording something as "detach to" or "detach as." These
aren't incorrect because they are missing an object, they are incorrect because
English grammar rules do not allow you to use the object of an intransitive verb
in a prepositional phrase or adverb. Use the transitive sense of the verb "save"
and you see how silly it becomes. Imagine saying, "The lifeguard saved the boy
to the shore." That makes no sense, and it would never be said by a native
speaker ... ever.
"Attach" and paper-clip icon are to suggest postal-mail physical acts of adding
papers to a letter by clip or staple ("Move" and connect).  For postal-mail
SFAIK there's no implication necessarily of photocopying the document first. But
by long convention for email, "Attach" *has* now come to imply the "Copy" (since
original file is not deleted), and as already stated, not practical for menu
labels to be so detailed. Attach is shortened form of, or at least
conventionally now means: "Attach Copy of".

Since there was no apriori relationship of the attached file to the message, a
strictly symmetric opposite of "Attach" would not leave a link/comment (also
already stated). And by postal-email analogy, detach should be "Detach and
File", meaning break the connection to the message, and Move it from the message
to elsewhere ("Detach and Move to, leave link", postal cover letters generally
list/identify their attachments).

This bug's trend is to reinforce a convention that Detach for email is shortened
form of "Detach and Move to" (true to postal-mail).

Thus Attach/Detach pair for postal-mail are like Move/Move, yet for email are
like Copy/Move (might be one contribution to the vigorous disagreement). I think
these are conventional meanings worth reinforcing (plus that Detach/Delete imply
leaving comment/link).

More precise but doomed as even less generally welcome for "Detach":
"Externalize" or "Externalize, leave link".
detach is a formation of the words "de" and "tach" - "de" meaning "of" in
spanish, and "tach" being short for "tachometer" which would measure rotations,
as in a car.

so really, detach means "from something that measures rotation" - clearly
inappropriate here. Attachments do not rotate, so we would be insane to continue
down this path, for fear of making the user dizzy.
(In reply to comment #377)
The nice thing is we have now a patch. Very grateful !

Words are not so important, use will make us get accustomed.

In case "Detach" makes a problem (which is not the case for me - even if I'm
French), here are some suggestions:
Deposit; discharge; excerpt; extract.

My preference is for "detach" or "deposit".
For the love of all that is good and right in this world and my email inbox,
please take this debate to some forum where every comment does not generate a
new email.  We've had 75 comments in the last three days.  Debating verb usage,
and what not.  I realize this comment is adding one more, but it is in the hope
that it will help stem the flood.  Why not the page linked to in #374?  I beg of
you, PLEASE!!
Attached patch seamonkey diffs (obsolete) — Splinter Review
Attachment #176100 - Flags: superreview?(mscott)
I have a proposal for a new feature in TB, based on this one. How about adding a
filter action to detach\delete attachments in incoming mail? One could set the
default location to detach attachments to (via a pref) and forget about manually
detaching all files (say, 'email contains @ ...'). It could also be used for old
mail (manually Run Filters in folders). What do you think about it? Should I
file a new bug for this feature request? This one is a bit too long already.
Anyway, great work so far!
(In reply to comment #382)
> (...) Should I file a new bug (...)

I think you may add your idea on filters to a related bug for the enhancements
that you suggest (Eudora style automatic detachment, etc.). It's bug 9309:
"option to have attachments auto saved to chosen location".


(In reply to comment #380)
> (...) please take this debate to some forum (...)

For example:

MozillaZine Forums
New: Deleting and detaching attachments (2920 almost fixed)
http://forums.mozillazine.org/viewtopic.php?t=228397
I've downloaded the 3/03 daily for Linux which has this patch and when I detach
or delete an attachment I get "The current command did not succeed.  The mail
server responded: Message contains invalid header."
A bit more information - using an IMAP account from the iPlanet / SunONE
Messaging Server.  I've tried with a new profile and my existing profile.
Anyone else seeing bug 284638? "The current command did not succeed. The mail
server responded: Message contains plain newlines."
Yes!  I get the "Bare Newlines" message almost any time a message is in a local
folder (either "Local Folders" or a POP account) and you try to copy/move it to
an IMAP folder/account.  I use Cyrus IMAP with Postfix, FWIW.  It seems that
Mozilla is malforming the message header/body when it writes it out to a
non-IMAP location, so it's not surprising that the same error occurs when
writing the modified message back to an IMAP location.
Comment on attachment 176100 [details] [diff] [review]
seamonkey diffs

I found a number of bugs in this patch...
Attachment #176100 - Attachment is obsolete: true
Attachment #176100 - Flags: superreview?(mscott) → superreview-
yeah, never mind - I'm not going to deal with Seamonkey...
Attached patch Suite Patch (obsolete) — Splinter Review
I've only done a bit of basic testing of this...
Attachment #176332 - Flags: superreview?(mscott)
Attachment #176332 - Flags: review?(bienvenu)
Attachment #176332 - Flags: review?(bienvenu) → review+
*** Bug 284937 has been marked as a duplicate of this bug. ***
*** Bug 285252 has been marked as a duplicate of this bug. ***
last night as i was forwarding this email to different addresses it keeps on
coming back as undeliverable automatically even when i delete it . I notice it
now that it is in my inbox 11 times that same message and I cannot read any of
my other mail.  here is the alert it states. Unable to write email to the
box,make sure the system allows you write privledges, and make sure you have
enough disk space to copy the box
It appears that attach/detach/delete functionality is coming. I want to make
sure bug 83040 is not forgotten. There needs to be an option to automatically
delete attachments for mail routed to the Sent folder. There's no point
detaching--the user already has the attachements in one form or another.

As a work-around, I assume the patch will let me select all messages in the Sent
folder and select Delete? This is better than nothing, but not very elegant.
(In reply to comment #394)
> There's no point detaching--the user already has the attachements in one form
or > another.

But the sender doesn't have the attachment then. I keep my attachments as a
version record of what I sent. People will want to do all kinds of things with a
detach feature. Trying to design umpteen different options just so the user
doesn't have to actually expend the effort of clicking "detach" seems
counterproductive to me, not to mention feature bloat.
Arghh! There's always someone.

First, did your note the optional part? Save all your attachements if you want to.

Second, I've used this feature quite a bit on my last mailer. It was the default
behavior there and I was shocked when my Sent folder was filling up with
attachments (and more shocked when I found no way or removing them). Other
people seem to value this feature, that's why bug 83040 exists.

Third, this is hardly code bloat. You place this option next to the option for
saving sent mail in a folder. You add an extra call to the delete attachment
code in the code that processes Sent mail.

Fourth, the main purpose of my comment was to find out if bug 83040 was being
fixed along with this. If not, does the patch allow for deleting attachments
from multiple selected messages in one step.

After those questions are answered, we can argue about whether this is a good
idea or not (and maybe somewhere besides this bug report). So can we hold the
arguments until we find out what the current plan is?

If it's not going to be implemented, I'd be willing to write an extension for
this (if I could figure out how to write extensions - does anyone know if there
is anything like an extension API? E-mail me with a response).
Please keep bug discussion to one issue at a time.  Discuss it over there.

Marking 83040 as blocked by this bug.

If 100+ people subscribe to that bug too, it will likely get some attention.
Blocks: 83040
Please don't forget the Suite patch before 1.8b2.
Flags: blocking1.8b2?
Moz suite has been killed so good bye.
Surely, just because Mozilla 1.8 has been cancelled, that does not preclude
moving forward with this issue for Thunderbird? I know some Suite devotees are
disappointed, but I would think that it would be fairly easy to make Firefox act
just like the Mozilla browser through extensions, for those who prefer that.
Flags: blocking-aviary1.1?
Been watching this discussion for a while and am very much in favor of this
being implemented in some fashion.  The thought just occured to me that while
moving a message to another folder, that would be the best time to strip an
attachment.  I recognize the overhead of stripping an attachment from a message
already in a folder (having to manipulate the folder directly).  It would be
really cool to have a right-click option on a message in the header pane to
"Move & strip attachment".  In this way, only the message would be moved to the
destination folder and a stub at the end detailing the name/type of attachment
that was stripped.

Sorry if this has been hashed through before, but I haven't read all 400+ comments!
fixed for Thunderbird - Neil has a patch to fix some remaining seamonkey issues.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.1?
If this no longer targets Seamonkey (although the upcoming patch comment is
welcome <grin>) then maybe the component should be changed to reflect that?
(In reply to comment #403)
> If this no longer targets Seamonkey (although the upcoming patch comment is
> welcome <grin>) then maybe the component should be changed to reflect that?

Not useful. IMHO the real solution is as long as the remaining Seamonkey
frontend patch isn't checked in to reopen the bug. Or simply check attachment
176332 [details] [diff] [review] in. :-)
The confusion is only because this bug stands for rather 3 bug reports (one for
backend Core and two for the frontend MAS/TB). Comment 402 makes it clear that
this is fixed for the TB side. 
It's GREAT to see that this bug is being worked on.  Thanks for your efforts.
I tested the 11 March 2005 nightly build (1.0.2) and wanted to report here that 
although it works the message which has had an attachment deleted disappears 
from the folder for up to 2 minutes.  My system for testing is winXP sp2 and TB 
is in IMAP mode to a cyrus imap server.

BTW, I don't care about the discussions about the language for 'detatach'.  
Detatch seems logical to me but it's the delete function which is the important 
one.  

Cheers
Seamonkey is not dead - see bug 286066. We should not forget to fix this on what
we used to call "the trunk".
Whiteboard: seamonkey-not-fixed
The disappearing email would most likely be due to the need to create a new
email and delete the old one.  The time before it shows up would be related to
the new mail checking interval either locally or on the imap server.
(In reply to comment #407)

I assume this bug is still in development so I'll post my findings though I'm 
aware that the programmers probably know this already.

11 March 2005 nightly build (1.0.2)
I can confirm (when using IMAP) that the delay is due to the checking for new 
mail.  Pressing F5 or "get new mail" makes the message reappear.  If the 
attachment is deleted from a message in a folder other than inbox then it is 
not visible until the folder is refreshed (by switching to another folder and 
then back).  On a non-imap folder there is no delay but both copies of the 
messages are still intact - one with & one without the attachment.

When a user moves a message from one folder to another they do not have to wait 
for a new mail checking interval or folder refresh.  Deleting an attachment 
should not be treated differently.
Using IMAP, the message with deleted attachment comes back as unread too 
although from a user perspective it obviously has been read.  Any chance of 
having the message set as read and also refreshing the inbox when an  
attachment is deleted?  

Cheers
Julian

> The disappearing email would most likely be due to the need to create a new
> email and delete the old one.  The time before it shows up would be related to
> the new mail checking interval either locally or on the imap server.
Attachment #176332 - Attachment is obsolete: true
Attachment #178638 - Flags: superreview?(bienvenu)
Attachment #178638 - Flags: superreview?(bienvenu) → superreview+
Fixed on suite.
(In reply to comment #410)
> Fixed on suite.

Thanks! Are the new icons used for SM? I don't see a reference (like for TB in
http://lxr.mozilla.org/seamonkey/source/mail/base/content/msgHdrViewOverlay.js#1270).

http://lxr.mozilla.org/seamonkey/search?string=message-mail-attach-del
Whiteboard: seamonkey-not-fixed
I am on Mozilla Suite 1.8b2.
From which version will we be able to test the changes?
Is there a special download link?
thanks
(In reply to comment #402)
> fixed for Thunderbird - Neil has a patch to fix some remaining seamonkey issues.

I'm using the windows nightly build from 2005-03-26.  Here are some impressions:

- When I delete an attachment, a new copy of the message is created without the
attachments, but the original message is not deleted nor marked as such.  Is
this a new feature?  I remember a previous build did delete the message.
- If I order by size, the newly created message will appear at a different
place.  It's obvious from the programming point of view, but not very much for
the user.  The previous bug make me create lots of copies with deleted
attachments before noticing the message was indeed in another place.  Is it
possible to keep the message at an "invalid" order, just until a user commanded
reordering occur?

Note: I did try to see if some option was created to set this behaviour, but
calling Tools/Options crashes the program.  I'll try a newer build later.
(In reply to comment #414)
> - When I delete an attachment, a new copy of the message is created without the
> attachments, but the original message is not deleted nor marked as such.

Bug 286655 (Bug 287938 also) is opened for the problem.

> - If I order by size, the newly created message will appear at a different
> place.  It's obvious from the programming point of view, but not very much for
> the user.

We'd better to respect David's willing(Comment #364).
> Then we can spin up new bugs for any remaining issues
Open new bug for new problem, with "detach" in summary, please.
(In reply to comment #415)
> (In reply to comment #414)
> > - When I delete an attachment, a new copy of the message is created without the

This is - as far as I know - done by really copying the message, leading to a
new "message id". Could anyone comment on this?
If you have your message sorting set to "order received" (because so many dates
are wrong), it is very disturbing that old messages  are re-sorted to the top of
the list when you delete their attachments, as is the case with Ausdilecce's
extension.
Is it possible to retain the "message id" when deleting attachments?
it's not possible to retain the msg key after editing the message. IMAP has no
provision for it, and our pop3 store format doesn't allow it either.
(In reply to comment #417)
> it's not possible to retain the msg key after editing the message. IMAP has no
> provision for it, and our pop3 store format doesn't allow it either.

OK, thanks, a pity.
Right now message IDs are numerically increasing by 1.
Would it be possible to create some other step size ID that would be sorted
between the previous and next message? Something like:
28671  ; 28672  ; 28673 -> Attachment stored from message 28672
28671  ; 28672a ; 28673
or does it have to be the next higher number?
Thank you!
Hmmm, I thought I already mentiond this (deja-vu?), but:

When an attachment is deleted or detached from a *digitally signed* e-mail, the
resulting e-mail (without the attachment) is "invalid" and, even worse, blank!
Dataloss? New bug?
The digital signature is supposed to show that the message hasn't been modified
since the sender signed it. Removing the attachment is obviously a modification,
and only the sender can recreate the signature (of course). However, the client
should obviously do something neater in that situation - maybe remove the
signature at the same time as removing the attachment? or have a check so that
if the signature is invalid on a message where the attachment is removed, we can
give a specific error and show the message anyway.

Either way, that issue, like any other remaining issues, should be in a new bug.
I filed bug 288700 to track that (cryptographic signed mails in combination with
the delete attachment feature).
*** Bug 290016 has been marked as a duplicate of this bug. ***
I am using IMAP of the 20040412 Nightly Build and experiencing problems deleting
multiple attachments from an email.  Say an email has four attachments that I
delete, then TB will make four copies of the email with each copy having a
different attachment deleted.  My email server is iMail.

Dan
(In reply to comment #423)
> I am using IMAP of the 20040412 Nightly Build and experiencing problems deleting
> multiple attachments from an email.  Say an email has four attachments that I
> delete, then TB will make four copies of the email with each copy having a
> different attachment deleted.  My email server is iMail.
> 
> Dan

I was doing a multiple select then DELETE.  I just realized that DELETE ALL
works as expected.  But what if I want to delete 2 of the 4 with a multiple
select then DELETE?

Dan
*** Bug 290516 has been marked as a duplicate of this bug. ***
Attachment #176332 - Flags: superreview?(mscott)
Attachment #173785 - Flags: superreview?(mscott)
Attachment #173793 - Flags: superreview?(mscott)
Dan, you should probably file a new bug for that behaviour with IMAP.
No longer blocks: majorbugs
Blocks: 303443
Blocks: 304359
Those that are interested..

You cannot pick and/or choose the value for 'order Received'.  This value is the
starting offset of that particular message in the message file..  When ANY
message is added to a folder ( either by a copy from another folder or a
incoming message or whatever) , its 'order received' will be updated ( because
its offset has changed.. )

This is NOT a 'bug' in this feature ( or my extension ).. It is how TB works..

I am also pretty sure the messageId of the modified message does not change ( or
threading would fail ).  I know for a fact that my extension does NOT modify the
messageId.

As far as sorting your TB folder by 'order received'... I would advise against
this practice since 'order received' is really 'order recieved *into this
folder*' and NOT 'global' order received..

BTW..  great job on implementing this feature guys..  
I would argue in favour of "don't change the sequence of messages upon
attachment operations".

(In reply to comment #427)
> You cannot pick and/or choose the value for 'order Received'.  This value is the
> starting offset of that particular message in the message file..  When ANY

Depending on "choose": if you choose not to place a new copy of the message into
the folder, but to change the original message...
Then again, this might not be possible on IMAP (?).

> As far as sorting your TB folder by 'order received'... I would advise against
> this practice since 'order received' is really 'order recieved *into this
> folder*' and NOT 'global' order received..

OK, but are there better alternatives to "order received"? I would be willing to
learn, but 1) sort by date is a very bogus solution since most people seem to
have their clock wrong 2) 'order received' on the INBOX gives the desired result
(to have the newest messages displayed topmost) in nearly all cases (unless you
remove attachments, of course).
And as I said, I am not aware of any method for sorting eMails that is more
sensible than 'order received'... Of course, if TB could be modified to generate
an additional header field stating when it first "saw" that message, ...

> BTW..  great job on implementing this feature guys..  

Certainly, thanky for this very useful feature!
it's not possible with imap; it's not possible with local mail messages given
our mailbox store. If it were possible to maintain order received, we would have
done it.

If someone will fix the date: field to get it from the received by message
headers, then date sorting will be much more useful.
(In reply to comment #429)
> it's not possible with imap; it's not possible with local mail messages given
> our mailbox store. If it were possible to maintain order received, we would have

OK, I really appreciate that you tried.

> If someone will fix the date: field to get it from the received by message
> headers, then date sorting will be much more useful.

That would be absolutely cool. It can't be that hard to use the date string at
the end of the topmost Recieved: Filed, instead of that from the Date: field,
for the "sort by date" button.
(Unfortunately I never compiled TB so the learning curve for me would be quite
steep...) I would certainly applaud to the person wo does this (probably easy?)
change!
*** Bug 305114 has been marked as a duplicate of this bug. ***
1 - Why this bug is marked:
          Status: RESOLVED
      Resolution: FIXED
Target Milestone: -
when the enhancement is never done?

2 - About when we can use this very usefull enhancement?
1 - Why this bug is marked:
          Status: RESOLVED
      Resolution: FIXED
Target Milestone: -
when the enhancement is never done?

2 - About when we can use this very usefull and most voted enhancement?
are you perhaps looking at a 1.0x build instead of a build with the feature in
it, like a nightly thunderbird build, or 1.1a2?
(In reply to comment #434)
> are you perhaps looking at a 1.0x build instead of a build with the feature in
> it, like a nightly thunderbird build, or 1.1a2?

There used to be a [fixed-aviary] field which might have helped here. Since
1.0.x is the only game in town as far as release versions, what else does she
have for choices as 1.1.x is for "testing purposes only"? I assume bugzilla is
for both testers of "test software" as well as users of "release" software,
right? Maybe this time around, Thunderbird 1.1 can come out first. There is a
crying need for it.
The bug is marked for "Mozilla Application Suite" in component "Main Mail Window".
Aviary and 1.1 are referred to Thunderbird only or no?
(In reply to comment #333)
> 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.

In Thunderbird 1.5 when I have deleted or detached an attachment, there is no change in the icon to let me know which emails have been "cleansed" and which haven't. I would suggest that the attachment icon in the Inbox list window either be removed after an attachment has been deleted or changed to a different icon.
(In reply to comment #437)
> I would suggest that the attachment icon in the Inbox list window
> either be removed after an attachment has been deleted or changed to a
> different icon.

What if you delete/detach only one of two attachments?

If any attachment remains, leave the icon. If no attachment -> no icon.
(In reply to comment #438)
> (In reply to comment #437)
> > I would suggest that the attachment icon in the Inbox list window
> > either be removed after an attachment has been deleted or changed to a
> > different icon.
> 
> What if you delete/detach only one of two attachments?
> 
> If any attachment remains, leave the icon. If no attachment -> no icon.
> 

In either case, I would also expect that when the message was opened, there would be some change to the icons in the attachment bar .... in the case of Comment #438, the only icons left should be the ones that are still attached to the email. Perhaps the "detached" icons can be grey (with target information) and the "deleted" icons (and related information) can be removed entirely from the message thus leaving no trace of their having ever existed. If you attempt to delete an attachment icon that had been previously detached, then that would delete the detach location information as well as any trace of the former attachment's previous existence.
I agree with "#433 From Valerio Messina  2005-08-18" and have 
used a large part of that post in mine below:

1 - Why this bug is marked:
          Status: RESOLVED
      Resolution: FIXED
Target Milestone: -
when the enhancement has never been done?

NOTE: 
The bug is marked for "Mozilla Application Suite" in component 
"Main Mail Window" -- I'm using 1.7.12 and (as of today) there
is no newer version.

2 - About when we can use this very useful and most-voted enhancement?

3 - It may also be the OLDEST BUG -- one comment at the top is from 10/26/98.
It is the oldest I've seen!!!

4 - Today I spent a fair amount of time trying to delete an attachment 
to an e-mail and I got no where with my efforts.

5 - If I've missed a magic bullet used to activate this "Resolved Fixed"
problem, please educate me.
PLEASE NOTE: This bug/enhancement *is* done in the suite. The Mozilla suite is now called "Seamonkey", and the first release under this name is currently in Beta. 

See: http://www.mozilla.org/projects/seamonkey/

I have checked and the ability to delete attachments is present and working in 1.0b.

So, it seems reasonable to say it is fixed.
(In reply to comment #441)
> PLEASE NOTE: This bug/enhancement *is* done in the suite. The Mozilla suite is
> now called "Seamonkey", and the first release under this name is currently in
> Beta. 
> See: http://www.mozilla.org/projects/seamonkey/
I knew that also the Mozilla Application Suite 1.7.x was named seamonkey.
So now the old "Mozilla Application Suite" 1.7.x and new "seamonkey" 1.x are two different product.
The bug marker is "Mozilla Application Suite", in the dropdown menu there aren't "seamonkey" item.
How the user can open a bug for the old 1.7.x suite and understand the difference from the new seamonkey 1.x?
Well for the new seamonkeyBeta that is fixed, but until 1.0final of this, it is very confusing.
Please differentiate inserting two item in bugzilla.
I think that all the user that voted for this bug, mean the old suite, as new seamonkey exist from few months, or no?
This eMail is meant as a test case for the attachment delete functionality of Thunderbird 1.5 not working. See Comment #443.
I am very sorry, but could this bug please be reopened?
Deleting attachments does work only intermittently using Thunderbird Version 1.5.0.4 (20060516) on WinXP on an IMAP store.
I did 2 successful deletes (BTW did anybody open a new bug for the "order received vs. more meaningful date field" agenda or should I do it?), and now am stuck with a message that just keeps being copied to new message IDs with all the attachments in place. I tried selecting the PDF and pressing delete, and selecting "delete all".
I am not so sure how to reference the mail in question for s/o to have a look at, I uploaded it as attachment (id=225575). To reduce file size, I deleted the middle portion of the attached PDF.
Maybe the problem has to do with the eMail being created on a Mac?
I would very much appreciate any input on this problem.
Sincerely, Simon
Comment on attachment 225575 [details]
eMail with PDF document attached, not deleted by TB 1.5

>Return-Path: <schmerold@uni-tuebingen.de>
>X-Original-To: tkibs01@mailserv06.uni-tuebingen.de
>Delivered-To: tkibs01@mailserv06.uni-tuebingen.de
>Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.3.13])
>	by mailserv06.uni-tuebingen.de (Postfix) with ESMTP id 8788E941D2;
>	Wed, 14 Jun 2006 07:56:33 +0200 (CEST)
>Received: from [134.2.125.215] (buero-9.neurologie.uni-tuebingen.de [134.2.125.215])
>	by mx03.uni-tuebingen.de (8.12.11.20060308/8.12.11) with ESMTP id k5E5uIBB024661;
>	Wed, 14 Jun 2006 07:56:18 +0200
>Mime-Version: 1.0 (Apple Message framework v749.3)
>To: Winfried Ilg <winfried.ilg@uni-tuebingen.de>,
>	Matthis Synofzik <M.Synofzik@gmx.de>,
>	Andreas Nieder <andreas.nieder@uni-tuebingen.de>,
>	Bruno Preilowski <preilowski@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Wolfgang_M=FCller-Schauenburg?= <wolfgang.mueller-schauenburg@uni-tuebingen.de>,
>	Hubert Preissl <hubert.preissl@uni-tuebingen.de>,
>	Eberhart Zrenner <ezrenner@uni-tuebingen.de>,
>	Gregor Rainer <gregor.rainer@tuebingen.mpg.de>,
>	Marc Himmelbach <marc.himmelbach@uni-tuebingen.de>,
>	Suryadeep Dash <suryadeep.dash@uni-tuebingen.de>,
>	Mathias Jucker <mathias.jucker@uni-tuebingen.de>,
>	Annette Denzinger <annette.denzinger@uni-tuebingen.de>,
>	Cornelius Schwarz <cornelius.schwarz@uni-tuebingen.de>,
>	GSNBS Studenten <gsforum@uni-tuebingen.de>,
>	Florent Haiss <florent.haiss@uni-tuebingen.de>,
>	Michael Weller <michael.weller@uni-tuebingen.de>,
>	Hans-Otto Karnath <karnath@uni-tuebingen.de>,
>	Volker Gauck <volker.gauck@uni-tuebingen.de>,
>	Andreas Luft <andreas.luft@onlinehome.de>,
>	Horst Herbert <neuro.school@uni-tuebingen.de>,
>	Christian Wehrhahn <christian.wehrhahn@tuebingen.mpg.de>,
>	Peter Thier <thier@uni-tuebingen.de>,
>	Christoph Linnemann <christoph.linnemann@uni-tuebingen.de>,
>	Markus Fendt <markus.fendt@uni-tuebingen.de>,
>	Konstantin Tziridis <konstantin.tziridis@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Ludger_Sch=F6ls?= <ludger.schoels@uni-tuebingen.de>,
>	Alla Ignashchenkova <alla@uni-tuebingen.de>,
>	Daniela Vallentin <daniela.vallentin@uni-tuebingen.de>,
>	Graduiertenkolleg Neurobiologie <gkkn@uni-tuebingen.de>,
>	Wolfgang Wick <wolfgang.wick@uni-tuebingen.de>,
>	Wolfgang Pfaff <wolfgang.pfaff@med.uni-tuebingen.de>,
>	Wolfgang Grodd <wolfgang.grodd@med.uni-tuebingen.de>,
>	Antonino Casile <antonino.casile@tuebingen.mpg.de>,
>	=?ISO-8859-1?Q?Heinrich_B=FClthoff?= <heinrich.buelthoff@tuebingen.mpg.de>,
>	Monika Fruhmann Berger <monika.fruhmann@uni-tuebingen.de>,
>	Christian Erhardt <christian.erhardt@med.uni-tuebingen.de>,
>	Thomas Haarmeier <thomas.haarmeier@uni-tuebingen.de>,
>	Arthur Melms <arthur.melms@uni-tuebingen.de>,
>	Karen Lidzba <knlidzba@med.uni-tuebingen.de>,
>	Oana Tudusciuc <oana.tudusciuc@uni-tuebingen.de>,
>	Fahad Sultan <fahad.sultan@uni-tuebingen.de>,
>	Johannes Dichgans <johannes.dichgans@uni-tuebingen.de>,
>	Nikos Logothetis <nikos.logothetis@tuebingen.mpg.de>,
>	Henner Giedke <henner.giedke@med.uni-tuebingen.de>,
>	Martin Staudt <martin.staudt@med.uni-tuebingen.de>,
>	Joachim Ostwald <joachim.ostwald@uni-tuebingen.de>,
>	Hans-Ulrich Schnitzler <hans-ulrich.schnitzler@uni-tuebingen.de>,
>	Hans-Joachim Wagner <hans-joachim.wagner@uni-tuebingen.de>,
>	Ute Grosshennig <ute.grosshennig@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?J=F6rn_Pomper?= <joern.pomper@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Barbara_H=E4ndel?= <barbara.haendel@uni-tuebingen.de>,
>	Dagmar Maier <dagmar.maier@tuebingen.mpg.de>,
>	Uwe Ilg <uwe.ilg@uni-tuebingen.de>,
>	Werner Schmidt <werner.schmidt@uni-tuebingen.de>,
>	Christian Plewnia <christian.plewnia@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Maik_St=FCttgen?= <maik.stuettgen@uni-tuebingen.de>,
>	Karl Beykirch <karl.beykirch@tuebingen.mpg.de>,
>	Hermann Ackermann <hermann.ackermann@uni-tuebingen.de>,
>	Nicolas Catz <nicolas.catz@uni-tuebingen.de>,
>	Christoph Braun <christoph.braun@med.uni-tuebingen.de>,
>	Ilka Diester <ilka.diester@uni-tuebingen.de>,
>	Hubertus Becker <hubertus.becker@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Martin_M=F6ck?= <moeck@anatu.uni-tuebingen.de>,
>	Graduate School <neuro.office@uni-tuebingen.de>,
>	Marc Ernst <marc.ernst@tuebingen.mpg.de>,
>	=?ISO-8859-1?Q?Bernhard_Sch=F6lkopf?= <bernhard.schoelkopf@tuebingen.mpg.de>,
>	Michaela Burkhardt <michaela.burkhardt@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Ingeborg_Kr=E4geloh-Mann?= <igkraege@med.uni-tuebingen.de>,
>	Simon Bock <simon.bock@uni-tuebingen.de>,
>	Peter Dicke <peter.dicke@uni-tuebingen.de>,
>	Hendrik Dietrich <hendrik.dietrich@uni-tuebingen.de>,
>	=?ISO-8859-1?Q?Almut_Sch=FCz?= <almut.schuez@tuebingen.mpg.de>,
>	Christine Pedroarena <christine.pedroarena@uni-tuebingen.de>,
>	Thilo Hinterberger <thilo.hinterberger@uni-tuebingen.de>,
>	Susanne Leiberg <susanne.leiberg@med.uni-tuebingen.de>,
>	Valentino Braitenberg <valentino.braitenberg@tuebingen.mpg.de>,
>	=?ISO-8859-1?Q?Frank_Sch=E4ffel?= <frank.schaeffel@uni-tuebingen.de>,
>	Jan Jastorff <jan.jastorff@tuebingen.mpg.de>,
>	Boris Kotchoubey <boris.kotchoubey@uni-tuebingen.de>,
>	Marko Wilke <MWilke@gmx.de>,
>	Martin Giese <martin.giese@uni-tuebingen.de>,
>	Werner Lutzenberger <werner.lutzenberger@uni-tuebingen.de>,
>	Barbara Wilhelm <b.wilhelm@uni-tuebingen.de>,
>	Zoe Kourtzi <zoe.kourtzi@tuebingen.mpg.de>,
>	Sylvana Freyberg <sylvana.freyberg@uni-tuebingen.de>,
>	Niels Birbaumer <niels.birbaumer@uni-tuebingen.de>,
>	Dirk Wildgruber <dirk.wildgruber@med.uni-tuebingen.de>,
>	Sergejus Butovas <sergejus.butovas@uni-tuebingen.de>,
>	Meng-Larn Lee <meng-larn.lee@uni-tuebingen.de>,
>	Hanspeter Mallot <hanspeter.mallot@uni-tuebingen.de>,
>	Thomas Gasser <thomas.gasser@med.uni-tuebingen.de>,
>	Friedemann Bunjes <friedemann.bunjes@uni-tuebingen.de>,
>	Dieter Kern <dieter.kern@uni-tuebingen.de>,
>	Barbara Lange <b.lange@uni-tuebingen.de>
>Message-Id: <1C6A239B-1551-4FD6-AF4D-66A9F0FF95E6@uni-tuebingen.de>
>Content-Type: multipart/alternative; boundary=Apple-Mail-5-158498447
>From: Dagmar Heller-Schmerold <schmerold@uni-tuebingen.de>
>Subject: Neurokolloquium
>Date: Wed, 14 Jun 2006 07:53:09 +0200
>X-Mailer: Apple Mail (2.749.3)
>X-AntiVirus: checked by AntiVir Milter (version: 1.1.2-1; AVE: 7.1.0.13; VDF: 6.35.0.28; host: mx03)
>
>
>--Apple-Mail-5-158498447
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=UTF-8;
>	delsp=yes;
>	format=flowed
>
>Sehr geehrte Damen und Herren
>
>wegen unvorhersehbarer Terminschwierigkeiten muss der Vortrag von =20
>Prof. Fahle (Bremen) auf den 27. Juli verschoben werden. Bitte =20
>beachten Sie das aktualisierte Programm des Neurokolloquiums (s. =20
>Anhang).
>
>Wir laden sehr herzlich zum n=C3=A4chsten Vortrag am 6. Juli ein. Prof. =20=
>
>Reichenbach (Leipzig) wird zum Thema "Neuroglia - the eminence gris =20
>of CNS" sprechen. =C3=9Cber eine rege Teilnahme w=C3=BCrden wir uns =
>freuen.
>
>Mit freundlichen Gr=C3=BC=C3=9Fen,
>D. Heller-Schmerold
>
>=EF=BF=BC
>
>Dagmar Heller-Schmerold
>Hertie-Institut f=C3=BCr klinische Hirnforschung
>Abt. Kognitive Neurologie
>und
>Sonderforschungsbereich 550
>Gesch=C3=A4ftsstelle
>Hoppe-Seyler-Str. 3
>D-72076 T=C3=BCbingen
>
>Tel. +49 (0)7071 29 85662
>Fax +49 (0)7071 29 5326
>e-mail: schmerold@uni-tuebingen. de
>
>
>
>
>
>--Apple-Mail-5-158498447
>Content-Type: multipart/mixed;
>	boundary=Apple-Mail-6-158498448
>
>
>--Apple-Mail-6-158498448
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=ISO-8859-1
>
><HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">Sehr geehrte Damen und =
>Herren<DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><SPAN =
>class=3D"Apple-style-span">wegen unvorhersehbarer Terminschwierigkeiten =
>muss der Vortrag von Prof. <B>Fahle</B> (Bremen) auf den <B>27. Juli</B> =
>verschoben werden. Bitte beachten Sie das aktualisierte Programm des =
>Neurokolloquiums (s. Anhang).</SPAN></DIV><DIV><BR =
>class=3D"khtml-block-placeholder"></DIV><DIV><SPAN =
>class=3D"Apple-style-span">Wir laden sehr herzlich zum n=E4chsten =
>Vortrag am <B>6. Juli</B> ein. Prof. <B>Reichenbach</B> (Leipzig) wird =
>zum Thema "Neuroglia - the eminence gris of CNS" sprechen. =DCber eine =
>rege Teilnahme w=FCrden wir uns freuen.</SPAN></DIV><DIV><BR =
>class=3D"khtml-block-placeholder"></DIV><DIV>Mit freundlichen =
>Gr=FC=DFen,</DIV><DIV>D. Heller-Schmerold</DIV><DIV><BR =
>class=3D"khtml-block-placeholder"></DIV><DIV><SPAN></SPAN></DIV></BODY></H=
>TML>=
>
>--Apple-Mail-6-158498448
>Content-Type: multipart/appledouble;
>	boundary=Apple-Mail-7-158498448
>Content-Disposition: inline
>
>
>--Apple-Mail-7-158498448
>Content-Transfer-Encoding: base64
>Content-Type: application/applefile;
>	name="NK_SS06_neu.pdf"
>Content-Disposition: inline;
>	filename=NK_SS06_neu.pdf
>
>AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAA8AAAACAAAA
>VwAAI/hQREYgQ0FSTwAATktfU1MwNl9uZXUucGRmAAABAAAAI5wAACKcAAAAXAAAAAAAAAAAAAAA
>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>AAAAIoYihgAAAAAAgABYABEC/wwA//4AAABIAAAASAAAAAAAAACAAFgAAAAAAB4AAQAKAAAAAACA
>AFgAmIAMAAAAAACAAFgAAAAAAAAAAABIAAAASAAAAAAAAQABAAEAAAABB/shrAf6y8QAAAABgAAA
>AQAA////////AAAAAAAAAAAAAAAAAIAAWAAAAAAAgABYAAMC9QAE9gAAEAL1AAL1AAL1AAL1AAL1
>AAL1AAL1AAL1AAL1AAL1AAL1AAL1AAL1AAL1AAT2AAD/BPYAAP8C9QAC9QAE9gAA/wT2AAD/AvUA
>AvUABPYAAP8E9gAA/wL1AAL1AAT2AAD/AvUABPYAAP8C9QAE9gAA/wT2AAD/BPYAAP8C9QAE9gAA
>/wT2AAD/AvUAAvUABPYAAP8E9gAA/wL1AAL1AAT2AAD/BPYAAP8C9QAC9QAC9QAC9QAC9QAC9QAC
>9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC
>9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC
>9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC
>9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAC9QAA
>mIBYAAAAAACAAFgAAAAAAAAAAABIAAAASAAAAAAACAABAAgAAAAIB/shYAf6yJgAAAAIgAAA/wAA
>////////AAD/////zMwAAP////+ZmQAA/////2ZmAAD/////MzMAAP////8AAAAA///MzP//AAD/
>/8zMzMwAAP//zMyZmQAA///MzGZmAAD//8zMMzMAAP//zMwAAAAA//+Zmf//AAD//5mZzMwAAP//
>mZmZmQAA//+ZmWZmAAD//5mZMzMAAP//mZkAAAAA//9mZv//AAD//2ZmzMwAAP//ZmaZmQAA//9m
>ZmZmAAD//2ZmMzMAAP//ZmYAAAAA//8zM///AAD//zMzzMwAAP//MzOZmQAA//8zM2ZmAAD//zMz
>MzMAAP//MzMAAAAA//8AAP//AAD//wAAzMwAAP//AACZmQAA//8AAGZmAAD//wAAMzMAAP//AAAA
>AAAAzMz/////AADMzP//zMwAAMzM//+ZmQAAzMz//2ZmAADMzP//MzMAAMzM//8AAAAAzMzMzP//
>AADMzMzMzMwAAMzMzMyZmQAAzMzMzGZmAADMzMzMMzMAAMzMzMwAAAAAzMyZmf//AADMzJmZzMwA
>AMzMmZmZmQAAzMyZmWZmAADMzJmZMzMAAMzMmZkAAAAAzMxmZv//AADMzGZmzMwAAMzMZmaZmQAA
>zMxmZmZmAADMzGZmMzMAAMzMZmYAAAAAzMwzM///AADMzDMzzMwAAMzMMzOZmQAAzMwzM2ZmAADM
>zDMzMzMAAMzMMzMAAAAAzMwAAP//AADMzAAAzMwAAMzMAACZmQAAzMwAAGZmAADMzAAAMzMAAMzM
>AAAAAAAAmZn/////AACZmf//zMwAAJmZ//+ZmQAAmZn//2ZmAACZmf//MzMAAJmZ//8AAAAAmZnM
>zP//AACZmczMzMwAAJmZzMyZmQAAmZnMzGZmAACZmczMMzMAAJmZzMwAAAAAmZmZmf//AACZmZmZ
>zMwAAJmZmZmZmQAAmZmZmWZmAACZmZmZMzMAAJmZmZkAAAAAmZlmZv//AACZmWZmzMwAAJmZZmaZ
>mQAAmZlmZmZmAACZmWZmMzMAAJmZZmYAAAAAmZkzM///AACZmTMzzMwAAJmZMzOZmQAAmZkzM2Zm
>AACZmTMzMzMAAJmZMzMAAAAAmZkAAP//AACZmQAAzMwAAJmZAACZmQAAmZkAAGZmAACZmQAAMzMA
>AJmZAAAAAAAAZmb/////AABmZv//zMwAAGZm//+ZmQAAZmb//2ZmAABmZv//MzMAAGZm//8AAAAA
>ZmbMzP//AABmZszMzMwAAGZmzMyZmQAAZmbMzGZmAABmZszMMzMAAGZmzMwAAAAAZmaZmf//AABm
>ZpmZzMwAAGZmmZmZmQAAZmaZmWZmAABmZpmZMzMAAGZmmZkAAAAAZmZmZv//AABmZmZmzMwAAGZm
>ZmaZmQAAZmZmZmZmAABmZmZmMzMAAGZmZmYAAAAAZmYzM///AABmZjMzzMwAAGZmMzOZmQAAZmYz
>M2ZmAABmZjMzMzMAAGZmMzMAAAAAZmYAAP//AABmZgAAzMwAAGZmAACZmQAAZmYAAGZmAABmZgAA
>MzMAAGZmAAAAAAAAMzP/////AAAzM///zMwAADMz//+ZmQAAMzP//2ZmAAAzM///MzMAADMz//8A
>AAAAMzPMzP//AAAzM8zMzMwAADMzzMyZmQAAMzPMzGZmAAAzM8zMMzMAADMzzMwAAAAAMzOZmf//
>AAAzM5mZzMwAADMzmZmZmQAAMzOZmWZmAAAzM5mZMzMAADMzmZkAAAAAMzNmZv//AAAzM2ZmzMwA
>ADMzZmaZmQAAMzNmZmZmAAAzM2ZmMzMAADMzZmYAAAAAMzMzM///AAAzMzMzzMwAADMzMzOZmQAA
>MzMzM2ZmAAAzMzMzMzMAADMzMzMAAAAAMzMAAP//AAAzMwAAzMwAADMzAACZmQAAMzMAAGZmAAAz
>MwAAMzMAADMzAAAAAAAAAAD/////AAAAAP//zMwAAAAA//+ZmQAAAAD//2ZmAAAAAP//MzMAAAAA
>//8AAAAAAADMzP//AAAAAMzMzMwAAAAAzMyZmQAAAADMzGZmAAAAAMzMMzMAAAAAzMwAAAAAAACZ
>mf//AAAAAJmZzMwAAAAAmZmZmQAAAACZmWZmAAAAAJmZMzMAAAAAmZkAAAAAAABmZv//AAAAAGZm
>zMwAAAAAZmaZmQAAAABmZmZmAAAAAGZmMzMAAAAAZmYAAAAAAAAzM///AAAAADMzzMwAAAAAMzOZ
>mQAAAAAzM2ZmAAAAADMzMzMAAAAAMzMAAAAAAAAAAP//AAAAAAAAzMwAAAAAAACZmQAAAAAAAGZm
>AAAAAAAAMzMAAO7uAAAAAAAA3d0AAAAAAAC7uwAAAAAAAKqqAAAAAAAAiIgAAAAAAAB3dwAAAAAA
>AFVVAAAAAAAAREQAAAAAAAAiIgAAAAAAABERAAAAAAAAAADu7gAAAAAAAN3dAAAAAAAAu7sAAAAA
>AACqqgAAAAAAAIiIAAAAAAAAd3cAAAAAAABVVQAAAAAAAEREAAAAAAAAIiIAAAAAAAAREQAAAAAA
>AAAA7u4AAAAAAADd3QAAAAAAALu7AAAAAAAAqqoAAAAAAACIiAAAAAAAAHd3AAAAAAAAVVUAAAAA
>AABERAAAAAAAACIiAAAAAAAAEREAAO7u7u7u7gAA3d3d3d3dAAC7u7u7u7sAAKqqqqqqqgAAiIiI
>iIiIAAB3d3d3d3cAAFVVVVVVVQAAREREREREAAAiIiIiIiIAABEREREREQAAAAAAAAAAAAAAAACA
>AFgAAAAAAIAAWAAkEvwADCsAKwArACsAKwArACu7ABj9AA4rACsAKwArACsAKwArACv8AAABwgBQ
>/AAWKwArACsBKwArACsAKwEAACwAAQAsAQH4AAQrACsAK/4AACv+AAAr/gAAK/4AACv+AAAr/gAA
>K/4AACv+AAAr/gAAK/4AACv+AAIrAABP/QAHKwArACsAKwH+KwUAKwcsACv+AAIrByv2AC0rACsA
>KwArACsAKwArACsAKwArACsAKwArACsAKwArACsAKwArACsAKwArACsA/isAAEf8AAwrACsAKwAr
>ASwBKwAr/gEFAAAHAQAB7wAAK/4ABCsAACtW/gAEKwArK1b+AAAr/gAAK/4ABCsAVgAr/gAAK/4A
>AisAAFL9AP4rDQArBysBKywrBysHMgAH/gAIKwErASsAAAEr/gAAK/4AACv8AP0rBVYAVlYrAP4r
>DgCBgSsAVgArAFYrKwArAP4rAgArAP4rBAArACsAU/wADysAKwcrACwHKwArBysHLAH8AAQHAAAH
>Af4ADiusVlYAgVZWK1YAVlasK/6BASuB/lYPgYFWVoErgVaBAIFWrFZWAP1WBCsrgVas/oECVgAA
>V/0AGisrLAAyKyssKwcrACsAMiwrACsAKwgrACssLP4ANVaBAFaBgVaBgSsAVoErgSsAVoGsViuB
>AFaBgVasVgBWrFYAK4FWKyuBVoEAVoGBK1ZWK4EAAFP8ABQrBywAMiwsACsAKwArAQAABwAAAQf9
>ABcBBwAAK1YAgVaBK1YrgStWVisrViuBVoH+VhIrVoFWgVaBK4FWgSuBVoErgVaB/FYGK1ZWAIEA
>AFT9AAUrACssKwD+KwsAKzMrACwALAAALCz+AAAr/AATKysAKwBWgSsAVoEAKysAVoErKwD+KxBW
>VgBWKytWgSsAVoGBViuBVv4rBVaBK1YAVv0rAABO/gAUAQAsLCsAKwArACsBLAcsAQcAKwAB9AAy
>AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABACsBAQBWVgEABwABAAEAKwArAAcBKwAAV/0ABysr
>MywsKysH/isAAP4rAAH+LAUALAcHACv+ADcBAAABCAEsAQgBLAEIASwBCAEsAQgBLAEIASwBCAEs
>AQgBLAEsBywHLAcsBywHLAcsBywHLAgsACr8ABYrACsHKwAsCCsHKwArASsHBwErAQcAB/4AAAfe
>AAZWACsAACsr8wA3/QD9KwUsKywAVyv+LAMrKywr/gACLCss/gAAK+AAF6xWKwBWVoErVlaBVitW
>gSsrVlYrgVYrADb8ABosMisHKywrKywzMwgsLCsABwArBywALAAALDPhAP5WBwBWgStWVoGB/VYC
>rIGs/YEBKwA9/QARKwdXKzIrLCsrADMzMissLCsB/iwJASsIKyssBwAAK+QABlYrgYFWVoH+Vg0r
>K1ZWgYFWgYFWVitWADT+AAEBAP4rFQAsKyssLAcrBysAMgAHLAEBKwEAACv+AP4H4gAAK/gACoGB
>VgArACsAKwAAKf4AAQEs/isQMitYMisHNCwsKysAKwgyCCz+AAQyBwArLP4B1wAAK/gAI/0AHQEr
>ACsrVzMyByssMywsATMHBwgsACwAACwsATIBAcsAJRsAACsAKysyBzIzNDNXLDMHMjNeECwyLAAB
>LDMI/iz+AAABzAA4/QAeASsAKzIzATMyKwArCDQsAAcsLDMHLAABASsAAQAAAd8AASsA/isNACsA
>KwArACsAKwArAAA3/QD9KxpXMzMsKwArBzMHMgEsBywzKwcrASsBAAcsAAHgABNWgayBgVasgayB
>/1asgYGsVoFWAFP+ADUBACsHMwAsMjMHKwErCCsBKwgsKywAAAEsBwEAKwArKwAAKwArACsAVisr
>ACsAKwArACsAKwD+KwgAKwArACsAVgD+KwMAKytW/Sv7VgEAAFX+ABYBKwcrK1czM1cyBywAMzNX
>LDMALCxXAf4rCAcrAABWrIFWgf2sAVaB/KwFgVaBrIGs/lYdrKz/gVasrIFWgayBgaysVlaBrIGs
>K6yBrFaBgVYAUv4AHgcBLAErASwzOgEsBysBMwcrLCwAMywAACwILAAHACv+AAQrACsAK/4AAisA
>K/4AAysrVgD5KwFWAP4rBwBWK1YAKytW/SsHVisAKwArAABJ/QAgMiwrKywBLDMsKywAKwcsLCsB
>LCxeBysAKwAsBysHAAEB8gASVoGBVqyBrIFWgaysgVZWrFYrrPyBBKysgVas/oEDrIFWAE79AAYs
>KwgsASwA/isPACsBMwAyAAAHKwEsAAcHK/4AAisAB/kABysrACsAKwAA/isAVv0rBABWKysA/CsG
>VlYrVisrAP4rAVZW/SsBAABTAwAAAQD+KxssLCssLCsAKwArMysHLAcrAQAHLDMyACsAAQAr+AAD
>rKxWgf6sDYH/gYGsrIGBVoFWrKxW/oELrFaBrIGBrIGsgaxW/qwEgaysVgBD/gAaLCwrATMHKwAr
>BysAKwAsAAABLAgsACwHLAAr8gAJKwArACsAKwArAP0rAVYA/isBAFb6KwBW+ysBVlb9KwEAAEH+
>AAIBKwD+LAkAKwArACsAKywr/gAEKywyByv+AQAr6QAPVqyBgayBgaysVoGsgayBVvysC4FWgSuB
>rP+BrKxWADf8AA0rBysAKwArACsAKwBeLP4AAQgr4gAAK/4AACv+AAAr/gAAK/4ABCsAKwAr/AAD
>KwArK/4AFP0ADisAKwArACsAKwArAFc7OrwAFPwADisAKwArACsAKwArOhE0K70AMP0ADisAKwAr
>ACsAKwArLDsRM9oAAlaBrP6BAFb7gQRWrFaBVv6BCFasK4FWrKxWAC78AA0rACsAKwArACsAKxA7
>LNkA/CsSACsAKwArACsAKwArACsAKwArAP4rAQAAFP0ADisAKwArACsAKwArADIrK7wAEvwADCsA
>KwArACsAKwArACu7ABP9AAsrACsAKwArACsAKwD+K7wAUPwADCsAKwArACsAKwArACv7AAYIDgcP
>Dg8H/gggBwgHDgcODggODgcHCA4OAAcOBw8ADwcICA4HDggOBw8A/g4MCA4OCAcPBw4HCAgOB/wA
>U/0ADisAKwArACsAKwArACsAK/0AOwFHHA4PORwVD0cWFhxBBxUcQAgjHEAHFRZHABUWQSMHFTMW
>HBZBIxwcQBwOHEcOIxZHFRYjQCMVFUAjFvwATvwADCsAKwArACsAKwArACv7AAoODgAHAA4ICA4I
>Dv4IFwcOBwEPCAcACA4PBwcOBxUABwAPDg4ID/0IAAf+DgcIDwgHCA4HD/0OAAf8ABT9AA4rACsA
>KwArACsAKwArACu8ABL8AAwrACsAKwArACsAKwAruwAj/QAOKwArBzQJNBAsEDsQLAAr/AAEK1ZW
>K1b+KwNWK1YrzQAd/AAMKwAHCQkICQgPCQ8BK/oA/isBByv+AP4rzQAn/QAOKwArACsAKwArACsA
>KwAr/AD4KwAA7SsAVvcrAwBWKyz8K/MAMvwADCsAKwArACsAKwArACv6AP4rAAH+KwQAKwErAPor
>BAcrACsA9isAAPwrAAf6K/MAMP0ADisAKwArACsAKwArACsAK/wABCtWVitW9CsCLCtW/isEMiss
>K1b6KwIsKyvoAC78AAwrACsAKwArACsAKwAr+gD7KwFWAPwrAQdW/isALP4rADL7KwIAVgD6K+kA
>FP0ADisAKwArACsAKwArACsAK7wAEvwADCsAKwArACsAKwArACu7ABT9AA4rACsAKwArACsAKwAr
>ACu8ABL8AAwrACsAKwArACsAKwAruwAe/QAOKwArADMPNBAsEBcQLAAr/AACKytW+isAVswAHPwA
>DCsAKwgJCDMIDwkQASv6AP4rAgArAPwrzQAg/QAOKwArACsAKwArACsAKwAr/AD3KwAs9isCVisr
>2gAq/AAMKwArACsAKwArACsAK/oA/isEASsAKwD+KwgAKwArBysAKwD+K9kALf0ADisAKwArACsA
>KwArACsAK/wA9ysBLAD7KwAs+CsAVvorACz8KwIyKyvuADH8AAwrACsAKwArACsAKwAr+gAAVvYr
>AFb7KwYAKwArK1YH/isCACsB/CsBADL8K+4APv0ADisAKwArACsAKwArACsAK/wAAitWVvgrAlYr
>Vv4rCCwrVisrACsrLPorAVYA+ysALPsr/VYDK1YrVvoAQ/wADCsAKwArACsAKwArACv6APwrAAD+
>KwAA/CsAB/srESwAKytWKysAKyssKysAKwArAPwrAAD+KwAA/isCACsr+gAU/QAOKwArACsAKwAr
>ACsAKwArvAAS/AAMKwArACsAKwArACsAK7sAFP0ADisAKwArACsAKwArACsAK7wAEvwADCsAKwAr
>ACsAKwArACu7ACD9AA4rACsHLAcsCCsILAgrACv8AAAr/gAEKwArACvKAB/8AAwrACsQMw8RCBcQ
>Fwgr+wAJAVYrK1YrKywrVssAQf0ADisAKwArBywHLAcsBysAK/wA/isLACsAKwArACsAKwAr/gAA
>K/4ABCsAKwAr/gAAK/4AACv+AAAr/gAAK+wANPwADCsAKwArACsAKwArACv6AAAy/isAVvorAFb6
>KwdWKysHVisrAP0rBVYrLAErAfwr7QBN/QAOKwArACsAKwArACsAKwAr/AD+KwMAKwAr/gAXKwAB
>ACsAKwArACsAKwArACsAKwArACsA/isFACsAKwAr/gAAAfoABCsAKwAr/ABR/AAMKwArACsAKwAr
>ACsAK/sADQcrK1YrVitWK1YrVitW/isGVitWK1YrVv4rAFb+KwRWKytWVv4rFFYrVitWK1YrVitW
>K1YrVitWK1ZWLP0AUv0ADisAKwArACsAKwArACsAK/wABysAKwcrACsA/isGACsAKwArAP4rBAAr
>ACsA/isKACsAKwArACsAKwH+Kw8AKwArACsAKwArACsAKwAr/AA1/AAMKwArACsAKwArACsAK/oA
>BlYrVitWKyz+KwRWKywrLP4rDSwrVitWK1YrVisrVlYr4gA4/QAOKwArACsAKwArACsAKwAr/AAJ
>KwArACsAKwArAP4rCwArACsAKwArACsAK/4ABCsAKwAr4gAS/AAMKwArACsAKwArACsAK7sAFP0A
>DisAKwArACsAKwArACsAK7wAEvwADCsAKwArACsAKwArACu7ACb9AA4rACsBLAcsCCsIMggrACv8
>APwrAwArK1b+KwUAACsAKyvTACT8AAwrACwQEA8QCBERFwgr+wABVv/+gQf/rIGBrIH/gfys0wBO
>/QAOKwArASsHKwcsBysHKwAr/AAFVlYrK4FW+isDVlYrVv4rD1YAKwBWACsAKwArAFYAKwD+KxMA
>KwArACsAKwArACsAKwArACsAK/wAT/wADCsAKwArACsAKwArACv7AAAr/oEAVv2BBqxWgYGsgaz9
>VgGBrP5WBIGBrIGB/lYIgYFWK6yBgVas/oEArP6BCiuBrIErVqyBgaxW/QBO/QAOKwArACsAKwAr
>ACsAKwAr/AD8KwEAVv4rHVYAKwArVisAKwArAFYrKwBWK4FWVisrACsAKwArAPwrCAArK1YAKwAr
>AP4rAgBWK/0AMPwADCsAKwArACsAKwArACv7AAxW/4GsgayBrCtWgYFW+qwAVv6sBoGBVlasrFbg
>AC39AA4rACsAKwArACsAKwArACv8APwrBlZWACsAKwD4KwBW/isFACsAKwAr4AAS/AAMKwArACsA
>KwArACsAK7sAFP0ADisAKwArACsAKwArACsAK7wAEvwADCsAKwArACsAKwArACu7ADb9AA4rACsB
>MggsCCwILAgrACv8AAhWKwAAKwArAAD+KxIAKysAKwArKwArKwArACtWVisr4AAx/AAMKwArDxAP
>EAgREBcHK/sAAVas/IEIrFaBVqxWgayB/awBVoH+rAGBVv7/ACvgADT9AA4rACsBLAErASwHKwcr
>ACv8AP4rAVZW/SsMACsAKwArACsrVgArAP4rAAD+KwEAK+AAHvwADCsAKwArACsAKwArACv7AARW
>/4GsVvysAFbMACX9AA4rACsAKwArACsAKwArACv8AAIrK1b9KwdWVisrACsAK9AAJPwADCsAKwAr
>ACsAKwArACv7AAkrVoGsgYEAVoGs/oEBrCvQAEb9AA4rACsAKwArACsAKwArACv8AAFWVv0rAIH5
>KwcAACsrACsrVv4A/isAAP4rBAArKwAA/isCACsA/isEACsAKwD+K/gASvwADCsAKwArACsAKwAr
>ACv7ABorrKyBVqyBrFasVoGBrFasgYGsrCus/6xWgYH8rARW/4GsgfysAYGB/qwA//6sBYGsgYGs
>K/oAPv0ADisAKwArACsAKwArACsAK/wA9SsAVvsrAgBWK/5WAAD9KwJWK1b+KwdWKysAKwArAPsr
>A1YAKwD+K/oAN/wADCsAKwArACsAKwArACv7AABW/qz+gQBW/oEXrKyBgf+BrIFWgYGsrIFWrKyB
>Vqysgays5AA0/QAOKwArACsAKwArACsAKwAr/AD8KwcAVgArACsAVvsrAgArAP4rCQArACsAKwAr
>ACvkABL8AAwrACsAKwArACsAKwAruwAj/QAOKwArACsAKwArACsAKwAr/AD8KwAA/SsAVv0rAQAr
>0gAm/AAMKwArACsAKwArACsAK/sAAVb//oEHrFaBAKz/rIH9rABW0wAy/QAOKwArACsAKwArACsA
>KwAr/AADK1ZWAP0rAFb3Kw8AKwArKwAAVisrACsAKwAr5AA2/AAMKwArACsAKwArACsAK/sACius
>gYFWVoGBVoFW/YEMrCtWgaxWgYGsK4GBrP6BAKz9geUAMv0ADisAKwArACsAKwArACsAK/wADVZW
>KytWAFYAKytWK1YA/lYAAPQrBVaBKytWK+YAOvwADCsAKwArACsAKwArACv7AAgrrKz/rKyBrFb9
>rAUrgaysgYH+rAaBgVasrIFW/qwFgays/6ys5wA2/QAOKwArACsAKwArACsAKwAr/AD8KwBW/isE
>AFYrKwD+KwQAKytWAPwrAgArAP4rAAD+K+YAEvwADCsAKwArACsAKwArACu7ABT9AA4rACsAKwAr
>ACsAKwArACu8ABL8AAwrACsAKwArACsAKwAruwAe/QAOKwArACwILAgrCDIIKwAr/AD+KwIAKwD8
>K8wAH/wADCsAKwkPDxAIEREXCCv7AAFW//2s/oEC/6yBzQA3/QAOKwArBywBKwcsBysHKwAr/AAB
>Vlb9KwBW/isAVv4rAQAA/isNACsAKysAAFYrKwArACviADb8AAwrACsAKwArACsAKwAr+wABK6z+
>gQZWVqxWgYGs/oERrCtWgaxWVqysVoFWgVaBgawr4gA8/QAOKwArACsAKwArACsAKwAr/AABVlb8
>KwEAVvwrA1ZWKwD7KwBW/SsFAFZWKwAr/gAGVgArAAArK+4AP/wADCsAKwArACsAKwArACv7AAVW
>rKyBgf/+gQFWgfysBVaBrKxW//2BDqyBgaysgaz/rP9WK4GsgfysAFbwAD/9AA4rACsAKwArACsA
>KwArACv8AAErAP4rC1YrK1YAVitWKytWgfsrBAArACsA/isAAPwrBQArACsrVv0r8AAp/AAMKwAr
>ACsAKwArACsAK/sABFb/K4FW/awCVqys/oEArP6BAayB1gAr/QAOKwArACsAKwArACsAKwAr/AD+
>KxEAKytWACsAKwArAFYrKwArACvWABL8AAwrACsAKwArACsAKwAruwAU/QAOKwArACsAKwArACsA
>KwArvAAM9gAGKwArACsAK7sAVwUAAFasgVb+rABW/oEUrFZWgaysVoFWK1aBgaxWgVasgStW/qz9
>gSVWrIGsgaysVlasgawrgYFWgayBgVaBrIGBrFaBrFYrVlasgaysVv6sBYFWgVYAAFX+AAFWVv2B
>DaxWgVaBK1ZWgVaBVoEr/YH+VgSBVitWVv6BAVaB/lYsgYGsVoFWViuBgStWgStWgayBgVaBgayB
>VlasVisrVlaBVoEAVoGsgayBgQAAEvsAASsA/isHACsAKwArACu8ABL8AAwrACsAKwArACsAKwAr
>uwAU/QAOKwArACsAKwArACsAKwArvAAS/AAMKwArACsAKwArACsAK7sAFP0ADisAKwArACsAKwAr
>ACsAK7wAAP8AAAAOwLQn8gABUElDVACAAAAAAAEAAAAjnAAAIpwAAABcBtBMdALTAAAAHABGAAFQ
>SUNUAAAAEnBub3QAAAAeAIAAAAAAAAAH+yDgAAAACgAAIooH+yCECVRodW1ibmFpbAtJbmZvcm1h
>dGlvbg==
>
>--Apple-Mail-7-158498448
>Content-Transfer-Encoding: base64
>Content-Type: application/pdf;
>	x-mac-type=50444620;
>	x-unix-mode=0644;
>	x-mac-creator=4341524F;
>	name="NK_SS06_neu.pdf"
>Content-Disposition: inline;
>	filename=NK_SS06_neu.pdf
>
>JVBERi0xLjQNJeLjz9MNCjEgMCBvYmo8PC9QYWdlcyAyIDAgUi9UeXBlL0NhdGFsb2cvTWV0YWRh
>dGEgNTI1IDAgUj4+DWVuZG9iag0yIDAgb2JqPDwvQ291bnQgMS9LaWRzWzYgMCBSXS9UeXBlL1Bh
>Z2VzPj4NZW5kb2JqDTMgMCBvYmo8PC9Nb2REYXRlKEQ6MjAwNjA2MTMwODI5MzgrMDInMDAnKS9D
>cmVhdGlvbkRhdGUoRDoyMDA2MDIyMTExMDI0NyswMScwMCcpL1RpdGxlKE5LX1Byb2dyYW1tX1dT
>MDMwNC5haSkvQ3JlYXRvcihJbGx1c3RyYXRvcikvUHJvZHVjZXIoQWRvYmUgUERGIGxpYnJhcnkg
>Ni42Nik+Pg1lbmRvYmoNNSAwIG9iaiBudWxsDWVuZG9iag02IDAgb2JqPDwvQ29udGVudHMgNDg0
>IDAgUi9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1RodW1iIDUyNCAwIFIvTWVkaWFCb3hbMC4wIDAu
>MCA1OTUuMCA4NDIuMF0vQmxlZWRCb3hbMC4wIDAuMCA1OTUuMCA4NDIuMF0vVHJpbUJveFswLjAg
>MC4wIDU5NS4wIDg0Mi4wXS9BcnRCb3hbMC4wIDAuMCA1NzAuMCA4NDIuMF0vUmVzb3VyY2VzPDwv
>Rm9udDw8L0MyXzAgNDUzIDAgUi9DMl8xIDQ1OCAwIFIvQzJfMiA0NjMgMCBSL0MyXzMgNDY4IDAg
>Ui9DMl80IDQ3MyAwIFIvQzBfMCA0NzggMCBSPj4vWE9iamVjdDw8L0ltMCA0NTIgMCBSPj4vUHJv
>Y1NldFsvUERGL1RleHQvSW1hZ2VDXS9FeHRHU3RhdGU8PC9HUzAgNDQ2IDAgUj4+L1Byb3BlcnRp
>ZXM8PC9NQzA8PC9Db2xvclsyMDIyNC4wIDMyNzY4LjAgMjAyMjQuMF0vVGl0bGUoRWJlbmUgMykv
>VmlzaWJsZSB0cnVlL1ByZXZpZXcgdHJ1ZS9FZGl0YWJsZSBmYWxzZS9QcmludGVkIHRydWUvRGlt
>bWVkIHRydWU+Pi9NQzE8PC9Db2xvclsyMDIyNC4wIDMyNzY4LjAgMzI3NjguMF0vVGl0bGUoRWJl
>bmUgMSkvVmlzaWJsZSB0cnVlL1ByZXZpZXcgdHJ1ZS9FZGl0YWJsZSB0cnVlL1ByaW50ZWQgdHJ1
>ZS9EaW1tZWQgdHJ1ZT4+L01DMjw8L0NvbG9yWzMyNzY4LjAgMjAyMjQuMCAyMDIyNC4wXS9UaXRs
>ZShFYmVuZSAyKS9WaXNpYmxlIHRydWUvUHJldmlldyB0cnVlL0VkaXRhYmxlIHRydWUvUHJpbnRl
>ZCB0cnVlL0RpbW1lZCB0cnVlPj4+Pj4+L0dyb3VwIDQ4NSAwIFIvUGllY2VJbmZvPDwvSWxsdXN0
>cmF0b3IgNyAwIFI+Pi9MYXN0TW9kaWZpZWQoRDoyMDA2MDYxMzA4MjkzNiswMicwMCcpPj4NZW5k
>b2JqDTcgMCBvYmo8PC9MYXN0TW9kaWZpZWQoRDoyMDA2MDYxMzA4MjkzNiswMicwMCcpL1ByaXZh
>dGUgOCAwIFI+Pg1lbmRvYmoNOCAwIG9iajw8L0NyZWF0b3JWZXJzaW9uIDExL0NvbnRhaW5lclZl
>cnNpb24gOS9Sb3VuZHRyaXBWZXJzaW9uIDExL0FJTWV0YURhdGEgMjY4IDAgUi9OdW1CbG9jayA4
>OS9BSVBERlByaXZhdGVEYXRhMSAyNjkgMCBSL0FJUERGUHJpdmF0ZURhdGEyIDI3MSAwIFIvQUlQ
>REZQcml2YXRlRGF0YTMgMjczIDAgUi9BSVBERlByaXZhdGVEYXRhNCAyNzUgMCBSL0FJUERGUHJp
>dmF0ZURhdGE1IDI3NyAwIFIvQUlQREZQcml2YXRlRGF0YTYgMjc5IDAgUi9BSVBERlByaXZhdGVE
>YXRhNyAyODEgMCBSL0FJUERGUHJpdmF0ZURhdGE4IDI4MyAwIFIvQUlQREZQcml2YXRlRGF0YTkg
>Mjg1IDAgUi9BSVBERlByaXZhdGVEYXRhMTAgMjg3IDAgUi9BSVBERlByaXZhdGVEYXRhMTEgMjg5
>IDAgUi9BSVBERlByaXZhdGVEYXRhMTIgMjkxIDAgUi9BSVBERlByaXZhdGVEYXRhMTMgMjkzIDAg
>Ui9BSVBERlByaXZhdGVEYXRhMTQgMjk1IDAgUi9BSVBERlByaXZhdGVEYXRhMTUgMjk3IDAgUi9B
>SVBERlByaXZhdGVEYXRhMTYgMjk5IDAgUi9BSVBERlByaXZhdGVEYXRhMTcgMzAxIDAgUi9BSVBE
>RlByaXZhdGVEYXRhMTggMzAzIDAgUi9BSVBERlByaXZhdGVEYXRhMTkgMzA1IDAgUi9BSVBERlBy
>aXZhdGVEYXRhMjAgMzA3IDAgUi9BSVBERlByaXZhdGVEYXRhMjEgMzA5IDAgUi9BSVBERlByaXZh
>dGVEYXRhMjIgMzExIDAgUi9BSVBERlByaXZhdGVEYXRhMjMgMzEzIDAgUi9BSVBERlByaXZhdGVE
>YXRhMjQgMzE1IDAgUi9BSVBERlByaXZhdGVEYXRhMjUgMzE3IDAgUi9BSVBERlByaXZhdGVEYXRh
>MjYgMzE5IDAgUi9BSVBERlByaXZhdGVEYXRhMjcgMzIxIDAgUi9BSVBERlByaXZhdGVEYXRhMjgg
>MzIzIDAgUi9BSVBERlByaXZhdGVEYXRhMjkgMzI1IDAgUi9BSVBERlByaXZhdGVEYXRhMzAgMzI3
>IDAgUi9BSVBERlByaXZhdGVEYXRhMzEgMzI5IDAgUi9BSVBERlByaXZhdGVEYXRhMzIgMzMxIDAg
>Ui9BSVBERlByaXZhdGVEYXRhMzMgMzMzIDAgUi9BSVBERlByaXZhdGVEYXRhMzQgMzM1IDAgUi9B
>SVBERlByaXZhdGVEYXRhMzUgMzM3IDAgUi9BSVBERlByaXZhdGVEYXRhMzYgMzM5IDAgUi9BSVBE
>RlByaXZhdGVEYXRhMzcgMzQxIDAgUi9BSVBERlByaXZhdGVEYXRhMzggMzQzIDAgUi9BSVBERlBy
>aXZhdGVEYXRhMzkgMzQ1IDAgUi9BSVBERlByaXZhdGVEYXRhNDAgMzQ3IDAgUi9BSVBERlByaXZh
>dGVEYXRhNDEgMzQ5IDAgUi9BSVBERlByaXZhdGVEYXRhNDIgMzUxIDAgUi9BSVBERlByaXZhdGVE
>YXRhNDMgMzUzIDAgUi9BSVBERlByaXZhdGVEYXRhNDQgMzU1IDAgUi9BSVBERlByaXZhdGVEYXRh
>NDUgMzU3IDAgUi9BSVBERlByaXZhdGVEYXRhNDYgMzU5IDAgUi9BSVBERlByaXZhdGVEYXRhNDcg
>MzYxIDAgUi9BSVBERlByaXZhdGVEYXRhNDggMzYzIDAgUi9BSVBERlByaXZhdGVEYXRhNDkgMzY1
>IDAgUi9BSVBERlByaXZhdGVEYXRhNTAgMzY3IDAgUi9BSVBERlByaXZhdGVEYXRhNTEgMzY5IDAg
>Ui9BSVBERlByaXZhdGVEYXRhNTIgMzcxIDAgUi9BSVBERlByaXZhdGVEYXRhNTMgMzczIDAgUi9B
>SVBERlByaXZhdGVEYXRhNTQgMzc1IDAgUi9BSVBERlByaXZhdGVEYXRhNTUgMzc3IDAgUi9BSVBE
>RlByaXZhdGVEYXRhNTYgMzc5IDAgUi9BSVBERlByaXZhdGVEYXRhNTcgMzgxIDAgUi9BSVBERlBy
>aXZhdGVEYXRhNTggMzgzIDAgUi9BSVBERlByaXZhdGVEYXRhNTkgMzg1IDAgUi9BSVBERlByaXZh
>dGVEYXRhNjAgMzg3IDAgUi9BSVBERlByaXZhdGVEYXRhNjEgMzg5IDAgUi9BSVBERlByaXZhdGVE
>YXRhNjIgMzkxIDAgUi9BSVBERlByaXZhdGVEYXRhNjMgMzkzIDAgUi9BSVBERlByaXZhdGVEYXRh
>NjQgMzk1IDAgUi9BSVBERlByaXZhdGVEYXRhNjUgMzk3IDAgUi9BSVBERlByaXZhdGVEYXRhNjYg
>Mzk5IDAgUi9BSVBERlByaXZhdGVEYXRhNjcgNDAxIDAgUi9BSVBERlByaXZhdGVEYXRhNjggNDAz
>IDAgUi9BSVBERlByaXZhdGVEYXRhNjkgNDA1IDAgUi9BSVBERlByaXZhdGVEYXRhNzAgNDA3IDAg
>Ui9BSVBERlByaXZhdGVEYXRhNzEgNDA5IDAgUi9BSVBERlByaXZhdGVEYXRhNzIgNDExIDAgUi9B
>SVBERlByaXZhdGVEYXRhNzMgNDEzIDAgUi9BSVBERlByaXZhdGVEYXRhNzQgNDE1IDAgUi9BSVBE
>RlByaXZhdGVEYXRhNzUgNDE3IDAgUi9BSVBERlByaXZhdGVEYXRhNzYgNDE5IDAgUi9BSVBERlBy
>aXZhdGVEYXRhNzcgNDIxIDAgUi9BSVBERlByaXZhdGVEYXRhNzggNDIzIDAgUi9BSVBERlByaXZh
>dGVEYXRhNzkgNDI1IDAgUi9BSVBERlByaXZhdGVEYXRhODAgNDI3IDAgUi9BSVBERlByaXZhdGVE
>YXRhODEgNDI5IDAgUi9BSVBERlByaXZhdGVEYXRhODIgNDMxIDAgUi9BSVBERlByaXZhdGVEYXRh
>ODMgNDMzIDAgUi9BSVBERlByaXZhdGVEYXRhODQgNDM1IDAgUi9BSVBERlByaXZhdGVEYXRhODUg
>NDM3IDAgUi9BSVBERlByaXZhdGVEYXRhODYgNDM5IDAgUi9BSVBERlByaXZhdGVEYXRhODcgNDQx
>IDAgUi9BSVBERlByaXZhdGVEYXRhODggNDQzIDAgUi9BSVBERlByaXZhdGVEYXRhODkgNDQ1IDAg
>Uj4+DWVuZG9iag0yNjcgMCBvYmogbnVsbA1lbmRvYmoNMjY4IDAgb2JqPDwvTGVuZ3RoIDgzOT4+
>c3RyZWFtDQolIVBTLUFkb2JlLTMuMCANJSVDcmVhdG9yOiBBZG9iZSBJbGx1c3RyYXRvcihSKSAx
>MS4wDSUlQUk4X0NyZWF0b3JWZXJzaW9uOiAxMS4wLjANJSVGb3I6IChQLiBUaGllcikgKEhJSCkN
>JSVUaXRsZTogKE5LX1NTMDZfbmV1LnBkZikNJSVDcmVhdGlvbkRhdGU6IDEzLjA2LjIwMDYgODoy
>OSBVaHINJSVCb3VuZGluZ0JveDogMCAwIDU3MCA4NDINJSVIaVJlc0JvdW5kaW5nQm94OiAwIDAg
>NTcwIDg0Mg0lJURvY3VtZW50UHJvY2Vzc0NvbG9yczogQ3lhbiBNYWdlbnRhIFllbGxvdyBCbGFj
>aw0lQUk1X0ZpbGVGb3JtYXQgNy4wDSVBSTNfQ29sb3JVc2FnZTogQ29sb3INJUFJN19JbWFnZVNl
>dHRpbmdzOiAwDSUlQ01ZS1Byb2Nlc3NDb2xvcjogMCAwIDAgMSAoW1Bhc3Nlcm1hcmtlbl0pDSVB
>STNfVGVtcGxhdGVCb3g6IDI5Ny41IDQyMC41IDI5Ny41IDQyMC41DSVBSTNfVGlsZUJveDogMCAt
>Ni4wOTg2IDU5NSA4NDguMDk4Ng0lQUkzX0RvY3VtZW50UHJldmlldzogTm9uZQ0lQUk1X0FydFNp
>emU6IDU5NSA4NDINJUFJNV9SdWxlclVuaXRzOiAyDSVBSTlfQ29sb3JNb2RlbDogMg0lQUk1X0Fy
>dEZsYWdzOiAwIDAgMCAxIDAgMCAxIDAgMA0lQUk1X1RhcmdldFJlc29sdXRpb246IDgwMA0lQUk1
>
>IDAwMDAwIG4NCjAwMDA2MTc3ODIgMDAwMDAgbg0KMDAwMDYxODM2NSAwMDAwMCBuDQowMDAwNjE4
>Mzg2IDAwMDAwIG4NCjAwMDA2MTg4MzQgMDAwMDAgbg0KMDAwMDYxODg1NSAwMDAwMCBuDQowMDAw
>NjE5MjQ1IDAwMDAwIG4NCjAwMDA2MTkyNjYgMDAwMDAgbg0KMDAwMDYyMDA4NiAwMDAwMCBuDQow
>MDAwMDAwNDQ4IDAwMDAxIGYNCjAwMDAwMDA0ODggMDAwMDEgZg0KMDAwMDYyMDE5OSAwMDAwMCBu
>DQowMDAwNjIwMjIzIDAwMDAwIG4NCjAwMDA2MjAyNDYgMDAwMDAgbg0KMDAwMDY3NDYzNCAwMDAw
>MCBuDQowMDAxNDYyNjI0IDAwMDAwIG4NCjAwMDE0NjI3NjEgMDAwMDAgbg0KMDAwMTQ2Mjc4NyAw
>MDAwMCBuDQowMDAxNDYzMDA3IDAwMDAwIG4NCjAwMDE0NjMwNzYgMDAwMDAgbg0KMDAwMTQ2MzI3
>NSAwMDAwMCBuDQowMDAxNDYzNDA4IDAwMDAwIG4NCjAwMDE0NjM0MzQgMDAwMDAgbg0KMDAwMTQ2
>Mzc4MyAwMDAwMCBuDQowMDAxNDYzODUyIDAwMDAwIG4NCjAwMDE0NjQwNDkgMDAwMDAgbg0KMDAw
>MTQ2NDE4NyAwMDAwMCBuDQowMDAxNDY0MjEzIDAwMDAwIG4NCjAwMDE0NjQ1NDIgMDAwMDAgbg0K
>MDAwMTQ2NDYxMSAwMDAwMCBuDQowMDAxNDY0ODE0IDAwMDAwIG4NCjAwMDE0NjQ5NTAgMDAwMDAg
>bg0KMDAwMTQ2NDk3NiAwMDAwMCBuDQowMDAxNDY1MzQ3IDAwMDAwIG4NCjAwMDE0NjU0MTYgMDAw
>MDAgbg0KMDAwMTQ2NTYxNSAwMDAwMCBuDQowMDAxNDY1NzQ2IDAwMDAwIG4NCjAwMDE0NjU3NzIg
>MDAwMDAgbg0KMDAwMTQ2NjEyMSAwMDAwMCBuDQowMDAxNDY2MTkwIDAwMDAwIG4NCjAwMDE0NjYz
>ODMgMDAwMDAgbg0KMDAwMTQ2NjUxOSAwMDAwMCBuDQowMDAxNDY2NTQ1IDAwMDAwIG4NCjAwMDE0
>NjY3NjUgMDAwMDAgbg0KMDAwMTQ2NjgzNCAwMDAwMCBuDQowMDAxNDY3MDMxIDAwMDAwIG4NCjAw
>MDE0NjcwNTMgMDAwMDAgbg0KMDAwMTQ2OTQ2NyAwMDAwMCBuDQowMDAxNDY5NTMzIDAwMDAwIG4N
>CjAwMDE0Njk1NTYgMDAwMDAgbg0KMDAwMDAwMDQ4OSAwMDAwMSBmDQowMDAwMDAwNDk0IDAwMDAx
>IGYNCjAwMDE0Nzk4NTYgMDAwMDAgbg0KMDAwMTQ3OTg3NyAwMDAwMCBuDQowMDAxNDgwMjQwIDAw
>MDAwIG4NCjAwMDE0ODAyNjMgMDAwMDAgbg0KMDAwMDAwMDQ5NSAwMDAwMSBmDQowMDAwMDAwNTAw
>IDAwMDAxIGYNCjAwMDE1MDQ5NTYgMDAwMDAgbg0KMDAwMTUwNDk3NyAwMDAwMCBuDQowMDAxNTA1
>NDU3IDAwMDAwIG4NCjAwMDE1MDU0ODAgMDAwMDAgbg0KMDAwMDAwMDUwMSAwMDAwMSBmDQowMDAw
>MDAwNTA2IDAwMDAxIGYNCjAwMDE1Mjg1MjggMDAwMDAgbg0KMDAwMTUyODU0OSAwMDAwMCBuDQow
>MDAxNTI5MDIxIDAwMDAwIG4NCjAwMDE1MjkwNDQgMDAwMDAgbg0KMDAwMDAwMDUwNyAwMDAwMSBm
>DQowMDAwMDAwNTEyIDAwMDAxIGYNCjAwMDE1NTI2NDYgMDAwMDAgbg0KMDAwMTU1MjY2NyAwMDAw
>MCBuDQowMDAxNTUzMjIzIDAwMDAwIG4NCjAwMDE1NTMyNDYgMDAwMDAgbg0KMDAwMDAwMDUxMyAw
>MDAwMSBmDQowMDAwMDAwMDAwIDAwMDAxIGYNCjAwMDE1NzIyODcgMDAwMDAgbg0KMDAwMTU3MjMw
>OCAwMDAwMCBuDQowMDAxNTcyNzk2IDAwMDAwIG4NCjAwMDE1NzI4MTggMDAwMDAgbg0KMDAwMTU3
>NDM1MSAwMDAwMCBuDQowMDAxNTc0MzcyIDAwMDAwIG4NCjAwMDE1NzQ3NDMgMDAwMDAgbg0KMDAw
>MTU3NDc5MiAwMDAwMCBuDQowMDAxNTc0ODEzIDAwMDAwIG4NCjAwMDE1NzUzMzAgMDAwMDAgbg0K
>MDAwMTU3NTM1MSAwMDAwMCBuDQowMDAxNTc2MzgyIDAwMDAwIG4NCnRyYWlsZXINPDwvU2l6ZSA1
>MjYvUm9vdCAxIDAgUi9JbmZvIDMgMCBSL0lEWzxhOTQwOGVmNmZhYTUxMWRhOWM0YjAwMGE5NThj
>ZGU2OD48ZmQxNTRiY2FmYWE1MTFkYTljNGIwMDBhOTU4Y2RlNjg+XT4+DXN0YXJ0eHJlZg0xNjA1
>NTczDSUlRU9GDQ==
>
>--Apple-Mail-7-158498448--
>
>--Apple-Mail-6-158498448
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=ISO-8859-1
>
><HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; =
>"><DIV><SPAN></SPAN></DIV><BR><BR><DIV> <P style=3D"margin: 0.0px 0.0px =
>0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
>Helvetica">Dagmar Heller-Schmerold</FONT></P> <P style=3D"margin: 0.0px =
>0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
>12.0px Helvetica">Hertie-Institut f=FCr klinische =
>Hirnforschung</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
>0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
>Helvetica">Abt. Kognitive Neurologie</FONT></P> <P style=3D"margin: =
>0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
>style=3D"font: 12.0px Helvetica">und</FONT></P> <P style=3D"margin: =
>0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
>style=3D"font: 12.0px Helvetica">Sonderforschungsbereich 550</FONT></P> =
><P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
>size=3D"3" style=3D"font: 12.0px Helvetica">Gesch=E4ftsstelle</FONT></P> =
><P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
>size=3D"3" style=3D"font: 12.0px Helvetica">Hoppe-Seyler-Str. =
>3</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
>face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">D-72076 =
>T=FCbingen</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: =
>12.0px Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px =
>0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
>12.0px Helvetica">Tel. +49 (0)7071 29 85662</FONT></P> <P style=3D"margin:=
> 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
>style=3D"font: 12.0px Helvetica">Fax +49 (0)7071 29 5326</FONT></P> <P =
>style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
>size=3D"3" style=3D"font: 12.0px Helvetica">e-mail: =
>schmerold@uni-tuebingen. de</FONT></P>  </DIV><BR></BODY></HTML>=
>
>--Apple-Mail-6-158498448--
>
>
>
>
>--Apple-Mail-5-158498447--
Attachment #225575 - Attachment description: eMail with PDF document attached, unfortunately large (2MB) → eMail with PDF document attached, not deleted by TB 1.5
Is there already another bug that refers to issues about this feature?

I ask this because I have reproduced the following issue:
- Thunderbird for Windows against IMAP exchange server.
- Select a message that contains a forward as attachment, which BTW contains another attachment (a TIF image file).
- Delete the forward attachment.

I then obtain a new message at my inbox that tells the following:

"Dear Recipient,

This mail is not complete because a part of it (body or attachment) violated GFI Content Security's Email Exploit Detector Module.

That mail has been quarantined and you will receive it if the administrator approves it.

Regards,

GFI Content Security
http://www.gfi.com/ "
This bug is dead. Please file new bugs (if you can't find an open bug about it)  for possible issues you may have with the current implementation.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.