leave messages on the server problem (Version 0.9.8 of GNU pop3d shipped on 30 Jan 2001 doesn't support UIDL & XTND XLST Message-Id)
Categories
(MailNews Core :: Networking: POP, defect)
Tracking
(Not tracked)
People
(Reporter: trkpower, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [223 Migration])
Attachments
(1 file)
|
2.72 KB,
text/plain
|
Details |
Comment 1•16 years ago
|
||
| Reporter | ||
Comment 2•16 years ago
|
||
| Reporter | ||
Comment 3•16 years ago
|
||
Updated•16 years ago
|
Comment 4•16 years ago
|
||
Updated•16 years ago
|
| Reporter | ||
Comment 5•16 years ago
|
||
Comment 6•5 years ago
|
||
(In reply to WADA:World Anti-bad-Duping Agency from comment #4)
(CAPA response)
SEND: CAPA
RECV: +OK Capability list follows
RECV: TOP
RECV: USER
RECV: RESP-CODES
(UIL, XTND XLST Message-Id are not supported by your server)
SEND: UIDL
RECV: -ERR Not implemented
SEND: XTND XLST Message-Id
RECV: -ERR Invalid commandFollow next message, please.
The POP3 mail server (mail.xxx.com) does not support UIDL or XTND XLST,
which are required to implement theLeave on Server'',Maximum Message Size'' or ``Fetch Headers Only'' options.
To download your mail, turn off these options in the Server Settings
for your mail server in the Account Settings window."I guess next;
Tb2 or older wrongly implemented "Leave Messages on Server",
a. after RETR of a mail, don't issue DELE for the mail
b. when a mail is deleted by user, issue DELE for the mail upon next
download
even if UIDL / XTND XLST Message-Id is not supported by server,
(correct implementation of "Leave Messages on Server" is impossible.)
based on wrong user requests.
It caused mail loss after mail box reorganization by POP3 server.
So, Tb3 stopped the wrong implementation, and issues the error message.
Any reason to believe this still exists?
Comment 7•5 years ago
|
||
I think this may still be an issue. It was last discussed on support forum on 3-2020. It seems to now be mostly confined to yahoo pop users due to "temporary" errors produced by the yahoo server. The reporter on the support forum provided what seems like a reasonable explanation as to the reason for the problem here: https://support.mozilla.org/en-US/questions/1268468?page=3#answer-1294494
I haven't verified all his assertion but I think he is saying the the server puts out a capability response indicating that UIDL is not supported. Servers that don't support this will delete messages fetched from the server so tb latches off any fetches of messages from the server (to avoid data loss) so users can't get mail. Tb never check again until it is restarted and then when the server reports support of UIDL, the mail can be fetched.
This seems like a real problem but Matt and Toad-Hall contend it is only a yahoo and yahoo-like (AOL, Verizon, etc) problem.
After a bit more digging I found a tb bug report with a patch for the problem here: Bug 1577548.
I think the current bug here is maybe a duplicate of Bug 1577548. The problem reported here was actually a constant server bug that I think has been fixed in gnu pop3 server per release notes, so the effect was constant and not transient like in Bug 1577548. So I'll just close this as INVALID since the server was the cause and just reference Bug 1577548 as a related bug.
Description
•