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
