User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows 98SE; en-US; rv:1.5) Gecko/20031007 This happened today for the first time. I don't know for how long it will last. Maybe they will fix it on the server. Reproducible: Always Steps to Reproduce: See the attached POP3 log. There are 196 messages on the server. Mozilla deletes some of them (i.e. 168). Then it tries to download new mail. The server reports 196 messages again. Some of them are 'marked for deletion'. Mozilla requests numbers and uids of those messages. The server correctly reports them, without the deleted messages (168 is missing in this list). Actual Results: Mozilla does not honor this numbers and tries to get messages with nonexistent numbers (RECV 168). This results in an error and the whole download is aborted. In my case, no new emails are downloaded even though there are some (and Mozilla reports the correct count in the status bar). Expected Results: 1. Either honor the numbers provided by the server and fetch only these. 2. Or skip this message number, if it is possible to realize that exactly this problem happens. I am not sure this is a bug in Mozilla, but it won't hurt if it is prepared for this case. It may also be a problem on the server. Why didn't it delete the messages immediatelly? This problem will probably disappear as soon as they flush the marked messages on the server.

There is one message on the server but marked for deletion. The server offers no usable UIDs or message numbers to download. But Mozilla still tries to download message 1.

This could also be marked major or critical, I am unable to download any emails from the server now. Interestlingly, Mailnews now pops up a dialog saying about the problem: that the RETR didn't succed because the message is marked for deletion. If mozilla cannot resolve this case automatically, the easiest solution would be to ask the user in this same dialog. "Do you want to skip this message and try the next?" Skip | Skip all(for which RETR fails) | Try again | Cancel download It is also possible that this behaviour of the server (not deleting the messages immediatelly) is correct. I had to kill my dialup connection while retrieving messages from this server. Since then, this problem appeared. Maybe the server still thinks that the (now interrupted) connection to it is open, and will purge the messages only when it is closed. Or times out after several days.

There's something wrong with the server. Messages marked for deletion have to be deleted in the update state (QUIT sent by the client). If they're not deleted, they must be listed next time connecting again. To this the second log shows a schizophrenic side of the server. As RFC 1939 for the STAT command says "Note that messages marked as deleted are not counted in either total.". It's nevertheless a bug in Mozilla, I agree. But it's also nevertheless a dupe. *** This bug has been marked as a duplicate of 226669 ***

Yeah, that's the ugly thing with searching the same problem in 2 products in Bugzilla :)