User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 if u set leave message on the server on a mail pop3 account i recive mails already donwloaded in some random check new mail action ( not rare case at all...) Reproducible: Sometimes Steps to Reproduce: 1. pop account 2. leave messages on the servers 3. check new mail Actual Results: download again all mails Expected Results: only new messages
But you don't get already downloaded ones each time? The duplicate ones are they the new ones from the last retrieve. Or all on the server to this date? Info: We store downloaded messages in a file called popstate.dat. You could watch this file if it a) is empty before retrieving messages or b) isn't updated after retrieving messages (in this case you should copy away it before to compare it afterwards).
Is your profile or mail folder hidden? See Bug 242736.
hi all the popstate.dat files have not the "hidden" file attribute , should it be set to hidden ? when duplicate mails happen it retrive all messages from the pop3 server (obv marked as new in the mail client). the relevant popstate.dat is not empty before retrieving messages. It has 24 lines (like the message the client download each time it happen). this problems seem to happen randomly in the download when i try to check mail by client :sometimes download all message sometimes nothingh, but the bug happen very often. The same problem i got on another xp pc with thunderbird on the same account and same settings (leave pop3 message on the server)
I've no guess, sorry. I the messages are listed in the file and loaded it's very strange Mozilla doesn't recognize the mails on download. If you send yourself a message and then retrieve messages, does a new line show up in the popstate.dat? You could also attach (use the function above please) a communications log when checking for mails: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop I don't expect to find anything surprising, but it's a try.
hi the postate.dat add a line with a new message. i tryed then to remove, restart latest Mozilla and then was ricreated with 25 lines . then i checked again and first replay was no new message, then at the secon check download again 25 messages. i run on dos set NSPR_LOG_MODULES=IMAP:5 set NSPR_LOG_FILE=c:\tmp\filename C:\Programmi\mozilla.org\Mozilla\mozilla.exe but log file was empity after downloading emails also i tryed the setting NSPR_LOG_MODULES=POP:5 with the same 0 byte log Btw could this be a problem of the provider pop3 server? set NSPR_LOG_MODULES=IMAP:5 set NSPR_LOG_FILE=c:\tmp\filename C:\Programmi\mozilla.org\Mozilla\mozilla.exe but no log
hi i think i have found the point i tryed with a different mail provider and all was fine. then i tryed on another account but on same provider that i got problem and it happen again the provider is lycos.it so i guss now it is a provider pop3 server problem with md5 or what it used for the pop3 protocol
> set NSPR_LOG_MODULES=IMAP:5 This line should be set NSPR_LOG_MODULES=POP3:5 as written in the description on the page. > Btw could this be a problem of the provider pop3 server? Might be if the message id's in the list we use to recognize a message change sometimes. That is, if the server genereates a different UIDL for the very same message. But this is very unlikely. What do you mean with MD5? The UIDL generation?
(In reply to comment #0) I have sometimes the same problem. Once in a while Mozilla starts downloading ALL messages stored on the server. That results often in lots of duplicate e-mails in my inbox. (about half of them are "unread"). I don't suspect that this is a bug in Mozilla, because I think that other mail-clients have the same problem. (Outlook) It also happens quite often after my provider did some maintanance on the (mail)servers. Since every email has a unique ID inside the header, is it possible to check if an email already exists with that ID and if found, don't download it.
It would be possible. With problems and drawbacks. The problem is to scan through all local messages for every message to be downloaded. Or Mozilla has to build up a database of all local messages (needs only to be build once for each get messages). Both quite slow. And on download, every message on the server (that can be twenty or fivethousand) needs to be downloaded (or even the header) to check its message ID.
i have wrote to isp i discoverd that 2 different versions of server answer: RECV: +OK Lycos Mail POP3 v2.1.0 RECV: +OK Lycos Mail POP3 v2.1.2 for european lycos server ; this seem why sometimes happen sometime not... so i have sent an email to them using postmaster@
And you could verify that the problem occurs only with one of the versions? Or if the problem occurs with both versions it might be that the generated ID are incompatible. So you get all messages if the popstate.dat contains ID from one version and you're connected to the other one. That would be very interesting. Please keep us up to date if Lycos answers (unlikely I guess).
i can not verify since i can not discover semparate box behind pop.lycos.it ( or .de, co.uk, etc) by nslookup or logs. the popstate.dat is always keeping status but some times the pop3 client return no new message some times all new then downloaded... so from the log i see that a difference was the version of the server. i could attach the log i think 1 server replay with uidl 134791168[80c4380]: SEND: UIDL 134791168[80c4380]: Entering NET_ProcessPop3 5 134791168[80c4380]: POP3: Entering state: 3 134791168[80c4380]: RECV: +OK 134791168[80c4380]: POP3: Entering state: 12 134791168[80c4380]: Entering NET_ProcessPop3 10 134791168[80c4380]: POP3: Entering state: 12 134791168[80c4380]: RECV: 1 352 and other with 134791168[80c4380]: SEND: UIDL 134791168[80c4380]: Entering NET_ProcessPop3 28 134791168[80c4380]: POP3: Entering state: 3 134791168[80c4380]: RECV: +OK 1 message, 1887 bytes. 134791168[80c4380]: POP3: Entering state: 12 134791168[80c4380]: Entering NET_ProcessPop3 12 134791168[80c4380]: POP3: Entering state: 12 134791168[80c4380]: RECV: 1 m:352 134791168[80c4380]: POP3: Entering state: 12 seem a "m:" is the difference on the same mailbox status...
Yep, that's what I meant. So if you are connected to a server with the same version on successive message gets, you'll only get the really new messages reported. But you'll get all if this message list comes from another server than the last time. So this explanation exactly fits the data we have and what you're experiencing. If you agree, would you please close this bug as INVALID? If another aspect arises you can reopen it at any time.
ok also surprise: seem that the m: prefix is dissapered so seem lycos fixed it. cheers
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
Component: MailNews: Notification → MailNews: Message Display
QA Contact: search
You need to log in before you can comment on or make changes to this bug.