------- 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