Messenger Express timeout reading from IMAP?
Recently, we started to see "httpd[11162]: General: Error reading from IMAP server: Timeout" on at least one email account when using Messenger Express. This seems to returned a message in the web browsers relating to the web server being unable to parse the results.
For this mailbox, it seems to be only the INBOX which has issues (a standard IMAP connection seems to work fine). The inbox has 18 messages and about 1.5M of data in it.
Thoughts on the cause?
benji
# 1
Hi,
Version (I assume 6.3 since it's talking IMAP, but which patch level)?
What changed 'recently' ?
Have you tried reconstructing the account (reconstruct -r -f user/<uid>)?
Are there any errors/log details on the IMAP end?
Have you tried enabling telemetry logging for the account?
Regards,
Shane.
# 2
Shane
Version (I assume 6.3 since it's talking IMAP, but which patch level)?
Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007) (base 6.3 install?)
What changed 'recently' ?
When this started. Nothing. About a month ago, an upgrade to 6.3 and arch change from Solaris to Linux
Have you tried reconstructing the account (reconstruct -r -f user/<uid>)?
that didn't seem to fix the problem. After some more playing, I am getting some really odd results. For example, saving off the mail box, removing it, then reconstructing it (so that the basic structure is recreated) still causes the problem :/ Could be an account issue?
Are there any errors/log details on the IMAP end?
Nothing on the IMAP end, though, logging is set to debug :
/
Have you tried enabling telemetry logging for the account?
hmmm...nope. looks like I need to investigate it (first time I have heard of it).
Thanks
Benji
# 3
telemetry logging is pretty nifty.
I did end up bouncing the IMAP servers (as it died?). The pop-up message now says "Login filed<new line>Timed out while waiting for the mail server response".
The HTTP session is using compression, so I didn't get real useful content from it. However, the IMAP Session is:
LOGIN <USERNAME> 2007/6/1 7:42:41
>0.000>A OK User logged in
<0.001<L LANGUAGE en
>0.000>* NAMESPACE (("" "/")) (("Shared Folders/User/" "/")) (("Shared Folders/Public/" "/"))
L OK Completed
<0.000<C COMPARATOR en;basic;uca=3.1.1;uv=3.2
>0.000>* COMPARATOR en;basic;uca=3.1.1;uv=3.2
C OK Completed
<0.383<F LIST "" "*"
>0.000>* LIST (\NoInferiors) "/" INBOX
* LIST (\HasNoChildren) "/" Drafts
* LIST (\HasNoChildren) "/" Sent
* LIST (\HasNoChildren) "/" Trash
F OK Completed
<0.001<G GETACL INBOX
S STATUS INBOX (MESSAGES UNSEEN SIZE)
G GETACL Drafts
S STATUS Drafts (MESSAGES UNSEEN SIZE)
G GETACL Sent
S STATUS Sent (MESSAGES UNSEEN SIZE)
G GETACL Trash
S STATUS Trash (MESSAGES UNSEEN SIZE)>
# 4
I won't claim I know this issue, but there is indeed a patch available for 6.3 that may help:
120228-20 for Solaris Sparc
fixes include:
6549459 Messenger Express unable to open attachments with single quote (') and hash (#) in filename
6509577 Messenger Express: possible Cross-Site Scripting vulnerability in errorHTML function
6520206 Bug 6284060 - Security issue with Sun ONE Messaging Server /Webmail and Internet Explorer
6546655 IE fails to display inline content when messages are stored in folders with double-byte characters
and lots more. . .
# 5
Hi,
Patching up to 120230-20 as per Jay's recommendation is a good start - if memory serves there is extra error logging for the mshttpd->imapd interface.
>> I did end up bouncing the IMAP servers (as it died?).
Did you get a core file? To get core files you may need to change the ulimit -S -c 0 command in /etc/profile to ulimit -S -c unlimited (this is for Redhat Linux AS 4.0 at least), then start a new terminal and login as root, verify that ulimit -S -c is now unlimited.
>> The pop-up message now says "Login filed<new line>Timed out while waiting for the
>> mail server response".
I assume that was 'Login failed".
So is this just for a single account or a number of accounts or all accounts?
What have you set the mailhost: value to for this user, does it match what other users have?
What does the imap logs show for the same time that you attempt to log in (set them to debug by running ./configutil -o logfile.imap.loglevel -v Debug; ./refresh imap)
Regards,
Shane.
# 6
120228-20 for Solaris Sparc -> thanks, I am on Linux, but, this does indicate that patches are out. I just need to find the Linux ones.
Did you get a core file: Not that I found. That would be helpful :/
was I supposed to type "Login failed" correctly? yeah, your assumption is correct.
At this point, I only know of a single account. That is what makes me think it is something specific with the account. I can't find anything odd with the LDAP record though.
The mailhost value does match everyone else (it was specifically re-written when I migrated in early May and I confirmed it since).
The imap logs are fairly useless (they are set at debug) for this. They show the user log in before the http/web browser error. The IMAP logs don't show anything else (except maybe a disconnect -- forgot that specific detail).
Thanks again
Benji
# 7
> 120228-20 for Solaris Sparc -> thanks, I am on Linux,
> but, this does indicate that patches are out. I just
> need to find the Linux ones.
"Patching up to 120230-20 as per Jay's recommendation is a good start"
-> 120230 should be the Linux version of the patch.
> Did you get a core file: Not that I found. That would
> be helpful :/
OK well your core file ulimit settings definitely need checking then.
> At this point, I only know of a single account. That
> is what makes me think it is something specific with
> the account. I can't find anything odd with the LDAP
> record though.
A definite mystery then...
> The imap logs are fairly useless (they are set at
> debug) for this. They show the user log in before the
> http/web browser error. The IMAP logs don't show
> anything else (except maybe a disconnect -- forgot
> that specific detail).
Interesting, another possibility is that perhaps the permissions on the IMAP folders are incorrect.
Try running:
./mboxutil -lxp user/<uid>/*
And verify the permissions.
Also if permissions are involved a "reconstruct -l" may help (that is the letter L and not the number one).
Regards,
Shane.
# 8
Shane...ummm...opps. The patch you listed wasn't the same as the one Jay listed :( I was blind.
The permission and ownership seems ok on the IMAP folders, though, I should confirm (learn) the IMAP ACL meanings.
Thank you for your help Shane. Seems as if I need Sun Support (and to apply the patch). Our support contract unknowingly lapsed and we are in the process of reinstating it. Waiting on some of the i's and t's to be completed.
Benji
