365045 - Early deletion of emails off server due to incorrect DateReceived value in popstate.dat

Status: UNCONFIRMED

(MailNews Core :: Networking: POP, defect)

Description

[andypopely]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; T312461; .NET CLR 1.0.3705; InfoPath.1)
Build Identifier: version 1.5.0.9 (20061207)

This problem applies to classic Hotmail webdav accounts and Live Mail accounts.  
When a single email is read into the Thunderbird inbox and there is already an UIDL entry of an older email in the popstate.dat then the new email gets assigned the same datereceived value as the email already in the popstate.dat.  Likewise if a batch of emails are read in one getmail retrieval then the first email in the batch gets the datereceived value of the first email in the popstate.dat but the other emails in the batch get the correct datereceived value.
The result is emails with the wrong datereceived value will get deleted early from the server when the account on Thunderbird is set to "Leave messages on server for at most n days"

Reproducible: Always

Steps to Reproduce:
1.On the test account delete all emails in the inbox on the server
2.Delete any emails in the inbox on Thunderbird for the corresponding account 
3.Ensure the popstate.dat has no UIDL entries
4.Send one email to the test account and receive it on Thunderbird
5.Send a second email to the test account and receive it on Thunderbird and then view the popstate.dat and the 2 entires will have the same datereceived value
6.Send a batch of emails to the test account and receive them on Thunderbird in one getmail operation and then view the popstate.dat and the first entry from the batch has the same datereceived value as the first 2 entries but the rest of the entries will have the correct datereceived value.

Actual Results:  
The datereceived values for the entries in the popstate.dat show duplicates when they should be unique.

Expected Results:  
Used the correct time for the datereceived value

This applies to Hotmail UIDLs with the following format

393d09de-1f18-43b3-bb76-7eb5d93628ca

Comment 1

[Mike Cowperthwaite]

Are you accessing this mail direct from the server to Thunderbird, or are you using the extension that provides a POP proxy to load the webmail?  I didn't think the former was possible; if the latter, you should file the bug with the extension author.

Comment 2

[andypopely]

It is my understanding that the popstate.dat is managed by Thunderbird.  I use the webmail extension and have also tried the freepops app and the problem occurs with both of them and only with this UIDL format.

Comment 3

[David :Bienvenu]

who is creating the UIDL's? hotmail, or the extension? Is it possible that the uidls are getting confused, e.g., when we list the UIDLs via POP3?

Comment 4

[andypopely]

hotmail .... the UIDLs are no problem it is the "datereceived" value that is assigned by Thunderbird that is the problem

Comment 5

[David :Bienvenu]

there's a one to one association between uidl and date received, right? If uidls get re-used or changed between sessions, strange things will happen in popstate.dat, because we rewrite the whole thing every time it changes.

Comment 6

[andypopely]

The UIDL is unique to a message and doesn't change.  When Thunderbird reads the UIDL and that UIDL isn't in the popstate.dat then that UIDL is added to the popstate.dat and a datereceived value is assigned to that UIDL entry.  That UIDL entry in the popstate.dat won't be touched by Thunderbird until it's time to delete it when it is no longer in the inbox on the hotmail server.

Comment 7

[alanrf3]

This problem (which I reported in the Thunderbird Support forum in October 2005 http://forums.mozillazine.org/viewtopic.php?p=1818397#1818397 ) has existed at least since Thunderbird 1.0.7.  

The problem continues to exist in Thunderbird 2.0.0.0 and I notice that it exists on more than one of my email accounts. 

Comment 8

[alanrf3]

All of my email in an account was deleted today because of this long standing fault in Thunderbird.  I am wondering how many years a problem has to exist and mature in Thunderbird before it gets looked at.  

If there is someone who would be kind enough to point me to the source code for this area then I suppose I can go and find out why it is broken myself.  The source code involved would be where the popstate.dat entry is created for a new mail item.