Thanks for the suggestion. I had a similar thought and emptied my entire inbox into some archival folders I have set up on the IMAP server. I now have new emails coming into the in-box (about a dozen in each of two different accounts), but still have the same trouble with headers not being synchronized with the corresponding messages. Repair folder always seems to fix the problem, but it's only temporary. I left a message on a Thunderbird forum asking about the same problem (https://getsatisfaction.com/mozilla_messaging/topics/mapping_between_message_headers_and_messages_is_corrupt?rfm=1), but it doesn't look like there is much activity on that site. Do you know of a better community forum for Thunderbird help?

Thanks so much for your help. 

-- Opticswalt 

[quote user="Greenman"]Resetting/editing pconfig files is a pita because I have to copy them to a 32bit machine, make the changes then copy them back to the 64bit server.[/quote]

There's an easier way - install DOSbox on the 64-bit machine and then you can run pconfig.

See this thread

[quote user="bollero"]Ok, when started mercury - one tip - can use only one click, this will open transfer module. If double click, two mercury will appear and error message will see. Frank
[/quote]

Frank,  I am not sure I understand what your original problem was, or if you have fixed it.  Post again if there is still an issue.

It is a good tip not to have more than one version of Mercury running from the same directory!

That's exactly my setup! But I think what you meant was to put "loader" instead of "Mercury" in the startup folder. This way at least Mercury would re-launch after a crash. 

In a way I am glad that I am not the only one having this problem. I am running Mercury on a Win2k3 server and I am having problems with crashes and corrupted IMAP folders that I believe are due to:

1. concurrent IMAP connections from Android and Outlook.

2. large IMAP folder size (>1.5GB). The large folders are usually "Sent/Sent Messages/Sent Items" and "Trash/Deleted Items/Deleted Messages", which make matter worse because they are constantly in use.

Android and iOS devices do not terminate IMAP connections properly, which compounded the problem as more and more of these devices are now connecting to Mercury. Add this to the time it takes to handle large folder and it stresses Mercury. When Mercury is stressed, just about anything would push it over and crash it. And it seems that when it crashes too many times consecutively, it moves everything in the queue to a sub-folder, thinking that something in the queue could be causing the crashes, by then there would have been a lot of zero size files in the queue.

For me at least, toggling the "affinity" to get it to run on two CPUs did not improve performance, but unchecking the "Enable support for SSL/TLS secure connections" checkbox did help slightly.

Just a note though: the largest folder size for me is 4GB instead of 2GB, and mine have both IMAP and POP enabled. 

regards,

Philip 

I have run into apps that weren't designed to recognize and utilize multiple cores.  Back when dual cores first came out I wanted to force some apps to run on the 2nd processor.  Changing the affinity worked, as you have discovered, but it is not sticky.  I found a utility that provided the capability of triggering an app with a specified processor affinity.   Unfortunately I don't remember what the utility was called.  I thought I might have it in my downloads folder but I don't.  I just did a quick web search and it appears that Win7 has the capability via the command line.  See here:

[quote user="chriscw"]We do run Spamhalter on the server but not clamwall I could never work out how to get it to work.  I guess that now we have a few Outlook users Ii maybe should have another go.[/quote]

For me Clamwall is a 'must have' first line protection for incoming mail.  I use some of the Sanesecurity signatures as well to catch spam as well as viruses.

Post on these forums if you are still having problems setting it up - the windows binaries from ClamAV are now very stable.

Have a look at this thread and see if one of the relaying options might work in your case:

If a message is CC'd to you by the sender the reply should go to the sender. If however a message is forwarded to you by one of the original recipients, the sender in that case is that recipient, not the original sender.

It's the email client that sets the reply-to header and it could be that different clients handle it in different ways. Mercury will deliver according to the SMTP envelope provided by the email client.

OK thank you for your informations!

Regards, Franz

To bypass the connection limit you will need to use SMTP, POP3 and IMAP to connect to the server. The integrated PMail/Mercury setup requires file sharing access.  The "force through server" option will write local messages to the Mercury queue rather than directly to the recipient mailbox directory.

Also, you can turn on session logging in MercP and examine the entire conversation to see exactly what is being asked for by the client and what is provided by the server.

There are some standard template files included with Mercury, for instance failure.mer. So for example, try replacing "Content-type: Text/plain; charset=US-ASCII" with "Content-type: Text/plain; charset=utf-8".

I close this old case.

After ran Mercury couple of weeks without Spamhalter, no crashes at all. After manually compacted Spamhalter's database, few crashes per week with Spamhalter.

 Jyrki

Thanks I will try that next time he mentions it.

So apparently XAMPP has a release where they have broken the Mercury installation by failing to include the required QUEUE directory. Well, at least now we know what to tell other people that are trying to get it to work!

As usual with XAMPP it advisable to remove references to localhost if you at all plan to use the server on the Internet. 

You could create a new folder, copy over the mail and delete the old one, then rename it to the old name.

Thanks Rolf for refreshing my feeble brain.  The ~r in the UDG does indeed pick up the content of the user default reply-to address.  I now remember configuring it this way because I use MercD to POP hosted mailboxes and could not use ~8 because the local account names and hosted account names are different.

The small daemon that hides and shows various module windows in Mercury has now been updated. It hides module dialogs instead of permanently closing them. Settings can be saved so they will be applied again when Mercury is restarted.

It's available for download here:  

If there is more than one concurrent connection to a mailbox it may not be possible to delete messages. Otherwise it should be OK though.

The  main question is probably if your Internet provider allows you to use port 25 (SMTP) for external communication. Otherwise use MercuryC instead of MercuryE and relay outgoing mail though the ISP's server. Using non-default ports on a public server will not work, you will be the only one to know what port to use. 

If you don't use MercuryX for scheduling anything it's better to disable it.

Binding to 127.0.0.1 only allows traffic from the server itself, so don't do that if you want to communicate with other computers. The IP interface field should in most cases be blank. It should never contain a domain name.

Please read Mercury help (or the PDF manual) about local domains.