On 10/21/2013 02:02 AM, Neil wrote: > NoOp wrote: > >>On 09/30/2013 01:21 AM, Neil wrote: >> >> >>>NoOp wrote: >>> >>>>The POP3 mail server (pop.att.yahoo.com) does not support UIDL or XTND >>>>XLST, which are required to implement the ``Leave 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. >>>> >>>>This typically happens if I've left the browser open for some time (over 24 >>>>hours). Email does not get downloaded until reset. If I close and restart >>>>SeaMonkey the problem goes away. >>>> >>>Might it be worth creating a POP3 protocol log? >>>https://wiki.mozilla.org/MailNews:Logging >>> >>Happened again today. Log is located at: >> >><http://pastebin.com/JB93S115> >> >> > That's weird. I split the log into its two halves and removed irrelevant > data (i.e. fetching of the actual messages, sequence numbers, etc.) The > one remaining difference was as follows: > 1738831680[7f2b66742480]: POP auth: server caps 0x21CB2, pref 0x1C00, > failed 0x0, avail caps 0x1C00 > 1738831680[7f2b66742480]: POP auth: server caps 0x21C82, pref 0x1C00, > failed 0x0, avail caps 0x1C00 > > The server caps are flags that list all of the supported functions, as > follows: > 0x00002: Don't know whether server supports GURL > 0x00010: Server supports UIDL > 0x00020: Don't know whether server supports XTND XLST > 0x00080: Don't know whether server supports TOP > 0x00400: Server supports USER > 0x00800: Server supports AUTH LOGIN > 0x01000: Server supports AUTH PLAIN > 0x20000: Server supports RESP CODES > > So in the failing case, the code failed to find UIDL or XTND XLST, which > is why it threw up the dialog, but in the successful case, the code > found UIDL and didn't bother with XTND XLST. > > Interestingly the code doesn't use the CAPA response to detect UIDL, > instead it assumes UIDL is available until a UIDL command fails, in > which case it assumes that it's unavailable. (There is a flag for UIDL > unknown but it is treated the same way as if it is available.) By my > reading of the code this can happen in one of two ways: 1) Connection > failure 2) Response to UIDL not starting with a +. I don't see either of > those in the log, so I'm at a loss to explain what happened there. Sorry > about that. >
Thanks for taking the time to have a look Neil. I still have it in the same state & will leave it like that for a few more hours. I have 3 other pop3 accounts that use the same pop servers & they aren't having issues. I've logged onto the account via the web interface and I can see two unread messages; 1 is a valid msg from VMware & the other is an obvious spam ("AT%T Security Center"). I moved both msg's to different folders one at a time & after the move tried to fetch mail from SeaMonkey - same results. Also backed up the mail folder s(o I can review later if necessary) & tried 'repair', deleting all of the msf files, & popstate.dat - no change. Not sure where else to look. _______________________________________________ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey