UID calculation in MercuryP and MercuryI have been overhauled in the upcoming release.

One of our users who is using Thunderbird to access his email via IMAP reports regular occasions when if he opens an email the body of the email does not match the title.   That is the body of a different email from a different sender is displayed.   If the same email is opened in a copy of Pegasus which is accessing the mail box locally in the normal way this does not happen.

Does anyone else have this problem and is there a way to stop it?

[quote user="chriscw"]

One of our users who is using Thunderbird to access his email via IMAP reports regular occasions when if he opens an email the body of the email does not match the title.   That is the body of a different email from a different sender is displayed.   If the same email is opened in a copy of Pegasus which is accessing the mail box locally in the normal way this does not happen.

Does anyone else have this problem and is there a way to stop it?

[/quote]

Sounds like their local cache does not match the folders on the server.  He needs to refresh the local cache.

Corruption of the Inbox folder in Thunderbird occurs when Thunderbird loses it's connection to the server - due to network error or Mercury stopping or being restarted.

I haven't found a way to stop it, except making sure that Thunderbird is closed before doing any maintenance which might disconnect it.

The fix when it happens is to close Thunderbird and delete Inbox.msf - on a Windows XP installation this will usually be

c:\documents and settings\[windows user]\Application Data\Thunderbird\Profiles\[random folder name]\Imapmail\[mail user]\Inbox.msf

 I've found it easiest to create a batch file to do this, with an icon on the desktop and tell the users that if they see a mismatch, just exit and click that icon.

Thanks for your suggestions I am awaiting feedback from my users.

I use Thunderbird 2.0.0.6 and this happens to me as well.

Right click on the folder, choose 'Properties', then 'Rebuild Index' cures the problem (until next time).

This feature is new in this ver. of Tbird (or was it the last one?)

One other thing to note is that the (tbird) message rules get re-run after the index is rebuilt. Also any tbird tags that are stored in the .msf file (i.e not in the headers) are lost, but this also happens when you manually delete the .msf file.

[quote user="dilberts_left_nut"]

Right click on the folder, choose 'Properties', then 'Rebuild Index' cures the problem (until next time).

[/quote]

That's the problem:  you cure the effect, not the cause.

Here my experiences:

With Mercury I had those problems with ThunderBird (all versions), Outlook 200x, Outlook Express, IncrediMail and others. Almost always after Mercuy crashed (and that happens often with IMAP, once a day or so with large mailboxes).

Once I evaluated other mailservers (ArgoSoft, MailEnable, hMailserver and others), this never happened again. Even killing the mailserver's process brutally did not show this misbehaviour. All of the above clients worked well. With hMailserver in particular there has never been such an issue in one and a half year.

My only guess is, that when Mercury crashes, at the next connect of that client things get badly messed up, and that this mess is then  carried over to the client, which in turn messes up its cache.

But as I always kept saying: starring for years at the client as the only possible culprit never solved the problem and will never solve it in the future... 

We access some big mailboxes regularly with IMAP but in our case Mercury crashes are extremely rare, actually.

At the start of an IMAP session the server assigns a message sequence number to each message in the selected mailbox. It's up to the client to sync to that list for each new session; it should not assume that a sequence number received during an earlier session still is valid. Besides that number there is a Unique Identifier (UID) for each message that should persist over sessions. If it for some reason has to be reassigned the client should be able to recognize this by checking the UIDVALIDITY part of the UID. (See the RFC for IMAP4: http://www.faqs.org/rfcs/rfc3501.html).

So unless Mercury fails to issue a new UIDVALIDITY number when reassigning UIDs (which perhaps can happen after a crash), it appears to me that it's the responsibility of the client to make sure that the message lists match.

/Rolf 

For what it's worth... This problem appears to be related to the way Mercury generates UIDs for messages. I am currently examining it trying to work out what might be happening, but the process is rather slower than it might be because I cannot duplicate the exact problem as described.

I'm proceeding on the basis of some assumptions though, and will let you know if I work anything out.

Cheers!

-- David --

This thread seems to finish in November last year.  Is there any news as to whether the issue is likely to be addressed?  I am having the same problems as described, of course.

Thank you

GordonM

Ditto, using Outlook and IMAP.  I think it gets confused when I try to read an e-mail while it is still updating its local cache.  But it can be good for 3 weeks, or it can go bad a day later. 

Thanks, Eric