Closed Bug 359319 Opened 18 years ago Closed 6 years ago

Attachments: Option to have attachments stripped from message upon receipt

Categories

(Penelope Graveyard :: General, enhancement, P3)

Product:
Penelope Graveyard
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mdudziak, Assigned: beckley)

References

(Depends on 1 open bug)

Details

Should Penelope have an option to strip attachments from messages upon receipt? Ideally, the user should be able to set the attachments folder on a mailbox-by-mailbox basis, as well as use Filters to extract attachments to a specific folder, or to the Trash, Recycle Bin, /dev/null, etc.


If you would like to see this option in Penelope, please vote for this bug.
Severity: normal → enhancement
love this feature
The lack of this feature is the ONLY reason I haven't switched to Thunderbird yet. The quick searches are cool too, but there's Google Desktop for that.
Yes, attachments should be saved separately from the message text to make them easily manageable and accessible form outside the program.  A per user (personality) option is something I've always wished that Eudora had.
This could be implemented by using the MIME external-body construct.  See RFC 2046.  That way the attachment stays as a separate file, yet the message still has a valid MIME structure to reference it.  The question is, what will be shown in the message window when it sees an external-body part?

I guess, this Eudora feature is also what enabled fast searching: the mailboxes contain text only, not encoded attachments like in Thunderbird, and thus measure MBytes at most, not GBytes. 

As Thunderbird now allows to detach attachments, it would be probably possible to use the same code base for both programs, just for Penelope set the default (or the only allowed) behavior to detach all attachments before the mail is ever put into its mailbox.
YES vote from me. The option to strip attachments out of email should always be there and attachments kept in a totally seperate directory .
I would group the benefits of this feature as follows:
a) Not counting spam, I have kept all the mail I received in the last decade (a madness that has proved its value on a number of occasions). Eudora's ability to keep attachments separate from mailboxes has been a crucial feature for my archiving as their size never became prohibitive.
b) A useful side effect of this separation is that, as attached files are written on disk upon receipt, they are scanned by the resident antivirus software on the spot. This prevents the need of having AV intercept mail traffic to scan attached content.
c) I've been taking this for granted for so long, that I only now noticed: It is so much better to have the attachments as files that can be evaluated and managed (deleted or archived) independently of the messages they were received with and of the mail client interface. Personally, I just open the attachments folder, sort them by date descending, and start deleting or moving to another folder.

One idea might be to have the user decide what size and which types of file (based on mime-types or filename suffix or ?) would be separated and which ones would remain encoded with the message. For example I would instruct the client to separated all word, powerpoint, excel, images, video and generally anything above 20K.

Thanks!
I'd think this would also be kinda necessary to import existing mail files from Eudora wihtout causing all sorts of problems.
(In reply to comment #8)
> I'd think this would also be kinda necessary to import existing mail files from
> Eudora wihtout causing all sorts of problems.
> 

Yes it is important, though that is a separate issue from attachment handling. That is covered under:

https://bugzilla.mozilla.org/show_bug.cgi?id=359219

Matt
One of the problems with the current Mac Eudora is that if you filter attachments into a different folder, then move to a new machine, Eudora can no longer find the attachments as the file ID (inode) has changed. (All of the filter definitions also lose the folder they were filtering attachments to.)

With Penelope, if there is some way to move to a new machine and still preserve all the attachment links, then I would be in favour of this. Otherwise, it becomes a mess of unattached attachments.
One of the problems with stripping the attachments into separate files is what to do when two or more attachments have the same name? Eudora currently adds a number to the end of the file name part, eg, word.doc, word 1.doc, word 2.doc, etc.

This is not ideal as it is actually impossible to know for sure which version belongs to any particular message, short of going to the message and opening the attachment from there. (This is even more of a problem when moving to a new machine and Eudora does not know which version is attached to any message.)

In many cases, the mutiple attachments are actually exactly the same file. What would be nice would be to compare the new version with any existing version (checksum perhaps?), and if they are the same, make the link point to the existing file rather than creating a copy.
Absolutely critical for me too, for mail archival purposes.
There was a feature in the Mac Classic Eudora where for each attachment the sender was listed in the "Finder Comments" when one activated "Comments" in list view. It disappeared in OS X.
Is there a way to bring this back in Penelope?
No problem if attachments are first kept in the mailbox, as part of the messages. If at this stage I want to delete a message and its attachments, it's simple.

But I want to have the option to (manually) move the attachment(s) out of the mailbox into an arbitrary folder on the disk and keep a link in the message which shows the place where the attachment(s) is (are) stored and allows opening them by clicking on the link.

Partially in reply to #10

It is desirable to somehow retain the link between the mail message and the attachment. Possible problems: File could have been manually moved into a different folder, or edited, or the whole thing moved onto a different computer.

Possible solution: use multiple means to keep track of attachments. If some means fail, there still may be one that work.

Use File ID (on  Mac, currently used by Eudora).

Save Mail ID within Spotlight comment (on Mac) of the attached file (would also help to find the corresponding mail from the attachment.

Calculating the file hash on arrival and saving hash, file path and name, size, creation/change date into the message. BTW, by calculating hash value it would be easy to find duplicate attachments (a common situation) and provide the option to keep only one of them. Also, the user may find it useful, if on opening an attachment from within a message, Penelope informs him if the attachment has been changed since arrival.

Re-linking of attachments could be done manually for selected messages / mail folders (the user will be asked to point to the folders which could contain the attachments, multiple selection would be useful). Optionally, attachments could be automatically re-linked on opening a message.

(In reply to comment #16)
> Partially in reply to #10

> Use File ID (on  Mac, currently used by Eudora).
> 
> Save Mail ID within Spotlight comment (on Mac) of the attached file (would also
> help to find the corresponding mail from the attachment.

Errr:
There is lots of pre-Spotlight OSX as well as "Spotlight off because it breaks things" boxes as well..
What I thought we could do it have attachments filtered into a location using a filter setting. Any attachment that comes with a message filtered into the eudora smith folder would filter the attachment into the smith folder in C:/mydocuments/smith. But linking is needs as I do move the smith folder around in the mydocuments folder. Clearly some form of tracking is needed. The system eudora uses now is not good. I have 3500 attachments in the attachment folder now. Also there is an embedded folders for images etc embedded in msgs. same problem there. I opened that folder the other day and had thousands of images that I need to keep but was not sure which msg they belonged to
What I thought we could do it have attachments filtered into a location using a filter setting. Any attachment that comes with a message filtered into the eudora smith folder would filter the attachment into the smith folder in C:/mydocuments/smith. But linking is needs as I do move the smith folder around in the mydocuments folder. Clearly some form of tracking is needed. The system eudora uses now is not good. I have 3500 attachments in the attachment folder now. Also there is an embedded folders for images etc embedded in msgs. same problem there. I opened that folder the other day and had thousands of images that I need to keep but was not sure which msg they belonged to
(In reply to comment #17)
>> Partially in reply to #10

>> Save Mail ID within Spotlight comment (on Mac) of the attached file (would also
>> help to find the corresponding mail from the attachment.

> Errr:
> There is lots of pre-Spotlight OSX as well as "Spotlight off because it 
> breaks things" boxes as well..

1. Moreover, there exist even much more boxes non-Spotlight OS's

2. My point was to implement linking of the files to messages by multiple means, *exactly* because it may happen some of them wouldn't function.

3. Even with "Spotlight off" it should be possible to set and read (from "File Information") Finder/Spotlight comments. So, a) The user would be able to know what message the mail came; and b) If Spotlight is off, Penelope could probably search for attachments with specific comments itself.
I almost lost track of all my attachments, when I moved the Eudora mail and attachment folders from one drive to another (on Windows). I ended up having to do a textual search and replace in all the .mbx files regarding both attachments and embedded content.
If possible, it would be preferrable if Penelope did not have this same problem.

Otherwise, I agree with comment #14.
(In reply to comment #21)
This is a potentially dangerous exercise, as replacing a string in a .mbx file with less or more characters can result in a mismatch with the message boundaries stored in .toc files.
It would indeed be nice if Penelope took care of this internally, e.g. with a built-in tool for changing the attachment root folder stored in any selected group of messages (or globally).
(In reply to comment #18)
Having attachments split from messages is a great feature of Eudora. A few improvements though would help:

* As suggested allow multiple attachment folders - a filter option would work, a folder per mailbox would but might be overkill, basically anyway to do it!

* Have "delete this message attachments" and "delete this message and attachments" options. The global "delete attachments with message" (or whatever it is called) is too coarse.

* Ever since MacOS X dragging attachments to the trash can seems to have broken - I keep an alias of the trash folder on the desktop just so I can trash Eudora attachments...
(In reply to comment #23)
Missed adding:

* When a message is moved from one mailbox to another there should be an option to move any attachments to a different attahcment folder as well. This is where being able to set an attachment folder
for a mailbox would be very useful.

Use case if it helps: I sort email by projects etc. Before travelling to a meeting I often collect a subset of messages, and any attachments, into a mailbox and transfer that mailbox to my laptop (which of course also had Eudora on it). Currently I have to collect the attachments by hand and they become disconnected from their messages :-(
I dont think it would be too hard to filter attachments into separate folders that sort of track the eudora folder stytem but the attachment folders could be set up anywhere. What needs to be done is that the msg needs to "tag" the attachment so that it can be relinked without depending upon a path in the incoming or outgoing email which can be broken if you move the attachment. Maybe some sort of ID tag can be added to the attachment file name so that it knows the date and time or some other string in the msg that only relate to that specific msg. You cold then turn this feature on and off if you did not care about where the attachments went. The ID would need to be very specific in case you get multiple mags with docs of the same file name.
(In reply to comment #25)
Your concern seems to be the technical issue of tracking files. While adding a sequence number to a file name to avoid a clash is OK, I'd argue strongly against adding metadata into the filename.

*nix can track files on a volume, so storing volume/file id in the message will give you on volume tracking. MacOS can also track between volumes. No idea about Win.

I'd be happy with a best effort track (say vol/inode), which will probably work 90%+ of the time, along with a manual "reattach attachment" for a message/selection/mailbox which takes a file/folder. Losing the odd attachment is unfortunate, but not being able to fix it a lot worse. Resorting to what will probably be ugly metadata to build a robust cross-platform solution wouldn't be good. But maybe someone knows how to do it cleanly?
(In reply to comment #23)
> (In reply to comment #18)
<snip>
> 
> * Have "delete this message attachments" and "delete this message and
> attachments" options. The global "delete attachments with message" (or whatever
> it is called) is too coarse.

?? Windows Eudora has had this for ages. Scroll to the bottom of the message, right-click on the attachment's icon. The pop-up menu offers the opportunity to copy, "save-as", and delete the attachment, as well as deleting the entire message.
(In reply to comment #26)
> (In reply to comment #25)

> a manual "reattach attachment" for a
> message/selection/mailbox which takes a file/folder. Losing the odd attachment
> is unfortunate, but not being able to fix it a lot worse.

At a minimum, this feature alone would make a big difference.
Depends on: 9309
I have always loved this feature and, for security reasons, I have always changed the name of the default folder where the attachments are stored.  I voted for this feature.
Of course I applaud the idea of having attachments as separate files. What to do with them is another issue. One should not expect Penelope (or Eudora) to handle everything in one's life: it is just an email client. If you receive ordinary letters with photos inside and do not know the senders you should rather keep the pictures in the envelopes not to mess them. But if you know the senders you can make your own album and sort them by any other criteria. This should be possible to do in Penelope with filters. What there should definitely be is a "move to" in the right-click menu to the attachments.
(In reply to comment #30)
> Of course I applaud the idea of having attachments as separate files. What to
> do with them is another issue. One should not expect Penelope (or Eudora) to
> handle everything in one's life: it is just an email client. If you receive
> ordinary letters with photos inside and do not know the senders you should
> rather keep the pictures in the envelopes not to mess them. But if you know the
> senders you can make your own album and sort them by any other criteria. This
> should be possible to do in Penelope with filters. What there should definitely
> be is a "move to" in the right-click menu to the attachments.
> 

Well all I want is a filter to strip the attachments from all msgs from x sender or with "y" subject etc. and dump them as is into a folder I have made for them in windows file mgr. I have lots of mail boxes and would likely have lots of attachments folders. I need this done automatically on a filter setting. I dont want to do it manually for all msgs I get. If I want to know which attachment came with which msg I can just look at the file name and the date stamp on the attachment and link it with the msg. Also Eudora leave the attachment name in the bottom of the email with a red x thru it noting it was stripped off. That is good.
(In response to comments #30 and #31)
To summarize... What's being asked for here is to be able to have a separate attachments folder for each mailbox, not for each message.  The idea is to support topical mailboxes and attachment folders, so that all messages that I get that relate to a course that I teach (for example) go into a specific mailbox, and all attachments to messages in that mailbox (such as student projects) go into the attachment folder that goes with the mailbox.
(In reply to comment #32)
> (In response to comments #30 and #31)
> To summarize... What's being asked for here is to be able to have a separate
> attachments folder for each mailbox, not for each message.  The idea is to
> support topical mailboxes and attachment folders, so that all messages that I
> get that relate to a course that I teach (for example) go into a specific
> mailbox, and all attachments to messages in that mailbox (such as student
> projects) go into the attachment folder that goes with the mailbox.
> 

You got it. I think this can be done with the existing eudora filter capability which really could be expanded. Right now it allows you to filter by headers but there is also a <body> option. Then on "actions" have an option for "strip attachment" and "transfer attachments to" and then have a dropdown where you can type in the folder path: c:/mydocuments/clients/smith/smith attachments/

Right now I am not worried about re-attaching like I said above. But I think filtering is the way to do this.
I don't want to have to set filters for attachments.  The current Eudora system of sending attachments to a folder works fine for me.  I've transferred emails from my old Mac, to Windows 95, ME, and XP without losing a single one. (That's the joy of plain text email!)

One folder for attachments, ability to rename it and set the path is preferable in my opinion.
The original point was to have attachments stripped from emails UPON RECEIPT (like Eudora does and did for decades :-). That's fundamentally different from how most other mailers, including Thunderbird, handle attachments, where the attachment remains with the message in the mail store and is only extracted when the user explicitly requests it. In Eudora, all attachments are immediately extracted into the "Attachments Folder". This keeps the mail store smaller, so that's why many people (including me) would like to see that basic behaviour in Penelope. But it's probably not too easy to add to the Thunderbird engine.

On the other hand, Eudora also can move attachments to other folders based on filter rules. That's a very handy feature as well. Especially it would be useful for moving Junk attachments away from the normal attachments folder (unfortunately, filters are applied to mails before junking them, so in current Eudora that does not work).

I'd like to have BOTH features retained in Penelope - generally separated attachments and moving attachments based on filters. And the very clever Eudora strategy to delete attachments with the mail message UNLESS the attachment file has been manually moved out of the attachments folder.

(In reply to comment #34)
> I don't want to have to set filters for attachments.  The current Eudora system
> of sending attachments to a folder works fine for me.  I've transferred emails
> from my old Mac, to Windows 95, ME, and XP without losing a single one. (That's
> the joy of plain text email!)
> 
> One folder for attachments, ability to rename it and set the path is preferable
> in my opinion.
> 

You would not have to. The default would be just as it is now. One folder. if you wanted to have the option to use folders you could. That is usually the way it works in software if they expand options. You get the simple or complex method. Pick either. But at least those of us that need the more sophisticated approach to attachments would have it. The others would loose nothing.

(In reply to comment #35)

> On the other hand, Eudora also can move attachments to other folders based on
> filter rules. That's a very handy feature as well. 

No Eudora cannot filter the attachments field in the msg or the attachments. I think you are mistaken on that. You can filter a msg but not its attachment separate from the email which is what I am taking about
I said you can make filters move attachments, and Eudora can do that for sure (at least in the Mac OS version).

I agree that Eudora can't base filter conditions on attachment properties (such as file name or type of attachments), but only header or body text. But all of the discussion here is on separating attachments from messages upon receipt, and then (optionally) have them moved to special places. Current Eudora does both - I hope Penelope will as well.
(In reply to comment #38)
> I said you can make filters move attachments, and Eudora can do that for sure
> (at least in the Mac OS version).

Not in version 7 of windows Eudora you cant. Dont assume Win and Mac versions of Eudora do the same things. The problem here is we have Mac versions of Eudora and Win versions then we have Thunderbird win/mac etc. Too much going on here
> 
> I agree that Eudora can't base filter conditions on attachment properties (such
> as file name or type of attachments), but only header or body text. But all of
> the discussion here is on separating attachments from messages upon receipt,
> and then (optionally) have them moved to special places. Current Eudora does
> both - I hope Penelope will as well.
> 

Right. I know you can strip an attachment off a msg manually in Eudora (Win) and jam it into a folder somewhere. Read my orig post. I want the option to use filters to do this AUTOMATICALLY. Msg. comes in, filtered to mailbox "smith" then takes all the attachments (as you specify) from the "smith" email box (as they come in) and puts them into a folder like C:/mydocuments/clients/smith/

(In reply to comment #39)

> Msg. comes in, filtered to mailbox "smith"
> then takes all the attachments (as you specify) from the "smith" email box (as
> they come in) and puts them into a folder like C:/mydocuments/clients/smith/

That's exactly what Eudora Mac does for me for several years now. The only manual part is in DEFINING the filter for moving client Smith's attachments to the folder "Clients/Smith" - once! But as you have to define a filter for moving Smith's MESSAGES to mailbox "smith" anyway, that's next to no extra effort - just add the "Move Attachments..." action. Is this lacking in the Win version? If so, hopefully Penelope will introduce it for all platforms :-)

(In reply to comment #40)
> (In reply to comment #39)
 Is this lacking in the Win
> version? If so, hopefully Penelope will introduce it for all platforms :-)
> 

YES its lacking in win version 7. I am **** that the Eudora mac people have had this. Why this was never done for the Win users I have no idea. Makes total sense. I just dont understand why they did not do it for Win. Maybe the 5 Eudora guys working on Penelope can tell us.

Again this is why we have to be careful mixing Win and Mac users in these forums as Eudora is different for each. I hope penelope is more similar for Mac/Win.
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
>  Is this lacking in the Win
> > version? If so, hopefully Penelope will introduce it for all platforms :-)
> > 
> 
> YES its lacking in win version 7. I am pissed that the Eudora mac people have
> had this. Why this was never done for the Win users I have no idea. Makes total
> sense. I just dont understand why they did not do it for Win. Maybe the 5
> Eudora guys working on Penelope can tell us.
> 
> Again this is why we have to be careful mixing Win and Mac users in these
> forums as Eudora is different for each. I hope penelope is more similar for
> Mac/Win.
> 


Let me reply to your comments in reverse order. First, I see no reason we need to be careful about mixing Mac and Win Eudora users here. Ideally Penelope will be close to identical on all 3 platforms (Mac, Win, Linux) except for things that are obviously platform-specific like OS X Address Book integration. Getting ideas from both Eudora camps is helpful. Mac Eudora has features Win Eudora does not, and Win Eudora has features that Mac Eudora doesn't...

As for why the ability for filters to move attachments was not implemented in Windows Eudora, I cannot give you the 'official' reason, as I do not know, but I can take a fairly good guess:

It was much, much easier to implement in Mac Eudora than in Windows. On the Mac, Eudora attachments are tracked by File-ID and name, instead of a hard-coded path. This means that a user could move an attachment around (outside of Eudora, even when Eudora was not running) and Eudora could still keep track of the attachment. The user could even have multiple copies of the same message (created by copying a message instead of transferring) and each of those copies could keep track of the attachment(s). Win Eudora (well, Windows in general) keeps track of files by a full path name. Move an attachment in Windows and the path is no longer valid. 

So, to implement on Mac, all that needed to be done by the filter was to move the attachment to the desired location. The OS still knew where the file was, thus Eudora could find the file. In Windows, Eudora would have had to move the file, then re-write the message with the new link to the attachment. Not necessarily a 'huge' deal, but it would have required significant work, unlike the Mac which basically gave it to us for 'free'. And Win Eudora would not have been able to deal well with copies of the message as each copy would need to have the path to the attachment updated every time an attachment was moved. Seeing as Eudora has no concept of 'message A is a copy of message B' there would simply be no way to update all the relevant paths.

The Mac OS made it easy by allowing Eudora to track files by a File-ID and NOT by path...

For Penelope we need to come up with a single method that will work on all platforms...

Matt
(In reply to comment #42)
> (In reply to comment #41)
> > (In reply to comment #40)
> > > (In reply to comment #39)

> The Mac OS made it easy by allowing Eudora to track files by a File-ID and NOT
> by path...
> 
> For Penelope we need to come up with a single method that will work on all
> platforms...
> 
> Matt
> 

Better address book and attachment handling...hmm I guess I better move to a Mac LOL. All I was trying to point out is that Mac and Win users are asking for things that the other side does not understand. Fortunately you developers do as you worked on both mac and Win Eudora. The other problem, as I mentioned before is we need to be knowledgeable in what Thunderbird does and does not do and we are all Eudora users.

Having the coolest features of Win Eudora and Mac Eudora in Penelope sounds like a tall order. Attachment handling/tracking/moving would be one.

The Penelope default should be to handle mail msg/attachment structures *exactly* like Eudora. -k
The most important feature of Eudora for me is ability to keep attachments separate from mailboxes. That is what I expect that Penelope will have, and Thunderbird in future. Otherwise everyday work with Thunderbird will be still very hard.
That's was one of best goal of Eudora!!
Just for example this feature, simplify a synchronyzation or incremental backup of mailboxes!
Assignee: mozilla-bugs → sdorner
With 46 (and rising) comments, I suggest that the many suggestions herein be summarized and to the degree necessary for prioritization, be separated.

My own priority is that the connection between e-mail messages and attachments be very robust.  Mac Eudora of recent versions invariably looses such connections when several duplicate filenames occur.  (I suspect it has to do with dealing with duplicate file names poorly;  instead of renaming a file once, there appears to be an attempt the preserve to most recent instance of a file name and renaming all that came before--such a scheme can not be successful as the e-mail client can only be sure of being able to control the file as it is being delivered.)

I echo comment Basil's comment in #13 above:  not only should one be able to authoritatively locate an attachment from it e-mail message, it would be very useful to be able determine the source of a received attachment file later.  (Perhaps this should be through Finder/Spotlight comments, but the mechanism isn't the issue, it is the capability.)
Something I left out of my comment #47 ...

The connection between e-mail messages and attachment file should be preservable even if one has to change computer or restore drives.  My own thoughts are that that attachment directories should be relative to a users home directory so as to be able to easily move (or duplicate, in the case of a laptop when traveling) everything.  Mac Eudora is problematic in that regard:  yes I can, and do, have many, many attachment folders to which filters can Move attachments, but if I have to travel with my laptop, this all breaks and I have to laboriously recreate all of those filter links on the laptop and then potentially again when I return from my travel.
Could it be a solution to use symbolic links to save the connection between messages and their attached files? Such are available in Linux and Windows (*.lnk); I do not know about Mac. 
These links could be stored in the same folder as the mailbox. 
Disadvantage would be that the mailboxes & attachment storage can not be transferred to a different operating system, but I fear that this would anyway be the case because of the differences in the file systems. 
The link would be created when an attachment is first stripped from its message. When later the attachment is moved, only the link must be updated.

To supplement my comments #47 & #48 in this thread:

Attachments should work with SEND AGAIN function (without having to re-attach the attachments).

Currently, SEND AGAIN on Mac Eudora does not work if there are attachments and the message was transferred after the original send.  Currently, Mac Eudora loses track of an attachment if one has a filter that transfers the outgoing message automatically from OUT to another mailbox.
This is my number one complaint about Eudora actually.  I have been using it since 1994, and for most if not all my old messages, the attachments have become lost or links broken due to folder changes.  I am quite looking forward to being able to archive messagess with attachments safely intact.

-z
This feature is one of the primary reasons I prefer Eudora to other e-mail programs, including Outlook (which I use all day at the office), Thunderbird and Apple Mail. I need to know where my attachments are. In fact, I always create a "Eudora Attachments" directory within "My Documents" to avoid the lost or hidden directory problem. It also makes it easier to transfer files around with Total Commander, my file manager of choice.


I'll add my 2¢.

I'd like to see each mailbox represented as a directory (specifically a package on OS X) containing the plain-text mailbox, index, and -- optionally, perhaps -- a subdirectory for attachments. That way an entire mailbox, including index and attachments, could be easily manipulated in the file system.

Further, I suggest that attachments be stored in per-message sub-directories; this would solve the attachment renaming problem. The sub-directory should also provide some way of finding the associated message.
I was amazed and confounded when I found out TB keeps attachments in mail unless I manually click each attachment.  It's good exercise for my finger, and I will use the middle one to do it...

Suggestions
1) Provide option to automatically strip off and send all attachments to the user specified folder, which is already defined in ThunderBird as first goal.  Do it soon as can be done to keep the ex-Eudora users like me on TB.
[Like other commenters, I regularly clean out this folder, removing duplicates, and moving files to other folders or deleteing.  I do NOT need any link to an email to continue doing this.  However, if an email is spam, and I delete it, I like seeing the attachment IN THE SPECIFIED ATTACHMENT FOLDER get deleted also -- standard old Eudora process.
2) When there is time, work on the other ideas provided as suggestions for keeping links, etc., for people who need that.
2) The ot
Yes! The number one reason I still use Eudora. There's room for improvement in the management of attachments, and some good suggestions here for that already. My needs are more simple, so I won't comment further, except to say that people who don't want automatic detachment of files ought to be looking at Thunderbird or some other client.
Status: NEW → ASSIGNED
Would love to have this feature.  I am still using Eudora, specifically to have all attachments appear in my attachment folder.
> ?? Windows Eudora has had this for ages. Scroll to the bottom of the message,
> right-click on the attachment's icon. The pop-up menu offers the opportunity to
> copy, "save-as", and delete the attachment, as well as deleting the entire
> message.
> 
Although that is true the point is that, as others have said, we a talking about mass moving messages around. Opening each message is not feasible in this context.

I definitely want to keep attachments outside the .mbx file itself, and by default Penelope should do the same as Eudora -- keep them all in a single folder.

Having said that, I would like the *option* of keeping all attachments for messages in a particular mailbox in a separate folder related to and nearby that mailbox -- eg. a mailbox stored as D:\Mail\SomeFolder\MyBox.mbx should have an attachments folder like D:\Mail\SomeFolder\MyBox.attach (or something along those lines).  It'd be ok if you'd have to set this up as a filter on a mailbox-by-mailbox basis, but I'd really prefer it if you could just set an option and have it happen automatically, with possibly filter rules for exception cases.

Similarly, when moving messages between mailboxes it should move the attachments accordingly (which is easier if you're not using filters to manage this process).  And I second the request for being able to manually fix up attachment links, if the need arises.

I also think that it should store the path to the attachment files as relative to the mailbox file, rather than an absolute path -- that way you can robustly archive an entire mailbox together with its attachments and you'll be able to restore it later on (or on a different computer) without losing any of the links.

I don't care about whether it can track attachments moved outside of Eudora/Penelope itself (I doubt that's feasible on Win anyway), although equivalent functionity within Eudora/Penelope would be nice (and for the most part already exists if you can find the corresponding message) -- which brings up the next request: add the ability to find a message by the filename of one of its attachments.  That way you can easily figure out which message the Blargl 242.doc file is attached to and work out if you want to keep it or kill it.
Jumping in with another reason to keep the behavior.

Eudora's action of decoding the attachments automatically has been a lifesaver with over-aggressive anti virus software.

A new virus comes out. The AV scanners have not updated for it yet. The user receives the virus as an attachment that is automatically decoded and saved. The user recognizes the attachment as a virus and doesn't open it. Later in the day, the AV scanner is updated. The next time the folder or that attachment is checked, the virus is destroyed. No problem.

The same situation with Outlook. If the AV scanner can decode mime (and some do) the first time that Outlook is opened after the AV is updated, AV may not be able to remove the mime from the database file and will quarantine the entire inbox, causing Outlook to crash.  It's been a while since I've had this happen, but it does.
I like that attachments are stored in a folder of my choosing, separate from the emails.  
I want that, if I move an attachment from the default folder to somewhere else on my hard drive, I can still find and open that attachment by using the email it originally came with.

My attchments folder is getting very huge, because I save a lot of images.  I wish I could put them where they make sense!
One more vote for the suggestion at the top of this discussion. Like pretty much everyone else here, having attachments stripped out of the mailbox and stored in their original file formats elsewhere is absolutely essential for me. Without this feature in Penelope, I'd simply keep using Eudora for as long as I could. Organizing attachments in their separate folders, but by mailbox, is a really neat idea, provided that they are moved automatically by Penelope when the messages are moved between mailboxes. If this is too difficult in Windows, I'd prefer to keep all attachments in one folder as Eudora does now.

In addition to all the reasons given above, my main reason for needing the current arrangement is that it greatly reduces the size of the files that one needs to transfer when synchronizing Eudora between different computers. If the attachments are still part of the mailbox file as in TB and Outlook, then the files that need to be transferred during the synchronization (i.e. the new files and files that have changed) get very big, making the synchronization very unwieldy. Eudora's way of doing it means that only new attachments, and the mailboxes that have been changed (which compress well), need to be synced, which is pretty manageable.
Very much in favour, but no valid additional comments
Essential to me for:
  - general file system hygene
  - keeping mail files fully parsable by external utilities
  - managing 10 years worth of mail as a single hierarchy (the text files and TOCs  total nearly a GB now, the attachments are 10 GB)
excellent idea.... been asking qualcomm for this for years [started using in v 1.1!!!]
One more vote for the separate storage of the attachments in their original format. Much easier to handle, manipulate, copy, move, file... you name it! This is a must! Do it, please.
(In reply to comment #65)
> One more vote for the separate storage of the attachments in their original
> format. Much easier to handle, manipulate, copy, move, file... you name it!
> This is a must! Do it, please.
> 

Yes I do want the mail format and the attachment formating to remain the same. I just want the ability to have the attachments diverted to a windows folder of my choice based on the mailbox the msg goes in. I just want the option. Nothing has to change from the way Eudora Win is now, just add this option
This is one of the main features which we MUST have. It allows one to manage, open, move attached files even from outside Eudora...
I agree that separating attachments is a Good Thing in Eudora, however I do have some concerns that the current attachment handling on the Mac is a little flaky. Attachments seem to come ... well, unattached, for reasons I have never been able to fathom. If this kind of functionality is to remain, it might do well to leverage some of the file system's meta data functionality to try and keep a better grip on where said attachments are being stored.
(In reply to comment #68)
> Attachments seem to come ... well, unattached, for reasons I have never
> been able to fathom.

The reason is that Eudora was never properly updated to handle long (>32 chars) filenames, even though OS X supports it.  Instead, Eudora stores the link to the attachment using a hash based on the file's inode... and, if you happen to move your Eudora folder from one hard drive to another, the inode value changes, and the attachment link is lost.

Even worse, there is no current way to re-attach the lost attachments except through a fairly complicated and time-consuming manual method.

See more about the attachment problem here:
http://eudorabb.qualcomm.com/showthread.php?p=32557#post32557
Actually, this feature is one of two reasons that I have considered leaving Eudora (the other is random loss of Imap messages). I don't like having to clean up the attachments directory manually, and I find that Eudora isn't always good about deleting files automatically. If this feature is added, it should at least be optional.
Well, the attachments not beeing cleaned up is one disadvantage of having the attachments kept external (detached on arrival). But most of my attachments need to be kept in some other folders, when I still need to keep the message which came with them. If attachments remain attached as it is the case with other email software, then all this stuff is stored twice and the mailboxes become very very big...
One suggestion would then be to have the option of deleting the attached file and embedded pictures (which are also kept in a separate folder) when deleting messages - except of course when you have moved or renamed these attachments.
So I insist that this feature is ONE CRUCIAL ADVANTAGE OF EUDORA over other software.
There were two reasons I originally chose Eudora:

- No database structure

 and

- No database structure

It made no sense to me at all that my e mail be hidden away in a proprietary data store that I had no means to access if I didn't have Eudora, that I couldn't do a text search over, that bloated when it started adding attachments into and that, when corruped (notice 'when' not 'if'), made it practically impossible to restore messages in readable form. Then there's the maintenance....

I feel that the retention of Eudora's ability to store Attachments in a regular folder is important, but I would really like to see the feature work reliably.  I say this as someone who has been using Euora on the Mac since System 6 and have had reasonable success with the feature, but feel that better consistency and modern file system support are necessary to make the feature successful.
Being Eudora User since Win 3.1, I must say I LOVE the separate attachment store. pst & Co simply sucks. Comment #7 speaks deep from my heart.

The concept of efficient separate attachment storage could even be improved over Eudora 7 in two ways:
1. The handling of incompletely doenloaded attachments in IMAP creates e.g. "filename", the full download "filename1". Most of the time the link in the Mail body is not updated correctly. Note that this is a different bug from Comment #11

2. Efficient storage could also be implemented by letting Penelope understand maildir format. The advantage: Export a maildir from the mail server as a share and save all the reading/copying etc. We distribute live mbx = mailbox format filea quite often in this way (using dovecot as a fuly fuctional mixed-mode MDA). So why not use the fairly efficient maildir standard as a second storage alternative to mailbox format? Woukld be great for people who get tons of attachments? There is plenty of code out there to use, so no need to re-invent the wheel.

+1 for Maildir :)  (And I repeat what I said in comment #58.)
Comment #0 
> a) Should Penelope have an option to strip attachments from messages upon receipt?
> b) Ideally, the user should be able to set the attachments folder on a
> mailbox-by-mailbox basis,
> c) as well as use Filters to extract attachments to a
> specific folder, or to the Trash, Recycle Bin, /dev/null, etc.
> 

comment #0 - point (a):
Yes Penelope MUST have this option. Comment #7 mentions 3 points which I also advocate - it is the same way I manage the attachments. I would add I find this EXTREMELY useful because:
a) It keeps my mbx files small. 
b) I can do a search from the OS command line to search for text in my emails and elsewhere in the file system (cf. In other systems you would need to search your files system PLUS another search of the PST files or other special formats ) 


comment #0 - point (b):
I think doing this by enhancing  filter processing is the way to go as it will allow bulk processing of messages. If point (b) is implying an extra attribute of mbx files (meta-data somewhere) so that moving messages between mbx files triggers attachment moves depending on meta data then  I think that would be a bad idea. An enhanced filter processing would cater for Comment #32 and #33 concerns.

comment #0 point (c) - These extra filter option would be very good


A few of the comments have suggested features that we need for the mbx/toc/external attachment files we really need but are not directly part of point (a),(b), and (c). Maybe a separate bugzilla entry should be made dependent on this (request bug # 359319)?

In Comment #7, his argument section (b is the reason I stayed with Eudora at work until recently when they ORDERED me to use Outlook.  I'm the Antivirus Admin, and I couldn't prevail on them to see the error in the way Outlook [and T'bird] keep attachments IN the incoming email messages.  Get them stripped OUT and scanned and only do it ONCE... not every time your Inbox file changes because you got new email!  BTW, I STILL use Eudora at home!!
Not only the waste of checking the whole Inbox over and over...
More importantly to me is the fact that I've seen several times a complete Inbox-file being invalidated or quarantined by an AV-package because of a virus in an attachment. That's a serious loss! Would the attachment had been stripped right away, like Eudora does it, then only the infected attachment is lost.

Furthermore it's so conveniant to be able to access the attachment-folder straight away, without first have to go to the email and then do an "detach" or "save as" of the attachment.
I am using Eudora as of day 1 of my online presence (since 1994) and I love the product a.o. because of this architecture.
At the risk of sounding redundant to the above, let me comment:

I've been using Eudora since version 2.something (and have 90% of the email I've received with it on file - something that's been useful at times) and love the fact that attachements are stored as separate files (forcing the antivifus software to inspect them as they get written to the hard drive). I also find it useful to be able to get into the attachements directory with a file manager... If I receive 20 source files as attachements I can open the attchments directory
(using a shortcut that lives on my desktop) grab those files and copy them to
the project directory.

My preferences for Penelope:
1) The existing attachments folder gets renamed to something like 
IN.attachments and moved to rest next to the IN folder. Likewise for
IN.embedded.

2) A separate attachments and embeddeds directory for each mail folder, if a
given message remains in the In box the attchment stays in the IN.attachment
and the embeddeds in the IN.embedded folder. 
I agree completely with Comment #58, especially the last paragraph.
Comment #33 handles this nicely with the filters function (which I really
really hope gets expanded to more than 2 conditions).
Comment #14 is appropriate - if I receive a message with a bunch of source
files attached I can move them to the project folder and the message "knows"
where they are. Right now I make copies.
Comment #11 presents something that has bugged me for years. Can we implement
that in the first release? 

3) Add a button to the toolbar library that when clicked deletes the attachment
(only works while reading the message). This is useful when going through
incoming mail and a dozen folks are sending you the same file.
I do this a lot with VCF files that I already have in my address book.

4) How about a way to decide which attachments get filed, or trashed: VCFs are
a special case - they get compared to the appropriate entry in the address
book. If equal they get trashed. If not, prompt for permission to update the
address book entry then trashed. And the address book gets a new entry: "Last
updated on" (date)(time) 

Speaking of address books, I'd like a way to be able to extract it as a comma
delimited file so I can process it elsewhere - like against my Palm pilot data
base.

And the conversion process from the present collefctive attachements directory
to a per-mailbox attachements directory should allow relinking lost
attachments.

A feature for shared and private address books for systems that have more than
one user on a machine.  The living room desktop machine is used by Dad, Mom and
three kids. Each "My documents" lives on the RAID-based server in the garage. 
Ther is no sense in having 5 copies of the email addresses for the extended
family when a programming change would allow a common address book named
"Extended Family".
About the idea in #78 that there be several attachment directories, rather than one global one:  an interesting idea, but I'd recommend the name/filespace be divided the other way.

If I understand it correctly, the suggestion was:

IN
IN.attach

FOO
FOO.attach

etc.

Which is fine except for when you want to globally search for an attachment using explorer or grep or whatever.  So I'd like to suggest:

IN
FOO
BAR
ATTACH
   \Attach.IN
   \Attach.FOO
   \Attach.BAR

As I said back in Comment #58, the default should probably be a flat directory (as now), but it should have both alternatives mentioned in the two comments above as options.  (Since some people will want it one way and others a different way.)

Extra points if it can auto-migrate the attachments appropriately when the option is changed :)  [Which would also be a useful way of identifying "dangling" attachments -- they wouldn't get moved from the flat folder to the box-specific folder.]
when sending attachments, however, don't recreate them in the "sent" folder~!
Priority: -- → P2
I'm agree with the comment #79. I like the structure of the directory inside the main folder ATTACH.


See comments 31-33, 36, 37, 39, 41, 47 and 66. All I wanted was the option to do this. Those that dont want it DONT USE THE OPTION once it becomes available. I think its simple. I am not a programmer so I think in terms of simplicity and user needs. I try not to make things over complicated or invest a million hrs in a solution that looks simple in the current win eudora filter framework
(In reply to comment #0)
> Should Penelope have an option to strip attachments from 
> messages upon receipt?

Yes!!  This facilitates malware management without the need for desperate av-email integrations that tend to mess up email traffic and will miss brand-new threats anyway.  See:

http://cquirke.mvps.org/9x/empath.htm

It is the #1 reason I use, advocate and deploy Eudora.
(In reply to comment #84)
> (In reply to comment #0)
> > Should Penelope have an option to strip attachments from 
> > messages upon receipt?> 
> Yes!!  This facilitates malware management without the need for desperate
> av-email integrations that tend to mess up email traffic and will miss
> brand-new threats anyway.  See:> 
> http://cquirke.mvps.org/9x/empath.htm> 
> It is the #1 reason I use, advocate and deploy Eudora.
> 
Chris, thanks for your detailed explanation.
YES, this definitely is the No. 1 reason why Penelope should have this facility!!! I advocated this rationale earlier in Comment#77.

Having separate attachments is one of the main reasons to use Eudora, which I am still using. If I wanted my email program to act like Outlook I would switch to Outlook. My only other comment is that I think that any new version should keep things simple, like Eudora. It should not try and do everything. It should just be a really good email program. Also fix the HTML rendering. Thanks

Let me pitch in with my thoughts...

Default Behavior - keep attachment with the message in the database file

Option1 - strip attachments into document root folder, e.g. on Mac, it would be /Users/(username)/Eudora/Profiles/Attachments... linux would be similar, e.g. /home/(username)/eudora/attachments (current thunderbird on linux puts things in a .thunderbird dir BTW). This would be consistent with current default eudora behavior.

Option2 - Similar to option one, but based on filter directives into user specified folders/directories.

Personally, I prefer the default option, as this is current thunderbird behavior, and makes backups a bit easier to manage. Additionally, this is less file system overhead, as I can still save a copy of the attachment if desired to a project folder. Option1 is workable, but option2 could be problematic if moving from one machine/platform to another, which could result in data loss.

It was one of my big gripes about Eudora, is that it did split the attachments from the message, and caused 2 problems: 1) data loss (apparent and/or real) and 2) significant filesystem fragmentation. I receive hundreds of emails a week, many with attachments, and both items one and two (item 2 being more significant).

Remember that code baseline for mailbox handling in Thunderbird is a sql oriented database, and not an indexed flat file that was previously implemented in Eudora.

The argument about AV apps, holds little water... most AV apps scan both on receive, e.g. either as a pop3/imap proxy, and they also scan on file operations, so updated AV definitions should catch this. 

-- Tim 
(In reply to comment #87)

> Default Behavior - keep attachment with the message in the database file

I'd vote AGAINST that.

> Personally, I prefer the default option, as this is current thunderbird
> behavior, and makes backups a bit easier to manage. 

I don't want unsolicited emaul attackments within my "data" backup, so that's a big reason why I not only want attachments never stored within mail stores under any circumstances, but also in a location that is user-definable, e.g. outside the mail data entirely.

> The argument about AV apps, holds little water... most AV apps scan both on
> receive, e.g. either as a pop3/imap proxy, and they also scan on file
> operations, so updated AV definitions should catch this. 

Not the point.  I don't want malware hidden on my PC, anywhere, and dependent on the av to catch it every/any time it might be invoked.

At the time email arrives, 1-generation mass spread can push new malware at you before your av knows what it is.  Most email apps will then store this within the mail "data", where it will remain hidden.  

An updated av catches the file when it's "opened", but can do nothing to clean the file within the mail store (or will most likely trash the mail store if it tries).  So the hidden attachment remains a risk, and every time it's invoked, the av has to catch it all over again.
(In reply to comment #14)

> No problem if attachments are first kept in the mailbox, as part of the
> messages. 

That I wouldn't want.  In practice, messages arrive in Eudora's spool folder as separate files, one per message, with attachments embedded - rather like OE's .EML files, I guess.  If anything crashes the process of managing the material at this point (e.g. the filenameNNN bug from version 6.xx or so) then Eudora crashes, and will re-crash every time it's started because it will immediately try to clear the spool into mail stores, etc.

By splitting the attachments out at this stage, *before* the material enters the mailboxes (and attachments are stripped and saved as files in Embedded or Attach), such problems are kept out of the mail stores.  IOW, logic bombs that blow up the email app when it processes mis-nested attachments etc. are not embedded in the mailbox... it may be a pain to flush the spool folder, but it is a LOT easier than manually recovering messages from a lethally-corrupted mailbox file.
(In reply to comment #87)

About file system fragmentation, etc. 

> 2) significant filesystem fragmentation. I receive hundreds of emails a
> week, many with attachments

I'm more concerned about risks associated with large mailboxes, compared to the fragmentation effect of small come-and-go files.  I think there's more impact from large web caches than loose attachment files, even if you don't have an IE with absurdly large web cache size to fight with   ;-)

Mailboxes are not only larger if attachemnts are kept within them, but the often extreme variation in "message" (i.e. message + all associated attachments) can skew database item hashing strategies that aim to distribute items evenly across the database's internal file structure.

The larger the mailbox file, the longer the critical windows when items are added, and the more likely it may be corrupted and data lost.  Large mailboxes take longer to compact, and finally, if you mimic Eudora's behavior in storing In, Out and Trash in memory, then the memory footprint bloats up as well.

So I'd prefer to trade off the fragmentation impact of loose attachment files against the fragility of larger and more fragile mailbox files.  From a fragmentation perspective, large slow-growing files (like mailboxes) become fragmentation issues in their own right, which contributes to the risks I mentioned; also, defragging may find it more difficult to unfragment a large fragmented mailbox file (especially if free space is low) than to re-arrange multiple small files.

On much of this, YMMV in terms of your file system.  Even in Windows, what is clunky in FATxx (large numbers of directory items, as FATxx uses linear look-up) is elegant in NTFS (as indexed directory structure reduces the impact).

On balance, I'd value data survivability and hygiene over performance efficiencies, though I'm not blind to that impact - my own Eudora data load is 900M, and that's excluding the attachment location.  The largest of over 100 mailboxes is 45M; folding attachments back into that would be ungood.

 
On losing links to attachments when moving mail; there are two parts to this, one easy and one less so...

1)  Attachment path

This is the easy bit.  I'd solve this by storing in Eudora.ini (or equivalent) a list of alternate lookup paths.  The logic would then be:
  - first, look in path specified in attachment link
    - if exists, that's the file; done (suggest MD5 matching sanity-check?)
    - if not, consult options
      - if option to alert is set, then 
        - alert and ask user what to do
      - else 
        - consult list of alternate locations in Eudora.ini
        - check each location in turn
        - if no match, show error

When Eudora first processes an incoming message from spool to mailbox etc., it is at this point that the attachment path is hardcoded into the reference within the message.  If you later re-locate the attachment location, you invalidate that link; current Eudora behaviour is to then "give up".

The above logic allows moved attachment stores to be tracked, after the initial lookup fails.  The same UI that the user uses to change the attachment location, can also maintains a list of historical locations in reverse order, e.g.:
  - I install Eudora and the wizard imports mail
  - all imported mail has links to default attachment location
  - I change the attachment location to A and move the files
  - I get more mail, which now has links to A
  - I change the attachment location to B and move the files
  - I get more mail, which now has links to B

By now, by Eudora.ini [AttachLookUp] looks like this:
  Location B
  Location A
  Original location

When I read one of the messages I imported first, it looks for the file in Original location, and can't find it.  So it checks the list from the top, and gets lucky... or should it check the list in the other order?   ;-)

If data is moved so that links are broken (i.e. as the approved UI is not used, the old location isn't saved in [AttachLookUp]) then the user can do one of two things; manually add the new location to the .ini file, do the same as a side-effect of "changing" the setting via the UI, or run a "special" function that wades through the mail stores to rebuild the list from scratch.

2)  Attachment name

This is the tricky part!  Eudora incriments names when these clash, i.e. ReadMe.txt, ReadMe1.txt, ReadMe2.txt etc. and we've already seen scalability issues with this when particular types of mail spawn thousands of attachments with the same name, blowing out at SomeName9999.ext or so.

The more insideous risk is that blind index incriments may foul up when "holes" are created, name ambiguities arise when merging mail stores and attachment collections, etc.  There's a potentially-spoofable safety risk when message A that should find attachment Blah5.txt finds and "opens" Blah3.txt instead.

In the simple case of moving one mail store with flat attachment storage location to another system, it's OK; in fact, as long as you use the same path on the new system for the attachment location, there's no problem at all.

But once you get into different subdirectories to mirror the mailbox heirarchy, it gets messier; it also gets messy when merging mail data sets (something that Eudora otherwise handles with aplomb; no "special" mandatory mailbox names to clash, just make a new Blah.FOL dir and drop the mailboxes in there).

I like the idea of sanity-checking that the "right" file is reached by using MD5, but that breaks the link if the file is changed (e.g. av removing malware macros from infected documents you still want to use, or your own edits and saves, etc.).
 

(In reply to comment #87)
> Remember that code baseline for mailbox handling in Thunderbird is a sql
> oriented database, and not an indexed flat file that was previously implemented
> in Eudora.
> 
> -- Tim 
> 

I have to correct myself on one thing... the mailbox is saved on the client side as a plaintext file, so it's not _that_ much different than eudora in that context. I was looking and thinking about a different application. Apologies for my misstating this particular item.

-- Tim
(In reply to comment #91)
> (In reply to comment #87)
> 
> About file system fragmentation, etc. 
> 
> > 2) significant filesystem fragmentation. I receive hundreds of emails a
> > week, many with attachments
> 
> I'm more concerned about risks associated with large mailboxes, compared to the
> fragmentation effect of small come-and-go files.  I think there's more impact
> from large web caches than loose attachment files, even if you don't have an IE
> with absurdly large web cache size to fight with   ;-)
> 
> Mailboxes are not only larger if attachemnts are kept within them, but the
> often extreme variation in "message" (i.e. message + all associated
> attachments) can skew database item hashing strategies that aim to distribute
> items evenly across the database's internal file structure.
> 
> The larger the mailbox file, the longer the critical windows when items are
> added, and the more likely it may be corrupted and data lost.  Large mailboxes
> take longer to compact, and finally, if you mimic Eudora's behavior in storing
> In, Out and Trash in memory, then the memory footprint bloats up as well.
> 
> So I'd prefer to trade off the fragmentation impact of loose attachment files
> against the fragility of larger and more fragile mailbox files.  From a
> fragmentation perspective, large slow-growing files (like mailboxes) become
> fragmentation issues in their own right, which contributes to the risks I
> mentioned; also, defragging may find it more difficult to unfragment a large
> fragmented mailbox file (especially if free space is low) than to re-arrange
> multiple small files.
> 
> On much of this, YMMV in terms of your file system.  Even in Windows, what is
> clunky in FATxx (large numbers of directory items, as FATxx uses linear
> look-up) is elegant in NTFS (as indexed directory structure reduces the
> impact).
> 
> On balance, I'd value data survivability and hygiene over performance
> efficiencies, though I'm not blind to that impact - my own Eudora data load is
> 900M, and that's excluding the attachment location.  The largest of over 100
> mailboxes is 45M; folding attachments back into that would be ungood.
> 
> 
> 

This is the critical issue surrounding this bug.  Over time, mailbox files get to be very large and increasingly filled with small errors due to application and system crashes.  Most of them are innocuous, but leaving the attachments in the mailbox file multiplies the risk and accelerates the time when there's an important corruption.

Avoiding corruption must trump performance issues.  Memory bloat isn't nice, but my Tbird already gets a total memory footprint of 500 MB after some usage (much larger than I experienced with Eudora) -- but I deal with it.
a) Can people *please* try to limit their quoting to the minimum needed for context? After all, Bugzilla keeps all the old text for us to review....

Also, please make your point{s} explicit; this thread is so long by now that I at least have a hard time trying to remember we're here to drain the swamp, not count the alligators..

That said, my comments/questions below may well just add to the muddle....

b) Have we explicitly said that the Inbox is treated the same as all others?

c) Having had a PHB who insisted he MUST keep everything in his Inbox, no matter how big that was... I can say performance issues better not be ignored. It matters. [Irony: the slowdown of such was an important ally; it got him to finally split up his mail folders....]

d) Re: "avoiding corruption" I'd like to ponder the concept of "fixing" a mailbox; i.e. a fsck-like function to repair a damaged mailbox. 

e) As I understand it [and I could easily be befuddled by the last 90-odd comments...] the folks in favor of "all in one & one for all" are worried about moving a mailbox inc. attachments to another machine/to off-site storage/etc.
Is a tool to do just that a good or bad approach? i.e it knows about attachments, and re-associates them as it goes...





I have roughly one hundred mailboxes, half of them old archives e-mails.
I receive probably over 10 attached files per day, related to different subjects and working groups. 
For most of these files, I need to have them in my document folders relative to these different groups and activities. If they were not stripped, I'd need to duplicate them.
In addition, quite often if not most of the time, I need to rename them to something more logical - the most obvious one is when somebody send you his article named article.doc...
Looking through all my numerous files in my computer, I use my one orgnisation of folders and Copernic Desktop Search, not my e-mails, except for quite recent e-mails.
For all these reasons, I need to have attachment stripped on arrival.
Of course, if there was a system to move (and even rename?) attached files from within Eudora while keeping a valid link to the file, that would be great... 
re comment 95:
(a) sorry for any contribution I may have made to this by using the "reply" link
(b) for the sake of usability, the Inbox ought to behave the same as all other folders.  I believe that the Inbox is the one that's most vulnerable to the bad aspects of BigFiles and attachments, but the rest of the mailboxes should be consistent (including, IMHO, "Sent")
(c) performance issues shouldn't be *ignored*, but they should be trumped by security and corruption.  i do LOVE the irony statement, tho.
(d) could do.  maybe should do.  would rather limit the cases so it's a "parts per million" problem.  Demming was right.
(e) your suggestion would be uber cool.  it would have to be pretty smart to find files that had been moved or renamed...but maybe it should just substitute a text file in the message attachment saying "file foo.bar (3453987 bytes) not found in attachment archive" 

re comment 95:
(oops, pushed commit too soon)
(b) I don't know that we've explicitly discussed the proper behavior when a message is deleted.  Eudora deleted attachments along with messages -- mostly harmless, but I'm not sure this behavior will be wonderful in Tbird.  Perhaps (to prevent nasty surprises) a message delete should move the associated attachments into a DeletedAttachments folder.
I’ve been a home user of Eudora for several years. I’ve used Thunderbird but do not like how attachments reside with messages.  Personally, I think Penelope should mimic Eudora’s abilities as much as possible in how it handles attachments and individual addresses in its address book (which is another topic). BTW, I sure do thank all of you who are helping to develop open source Eudora.
(In reply to comment #98)
> Eudora deleted attachments along with messages -- mostly
> harmless, but I'm not sure this behavior will be wonderful in Tbird.  Perhaps
> (to prevent nasty surprises) a message delete should move the associated
> attachments into a DeletedAttachments folder.
> 
Eudora 6 for Mac gives one the option in Settings of deleting attachments with parent mail or not. An option I really like.

My first post; I've been a home Mac Eudora user since version 2 in 1994. Many thanks to all working on this vital project. If there is another mailer which comes within light years of Eudora, I have yet to find it.
(In reply to comment #92)
> 2)  Attachment name
> 
> This is the tricky part!  Eudora incriments names when these clash, i.e.
> ReadMe.txt, ReadMe1.txt, ReadMe2.txt etc. and we've already seen scalability
...
> In the simple case of moving one mail store with flat attachment storage

There is a simple solution to the problem of auto-connecting attachment files with messages: Use wht's alreday in the message, i.e. the message ID. Prepend it to the filename. This solves not only the 1...999-Problem, but lets you rebuild index and the links in the Mailbox file.

That would be fairly sinple to implement and still human-readable, eg. 825CECCC1A037842B62C6593D1EB51F6952E0E40_Some_File.doc

Other alternative: Use a fine-grain timestamp, eg. ssmmhhddMMYYYY:
11231310092007_some-file.doc

Would be even more trivial to strip these filenames back to original - if ever desired.
(In reply to comment #101)
> That would be fairly sinple to implement and still human-readable, eg.
> 825CECCC1A037842B62C6593D1EB51F6952E0E40_Some_File.doc
> Other alternative: Use a fine-grain timestamp, eg. ssmmhhddMMYYYY:
> 11231310092007_some-file.doc
> Would be even more trivial to strip these filenames back to original - if ever desired.

That's not exactly what I'd call human readable.  (And if you do something like that anyway, the weird numbers should be at the end, otherwise there's no way you'd find something you're looking for by browsing the folder directly.)

It's already been discussed earlier in this bug that Mac Eudora already tracks attachments through some filesystem id tag (as long as it stayed on the same volume, anyway).  A similar mechanism is available in Linux and OSX (inodes).  I don't know if there's an accessible equivalent in NTFS, but there might be.  (I don't hold out much hope for FAT32, though, which could be an issue for people running Eudora from memory sticks.)

On #10 and #21, one solution to the "I moved the mail location, now lost the attachments" is to use relative path addressing as the value for attachment path, including as this is embedded as link within the message.

That works if the link is interpreted relative to the base of the data set, i.e. location of Eudora.ini rather than the location of the mailbox.

So if you store attachments in ATTACH within the data set (as is the default) the path value should be .\ATTACH, not "C:\Wherever\Blah\Base\Attach".  That way, you could move the whole data set from "C:\Wherever\Blah\Base" to "E:\Some\New\Place" and the links within old messages would still work.

Those of us who prefer to keep attachments out of the data set can still do this, by reversing out of the data set via .. navigation, e.g. relative to...

   Data\Mail\Eudora.ini

...the attachment location might be pathed as...

   ..\..\Incoming\Attach

...for this layout:

\Fred\Data\Mail\
\Fred\Incoming\Attach

That way, all of \Fred\Data can be backed up including Eudora mail, but excluding attachments (as may be desirable for risk management).
Eudoras simple GUI tools and functions environment is so well established this is the reason why so many users stayed with it.

I was campaigning for the multiple attachments folders with many others in the Eudora forum and the requests posted in the Eudora forum are still very much relevant. First though Penelope needs to become Eudora not Thunderbird with a Eudora face. That would be a waste of time and effort.
See Original Thread on this requirement.
http://eudorabb.qualcomm.com/showthread.php?t=5697
Yes, multiple attachments folders would be VERY useful as I have accidentally deleted important attachments in the past when receiving virii attachments and having PC Cillin go nuts.

I currently right click and save important attachments elsewhere, but your option is much more efficient. 

I would find the ability to preserve attachments in certain folders permantently a great advantage.



Um... what happened to the Cc list for this bug?!
According to the change email, they were all inexplicably removed by Deanna's comment.  I've got them all listed in the email, but I doubt it'd be polite for me to add them back in.  Hopefully one of the admins will see it and sort it out.

(Although having said that, I received a notification for #106 despite apparently not being on the CC list any more.  Freaky things are afoot.)
(In reply to comment #107)
> Freaky things are afoot.)
You receive a notification if you vote for the bug, as well.

Hopefully the mods will fix this soon and then remove these off-topic comments. =)
Deanna: don't mess with the CC list! It's hardly ever ok to remove people from it. [adding people back...]
I would realy like the feature to choose per account where attachements will be saved. That would save a lot of search time!

An emphatic yes from me as well...
I agree.  Having attachments automatically put into a separate attachment folder is an important feature for me.
A most important option for me and all my clients is the ability to separate the application from Mailboxes and Data. That was I can setup sytems to view and receive mail from more than one workstation, but the data remains if the assigned location. I'm not sure what thread this belongs in. I didn't see a specific bug report for this issue
I agree 100% – this was the main reason for sticking to Eudora in our office, because Eudora made it possible to have the software installed on different computers of the network, allowing different people to access the same mailboxes and data on the server – with a protection Eudora offers to prevent simultaneous access whrough a eudora.lok file in the mailboxes main directory.
I suspect that the management would prefer that this discussion be moved to support forums, since it's both off topic and does nothing toward resolving the bug in question.

I'll just mention, I use SeaMonkey, not Thunderbird, but both SeaMonkey and Firefox let you put your profile anywhere you want, so I've got no reason to think that you can't do so in Thunderbird. We've got 200 people in my office using SeaMonkey, and their profiles (including their e-mail) are stored in network file space so that they can move to any computer and use their own profile when SeaMonkey starts.
(In reply to comment #0)
> Should Penelope have an option to strip attachments from messages upon receipt?
> Ideally, the user should be able to set the attachments folder on a
> mailbox-by-mailbox basis, as well as use Filters to extract attachments to a
> specific folder, or to the Trash, Recycle Bin, /dev/null, etc.
> 
> 
> If you would like to see this option in Penelope, please vote for this bug.

YES, this is definitly a MUST TO HAVE feature. That's really important for sales people, which are receiving tonns of datasheet, quotation, PDF... all day long.  
BUT, don't forget NOT TO STORE sent attachments in the mailboxes neither! 
The really nice thing with Eudora was attachment management : They are not store inside mailboxes, allowing IT Team to easily backup/restore/delete attachments, without modifying the mailboxes.

Regards,

Laurent.



I've got 4 IP security cameras that send email snapshots periodically. The file name from each camera is always the same so Eudoras Attachment feature to sequence files of same name with a number is an essential feature in this case. Because files are already detached it's easy to scan through them for quick viewing and transfer. This is a major feature of Eudora that should be maintained. Anybody suggesting embedding attachment files with mail message should stick with their existing mail client and not interfere with Eudoras existing features. Eudoras features need to be extended without losing Eudoras originality or identity such as addition of separate attachment folders with filter options. 
Consider having an attachements folder for each mailbox with the option to mirror critical fles to other folders say for project work. That way if message and attachment deleted in Eudora then file is backed up. Attachments folders could otherwise have an autozip file similar to compacting mailboxes
to backup all files in folders allowing file recovery feature.


Penelope should be able (user option) to strip attachments from emails and put them in a user specifiable directory.
Please add this option to Penelope This is the sole reason I don't migrate immediately to Thunderbird from Eudora 7.1. I get 10's of MB of attachments a day. This is the only way I can manage mailboxes in a sensible way.

Thank you for all your work!
Priority: P2 → P1
Assignee: sdorner → beckley
Status: ASSIGNED → NEW
Version: 0.1 → unspecified
Priority: P1 → P3
Status: NEW → ASSIGNED
I was delighted to see this bug go to P1, and then disappointed to see it dropped down (?) to P3. Matt - would you be willing to explain why you made this decision? Thanks in advance.
As I have said a number of times, as a long time Eudora user (from 1.0), the differentiating factor of Eudora has always been the ability to manage attachments. The "Outlook" approach, which Thunderbird seems to follow, is wrong-headed and dangerous, because it makes backups, first and foremost,  difficult and therefore inhrerently unreliable and insecure.


This is critical and a lovely feature of Eudora.
The <drive>:\Attach directory is a fantastic capability that cannot be lost.


(In reply to comment #116)
> (In reply to comment #0)
> > Should Penelope have an option to strip attachments from messages upon receipt?
> > Ideally, the user should be able to set the attachments folder on a
> > mailbox-by-mailbox basis, as well as use Filters to extract attachments to a
> > specific folder, or to the Trash, Recycle Bin, /dev/null, etc.
> > 
> > 
> > If you would like to see this option in Penelope, please vote for this bug.
> YES, this is definitly a MUST TO HAVE feature. That's really important for
> sales people, which are receiving tonns of datasheet, quotation, PDF... all day
> long.  
> BUT, don't forget NOT TO STORE sent attachments in the mailboxes neither! 
> The really nice thing with Eudora was attachment management : They are not
> store inside mailboxes, allowing IT Team to easily backup/restore/delete
> attachments, without modifying the mailboxes.
> Regards,
> Laurent.


While I am late with a response to this comment, I would very much prefer that no more processing overhead be added to the Eudora/Penelope engine in ordert o handle this issue.

I have dealt with this issue by using MS-Office File-Compare capability. Quick and easy.

But I do acknowledge and understand the issue.

(In reply to comment #11)
> One of the problems with stripping the attachments into separate files is what
> to do when two or more attachments have the same name? Eudora currently adds a
> number to the end of the file name part, eg, word.doc, word 1.doc, word 2.doc,
> etc.
> This is not ideal as it is actually impossible to know for sure which version
> belongs to any particular message, short of going to the message and opening
> the attachment from there. (This is even more of a problem when moving to a new
> machine and Eudora does not know which version is attached to any message.)
> In many cases, the mutiple attachments are actually exactly the same file. What
> would be nice would be to compare the new version with any existing version
> (checksum perhaps?), and if they are the same, make the link point to the
> existing file rather than creating a copy.


I dont think implementing this feature would add any additional overhead. If you think about it, it has to strip out the attachment anyhow in order for you to use the attachment. When you open the message and click to open the attachment, it's basically doing the same thing it would be doing if it stripped it out and saved the attachment to a folder automatically. In fact, not implementing this might actually add overhead as far as cpu cycles go. Because every time you opened the message and clicked to open the attachment, it would have to decode the attachment from the message. if it saved the attachment to a directory automatically, it would only do this once. 

I have to agree with many of the other people in that this feature was extremely nice with eudora. It was one of the things that made it stand above outlook. Because with this feature i was able to better manage my email. I could get rid of attachments i didn't need any more but still retain the message. And it meant the flat files that stored the messages were always of a manageable size. as soon as you retain attachments as part of the message, your data store is going to explode in size. 

I would REALLY REALLY like to see this feature kept. 
Stripping attachments into multiple folders is a critical feature for me.


As to only keeping one copy of identical attachments. How does this work when you do "delete message and attachments". Won't this break the attachment link in all the other messages? This seems to have too many side effects to be something to happen automatically. If the facility exists to re-associate attachments then you can manually tidy duplicate attachments. But, automatically sounds too risky to me.

(In reply to comment #11)
> One of the problems with stripping the attachments into separate files is 
> what to do when two or more attachments have the same name? Eudora currently 
> adds a number to the end of the file name part, eg, word.doc, word 1.doc, 
> word 2.doc, etc.
> 
> This is not ideal as it is actually impossible to know for sure which version
> belongs to any particular message, short of going to the message and opening
> the attachment from there. (This is even more of a problem when moving to a 
> new machine and Eudora does not know which version is attached to any 
> message.)
> 
> In many cases, the mutiple attachments are actually exactly the same file. 
> What would be nice would be to compare the new version with any existing 
> version (checksum perhaps?), and if they are the same, make the link point 
> to the existing file rather than creating a copy.


I agree with dennis...i'd rather have it rename the file. Or at least give me an option to have it rename the file rather then checking for duplicates. It never gave me a problem in the past when it renamed files. for me at least, it was easy enough to find the right attachment since it was never difficult to either find the message or just sort the attachments by date. 

and i'm not sure why moving to a new machine would cause problems unless you changed the folder names.
(In reply to comment #120)
> I was delighted to see this bug go to P1, and then disappointed to see it
> dropped down (?) to P3. Matt - would you be willing to explain why you made
> this decision? Thanks in advance.
> 

The Penelope team held a meeting and created a schedule of sorts. This option is slated for release 3, scheduled for late Q2 2008. P3 is just my way of indicating a Release 3 feature. It's priority will get bumped up as we get closer to working on that release.
(In reply to comment #126)
> I agree with dennis...i'd rather have it rename the file. Or at least give me
> an option to have it rename the file rather then checking for duplicates. It
> never gave me a problem in the past when it renamed files. for me at least, it
> was easy enough to find the right attachment since it was never difficult to
> either find the message or just sort the attachments by date. 

Not keeping around duplicates would be useful for all the .vcf files (and similar signature type things) that sometimes get attached to messages.  But that should probably be the exception rather than the rule, since it's no great loss if you lose a .vcf but if the reference count for a more important document goes out of whack and it gets deleted before it should then it's a significant problem.

The danger in stripping the attachments from messages is losing the link between the message and the attachment (this happens to me all the time in Eudora; even though I've asked it to delete the attachment with the message, quite often the attachment sticks around even after the message is deleted).  So hopefully Penelope will do a bit better there.

But I definitely prefer having plain-text mbox format message folders and separated attachments over a monolithic database file (a la Outlook).  My Thunderbird newsgroup database has gotten f***ed up *very* frequently (and there's no evident way to fix it short of "scorched earth"); my Eudora got itself messed up *once*, and it fixed itself automatically.
Good point about all those vcf files. I think the optimal solution would be to be able to create filters for attachments. So for example, create a filter that automatically deletes all attachments that end in .vcf, or maybe optionally checks for duplicates. I think having the option to check for dupes would be ok, but i wouldn't want it forced - sounds too risky.
For what it is worth, the current plan is to implement a series of filter
actions such as:

- Copy attachments to -> Some folder (Put a COPY of the attachment on your HD)

- Move attachments to -> Some folder (Remove the attachment from the message
and put it on the HD)

- Delete attachments from message (without saving it to your HD)


This way, the default can/will remain the same as it is now, but those people
who want the Classic Eudora behavior can create one or more filters. As part of
this we will likely add some additional filter options for matching, like "All
messages"


I think the advantage here is that you can choose the level of granularity you
want. You can have ALL attachments go to a single folder (like Classic Windows
Eudora), you can have separate attachment folders for each of your mailboxes
(based on the filter that moves to the messages to that mailbox), you can have
separate attachment folders for each sender that you filter, etc...

While it won't be exactly the same as Classic Eudora, it should provide
essentially the same experience, with some added flexibility.
Sounds even better then what we had with the original Eudora. Thanks for the explanation Matt!
(In reply to comment #130)
> For what it is worth, the current plan is to implement a series of filter
> actions such as:
[...]

Cool.  As it is that sounds pretty good; even better if you can affect individual attachments separately (eg. for a single message containing both a .vcf and a .doc, delete the .vcf and save the .doc out to a folder.  Or even save both of them to separate folders based on their extension).

Either way would be more flexible than the standard Eudora approach, which is a Good Thing.

And when linking moved attachments to messages, it'd be good if that can be done with relative paths (where possible) instead of absolute paths.  That will help with the "moved mail archive to a different computer" scenario.
I would have thought that Apple's Time Machine backup process is obviously best served by having mail attachments as regular files in a mail attachments folder, rather than bound up in some monolithic file alá Outlook. Why have some multi-hundred-megabyte archive re-backed up in it's entirety when it's increased in size by a few Kb? Similarly, why have some internal, proprietary, spaghetti-filenamed mailstore which wraps up the attachment when saving attachments to a folder helps everyone (including Mac users with Spotlight).


I regard being able to save attachments to a regular folder as essential. Why are we even debating this? The debate around Eudora "losing" attachments when moving things around is not a show-stopper. Yes, the process could be made smarter, but this feature is a must-have.


I like the dup check idea (comment #11). This would solve a few annoyances: people who embed files in their sigs, people who use "stationary", and people who reply/foward with duplicative attachments.

Like others here, Eudora's attachment handling is THE feature for me. But the filters Matt describes (comment #130) sound like a major improvement over the "classic" method. Huge potential there...

Also like the idea of relative paths for attachment links. In practice, it might obligate a user to store attachments under the account hierarchy, but for me, that disadvantage would be offset by the improved portability.
I like Eudora's attachment handling and I would not miss it. This is a major feature of Eudora that should be maintained.
Possible Solution to "same name problem"?

As Comment#92 (and some others) point out correctly, simply adding numbers to the separate attachment filename may not be perfect. Agreed. But it solves 99,9% of the "same name" cases. And most humans can deal very well with some attached digits in a name, so it has created little or no confusion in the past. 

The true problem seems to be tracking the file(s). While many comments suggest heuristic methods or implementing a sepearate tracking store, all these solutions make the process more comlicated than absolutely necessary. Can't we do this without any additional overhead? In a KISS kind of way?

The most logical point to store the path information in Eudora/Penelope would be the origin, i.e. the message itself. So why not simply adjust the link inside the message when a file gets another name/path because it was received twice or moved around (by Penelope)? The lack of correctly updated links was/is a long-standing bug/major annoyance in Eudora that surely would merit fixing.

Any reason why the message is a bad place to store this information? 

(Remember that Eudora has never been overly puristic about keeping real, real original file name info anyway.)

P.S.: This is different from the "same file problem". For me, Penelope does not need to deal with space savings by linking identical duplicates to one physical storage location. That could IMHO well be done by a separate tool, even an offline batch procedure. For examples how this is done with Outlook take a look at Legato Email Extender or with regular files at half a dozen other HSM(hierarchical storage management) solutions.

Eudora 8.0.0b3 and Mac Leopard - still can't set an attachments folder location as in previous Qualcomm Eudora versions.  This is a NECESSARY feature.
Blocks: eudora
Having used Eudora since about 1995, I also have e-mail and attachments dating back many years. That "madness" has also proved its value to me. I also considered switching to TB and decided not to for that reason among other. 

Thanks.
Arthur Naman


(In reply to comment #7)
> I would group the benefits of this feature as follows:
> a) Not counting spam, I have kept all the mail I received in the last decade (a
> madness that has proved its value on a number of occasions). Eudora's ability
> to keep attachments separate from mailboxes has been a crucial feature for my
> archiving as their size never became prohibitive.
> b) A useful side effect of this separation is that, as attached files are
> written on disk upon receipt, they are scanned by the resident antivirus
> software on the spot. This prevents the need of having AV intercept mail
> traffic to scan attached content.
> c) I've been taking this for granted for so long, that I only now noticed: It
> is so much better to have the attachments as files that can be evaluated and
> managed (deleted or archived) independently of the messages they were received
> with and of the mail client interface. Personally, I just open the attachments
> folder, sort them by date descending, and start deleting or moving to another
> folder.
> 
> One idea might be to have the user decide what size and which types of file
> (based on mime-types or filename suffix or ?) would be separated and which ones
> would remain encoded with the message. For example I would instruct the client
> to separated all word, powerpoint, excel, images, video and generally anything
> above 20K.
> 
> Thanks!
I have loved separated attachments for the many years I have used Eudora, for the many reasons given here. I can't imagine any value in not separating them.
Bill
Hello people.
It is 1 year, 8 months since I first looked at T-Bird as possible way to replace my Eudora mail program.  The only reason I don't switch from Eudora is the issue with embedded attachments in T-Bird versus the freedom to control attachments separately in Eudora.  All the many, many comments in this bug trail testify to the many reasons to have this capability.  Why has nothing been done?  Who is in charge of decisions?

I really don't care if T-bird exactly emulates Eudora in this functionality, or uses some other method which I can adapt to use; I just want something done other than talk -- which is all that has happened so far.
Waiting... waiting... waiting...
Roy
I very much like the attachment handling in Eudora but I think it would be an improvement to have greater configurability with reasonable defaults to ease the way for new users. Easing the migration path from one platform or computer to another would make the product a lot of friends.

Dave
I agree with comment #140.  I am still using the old Eudora 7 waiting for mozilla to add the attachment separation function to Eudora 8 (TB).  This issue has been pending for well over a year.  What is the result?  Has that function been added?  As evidenced by all the people who have requested it, it is an important function for many Eudora users.

Gary
It's not in Eudora 8 yet.  I'm planning to implement this in the next couple of months.
Nice to hear this. For me, it is a must together with bug 359311.
cool! great to hear this something that will be included. And also bug 359311 would be very nice to have included as well. The search function there is better then the search gmail gives me.
This feature is vital to Penelope & Thunderbird, as is it's corollary: the option to strip attachments from OUTGOING
This feature is vital to Penelope & Thunderbird, as is it's corollary: the option to strip attachments from OUTGOING or SENT messages as a default procedure.
When using encrypted mail, it appears that Thunderbird now saves messages in encrypted form.  It will be obvious to you, dear reader, that this interacts with the proposal to separate attachments. [0]

Probably some folks like this feature of Thunderbird.  I'm sure there are good arguments for it.

This feature is big trouble for many users. See below.

And I feel strongly it is an architectural error, conflating encryption on the wire with encryption at rest.  These are distinct functions and should be cleanly separated as a matter of principle. [1]

Context: 

All the users of encrypted mail I know also encrypt their local storage. [2]

When I save an attachment from an incoming message, Thunderbird correctly decrypts the attachment and saves the decrypted file; TrueCrypt then encrypts the file automagically. [3]

Here are the problems:

A. It appears that Thunderbird keeps the entire incoming message, attachments and all, in the wire encrypted form.  This uses a lot of space. [Minor problem (for those of us who swing a big disk)] [4]

B. If Thunderbird keeps the entire outgoing message, attachments and all, in the wire encrypted form, this also uses a lot of space. [4]

C. When Thunderbird saves a message (File SaveAs File) it saves the encrypted wire format.  This means that to save a message in the clear, it is necessary to copy the body, put it in a text file, and then reenter the headers in that file. [Not only an irritating problem, and subject to error in reentering the headers. Also, I feel, a design flaw] [5]

D. When forwarding an incoming encrypted message, the entire incoming message is sometimes attached as an encrypted attachment to the outgoing message, instead of being included in the body; of course, the recipient is then not able to read the forwarded message. [Extremely irritating problem.  Since it happens only occasionally, perhaps a bug. Or maybe a result of a bug in the way some other mail reader formats outgoing messages (I mention no names).]

E. >>> We come to the point of including this discussion here: If Thunderbird separates attachments, it will need to keep them in the clear.

F.  I'll add more problems, if any, as I experience them.  Bottom line: It is cleanest to separate encryption on the wire from encryption in storage.  (At least: to have the option to keep messages in the clear.)


Notes:

0.  I know I should add the discussion here as a separate item in Bugzilla.  I offer no excuses.  I will do that as soon as I get a round tuit.

1. This is not criticism of Thunderbird developers. But it is a strong opinion on future development. 

2. Not necessarily all local storage, but what needs to be encrypted. I set up a separate OS partition for my work and create a TrueCrypt partition on it.

3. Thunderbird may for a moment put a copy of the file in my Temporary directory in clear, but that can easily be fixed if Thunderbird allows specification of the temporary directory to use for each mail account. This is a real security hole.   I regularly (Ha!) trash my Temporary directory with Zilla Data Nuker. Not a trivial job, since there are always several open files which cause messages I have to deal with.

4. Of course, there are good arguments for keeping a full copy of every message.  So maybe this way is best.  I have both disk space and good reason to keep the entire message in Thunderbird (just in case there is a dispute where ability to prove a message would be useful).  On the other hand, it is sound architecture to separate the function of non repudiation from the function of encryption on the wire. Non repudiation requires only a signature.

(And,Eudora, as we know, allows editing messages.  I really miss that feature: I use it to change the subject line to help organize messages, and sometimes to make notes inside an incoming message. Different topic.)

5.  Just as there are no excuses: There is no blame.

P.S. I use Thunderbird only for the work that requires encryption on the wire and at rest. (The group has standardized on Thunderbird: we'd rather all have the same problems, than deal with mail reader interoperability problems.)

For other work, I can't give up Eudora's excellent search feature and other features that Thunderbird lacks.  I hope to move to Eudora8|Penelope, if it has all the Eudora features I use regularly.
Comment 44: The Penelope default should be to handle mail msg/attachment structures *exactly* like Eudora. -k

Yes.  Wherever possible.  

The Penelope default should be to   *everything*   exactly like Eudora. 

Except, of course, when Eudora does not handle everything exactly like Eudora (e.g., file ID vs. path name).
Glad to see this one at the top of the list, having to detach each attachment before using it is a pain -- far easier in Eudora 7 to just grab the file out of the Attachments folder. Using a filter to do it as in comment 130 is even better (more flexible).

As a minor comment, I'd like to see filename collision handled by suffixing digits, but with punctuation (unlike Eudora 7). For example, three attachments of the same name might produce the files:

file.ext
file(2).ext
file(3).ext

Could be a hyphen rather than parenthesis if that's more compatible with other filesystems. The point is that many attachments arrive with digits in their file names; suffixing bare digits is often confusing.
Well, I checked again; in 2008-11-12 Jeff Beckley said in comment #143
> It's not in Eudora 8 yet.  I'm planning to implement this in the next couple of
> months.

This request started in 2006; there have been many votes to do it and strong comments; I'm still using old Eudora, waiting for this change.

Also, I do NOT agree this bug depends on 9309; 9309 is only one way to do it. ANY way that does it is at least a start. I think the 9309 is a trap to kill this bug, since 9309 is not assigned.

Also, I noticed my account keeps getting deleted when I check back after 6 months to [again] find no progress... what's the matter, someone can't hantle criticism?

Roy
I insist on this feature. I explained it here that this blocks me from leaving old Eudora 7.1 together with bug 359311.
However I have problems with multi byte characters and various encoding, I like separated attachments and fast search.

Dusan
I agree with Dusan :
This feature is for me one of the main reason why I still use Eudora (with the Index Search of course, and the fact that sent attachments are not stored in the mailer), and I believe this is one of the features that makes Eudora so good compare to other mailers)... Hope this feature will be soon implemented, so I can get rid of my "UTF8->ISO" plugin and other encoding issues present in my good old Eudora 7 !

Laurent
I COMPLETELY agree with Laurent about detachment of attachments and Index Search
Just to add a twist to this one, I'm a Eudora veteran who switched early despite this issue.  Now that I've been using Penelope for over 18 months, I have 5 GB of mail files with attachments embedded.  Whenever this feature gets implemented, it would be very helpful to have a utility (or "mode" in Eudora) that strips out attachments from *existing* mail files using the same logic as Penelope would use with new file additions.
 The lack of old Eudora-type attachment handling has kept me from making the switch to Thunderbird/Penelope.
 Without automatic attachment handling, I'll have 50 or more users pulling their inboxes, packed with large attachments, off the file server and over the LAN, killing my bandwidth.  I'm not likely to either change their habits or prevent them from complaining when everything slows down.
 Without it, I won't be able to test, kill, prune or classify attachments as easily as I do now with the old Eudora, or at the same level of paranoia.
 On the user side, Thunderbird/Penelope has tremendous benefits.  They would probably be willing to go along with a relatively painless transition.  But, I need to be able to maintain the infrastructure.
Due to the attachments issue, I am still using the classic Eudora for all good reasons that have been previously reported.

I have seen that new the Eudora OSE has the capability to manually permanently detach message attachments.
Please see: https://wiki.mozilla.org/Message_Attachments

I can imagine that the same feature can be automatize to permanently detach all incoming message attachments and a new option can be set on the preference to give the users the capability to chose if they want or not this features.

There is a reason way this is not possible?

I want to remember that this capability blocks many users to switch to the new Eudora OSE

Thanks for an answer.
This is a notice to all who care about this bug:  please make sure to vote for bug 9309, as this one depends on that one being fixed.

NOTE THAT IT WAS REPORTED 11 YEARS AGO!!

That bug is "p3" and has no owner.  Are they serious about this Eudora feature, or aren't they?  

Unbelievable.
My ISP buffers all email through Gmail and then simple settings put those emails into Eudora. I can tell you how superior Eudora is to Gmail. The fact that attachments are downloaded into a separate folder (if you choose) relieves our back up. I would never want to have to depend on an inferior product like Gmail - I say this after a year's experience with both. The ability to make folders is a far more powerful tool than Google's labels.
I am still here, and still waiting, hoping, someday this will be done. And I still use Eudora as my primary email because of this situation.
(In reply to comment #159)
> My ISP buffers all email through Gmail and then simple settings put those

I should add: I am using Eudora 7.1.0.9 which I now understand is a pre-open-source version.  I did not know an open source version was around.  Thanks for the tip.
David Taber suggested that I mention here that TB 3.1 (and any code that relies on the same backend) now has a new backend function available that will silently strip attachments from emails, as requested in this bug. The only existing UI that uses this feature however is my FiltaQuilla addon, though that new code is not specifically designed for that addon. So within TB 3.1 it is now possible, in conjunction with FiltaQuilla, to implement the requested functionality of this bug using a message filter.

That of course does not fix this bug, but does show that the issue is now implementing this in the user interface (which is application specific) rather than in the messaging backend.
The last version of Eudora that I tried was 8.0 Beta 9.

Disassociating the attachments from the email was real hassle, so I returned to Eudora 7.1.0.9 that I paid for years ago.

The only thing keeping me from using the latest version of Eudora is the attachment hassle.

I receive in excess of 150 documents a month that need to be placed in specific folders, depending upon content and client, and without them automatically being detached and put in something like the Eudora Attachments folder where I can easily find and move them to their proper folder, any email program is not worth a damn.

Just my 2cents worth.
I'd have to agree with Charley Randall.  Attachments should not be stripped and placed into a general "Attachments" folder; each mailbox should have its own folder for attachments, and when messages are moved between mail stores (aka: mailboxes, or folders) the attachments should also then move between the respective attachment directories.  This allows for selective deletion, archiving, and searching of the massive number of attachments I get each day.
I'm agree with Charley Randall and John Todd. Up to now i'm using Eudora 7.1.0.9 I'll move to the new version when will be possible to place it into a container where each mailbox must have its on folder.
(In reply to comment #35)
> The original point was to have attachments stripped from emails UPON RECEIPT
> (like Eudora does and did for decades :-). That's fundamentally different from
> how most other mailers, including Thunderbird, handle attachments, where the
> attachment remains with the message in the mail store and is only extracted
> when the user explicitly requests it. In Eudora, all attachments are
> immediately extracted into the "Attachments Folder". This keeps the mail store
> smaller, so that's why many people (including me) would like to see that basic
> behaviour in Penelope.

I will second this.  Generally, if I need an attachment, I will move it out of cE's Attachment folder to an appropriate folder.  At work, this will usually be a project folder.  At home, its a bit more complex, but in general, pictures go to the Pictures folder, finacial stuff goes to the Finances folder, bike stuff would go to the Bikes folder , , , etc.  When I go to back-up my e-mail, I generally look thru cE's embedded & attachment folders for items I've missed, move them where they should be, and delet the rest.  My e-mail storage requirements are greatly reduced & things are easier to find.

In my opinion, e-mail seems to be best at keeping track of textual based information.

Here at work, I am currently keeping cE and Eudora OSE both up to date.  cE's backup was 15MB {zipped}, Eudora's OSE's backup was 146MB {zipped}.  Difference is cE's backup does not include attachments or the embedded images.
For those who haven't been tracking the conversation in related bug #9309, this issue is more or less SOLVED if you wait for the next Eudora release (or maybe a bit longer).

T'Bird 3.1 has underlying infrastructure to support the behavior you want, and the FiltaQuilla plug-in lets you set up a set of document-detaching filters that can automatically send documents into various folders.  

The original mail will look like it has an attachment, but the icon is just a symbolic link to the document that's stored in the folder of your choosing (seems that there can be an arbitrary number of folders to which filter rules can direct attachments).

It's possible that the Eudora team is working on something else, but this feature is "already here" if you're willing to run on T'Bird 3.1 rather than the current Eudora.
Penelope didn't see any activity in the vcs for the last 8 years, closing.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.