User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Build Identifier: Thunderbird 0.7 - 0.8 It is sometimes desired to edit saved message, whether they were originally composed on the client or arrived from outside sources. Currently the only way is to "Edit As New", save to Drafts, move the new copy from Drafts to the original folder and finally delete the original message. Why is real editing fnctionality very much needed? * To change incorrect charset, so the message subject will be displayed correctly and the content will be previewed correctly. * To make correction in sent messages, in case they need to be re-sent in the future (and by then I'll forget that I have to fix something). * To add comment for future reference. * Etc. Reproducible: Always Steps to Reproduce: 1. Pick any message in Inbox. 2. Try to edit the message - no way. 3. Forced to "Edit As New" which creates a second message. 4. Save the new message - it goes to Drafts. 5. Need to move the message back to original folder. 6. Need to delete the original message. Expected Results: Allow "in place" editing of the original message. The current behavior is unfriendly and counter-productive from user perspective. Some other mail clients (eg. Outlook) let the user open almost any message for editing, and the message is saved back to the original copy. Very useful and for some of us unlucky people who need to use exotic locales (eg. Hebrew) - essential. This is different from my other report which presents the same need but restricts it to Unsent Messages (which I suppose is less controversial).

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

only for unsent messages: Bug 254738

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

Any possibility of getting that for 1.0? It would be *MUCH* user friendlier, and I guess 1.0 should have this!

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

Easy workaround when simple modification : (1) Create a folder(say "Work") (2) Move a mail to "Work" folder (If other mails exist, delete them and compact-folder for easy operation) (3) Edit file of "Work" under Mail directry by text editor, then save the file. - ".msf" file is locked but non-msf file is not locked. - You can change or delete any data in mail source. If you know mutipart/mixed mail format well, you can easily delete it. (4) Click other folder, then click "Work" folder - Due to timestamp mismatch between "Work" file and "Work.msf" file, .msf file is re-created and modified mail could be accessed. (This maybe is applicable to latest version only, because some modification) ( around .msf re-creations were done this year, as far as I remember. ) (Restriction) - It is difficult if subject is encoded, but chage to ASCII-only is easy. - It is difficult if text data is encoded(such as base64, quoted printable)

(In reply to comment #6) This is by no means an easy workaround. Measure the time it takes and compare it to the steps required in eg. Outlook: 1. Open message (double click or Enter when message is highlighted). 2. Choose Edit / Edit Message (Alt-E, E). And with your workaround it is only possible to modify text. Anything beyond that is too complicated (change encoding) or nearly impossible (add/delete attachments).

(In reply to comment #7) Eyal Zvi, I don't deny nor interrogate your enhancement request. I also think it is very convinient if this enhancement will be implemented. Above workaround is for user's who are in trouble to arrange mails by adding small memo to mail due to lack of this function. - By adding a short comment in subject - By adding a short comment in mail body of plain text mail For subject, adding short comment is easy even for encoded Subject: header. > Subject: ...Encoded-Subject-Line-1... > ...Encoded-Subject-Line-2... > ...Encoded-Subject-Line-N... can be changed to > Subject: <ASCII only short comment> > ...Encoded-Subject-Line-1... > ...Encoded-Subject-Line-2... > ...Encoded-Subject-Line-N... This is usually sufficient for arranging puropose. See Bug 2920 for enhancement request of attachment deletion, which is one of the most oldest and lo---nglived bug.

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

This is a feature that has wide-spread acceptance by users of Outlook and other clients. I too would like to see an edit option added for any received or pending email.

I would also like to see this feature. Very powerful in Outlook. Great for - * creating follow up notes even in messages sent by others * delete huge attachments without deleting the message * converting HTML into plan text messages for saving space (important for IMAP)

totally agree. I really miss this as old outlook user.. especially editing 'send later' emails!

I would like this feature very much. It is one of the few important ones available in M$ Outlook and Eudora which Thunderbird does not have.

just to be clear, i would like this as well, but only if it is a separate "edit old command in place" command that allows "edit message as new" to remain in place.

This is a really big problem for me. I get lots of email, including mailing lists. Subjects of discussions are always drifting away from the actual subject lines. I need to change the subject line of I'll never find the saved message. Also, it's really helpful to trim quoting to just save the part of a message that I'm interested in. There was a suggestion to move a message to the drafts and then edit it. This is no good, since it changes the date of the message.

I can only agree that this would be a core function for my daily work with Thunderbird. It might even be an idea to have an option to record the original version of the message as an attachment of the edited message?

This is NOT a duplicate of core bug 40694. Core bug 40694 only addresses this defect for Unsent messages. This bug (254739) addresses the fact that the user cannot edit a received message. The folder containing the message should be irrellevent. Such functionality allows the user to add notes and comments, yet leave those notes in the context of the received e-mail message. It also allows the user to delete unneeded or unwanted text from messages (like ads in newsletters).

Ideally, adding comments should be possible without changing the original email; the comments should be "metadata". This way: - The original message can be forwarded, quoted in replies, etc. without reflecting any changes made in comments. - The search dialog should allow searching in comments (as a separate field). - In particular, comments can be used for tagging with search keywords.

(In reply to comment #18) > Ideally, adding comments should be possible without changing the original > email; the comments should be "metadata". This way: > I disagree. I suppose there could be an option to do what you are asking, but it should be a choice. I lot of what I want to do when I edit saved email and Usenet messages is remove lot of extra quoted text. I don't want to have this all saved. David

(In reply to comment #19) > I disagree. I suppose there could be an option to do what you are asking, but > it should be a choice. I lot of what I want to do when I edit saved email and > Usenet messages is remove lot of extra quoted text. I don't want to have this > all saved. David, I suppose this is the difference between "edit" and "add comments"... - Tal

(In reply to comment #20) > > David, > > I suppose this is the difference between "edit" and "add comments"... > > - Tal > I suppose the real bottomline is that you should be able to change every part of an email that is sent to you, whether you add something or remove it. I can't believe that it is taking this long to get this "old" feature of Outlook, installed into Thunderbird. Having used Outlook in a past life, I can only tell you that once you have used this feature, it's damned near impossible to live without it and it is very perturbing that it's not been there from the start of Thunderbird. I love Thunderbird, but I'm embarrassed to admit to Outlook users that this feature isn't available yet.

(In reply to comment #21) > (In reply to comment #20) > > > > > David, > > > > I suppose this is the difference between "edit" and "add comments"... > > > > - Tal > > > I suppose the real bottomline is that you should be able to change every part > of an email that is sent to you, whether you add something or remove it. I'm personally not convinced this would be used or needed by tons of people. Some examples cited (removing attachments) are already delivered. Subjects can be changed with extension Thunderbird Header Tools https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&id=875 Note: I wouldn't count on this enh being delivered based on the fact that the bug is not UNCOnfirmed - the bug was submitted by the reporter as NEW, so it was never confirmed by a developer bug or triager. It hasn't even moved from component=general to some place where it might be more thoughtfully considered.

(In reply to comment #22) > > I'm personally not convinced this would be used or needed by tons of people. > Some examples cited (removing attachments) are already delivered. Subjects can > be changed with extension Thunderbird Header Tools > https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&id=875 > > Note: I wouldn't count on this enh being delivered based on the fact that the > bug is not UNCOnfirmed - the bug was submitted by the reporter as NEW, so it > was never confirmed by a developer bug or triager. It hasn't even moved from > component=general to some place where it might be more thoughtfully considered. > I guess the biggest problem here is that we are NOT dealing with a BUG, we are dealing with a "missing" feature. If you don't see the value of this simple feature, then I would have to guess that you have never had the need for it or you have never used Outlook to any extent. What is great about it, is that you don't have to mess around with extentions or workarounds. It's just simply there and you treat the message as though you own it. I used it extensively when I was working in an engineering department, where oft times you would get a lot of unnecessary garbage along with a tidbit of important data that you wanted to save. The advantage of this is many fold, but one very definite advantage is that you don't end up having Gigs of messages saved on your system or the server. How can I take this to a higher level, where it will get some attention, good or bad? Allen

(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) > > > > > > > > David, > > > > > > I suppose this is the difference between "edit" and "add comments"... > > > > > > - Tal > > > > > I suppose the real bottomline is that you should be able to change every part > > of an email that is sent to you, whether you add something or remove it. > > I'm personally not convinced this would be used or needed by tons of people. > Some examples cited (removing attachments) are already delivered. Subjects can > be changed with extension Thunderbird Header Tools > https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&id=875 I agree that the header tools extension does more than half of what I need. However, it doesn't do the other half (getting rid of tons of extraneous quoted text) and it doesn't work on many messages (don't know why). I also agree that this enhancement wouldn't be used by "tons of people." So? Most people don't even save many messages. Most people don't use most of the features. Probably 90% don't know the difference between text and html messages (unfortunately). It will be used by many "power users" who get tons of email and have to track many message threads. I hope Thunderbird is supposed to support more than just computer novices. David

This is getting just a wee bit pathetic. Maybe it's just because I am a writer and researcher, but I have missed this feature daily since I switched to Tbird. I thought open source was supposed to be better than this... -- toma

I agree, this seems to be such a trivial feature that a mail client should have. I store many thousands of email messages in Thunderbird, I rarely delete anything except for the rare spam message I get, but I only usually get about one of those a month. It would be so convient to be able to edit any message, not only to save space (messages don't take much space) but just to make finding old messages easier, removing the junk that sometimes ends up in them such as forward tags, reply quotes, ads from all the free web email apps that add thier ads to the bottom of all messages. Endless junk in newsletters when you only need to keep a section of it, not to mention just making it easier to add a note to the message (I know there are extensions for this, but none are great, and many of them will lose the notes eventually). I use Thunderbird as my primary means to store information so it is all in one place, searchable and wont get lost. It would be nice to be able to edit this information at anytime. I could go on and on of how this simple feature would be so useful, I've often been tempted to switch to some other mail app, I switched to Thunderbird from Outlook long ago. The stability of Thunderbird is what has kept me here.

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

Hi all. There is now a great workaround for this missing feature. I had been using the Header Tools extension in TB 1/1.5, which allowed editing the Subject and other header fields. I just moved to TB 2 beta and found the extension wasn't compatible. When I got the updated version, I found it had the additional feature "Edit Full Source." Of course, you can mess yourself up editing messages that aren't just plain text, but I'm very happy with this. It's version 0.6.6 at http://www.supportware.net/mozilla/HeaderTools.xpi. The discussion of it is at http://forums.mozillazine.org/viewtopic.php?t=279907 David

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

The main reason I would find this useful is for changing the Subject header. I have friends and co-workers who often use an empty subject for their messages. I want to be able to change the subject to make that message easy to find later.

I just installed TB2 and I have to say that I was quite disappointed that this feature request, which is pretty long standing, had been ignored. I am working on a new book (non-fiction) and it would have really helped me (lots of info in email folders) a lot. Also, the note about how the Header Tools extension is a good workaround for this is utter bollocks. -- toma

This is getting ridiculous! This bug/feature request is now over 3 years old. I don't see a single comment from Scott or any other TB developer. I've tried emailing Scott a couple of times and got no response. What's the point of having this fancy bug-tracking system if the developers just ignore it? Scott - please post something here to tell us the status of this. If you're never going to implement this then have the courtesy to tell us that so we don't wait around for years hoping it will be in the next version of TB. David

David R: there are a lot of enhancement requests, and everyone have their own favorites. Not saying it won't ever get fixed, patches are certainly welcome;)

Magnus M: You're right, there are probably a lot of enhancement requests, but I disagree with you on the urgency of this one. This is not so much an enhancement request as it is a necessity that should have been in the 1st version of Thunderbird. It has been available in M$ Outlook for at least 10 years!! It's taking far too long to get it into TB and someone needs to address it soon. I find it unbelievable that it isn't there by now. On the other hand, I've seen enhancements that I doubt most people think were as important as this, already inserted into the code. David R. is right, we need someone to at least post something here to tell us the status or if it will ever be addressed. If it is not going to be addressed, those of us who have need for it will then be able to switch to a different email client that will serve us better. As David said....ridiculous!

Great - we ask for someone to do something or tell us something, and instead the bug has just been reassigned: from Scott to nobody!!! Who When What Removed Added mkmelin+mozilla@iki.fi 2007-09-02 03:53:50 PDT AssignedTo mscott@mozilla.org nobody@mozilla.org I hope this is just a temporary transition, but it's looking like dealing with mozilla.org is about as effective as talking to Microsoft.

That was just meant to reflect reality and make it clear to everyone that they are free to work on it. Including the penelope team that seems to want this too in bug 360975 - so yes, I think it's likely this will get fixed by someone eventually. It was assigned to Scott by default only, if he's currently working on this, he will assign the bug to himself, and he's getting the bugzilla mails anyways.

Magnus M: You're right, there are probably a lot of enhancement requests, but I disagree with you on the urgency of this one. This is not so much an enhancement request as it is a necessity that should have been in the 1st version of Thunderbird. It has been available in M$ Outlook for at least 10 years!! It's taking far too long to get it into TB and someone needs to address it soon. I find it unbelievable that it isn't there by now. On the other hand, I've seen enhancements that I doubt most people think were as important as this, already inserted into the code. David R. is right, we need someone to at least post something here to tell us the status or if it will ever be addressed. If it is not going to be addressed, those of us who have need for it will then be able to switch to a different email client that will serve us better. As David said....ridiculous!

I think the tone of some of the (recent) posts is not very appropriate. After all Thunderbird is free and open source and there is nobody who _has to_ do something. Perhaps some people are employed somewhere and assigned to Thunderbird officially, but I can imagine that others just do it because they like it. And unless they are very strange, I would not imagine them happy to be talked to like this. Otherwise I agree that there is not very good visibility what the overall priorities of the project are. And I think what is long overdue is a simple sponsoring scheme, may be part of Bugzilla. If all frustrated users would donate (shedding this way some blood on the open source battlefield, instead of just complaining) - this would make some features appear much faster.

(In reply to comment #37) > If it is not going to be > addressed, those of us who have need for it will then be able to switch to a > different email client that will serve us better. . . > Would there another equally-secure free or low-cost E-mail program we could use? While the sponsored version of Eudora allows editing of received messages, it will not compose messages with tables.

This gets my vote, and I'll add "Lotus Notes" as another mail client that does it. The ability to edit emails has been around since Notes first had email (Notes 2 or even Notes 1) and it's now Notes 8.0. In Notes, everything is a document, and every document can be edited (unless you set your access permissions otherwise). One concern: Is edit supported by IMAP, or would it just be an offline facility? I'd want my edits synchronised back to my IMAP server

Several more use cases that require this functionality: 1. Annotating email. This can be used to summarize the content of a message or to include follow up notes. 2. Support email as a PIM. Although not the expressed use of email, many people in fact use email as part of a task management workflow. Being able to edit an information item as it circumstances evolve in real life would greatly increase this type of use. It should be noted that an ideal implementation of this would include IMAP persistence.

I'd like to get some perspective from david bienvenu in particular as to the difficulty of doing this. In particular, being able to use the implied capability to do "notes" with a different UI but the same backend, would seem like an easy win (assuming the backend work isn't too hard).

I think the "notes" and general annotations use-cases can be best addressed by the global database. Meta-data is what the global database is (going to be) all about. Also thinking of the global database, it would be nice if any solution to this specific enhancement somehow kept the original message around. For example, make the message multi-part and include the original, but display only the new user-modified part. At the very least, a header should be added that indicates that the message has been modified (with their being some value in distinguishing between a message edited by the original author). The intent of such a header to allow automated analysis by the global database and extensions to know what they are dealing with. Also, it allows a nice "you modified this" flag to be associated with the message, so people don't get confused when revisiting a message they modified.

"it would be nice if any solution to this specific enhancement somehow kept the original message around. For example, make the message multi-part and include the original, but display only the new user-modified part. At the very least, a header should be added that indicates that the message has been modified" I think this is probably the safest direction. In the old days, I would have been against this since I wanted to remove extraneous text to save disk space. Except in extreme cases, I don't think this is an issue now. Would this allow changes in headers, though? One of the most common things I do now, using TB Header Tools, is change/add the Subject field, since this often is wrong when people reply to emails and change the message subject but not the Subject field.

davida, I'm not sure what "this" is exactly. Conceptually, allowing the user to edit messages is similar to what we already do for detach/delete of attachments, combined with edit message as new/edit draft. We can load the existing message into an editor, like we do for edit message as new/edit draft, and let the user edit the message, and then replace the existing message with what's in the editor, like we do when we detach/delete attachments. But the devil's in the details :-) Especially making sure we don't lose information when bringing the message into the editor. For annotations, storing out of band information and then applying it to a message when the message is displayed, we could remember enough information to know how to modify the dom once the message is displayed, or, shudder, we could change libmime so that it knew how to insert the annotations when generating the html for the message. libmime is not fun to change, but it can be done.

As the person who submitted this bug about 4 years ago, I have to say that it is a relief to finally getting some attention. I bought MS Office 2007 (I need Word) and have been *sorely* tempted to cut over to Outlook because I need this so bad. I have been resisting, but I was running out of strength. Any idea when I will see an release of Tbird that supports editing of email? -- toma PS: In case anyone is wondering why I need this. I am a writer. I am working on a new book of climate change. I'm against it. Anyway, there is a lot of mail in the climate business. I like to annotate and bolden the bits that I keep. It's not asking too much.

Tom, Please look at the bug header - *I* am the one who submitted the bug... It's not that important, as we both want the same thing. Eyal.

David(s), Andrew, You seem to support the notion of "protecting" the user by backing up the original text. I think this is a bit redundant and should be an option (off by default) and is anyway a separate requirement. Right now users can easily delete messages, and no one is suggesting that deleted emails should be kept hidden somewhere, just in case the user wants to know "how things were originally". Editing a message is just a variation on the theme - in essence it's just an easier way to "Edit as new" and then "Delete the original". Moreover, in many cases editing an existing message is needed in order to remove information that the user doesn't want to keep - for example big signatures, inappropriate words, confidential information, etc. For example I wouldn't want to edit a message, and then a few days later forward it to someone, forgetting that some sensitive information is still contained in it! That said, an option to keep the original may be useful in some cases, but only as an option only - and I think it should be handled as a separate issue. Thanks for the attention to this. Eyal.

I completely agree with Eyal. I would like to emphasize that what he describes is the primary use case and it does not require the functionality of optionally keeping the original content. Therefore, to expedite implementation of the primary use case, I vote to focus on implementing only the functionality entailed by the primary use case and not including the unnecessary functionality of optionally keeping the original. At least not until the primary use case is delivered.

Completely agree with Eyal and Mike. The basic idea seems to edit (i.e change) the original, not to keep it as it is. Besides there are already perfectly valid options of preserving the original of a message: [archive-it|don't-touch-it|print-it]

Andrews idea of a header entry, indicating that a given message was modified, seems valuable to me (e.g. for filtering, searching or just the record...) Just as a side note: I personally never have used the "edit-as-new" function, but would find it interesting to hear from someone actually using it, what purposes it can serve.

Joerg, Check the initial report (ie. first message) to see some examples why editing is needed. "Edit as new" is not the same thing, it's intended (as I see it) to re-send a copy of a message. Eyal.

Eyal, my side-note in comment #53 really targeted the "edit-as-new" function only (I rather use "forwarding" for such cases). Just to make it clear: I agree with the necessity of your feature request, as also stated in my previous comment (#52) above. Cheers. Jörg

As a header change to indicate that a message has been edited, I suggest using a new header line "last-modified" or something like this, which indicates the time/date when the message was last edited. That way, the header not only indicates *that* the message was edited, but also *when*.

Eudora has allowed editing of received messages for at least 10 years. M$ Outlook has accommodated it for at least 8 years. I would like to understand why there has been any delay at all in incorporating this very useful feature into Thunderbird. Eudora is no longer being updated, and the last time I checked, its migration to Mozilla via Penelope did not allow editing of received messages. I would not use the last version of Eudora, because its rich-text format does not support tables. Some people, myself included, may just give up waiting, and switch from Thunderbird to Outlook.

Hi, I would like to strongly support this enhancemant. I'am used to use Lotus-Notes at work. And we extensively use that feature within LoNo. You just d-click the mail and comments, hints, etc. can be written directly into a mail. There is even a special "comment-pen" available. And I do miss this option in TB desperately. I'am an author, too. I rec a lot of news-mails from google-alert besides other ones every day. And in order to comment them immediately, an edit-option would be fantastic. All workarounds I tried so far, are rather complicate. Cut and paste into different text file leads to loss of hyperlinks. Exporting to html is time consuming due to amount of messages. And, of course, using Firefox, I have no option to edit the html source code directly (like in the IE), which is not easy anyway. OK, to cut a long story short: if I had the programming skills to develop the feature needed, I would have done it the day before yesterday. Regards Rudy

Retriaging according to new policy for flags. https://wiki.mozilla.org/Thunderbird:Release_Driving (bugs marked wanted- don't indicate we wouldn't accept patches, but that they're not going to be the focus for release drivers)

David A, or someone else - can you comment about the status of this being implemented in TB3? Now that it's gone Beta (great work!), I would assume (possibly incorrectly) that you know what features will be in the final version. Thanks, David

Unfortunately the Header Tools extension mentioned in comment 22 does not work with Thunderbird 3, so we've lost our work around.

When does TB3 come out? I ask because I have decided to switch to Outlook if this feature is not properly supported. And I will also say that, in part, this decision would be a vote against the decision making process that decided not to support it. -- toma

There's no decision "making process that decided not to support it". Simply lack of time/resources, and other bugs with higher priority. You're welcome to provide a patch!

(In reply to comment #61) > Unfortunately the Header Tools extension mentioned in comment 22 does not work > with Thunderbird 3, so we've lost our work around. Any update on implementing this feature and/or Header Tools being updated. Without this, there's no way I can switch to TB3.

Not good: TB3 doesn't have this, or appear to have any plan to have it. In addition, Header Tools doesn't appear to work with TB3 and the developer seems to have abandoned it, so now there's not even a work-around!

Regarding use cases comment #43 , asuth suggests that they should be implemented through gloda (comment #45). I don't like this idea for the following reasons: As I understand it gloda is handled and stored locally. As such information stored in gloda can only be accessed on the local computer. I my opinion all information should be stored server side (on IMAP server) and not locally. This is the only way to make information available from multiple mail profiles or computers.

Currently I also use the following workaround to edit messages: - Move message to Drafts folder. - Edit message button appears, click it. - Edit message, when finished click "save" - Move message back to original folder. Drawback: Saving message does change the date. "Editing" messages works already regarding attachments. Attachments can be removed while the timestamp of the mail stays intact. "Editing" messages also works as described above. What we need is - the edit button on every message, configurable, for experts :-) - allow for saving edited messages while keeping mail headers intact - adding header to indicate that editing has taken place.

I sympathize with the developers that there is not enough time/resources to implement this feature. I do not intend to start a flame war, however last year I switched to Postbox, a partially-open-source derivative of Thunderbird (covered source here: http://postbox-inc.com/coveredcode ). It's $40 but if you can deal with the philosophical issue of paying for partially-closed-source software, you get a cross-platform license to a highly-usable implementation of message editing (among other things). Practically speaking, it has been 6 years since this issue has been reported, and it may require as many more to get this functionality. My calculation of the value of this for the cost over 12 years is high. Drawback is that you manually have to hack extension packages to get them to work for Postbox, since most extension developers don't include support for it.

> Bug summary: Allow edit any message (Note: real edit, not "edit as new") To Eyal Zvi(bug opener) and all requestors of RFE stated in bug summary: Are you really requesting alteration of original mail data saved in local mail folder or IMAP mail folder by mailer according to user's request? You all are requesting feature to add meta data like "memo of Post it!", "comment by you on mail", to make your daily mail data management easy and comfortable, aren't you? If such kind of feature request, there are some possible solutions. (a) Add X-Mozilla-Comment: header. It's similar to current X-Mozilla-Keys: header for Tb's Tag. If thread pane column for this header is added, it can be shown at thread pane. Note: for example, Mail header handling by addon(e.g. Message-Id: by duplicated mail remover), Thread column addtion(GlodaQuilla), Data input by user for addon(many many addons support it). Tb Header Tools Extension looks this kind of addon(extention), https://addons.mozilla.org/en-US/thunderbird/addon/875/ although the extention is for Tb 1 only. (b) Meta data support for mail. Saved in .msf, or extended mail header. If mail with the meta data is shown, original mail is shown at message pane as if message/rfc822 part of multipart/mixed mail with text/plain part of the meta data. If this kind of request, I think implementation by addon developers is possible, because no alteration of original mail data(alteration==corruption of mail if mail is digital signed mail) is involved in request. Or you all need to see/use added comment data or added meta data by other mail cilents? Note: Alteration of original mail data was already done by Tb - Detatch/Delete of attachment. So, "Alteration of original mail data" can't be a reason for WONTFIX of this bug.

I understand this bug as follows: "TB should allow user to alter original mail data stored on IMAP mail folder." User stories rationale: - Changing meaningless subjects to meaningful ones e.g. changing subject "FYI" to "meeting minutes HeliumCar project cw 21" - Adding comments or notes to the mail body e.g. describe action that has been taken in real world (beyond domain of mail conversation) I am happy to file separate RFE for each user story. I don't understand this bug as to request adding meta-data like "memo of Post it!" etc.. This can already be done using tags (see bug #432710)

This is a joke. As one of the original supporters of this bug, I can tell you that it has NOTHING to do with IMAP, which would not help me because I do not use it. Nor does a hack that just allows you to change PART of the mail -- but not to make arbitrary edits -- help. It is nothing more or less than a request to be able to EDIT AN EMAIL in place. -- toma

Toma, although you might use POP and therefore think this feature request (which was actually reported by Eyal Zvi) has nothing to do with IMAP, an analysis of the feature indicates that it does involve IMAP. Thunderbird is a client for both POP and IMAP. I believe the consensus is that providing such a feature for POP accounts only would create an awful user experience.

I didn't claim the I had filed this bug, only that I was one of its original supporters. WRT to your claim that there is a consensus that providing this only for POP would be awful, UE wise, I beg to disagree. True, it would make Tbird work differently in the two cases, but it already does that. Also, neither a POP user nor an IMAP user would notice the difference, as they would not see any incongruity with the other mode, which they never use. Thus, I see no problem at all. Which, by the way, makes it not a consensus, by definition!

(In reply to comment #70) > User stories rationale: > - Changing meaningless subjects to meaningful ones > e.g. changing subject "FYI" to "meeting minutes HeliumCar project cw 21" > - Adding comments or notes to the mail body > e.g. describe action that has been taken in real world (beyond domain of mail > conversation) I understand your use case(and probably bug opener's). You want to alter mail data itself for your convenience, because mail data you received and you hold locally(as POP3 only) is data in mail format which you owns(mail folder of Tb is local data base of data in mail format), instead of copy of original mail data which mail sender wrote(digital signed mail can be used as evidence of a case, even if copy at recipient side).

I just want to be able to add a note to an incoming email

@TOM (In reply to comment #73) > WRT to your claim that there is a consensus that providing this only for POP > would be awful, UE wise, I beg to disagree. Sorry, I'm an IMAP user and I want this feature, too. Providing this feature for POP only is an awful idea. @WADA Mail should provide the same information and provide the same functionality no matter how TB accesses mail accounts (POP or IMAP). I think the general idea is that user experience must not depend on access methods or implementation details. Everything else is a fuss (see for example bug #533337 where UX differs depending on IMAP implementation details).

(In reply to comment #76) Daniel Kabs, I can understand your use case well - not local mail folder only, IMAP case which is most difficult case is involved. When IMAP, there is next problem. If mail size is 10MB, download of 10MB and upload of 10MB happens by adding small text to mail. It's usually not problem when detach/delete, because upload by detach/delete is merely several KB in ordinal case. What do you think about it? As Tb is general mailer, Tb has to care for any of small/old PC with network of low capacity/low speed and big/fast PC with network of high capacity/high speed.

@WADA 1. Yes, I want (need) to modify a message, whether it's a message that I've sent or received. I'm not sure why you're asking as it's rather clear from the initial bug report. 2. I did not refer to any means of recording the fact that a message was edited. Personally I don't care for such a feature, but I understand the need. @Daniel, @Tom, @Mike I think the approach to IMAP editing should be a practical one. If it's feasible and easy to implement - great. However, if IMAP editing prevents implementing a solution for local storage (POP) - then let's a have local editing first, and then press for extending the feature to IMAP. Regarding big (IMAP) messages - this can be solved with a per-account option that limits editing to user specified size. An attempt to edit a bigger message should POP a warning/confirmation dialog. Eyal.

(In reply to comment #78) > @WADA > 1. Yes, I want (need) to modify a message, whether it's a message that I've > sent or received. I'm not sure why you're asking as it's rather clear from the > initial bug report. Why I asked some questions to comment posters. (1) I understand your request in comment #0, but I can't understand why "altering of original mail data which mail sender sent" is mandatory and is only solution of your requirements. If change of subject, why X-Mozilla-Subjet: and feature which shows Subject: and X-Mozilla-Subjet: in convenient style can not be a solution of your requirements? (2) After your bug open, very many users added many comments. Altering of original mail data itself is a solution for added comment's cases. But I can't think "altering original mail data" is only solution for all comment poster's requirement. (3) I thought request is mainly local mail folder. However, some peoples referred to IMAP. And, someone says POP3 case is sufficient but other says it' require for IMAP too, someone says feature should be seamless or universal between POP3 and IMAP but someone says POP3 case and IMAP case can be indpendent, you say POP3 first IMP second but other may say IMAP first POP3 second :-). So, I aked question about IMAP case by other comment posters. (4) I wanted to clarify about next. What you need is "altered mail data" itself? What you need is your convenience which can be achieved if "alteration of existent mail data" will be implemented, which is probably implemented with not so large changes, isn't it? (Note: In some use cases, "altered mail data" sounds required.)

This has been going on now for how many years? Why not get off your bum and just allow editing of any message and be done with it. I am now looking at going back to outlook. All this argument about pop3 and imap is a load of ****, just make it happen and stop this ****.

I agree with Greg. It's become a joke after all these years. I've moved to Postbox (http://postbox-inc.com/). It's commercial, Mac & Win (maybe Linux in future) and supports modified TB add-ons, including Nostalgy, which I can't live without! It also allows editing save messages. I don't know the details about support for different environments since I'm only using pop3. I see some former TB programmers over in their forums...

I agree. In fact I will go further. I think this situation is giving open source software, and Mozilla, a bad name. Maybe some adults can come over from Firefox and fix this or something. It is indeed a bad joke.

Fifth purpose of my questions. (5) To avoid similar mess on this bug to Bug 166254 (+ Bug 341548 + bug 402594 + Bug 570355, Received: column case), which is mainly caused by many many comments of merely complaint in Bug 166254, when a developer will start to implement changes for request of comment #0 by bug opener (if and only if a developer, who thinks requested change is mandatory and needs and wants the change, will try to change Tb's code). In Received: column case, POP3 case is resolved first after mess in Bug 166254, and, because of too many comments of merely complaint by POP3 users, recommendation on INTERNALDATE on IMAP case by a few good comment posters was hidden(it's hard to read thru bug if too many comment of merely complaint are added), and some issues in IMAP case remained. Then bug 402594 was opened and some IMAP users posted some comments of merely complaint in bug 402594. Finally, a comment poster dig out hidden recommendation of INTERNALDATE, and bug 570355 was opened recently. There is no need to add comment of "I go back to Outlook" or comment about your frustration to bug report at B.M.O. No one forces you to use Thunderbird. You are absolutely free to use Thunderbird, and you are absolutely free to stop using Thunderbird.

Sixth purpose of my questions. (6) To clariy neded functionality in "add comment" type use case in your comment #0, when multipart/alternative and/or text/html mail, instead of simple text/plain or multipart/mixed with text/plain part as mail body. "Add comment" type use cases written in this bugs; (Copy of comment #19 Tal Cohen) > (In reply to comment #19) > > I disagree. I suppose there could be an option to do what you are asking, but > > it should be a choice. I lot of what I want to do when I edit saved email and > > Usenet messages is remove lot of extra quoted text. I don't want to have this > > all saved. > David, I suppose this is the difference between "edit" and "add comments"... > - Tal (A part of comment #70 by Daniel Kabs, reporting bugs since 2002) > User stories rationale: >(snip) > - Adding comments or notes to the mail body > e.g. describe action that has been taken in real world (beyond domain of mail > conversation) Next part in Your(Eyal Zvi, bug opener) Comment #78 sounds similar use case. Is it right? > 1. Yes, I want (need) to modify a message, whether it's a message that I've sent or received. (snip) If this kind of request, current "Edit As New" like process is not appropriate for text/html mail and multeipart/alternative mail of text/html part and text/plain part. To keep original structure/tags of HTML, "direct HTML source change" like next will be required. <p>statements by mail sender</p> <blockquote>added your comment</blockquote> <= Inserted by you All other data in text/html part shouldn't be changed. <p>next paragraph by mail sender</p> And, if multipart/alternative, and if multipart/alternative stucture and text/plain part in it should be kept, it is required to reflect the addion of comment to text/plain part.

@WADA - I'm not sure I understand all your questions, and I'm very sure I don't understand why you need so many clarifications when the bug/request is clear from message #0. But for you I'll try to explain again. I want and/or need to edit messages. There are different reasons, for example: * Add comment for future reference. * Correct spelling or syntax original text. * Correct factual errors in original text. * Fix/add charset (sender specified incorrect charset or no charset). * Emphasize important sections (ie. make bold, color, etc.) * Add forgotten attachment. * Remove redundant attachment (yes, I know I can do it today). NOTE!!! Those are examples. There may be other reasons. Use your imagination. The bottom line is that I need to edit any message, I need full control of the message, regardless of who wrote it to whom, regardless of the type (plain-text or HTML), regardless of headers, regardless of size, regardless of anything. Just think of it like this: I want to edit any message as if it's a new message that I'm writing. If TB can edit a plain-text/HTML/whatever message, if TB can edit an existing (eg. draft) message of any kind - then I want TB to let me edit any other message as well. So, I understand you have good intentions, but I think you're only complicating the discussion with irrelevant questions. @Greg (and others) - I'm at least as frustrated as you are because of this missing feature. However I think that we all need to maintain proper manners and respect the developers. TB is still a great piece of software. It has its advantages and disadvantages compared to other mail/news clients, but this is true for any other mail client. I do want to help make TB the best mail client, and I do hope the developers will take care of this bug. The way to do it is getting more votes for this bug report, and getting attention to it on relevant forums. Flaming the developers will probably not convince them to spend their spare time on this. Eyal.

(In reply to comment #85) > and I'm very sure I don't understand why you need so many clarifications > when the bug/request is clear from message #0. > But for you I'll try to explain again. Thanks for explaing again. Your request itself is clear since initial. I couldn't think it would be implemented soon, so I posted comment #8 as relief of "add ascii string to Subject: by text editor" for some user's convenience. However, why "edit of existent mail data" is mandatory is not clear. If clear in comment #0, why comment #19 and comment #20 exist? As you didn't add negative comment to it, I think your case needs "alteration of existent mail data". So I wrote "I understand your use case(and probably bug opener's)" in comment #74, in reply to comment #70 by Daniel Kab. As seen in Bug 166254, many comments of merely complaint merely make bug reading hard. So, I wanted to summarize next things, in order that developer can read your comment #0 then skip to new version of your request. - Required feature : edit mail data of any message - Use case and why "edit of mail data itself" is mandatory. - Required care for IMAP case. - Required care for multipart/alternative and text/html - Other requirements, or other considerations

(In reply to comment #85) > but I think you're only complicating the discussion with irrelevant questions. Eyal Zvi(bug opener of this bug): My questions are similar to comment to Comment # 68 by Mike McGranahan. I dislike many comments of merely complaint which surely spoils bug opener's reasonable request. I merely tried to keep your initial request reasnable, and tried to keep developer's readability of your request.

(In reply to comment #77) > When IMAP, there is next problem. > If mail size is 10MB, download of 10MB and upload of 10MB happens by adding > small text to mail. > It's usually not problem when detach/delete, because upload by detach/delete > is merely several KB in ordinal case. > What do you think about it? This should not be a problem as I believe that most messages are small enough and most connections with IMAP servers are fast enough. This assumption is the foundation of other functions, e.g. Auto Save. "Auto Save" = While composing mail, TB periodically seems to store the mail in Drafts folder. There is no size limit for this function and there is no bandwidth "detection" that would switch Auto Save off on low bandwidth connections. However, the feature can be switched off altogether.

(In reply to comment #88) > This should not be a problem as I believe that most messages are small enough > and most connections with IMAP servers are fast enough. > This assumption is the foundation of other functions, e.g. Auto Save. I see. (IMAP case) - There is no difference between altering of mail of big attachment and saving of draft mail of big attachment. Even if mail of big attachment, user can remove it by detach/delete. - Saving of altered version to IMAP folder is same as saving in detach/delete. Note: In addition to Tb 3.0's detach/delete code, bug 521867 is required.

One thing you may or may not have noticed is that edit message as new brings up the plain text editor, and in general, is not a very pleasant experience. Fixing it to use the html editor is quite a bit harder than you might expect.

@Eyal Zvi(bug opener of this bug): You say next in original request of comment #0. > Currently the only way is to "Edit As New", save to Drafts, move the new copy > from Drafts to the original folder and finally delete the original message. Can feature of "Edit of existent mail data" be same one as your circumvention + kept mail timestamp by INTERNALDATE if IMAP? Can you accept loss of Received: header etc., loss of some data in original HTML source, ...? (according to David's comment, all HTML tag seems lost because plain text editor is invoked, if "Edit As New" is utilized for the feature.)

to be clear, I don't think editing a message using the plain text editor is really an acceptable UI for this feature.

As I indicated in Comment 68, an excellent implementation of this feature exists in Postbox, which is derived from Thunderbird. The implementation supports POP and IMAP, HTML editing, retains all headers, and will transfer all attachments upon save. In that comment I had included the link to their source packages, which may include the code for the message editing functionality. Here is that link again. http://postbox-inc.com/coveredcode

(In reply to comment #93) > (snip) which is derived from Thunderbird. I visted features page. > http://postbox-inc.com/features#platform > Postbox is based on Mozilla technology, (snip) > we'll quickly incorporate Mozilla security updates as they become available. Mike McGranahan, you didn't try to find coupon code? :-) > http://postbox-inc.com/blog#entry-2 > Step 1 - Save $10 on Postbox! > Use your search skills. Find a coupon code to purchase Postbox for just > <strike>$39.95</strike> $29.95!

First a comment on the meta discussion here... In reply to comment #82 by Tom Athanasiou: > I think this situation is giving open source software, and Mozilla, > a bad name. In my opinion open source developers have an obligation to listen to the non-developer user community. At the same time, those users have an obligation to understand that open source developers are going to take your input into account, but ultimately apply their limited time to the problerms that most interest them. I'm generally happy with any open source project that at least gives serious consideration to ideas I've proposed. With most projects, you'll either received no comment, or an immediate refusal. > Maybe some adults can come over from Firefox and fix this or something. Keep in mind that the TB community and resurces are tiny compared to FF. And, that although there are other mail clients that support this functionality, I expect only a tiny minority of power users actually would make use of it, so expect developers to prioritize their time accordingy. I don't know if WADA is a TB developer (perhaps you could state your role, WADA) now interested in addressing this need, but if so, calling the response "a joke" isn't exactly going to motivate action. I also think it is perfectly resonable for a developer to request a clarification of the requirements, particularly for a request this old, where the requirements (and interested parties) have likely changed. If you have a constructive, specific, detailed use case, post it. In reply to comment #79 by WADA: > Why I asked some questions to comment posters. > > (1) I understand your request in comment #0, but I can't understand why > "altering of original mail data which mail sender sent" is mandatory and is > only solution of your requirements. If change of subject, why > X-Mozilla-Subjet: and feature which shows Subject: and X-Mozilla-Subjet: > in convenient style can not be a solution of your requirements? I happen to have a few use cases that would benefit from this proposed feature (editing of messages). One of them would indeed be addressed by the specific solution cited in #1. Use Case #1: Voice Mail I receive voice mail messages as an email attachment. The supplied subject line indicates the phone number of the caller. I'd like to be able to replace the subject line with the name of the caller when archiving the message. (Even better if it could be done via an automated mapping mechanism, but lets stick with hand editing to start with, as this same functionality works for several similar use cases.) This use case can be addressed by the TB Header Tools Extension (as mentioned in Comment 22): https://addons.mozilla.org/en-US/thunderbird/addon/875/ but I found it to be unreliable. I haven't tried it in a few years. For other use cases, more than editing the subject is required... Use Case #2: PIM Using TB as a personal information manager. Here you might have a folder structure with the folders representing different states of tasks, etc. The need is to be able to create new messages in arbitrary locations, and likely modify those messages. Current workaround is to create a message, save it as a draft, them move it from the draft folder. So inconvenient as to make thise use case impractical. This use case could be expanded to include adding custom headsers to reflect PIM-specific functionality, but that's best left to an extension specifically for that purpose. Use Case #3: archiving mail sent via web form Archiving messages sent via means other than email. When I run across a vendor that annoyingly accepts messages only via a web form, I'll often save a copy of the message I sent in my TB mail archives. This requires creating a new message in an arbitrary (I may have a folder for the vendor) location. Editing is not required. The drafts folder workaround is adequate for this use case, though not ideal or obvious to a novice. Use Case #4: annotating received mail I don't have a strong use case for this, but occasonally it would be convenient to be able to add notes to received messages. (I suspect there are already extension to address this.) I don't really have a use for making arbitrary edits to received messages. Storage space has obsoleted the need to trim things, and if I did alter a received message, I'd likely want to preserve the original for historical purposes, which then suggests having a revision system. More complication than is needed for my use cases. In reply to comment #77 by WADA: > ...mail timestamp by INTERNALDATE if IMAP? > Can you accept loss of Received: header etc. ... Use case #2 and #3 can tolerate this. The others would be negatively impacted if the original timestamps or other headers are lost. In reply to comment #79 by WADA: > (3) I thought request is mainly local mail folder. However, some peoples > referred to IMAP. And, someone says POP3 case is sufficient... I think POP3 is irrelevant, as the question is about storage, not retrieval mechanism. I agree with the commenter who said the objective should be to implement the feature so that it works with any storage back-end. If it isn't possible to meet that objective, or the feature can be incrementally implemented, then I agree with the suggested approach of implementing for local storage first, followed by IMAP. In reply to comment #77 by WADA: > When IMAP, there is next problem. > If mail size is 10MB... > ...Tb has to care for any of small/old PC... Implement first, then worry about optimizations. It's likely that a user who is slowed down by 10MB emails is already use to that slowness. Adding editing fnctionality is not making things worse. As someone else pointed out, the same probems apply to the auto save feature. If nit is too slow, users will turn it off, not use it, or figure out that they need to move the message to a local folder first. In reply to comment #84 by WADA: > ...current "Edit As New" like process is not appropriate > for text/html mail and multeipart/alternative mail of text/html part and > text/plain part. To keep original structure/tags of HTML You might be making this more complicated than it needs to be. Obviously the parts that can be edited in TB would have to be restricted to the data types that TB's internal editor can handle. For multipart/alternative, you'd likely need to open the HTML part for editing, and regenerate the text/plain part on save (using TB's existing algorithm for doing this). I don't see any reason why you'd need to "keep original structure/tags." In reply to comment #86 by WADA: > ...many comments of merely complaint merely make bug reading hard. Bug comments aren't a great way to gather requirements, either. Something I've always found lacking in Bugzilla is a separate description section that remains editable, like a wiki. You can work around this by linking to a wiki. Accordingly, I'd recommend summarizing the collected use cases on a wiki page, and link to it. Perhaps here: https://wiki.mozilla.org/Thunderbird:Collected_User_Requests or linked to that page. -Tom

Great comment, Tom. I'd ammend his by saying that I have many of the same use cases, but as an IMAP user I am accustomed to accessing my email from multiple machines and devices. Therefore, if I edit a message on my work desktop, I would expect to see the edits on my phone, a webmail interface, and my home desktop. Persisting to IMAP would satisfy this requirement (which is how it is implemented in Postbox).

(In reply to comment #95) Tom Metro, thanks for clarifying requirements. There is aparantly use case which requires "alteration of mail data itself without loss of message headers". > I think POP3 is irrelevant, as the question is about storage, not retrieval mechanism. Difference between PO3 case and IMAP case is not retrieval mechanism. Difference in storing mechanism is problem. The difference in storing mechanism shouldn't be exposed to user of the feature. Feature should be usable for both POP3 folder IMAP folder seamlessly. > You might be making this more complicated than it needs to be. > For multipart/alternative, you'd likely need to open the HTML part for editing, > and regenerate the text/plain part on save (using TB's existing algorithm for doing this). > I don't see any reason why you'd need to "keep original structure/tags." I never say I need "keep original structure/tags". I asked "keep original structure/tags" is mandatory or not to who requested same feature which bug opener requested in comment #0. One of reasons why I referred multipart/alternative; If multipart/alternative, RFC doesn't prohibit different contents in text/html part and text/plain part. What action the new feature should take on such mail? Problem in multipart/related with text/html mail. HTML can has <iframe src="cid:<id of embeded part>"> in it. And the embeded part can be text or html. Should new feature support alteration of such embedded parts? Other concerns. What should be done on digital sigend mai or cypherd mail? If wrong data exists, what should feature do on such data? 0x00, standalone LF or CR instead of correct CRLF, ... Many RFC violation may exist in mail data if mail data was generated by other mailer. If feature will be implemented, the feature should be torelant with many RFC violations, and action on RFC violation sould be concistent. It's defference from "Edit As New" like process which is composing of Tb's mail using text data in received mail after interpretation of the mail. > Obviously the parts that can be edited in TB would have to be restricted to > the data types that TB's internal editor can handle. New feature can be be like next? (feature-1) "Replace of a part data" which is similar to alteration of part data by detach/delete. I think it doesn't need to be limited to text part only. If replace of whole mail, enhancement of "import mail by Drag&Drop of .eml file" may be simplest one. (feature-2) Capability to edit any existing text part data. For example, (i) export html part data to HTML file, (ii) edit it by HTML editor, (iii) replace html data in the part by edited one. If (i)/(ii) is seamlessly executed, (ii) can be external editor like user selected source viewer. (i)/(ii) can be implemented as add-on. As purpose is basically "add comment" type, editing of whole HTML at once is better to be avoided. Edit of required portion only like wiki is better. "View selection source" can be utilized for it? Above can be done manually by very simple next steps if local mail folder. 1. Click other folder, and force close of file of <folder>. 2. Edit mail source by text editor, and change file length. 3. Click folder, to force rebuild-index. However, mail data can contain binary of different charset in a file even if single mail only in Unix Mbox file. So, mailer's support for mail structure analysis is mandatory to alter mail data correctly. By the way, I'm a helper of QA team and a nightly tester to help developers. I'm trying to break down bug oper's request as a QA work. And I'm searching for low cost solution to achive bug opener's request, because I also can't easily transfer to other mailer merely by lack of some features even if I want features and even if other excellent mailers alreay have the features.

Other concern. Gmail IMAP/Gmail ignores mail data if slightly different mail data is uploaded, because Gmail considers such mail data "duplicated mail". Change of some important header such as Subject:, Message-Id: or addition of different header such as X-Mozilla-Replace-Version-NNNN: header may be required to replace mail data by new version.

I'd like to see this RFE implemented but I think this won't happen in the near future. What about realizing a subset first: - changing the subject line - adding a note / comment to the mail Both could be implemented by adding X-Mozilla headers to the mail. What do you think? Is it worth filing separate RFEs for those ideas?

Subject RFE was Bug 532153, DUP'd to Bug 195138 (don't ask ME why...). Comment RFE was Bug 404535, DUP'd to this bug. If those bugs should just be re-opened and "detached" from the ones to which they're DUP'd, rather than open new bugs.

Thanks Michael, I added comments to the two RFEs you mentioned. However, I can not reopen bugs, I can only file new bugs. Somebody else will have to reopen them.

Found RFE for editing subject. It is not bug #532153 nor bug #195138. RFE for editing / changing subject is bug #91106

I'd just like to add my vote and agree wholeheartedly with Eyal's concise use cases in post #85: https://bugzilla.mozilla.org/show_bug.cgi?id=254739#c85 Oh, and here's another use case: I often read informational newsletters and then move them into my wife's "read" folder. She does the same for me. Being able to bold/underline just the relevant parts, and to cut out irrelevant sections entirely would save us both quite a bit of time. (We do this on a single computer with POP-ed email, but the same would apply in an IMAP-synced scenario.) Another use case: Someone sends me an email that is useful except for the 10MB photo that was pasted into the body (not attached). Since it's not an attachment, editing the body seems to be the only way to delete it. The specific use cases would go on an on. I disagree that this is a feature that only a small minority of power users would use. I think most power users would use it--it is the number two feature that I miss most since I transitioned from Lotus Notes. (The number one feature is usable sync-ing across computers. IMAP--with TBird at least--is far too inefficient with bandwidth for my connection.) Regarding addressing this issue with part-way solutions that don't provide real editing of the message body, I think better band aids would be great and helpful, but I don't think they'd truly address most of the use cases we're talking about here. (One band aid not yet mentioned here is the XNote plugin, BTW.) Jon C

I've been using the Header Tools Extension for some time, and while it's not everything I could ask for, it has worked well within its limits. I've come to depend on it enough that I've delayed updating to Thunderbird 5.0, since it's not compatible with it. I appreciate the efforts of the developer, but I learned that he's no longer working on it, so the urgency of getting a replacement (and upgrade!) has increased. I hope Thunderbird developers will see fit to take this task on, soon.

howdy y'all, this extension replaces the old headertools and does it quite nicely. plus, the author [kaosmos] is a _very_ active extension writer while still apparently having a Real Life. [*grin*] - Headers ToolsLight: edit Subject, Sender, Full source etc http://forums.mozillazine.org/viewtopic.php?f=28&t=2300561 seems to be a useful workaround until the "real thing" shows up in tbird. take care, lee