Discussion:
Does not support UIDL or XTND XLST
NoOp
2013-09-13 21:49:50 UTC
Permalink
Following the 2.20 upgrade I am receiving (again)* the following when
attempting to fetch mail:

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.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101
Firefox/23.0 SeaMonkey/2.20

Also has occured on another users Windows system (SeaMonkey 2.20).

Anyone else seeing he same/similar?

* I say 'again' as this also happened back in 2010:
<http://www.mail-archive.com/support-seamonkey-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org/msg18466.html>

Followups set to mozilla.dev.apps.seamonkey
NoOp
2013-09-13 21:59:40 UTC
Permalink
Post by NoOp
Following the 2.20 upgrade I am receiving (again)* the following when
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.
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101
Firefox/23.0 SeaMonkey/2.20
Also has occured on another users Windows system (SeaMonkey 2.20).
Anyone else seeing he same/similar?
Followups set to mozilla.dev.apps.seamonkey
Sorry for the followup to my own msg. I forgot to add that the issue
still exists even if I change the POP3 server:

The POP3 mail server (inbound.att.net) 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.

And generally only happens on one account at at time (I have multiple
POP3 accounts).
Neil
2013-09-30 08:21:33 UTC
Permalink
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
--
Warning: May contain traces of nuts.
NoOp
2013-10-01 00:38:05 UTC
Permalink
Post by Neil
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
Thanks & a good idea. I always tend to forget that the script is running
& then the log balloons to a huge file that I forget until I get low on
disk space. So... I modified Joshua Cranmer's addon to use so that I can
turn logging on/off without having to start/restart SM:

<https://bugzilla.mozilla.org/show_bug.cgi?id=193873#c17> &
<https://wiki.mozilla.org/Thunderbird:Logging_UI>
Post by Neil
<!-- SeaMonkey -->
<em:targetApplication>
<Description>
<em:id>{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}</em:id>
<em:minVersion>2.0</em:minVersion>
<em:maxVersion>2.22</em:maxVersion>
</Description>
</em:targetApplication>
<em:targetApplication>
<Description>
So far it's working just fine. The only issue is it doesn't have filters
and timestamp; but still much nicer than running my old script.
NoOp
2013-10-21 00:17:48 UTC
Permalink
Post by Neil
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>
Neil
2013-10-21 09:02:05 UTC
Permalink
Post by NoOp
Post by Neil
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
<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.
--
Warning: May contain traces of nuts.
NoOp
2013-10-21 16:39:54 UTC
Permalink
Post by Neil
Post by NoOp
Post by Neil
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
<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
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
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.
Neil
2013-10-22 08:56:39 UTC
Permalink
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.
What you can try is a complete hack to reset the server's flags. Note:
this procedure does not work if you are using the Global Inbox.

1. Select the failing account or one of its folders
2. Open the Error Console from the mail window
3. Evaluate the following text
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags
|= 0x30;
--
Warning: May contain traces of nuts.
NoOp
2013-10-22 14:34:38 UTC
Permalink
Post by Neil
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.
this procedure does not work if you are using the Global Inbox.
1. Select the failing account or one of its folders
2. Open the Error Console from the mail window
3. Evaluate the following text
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags
|= 0x30;
Thanks. I'll give that a go when it happens again. I had to restart
SeaMonkey for other reasons so the issue has cleared for now.
NoOp
2013-11-14 23:37:32 UTC
Permalink
Post by Neil
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.
this procedure does not work if you are using the Global Inbox.
1. Select the failing account or one of its folders
2. Open the Error Console from the mail window
3. Evaluate the following text
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags
|= 0x30;
Neil,

Finally caught the error & copy & pasted the above into the error
console & clicked 'Evaluate' Got this response:
Timestamp: 11/14/2013 03:32:42 PM
Error: TypeError:
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer is undefined
Source File:
javascript:%20top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags%20%20%20%20%20%20%20|=%200x30;
Line: 1
Hartmut Figge
2013-11-15 06:12:47 UTC
Permalink
Post by NoOp
Post by Neil
this procedure does not work if you are using the Global Inbox.
1. Select the failing account or one of its folders
2. Open the Error Console from the mail window
3. Evaluate the following text
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags
|= 0x30;
Neil,
Finally caught the error & copy & pasted the above into the error
Timestamp: 11/14/2013 03:32:42 PM
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer is undefined
javascript:%20top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags%20%20%20%20%20%20%20|=%200x30;
Line: 1
I do not have the problem you described in the OP, but i tried the
proposal of Neil nevertheless when i saw the error you got in the
console. Curiosity. :) First i got the same error. Then i realized, i
had not followed exactly the instructions. Step 1 and 2 are important.

And now i get 394426 as reaction.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/2013111506
SeaMonkey/2.25a1-h

Hartmut
Neil
2013-11-15 09:56:29 UTC
Permalink
Post by NoOp
Timestamp: 11/14/2013 03:32:42 PM
Error: TypeError: top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer is undefined
Source File: javascript: top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags |= 0x30;
Line: 1
What does top.opener.msgWindow.openFolder.server.type say?
--
Warning: May contain traces of nuts.
NoOp
2013-11-15 17:43:44 UTC
Permalink
Post by Neil
Post by NoOp
Timestamp: 11/14/2013 03:32:42 PM
Error: TypeError: top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer is undefined
Source File: javascript: top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags |= 0x30;
Line: 1
What does top.opener.msgWindow.openFolder.server.type say?
Arggh! Sorry, I accidentally closed SM from the error console
(File|Quit) & had to restart. I'll need to wait until the next occurance.

FWIW the above (now) shows nothing.

Also, with the failed account working again and
<top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags
|= 0x30;> I get:

When account 'inbox' selected:
(information) 138418

When account only is selected:
(error) Timestamp: 11/15/2013 09:37:34 AM
Error: TypeError: top.opener.msgWindow.openFolder is null
Source File:
javascript:%20top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags%20%20%20%20%20%20%20|=%200x30;
Line: 1
Neil
2013-11-15 20:51:05 UTC
Permalink
Post by Neil
What does top.opener.msgWindow.openFolder.server.type say?
Arggh! Sorry, I accidentally closed SM from the error console (File|Quit) & had to restart. I'll need to wait until the next occurance.
FWIW the above (now) shows nothing.
Odd; all servers should have a type.
(information) 138418
Not very useful when it's working, sorry. (I'm too lazy to read the
thread all over again to work out whether the value is ever useful,
either with or without the |= 0x30.)
Error: TypeError: top.opener.msgWindow.openFolder is null
Oops, my bad, I forgot that there's no open folder in that case.
--
Warning: May contain traces of nuts.
NoOp
2014-01-11 03:00:34 UTC
Permalink
Post by Neil
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.
this procedure does not work if you are using the Global Inbox.
1. Select the failing account or one of its folders
2. Open the Error Console from the mail window
3. Evaluate the following text
top.opener.msgWindow.openFolder.server.nsIPop3IncomingServer.pop3CapabilityFlags
|= 0x30;
Neil,

Just to confirm: this happened again today & the 'hack' (number 3) does
work for me. It clears the issue & the held emails are immediately
downloaded.

Is there a way to script this so that I only have to click an
icon/button? Would be helpful for both linux & windows (my brother has
the same issue on his windows xp system).

Gary
Neil
2014-01-11 16:58:36 UTC
Permalink
Is there a way to script this so that I only have to click an icon/button? Would be helpful for both linux & windows (my brother has the same issue on his windows xp system).
I believe you can use the Custom Buttons extension to achieve this.
(Note that you should remove the 'top.opener.' prefix from the code if
you run it as a custom button.)
--
Warning: May contain traces of nuts.
Loading...