------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127696         
mcmanus ducksong com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcmanus ducksong com



------- Additional Comments From mcmanus ducksong com  2008-01-16 22:51 -------
The issue here is error handling when receiving a blank uid prortion of a UIDL 
response.. for instance:

1 1200413730.1[CRLF]
2 [CRLF]
3 1200414111.3[CRLF]
. [CRLF] 

will trigger it. John's debug data from the original bug description shows this 
nicely.

it seems some pop server will generate a bogus uidl response like the above 
based on the email containing an invalid message-id header. 

I only tested with Dovecot, and could not reproduce that behavior, but forcing 
the protocol trace with netcat using the above sequence did create a 
reproduction.

If any of the reporters could identify the pop server that is doing that, we 
could potentially file a bug against the server which is really the root cause 
here too.

In any event, without a valid UIDL identifier the message cannot be persisted 
on the server - otherwise, everytime a LIST operation occurred there would be 
no way to know whether or not there was a local copy of this message and we 
would keep downloading it over and over again.

The attached patch 

 * separates error handling for LIST and UIDL operations (removing the 
confusing error dialog here that casts doubt on LIST un-necessarily)
 * takes UIDL lines with an ID but without a valid UID portion and forces a 
download of those messages and a delete from the server
 * logs a debug message when it is doing this
_______________________________________________
Kdepim-bugs mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kdepim-bugs

Reply via email to