User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 POP3 Download (leave msgs on server) + Disk full = Re-download of all email due to lost/forgotten UIDL's. If your POP3 is configured to "leave msgs on server" and you experience a "Disk full" condition (to the $HOME/.Mozilla file system) during POP3 download. Once you clear the "Disk full" condition the next download results in all emails being retrieve again. 1) Can the updating of the UIDL's and/or Message-Id's history be made more robust, I guess there is a file updating going on which also gets disk full condition and it renamed/moves a truncated file (zapping the previous UIDL history). 2) Can Mozilla support Message-Id de-duplication (in addition to POP3 server UIDL support). Think of UIDL being server side support and optimization to reduce the amount of data to be downloaded. But the real de-duplication system should be based on Message-Id uniqueness of Mozilla's recent history and currently stored email. Since I am guessing by the way Mozilla is behaving it does not do this already and since it would be a change to how things are right now then some control on it maybe needed hence point 3 below. 3) Wishlist item: The Account Manager dialog might need a pane to perform admin functions in respect of UIDL/Message-Id history. For example enabling/disabling UIDL usage, enable/disabling Message-Id de-duplication. A function to zap/clear the UIDL history. With all these options there should be no reason a Mozilla user with a badly performing POP3 server of badly performing mail server which are repeating UIDL/Message-ID will not be able to configure up some workaround. This would make support on this issue a non-issue for the Mozilla team. 4) Wishlist item: A mailbox function which would perform a de-duplication (or even just marking/flagging) of messages based on duplication of Message-ID. The candidate for flagging is selected by sorting all those with the same Message-ID based on oldest time into mailbox being 1st, then on read/unread status with read mail being 1st and the marking/flagging will mark the 2nd to Nth duplicate, leaving the 1st unmarked. This 3rd/4th items are more a wish list than a requirement to for fill the problem this bug reports on. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Graceful handling of Disk full, by not causing a download of ALL email again at the next POP3 poll.