'safety' in reference to dataloss, either confined to the one message or corruption of the containing folder and/or any folder that messages from that containing folder are copied to
'safety' in reference to dataloss, either confined to the one message or corruption of the containing folder and/or any folder that messages from that containing folder are copied to
Thanks for getting back to me.. Is there any way that the Received header could be added to the list of editable headers? (You know what they say, you don't ask, you don't get! )
I appreciate that it's quite a specific request and may not be used by many people, but it would really be cool to have that editable as well..
If it's possible I would love to see that added, but only if it won't distract you from all the other cool extensions you frequently come up with..
I just wish TB developers would finally implement a decent meta-data backend for emails. This would be incredibly usefuly and free extension programmers from using workarounds like this one.
Every decent email client has a some form of meta-data handling mechanism. To "forget" this was already very bad design from the start but that it is still missing is kind of embarrassing.
“Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe.”
So, does this extension work with IMAP or not? It seems that earlier versions didn't, but then there were some posts that said newer verisons did. If it's manipulating mbox files, which IMAP doesn't use, I can't see how it's supposed to work.
I'm asking because it doesn't work for me using an IMAP account. The dialog box comes up but it doesn't seem to be able to read any existing header information -- it's blank except for the ability to add a new header. if I do that, it apparently deletes the other header info so the message disappears.
I do have the "order" pref in prefs.js and have read the entire thread, but I did not see anything definitive about whether or not IMAP was supported.
BTW: It does work if I copy an IMAP message to a local folder. Oh, and I'm using TBird 1.0.2.
While IMAP message headers *are* (kinda) stored locally in an encrypted form.. These local headers are simply placeholders that allow TB to locate and display the real message on the IMAP store.. If the local header and the IMAP header differ - even slightly - TB will not be able to display that message.
The only way, then, to modify headers on messages in an IMAP store is to
1) move the message to a local folder
2) modify the headers
3) move the message back to the imap store..
Ah, OK, that makes sense. I knew the headers were fetched, but I didn't know how TBird handled them.
So, the next question is: Can what you describe as the procedure for handling IMAP (copy to local, modify, copy back) be handled programmatically in the background by the extension when it's operating on an IMAP account?
I guess this would be a big "feature request," then....
While, in theory, this can be done programatically, there are several reasons why this would not be ideal..
1) it would be a fair amouont of work
2) if the IMAP message in question was one with large attachments, the *whole* message would need to be downloaded first, then modified, then uloaded back to the IMAP store ( dail-up users would scream )
3) There would be several 'failure points' where it is possible the message would be lost..
I think is would be easier/safer if the user performed the moves from and to the IMAP store.
Sorry
the "New" Button does not work in my case (tried with Tb 1.0.2, HT 0.4.0, 0.4.1 and 0.4.2 on a (almost) new profile).
Does anyone have the same problems or is it only on my computer?
In order for you to get a new line, you will need to enter details in the two blank boxes to the left of the 'new' button first ( that would be your first new header.. )
I know because it used to work this way in older versions, but now it doesn't work any longer. To get X new headers I have to start the process X times an always use the predefined empty line - which works just fine.
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.