Hi,
I've got a tricky roundcube problem. It seems related specifically to our communigate pro imap server. When clicking on reply, none of the header information that should be in a reply gets populated (subject, original email date, recipient).
I've noticed that this always happens when the preview pane is turned on, and only sometimes happens when the preview pane is off.
I've been using roundcube elsewhere for quite some time with a courier imap server, and don't have the same problems.
I've looked at compose.inc, rcube_imap.inc and imap.inc, however, I am struggling to find out the cause of this problem.
Any ideas of what to look for would be appricated. I am a php developer, so happy to hunt around in the code, just struggling to get my head around what is supposed to happen. Running rev 912 from svn.
If I set $rcmail_config['enable_caching'] = FALSE;
Then this problem occurs all of the time.
I've done a tcpdump of the traffic between roundcube and the imap server. Something that I don't quite understand is why the appears to be 2 imap queries.
What I see is: fh0 UID FETCH 6095 (BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES)]) and then fh0 FETCH 927 (BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES)])
Not sure why it does this twice. Also, I noticed that it's trying to fetch "Reply-to" which is not returned from Imap. Any ideas.
TCP dump below:
- OK CommuniGate Pro IMAP Server 4.3.6 at oss.co.nz ready
cp01 CAPABILITY
- CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA ID
MULTIAPPEND LISTEXT CHILDREN BINARY LOGIN-REFERRALS STARTTLS AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=MSN cp01 OK completed a000 AUTHENTICATE CRAM-MD5 a000 OK completed ns1 NAMESPACE
- NAMESPACE (("" "/")) (("~" "/")) (("~public/" "/"))
ns1 OK completed sel1 SELECT "INBOX"
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent $Hidden)
- OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent
$Hidden)] limited
- 937 EXISTS
- 0 RECENT
- OK [UIDNEXT 6107] predicted next UID
- OK [UIDVALIDITY 278662535] UIDs valid
sel1 OK [READ-WRITE] SELECT completed fh0 UID FETCH 6095 (BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES)])
- 927 FETCH (BODY[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC
BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES)] {259} From: "Someone" <removed> To: gogilvie@oss.co.nz Subject: WR for meeting Date: Wed, 7 Nov 2007 11:35:19 +1300 Content-Type: text/plain; .charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: auto-000004410094@oss.co.nz
UID 6095) fh0 OK completed fh1 UID FETCH 6095 (UID RFC822.SIZE FLAGS INTERNALDATE)
- 927 FETCH (UID 6095 RFC822.SIZE 1576 FLAGS (\Seen) INTERNALDATE "06-Nov-2007
22:35:21 +0000") fh1 OK completed srch1 SEARCH UID 6095
- SEARCH 927
srch1 OK completed F1247 FETCH 927 (BODYSTRUCTURE)
- 927 FETCH (BODYSTRUCTURE ("text" "plain" ("charset" "us-ascii") NIL
NIL "7bit" 746 24 NIL NIL NIL NIL)) F1247 OK completed FUID FETCH 927 (UID)
- 927 FETCH (UID 6095)
FUID OK completed fh0 FETCH 927 (BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES)])
- 927 FETCH (BODY[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC
BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES)] {259} From: "Someone" <removed> To: gogilvie@oss.co.nz Subject: WR for meeting Date: Wed, 7 Nov 2007 11:35:19 +1300 Content-Type: text/plain; .charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: auto-000004410094@oss.co.nz
) fh0 OK completed fh1 FETCH 927 (UID RFC822.SIZE FLAGS INTERNALDATE)
- 927 FETCH (UID 6095 RFC822.SIZE 1576 FLAGS (\Seen) INTERNALDATE "06-Nov-2007
22:35:21 +0000") fh1 OK completed ftch FETCH 927 (BODY.PEEK[1])
- 927 FETCH (BODY[1] {746}
The WR for the meeting this morning: [cut]
) ftch OK completed I LOGOUT
- BYE CommuniGate Pro IMAP closing connection
I OK completed
Regards
Glen Ogilvie wrote:
Hi,
Hi Glen,
I've got a tricky roundcube problem. It seems related specifically to our communigate pro imap server. When clicking on reply, none of the header information that should be in a reply gets populated (subject, original email date, recipient).
This was already reported once but none of the devs was able to reporduce it. I hope we can get it fixed with your help now...
I've noticed that this always happens when the preview pane is turned on, and only sometimes happens when the preview pane is off.
Not sure if this has something to do with the preview pane.
I've been using roundcube elsewhere for quite some time with a courier imap server, and don't have the same problems.
We found out that it's related to a specific IMAP server and not a general problem.
I've looked at compose.inc, rcube_imap.inc and imap.inc, however, I am struggling to find out the cause of this problem.
compose.inc fetches the headers using $IMAP->get_headers($uid) which should work since this is used everywhere.
When looking at the code I found out that compose.inc also calls $IMAP->get_structure($uid) which then again calls $IMAP->get_headers() but with the message ID and not the UID. This explains why you see two FETCH requests, one with UID FETCH 6095 and another with FETCH 927.
However your IMAP server seems to accept the UID FETCH command and return the requested headers.
Any ideas of what to look for would be appricated. I am a php developer, so happy to hunt around in the code, just struggling to get my head around what is supposed to happen. Running rev 912 from svn.
If I set $rcmail_config['enable_caching'] = FALSE;
Then this problem occurs all of the time.
Hmm, this is strange...
I've done a tcpdump of the traffic between roundcube and the imap server. Something that I don't quite understand is why the appears to be 2 imap queries.
[...]
I've just committed (r913) some improvements to optimize the internal caching and to prevent unnecessary requests to the IMAP server. Not sure if this solves your problem but you should update your SVN checkout.
To track it down you can dump some vars in rcube_imap::get_headers() and rcube_imap::get_structure() in order to find out where those headers get lost when replying to a message.
Thanks so far! ~Thomas
List info: http://lists.roundcube.net/dev/
Hi Thomas,
After much interesting debugging, I've found the problem and fixed it.
Here is a patch, and a copy of the file with the patch applied. (merged with svn today)
The problem I've fixed was in the imap library. I am not sure if it's the imap server I have (Communigate Pro) not implementing imap correctly, or if the library that is wrong.
If the IMAP fetch specification says that the termination of a fetch command is ) at the beginning of a new line, then this is a work around for imap servers that do not follow the spec. If however, the specification for IMAP is that ) is at the end of a line that does not contain a : in it, then this patch fixes the imap library.
I think this patch, being an addition of just 1 line and some comments is fairly trivial so should not risk breaking too much else.
I've written the comments as I suspect maybe other people will also be affected by this problem.
Regards Glen Ogilvie
On Thu, 08 Nov 2007 10:54:13 pm you wrote:
Glen Ogilvie wrote:
Hi,
Hi Glen,
I've got a tricky roundcube problem. It seems related specifically to our communigate pro imap server. When clicking on reply, none of the header information that should be in a reply gets populated (subject, original email date, recipient).
This was already reported once but none of the devs was able to reporduce it. I hope we can get it fixed with your help now...
I've noticed that this always happens when the preview pane is turned on, and only sometimes happens when the preview pane is off.
Not sure if this has something to do with the preview pane.
I've been using roundcube elsewhere for quite some time with a courier imap server, and don't have the same problems.
We found out that it's related to a specific IMAP server and not a general problem.
I've looked at compose.inc, rcube_imap.inc and imap.inc, however, I am struggling to find out the cause of this problem.
compose.inc fetches the headers using $IMAP->get_headers($uid) which should work since this is used everywhere.
When looking at the code I found out that compose.inc also calls $IMAP->get_structure($uid) which then again calls $IMAP->get_headers() but with the message ID and not the UID. This explains why you see two FETCH requests, one with UID FETCH 6095 and another with FETCH 927.
However your IMAP server seems to accept the UID FETCH command and return the requested headers.
Any ideas of what to look for would be appricated. I am a php developer, so happy to hunt around in the code, just struggling to get my head around what is supposed to happen. Running rev 912 from svn.
If I set $rcmail_config['enable_caching'] = FALSE; Then this problem occurs all of the time.
Hmm, this is strange...
I've done a tcpdump of the traffic between roundcube and the imap server. Something that I don't quite understand is why the appears to be 2 imap queries.
[...]
I've just committed (r913) some improvements to optimize the internal caching and to prevent unnecessary requests to the IMAP server. Not sure if this solves your problem but you should update your SVN checkout.
To track it down you can dump some vars in rcube_imap::get_headers() and rcube_imap::get_structure() in order to find out where those headers get lost when replying to a message.
Thanks so far! ~Thomas
After much interesting debugging, I've found the problem and fixed it.
...
Glen Ogilvie
Brilliant, thank you! I've been fighting this problem for 1+ month, I thought it was only a problem on my side as nobody on the list had seen it. FYI, I'm running BincIMAP which also seems to have the issue.
List info: http://lists.roundcube.net/dev/
-
Ethan Erchinger -
Glen Ogilvie -
Thomas Br?uederli