View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001425||SOGo||Backend Mail||public||2011-08-19 14:52||2011-10-14 17:49|
|Reporter||Christian Mack||Assigned To|
|Target Version||1.3.9||Fixed in Version||1.3.9|
|Summary||0001425: Email is displayed with incorrect subject "Untitled" and body "untitled(0)"|
On reading emails via SOGo web interface you sometimes open one and only see a subject of "Untitled" and a body consisting of one attachment called "untitled(0)" see screenshot.
In the folder list the corresponding email is listed correctly with its subject, from and date.
So I assume this is an backend problem.
But sometimes this persists for several hours.
|Steps To Reproduce|
Just jump from one email to the next, till you get this failure.
This is valid for all browsers I testet Firefox (4 + 5 + 6), IE (8 + 9), Safari (Snow leopard)
|Tags||No tags attached.|
untitled(0).png (154,426 bytes)
untitled(0).png (154,426 bytes)
I've also had this problem numerous times over the past few weeks. I've had it with Safari, but I don't recall having had it with Firefox.
It seems that the array of MessageUids gets corrupted, it requests message numbers which do not exist - at least this is one cause of displaying "untitled(0)" we had.
I've got the same problem with Chromium/Firefox.
I've had a hard time reproducing that issue.
Is it easy for you guys? If so, please produce TWO tcpflow when that happens:
1- first on the IMAP port, removing any sensitive info
Use tcpflow -i ethX -c tcp and port 143 > imap.log
tcpflow -i ethX -c tcp and port 80 > http.log
Ajust accordingly. If you can also LIMIT the traffic to only yours, it would be nice.
I think I have found the cause.... Je crois que j'ai enfin trouvé le coupable!
It seems that idled gets confused sometimes and sends idle messages to a process which has the same process id as the one which sent the idle request to idled originally. imapd processes are started with "U 50" so that they shut down and restart after 50 requests to prevent memory leaks which was a problem in early SASL2 days. This is no more necessary so stopping the U 50 should minimize this error.
The tcp dump got the following:_
9 uid fetch 75295 (FLAGS ENVELOPE BODYSTRUCTURE RFC822.SIZE RFC822.HEADER)
SOGo seems not to expect the erroneous idle messages (that the state of the mailbox changed) before the FLAGS answer.
Tonight we'll restart our Cyrus to watch the issue....
Our SOGo webmail is over HTTPS so using tcpflow isn't relevant.
I've use tcpflow on our SOGo server for the IMAP trafic.
The problem could be beetween the web browser and SOGo ?
Orchal: You can follow the flow on Interface lo to port 20000 of the SOGo service (if httpd and sogod run on the same host).
gienger, can you identify in your sogod.log file the request that is the 'culprit'?
Thank you Gienger. I don't see anything for the moment except :
<?xml version="1.0" encoding="ISO-8859-1"?>
I'm not sure that's the problem.
I think Gienger is more on the right way. It seems that this bug has appeared since I use CAS for authentication.
Oct 14 12:00:08 sogod : [ERROR] <0x0xe488750[UIxMailRenderingContext]> found no viewer for MIME type: (null)/(null)
I am sure he gets confused by
because he expects
as reaction to the uid fetch command.
As i said this is due to the idled daemon getting confused by too many reused process ids (signalling the wrong processes to reread changes and print them out).
I'll keep an eye on the (null)/(null) errors and their frequency of appearence after having restarted our cyrus tonight.
Let me look at the code for the "POST /SOGo/so/pop15959/Mail//0/folderINBOX/75295/view?noframe=1 HTTP/1.0" request.
It likely does NOT expect untagged responses that it hasn't asked for - which is wrong. Can you try a patch if I produce one?
Sure, this is SOGo 2.0.0 beta which I used for the test because the same error with the same result does appeaar there.
And: it is a bug from Cyrus IMAP due to an overloaded idled.
Wrong patch, this one is ok:
--- SoObjects/Mailer/SOGoMailObject.m dce1acbc5faa515575bd7594aef4bd27df037ff1
Fixed with: http://mtn.inverse.ca/revision/diff/5be507aec21eb7c99a5024135035b80901450a40/with/d85ac88023025021e4352537636d2fc8a8d43667
|2011-08-19 14:52||Christian Mack||New Issue|
|2011-08-19 14:53||Christian Mack||File Added: untitled(0).png|
|2011-08-21 23:17||ludovic||Note Added: 0002815|
|2011-08-22 10:36||gienger||Note Added: 0002817|
|2011-10-05 14:16||ludovic||Target Version||=> 1.3.9|
|2011-10-07 08:23||Orchal||Note Added: 0002874|
|2011-10-13 18:19||ludovic||Note Added: 0002891|
|2011-10-14 10:24||gienger||Note Added: 0002895|
|2011-10-14 12:22||Orchal||Note Added: 0002896|
|2011-10-14 12:27||gienger||Note Added: 0002897|
|2011-10-14 12:32||ludovic||Note Added: 0002898|
|2011-10-14 13:17||Orchal||Note Added: 0002899|
|2011-10-14 13:25||gienger||Note Added: 0002900|
|2011-10-14 13:27||gienger||Note Added: 0002901|
|2011-10-14 13:34||ludovic||Note Added: 0002902|
|2011-10-14 13:36||gienger||Note Added: 0002903|
|2011-10-14 13:36||gienger||Note Edited: 0002903|
|2011-10-14 13:55||ludovic||Note Added: 0002905|
|2011-10-14 17:49||ludovic||Note Added: 0002910|
|2011-10-14 17:49||ludovic||Status||new => closed|
|2011-10-14 17:49||ludovic||Resolution||open => fixed|
|2011-10-14 17:49||ludovic||Fixed in Version||=> 1.3.9|