HeaderTools ( for TB ) ver 0.6.0 available

[Worldseye]

The extension ignores the following headers for safety reasons
Received, Message-ID, X-Account, X-UIDL, X-Mozilla, Delivered

Sorry Frank, when you say safety, what are you referring to?.. dataloss?, fraud/Misuse? or something else?

Thanks

[Old Ausdilecce]

Worldseye,

'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

[AmirG]

AmirG,
Have you checked to see if the preference:
user_pref("hdrtools.headers.order", "");
is in your prefs.js file?

If you say yes to both of those, then it might be a new problem...

Umm , that did the trick. I usually read through the whole thread before I ask a question, got lazy this time.

But shouldn't the extension create the settings it requires on its own?

[Old Ausdilecce]

Yes, it should.. and I thought I sorted that issue out in the latest version.. Maybe I didn't

[Worldseye]

Worldseye,

'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..

Thanks

[johann_p]

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.

[majorsteel]

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.

[Old Ausdilecce]

NO,

the extension does NOT work with IMAP stores..

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..

Sorry

[majorsteel]

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....

[Old Ausdilecce]

Majorsteel,

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

[TobyK]

Hi,

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?

btw. which change have been made for 0.4.2?

Toby

[Old Ausdilecce]

TobyK,

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.. )

[TobyK]

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.

[Old Ausdilecce]

Looks like there was a bug there afterall..

Sorry bout that TobyK..

Get the fixed, new version from www.supportware.net/mozilla/HeaderTools.xpi

[TobyK]

wow, this was fast! Thanks alot!

Sorry bout that TobyK..

No worries!

btw. is there a thread like this for Freeform From and FCC on Compose?