Hello Devs,
from time to time I receive Emails without a date header, f.e.:
Return-Path: you@your.tld Delivered-To: me@my.tld Received: from server2 ([xxxx]) by smtp.roland-liebl.de ; Fri, 16 Dec 2011 13:45:26 +0100 Message-ID: 000301ccbbf1$33935db0$6400a8c0@server2 From: "You" you@you.tld To: me@my.tld Subject: Fax empfangen von 0049xxxxxxxxx MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01CCBBF9.951F2980" X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
The mail is sorted in the messagelist to the appropriate position using the received header in case that "Sorting column" "None" is selected. If "Sorting Column" "Date" is selected the mail goes to the very bottom of the list. Is there a way to fix this in Roundcube or is it an issue of the IMAP-server backend (SORT)?
Regards, R.
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 12/17/2011 06:42 AM, Roland Liebl wrote:
Hello Devs,
from time to time I receive Emails without a date header, f.e.:
The mail is sorted in the messagelist to the appropriate position using the received header in case that "Sorting column" "None" is selected.
No, it doesn't use Received heasder. It uses message sequence id (or UID) then.
If "Sorting Column" "Date" is selected the mail goes to the very bottom of the list. Is there a way to fix this in Roundcube or is it an issue of the IMAP-server backend (SORT)?
What server it is? Does it support SORT? If so, it is the server issue. Server should use INTERNALDATE in case of non-existing Date header (RFC5256).
What server it is? Does it support SORT? If so, it is the server issue. Server should use INTERNALDATE in case of non-existing Date header (RFC5256).
It is hMailserver. SORT is supported. Here is the server response for the message without date header (complete log below):
61 FETCH (UID 30234 RFC822.SIZE 62927 FLAGS (\Seen) INTERNALDATE "16-Dec-2011 13:45:26 +0100" ...
So, the INTERNALDATE is returned to Roundcube.
Any other thoughts? FYI, Thunderbird sorting is ok.
Regards, R.
"IMAPD" 4305400 8233 "2011-12-18 05:57:17.670" "127.0.0.1" "RECEIVED: A0007 SORT (DATE) US-ASCII ALL" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: * SORT 61 26 24 23 45 41 40 38 30 13 12 11 10 9 8 7 6 5 4 3 2 1 14 15 16 17 18 20 19 21 22 25 27 28 29 32 31 33 34 35 36 39 37 42 43 44 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 62 63[nl]A0007 OK Search completed" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "RECEIVED: A0008 FETCH 61,26,24,23,45,41,40,38,30,13,12,11,10,9,8,7,6,5,4,3,2,1,14,15,16,17,18,20,19,21,22,25,27,28,29,32,31,33,34,35 (UID RFC822.SIZE FLAGS INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)])" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: * 61 FETCH (UID 30234 RFC822.SIZE 62927 FLAGS (\Seen) INTERNALDATE "16-Dec-2011 13:45:26 +0100" BODY[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)] {212}" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: )" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: * 26 FETCH (UID 29612 RFC822.SIZE 22749 FLAGS (\Seen) INTERNALDATE "24-Nov-2011 10:53:52 +0100" BODY[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)] {206}" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: )" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: * 24 FETCH (UID 29526 RFC822.SIZE 29561 FLAGS (\Seen) INTERNALDATE "22-Nov-2011 12:58:27 +0100" BODY[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)] {206}" "IMAPD" 4305400 8233 "2011-12-18 05:57:17.686" "127.0.0.1" "SENT: )"
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 12/18/2011 06:06 AM, Roland Liebl wrote:
61 FETCH (UID 30234 RFC822.SIZE 62927 FLAGS (\Seen) INTERNALDATE "16-Dec-2011 13:45:26 +0100" ...
So, the INTERNALDATE is returned to Roundcube.
We're using SORT not FETCH for sorting.
Any other thoughts? FYI, Thunderbird sorting is ok.
Maybe Thunderbird doesn't use SORT command.
Am 18.12.2011 11:48, schrieb A.L.E.C:
On 12/18/2011 06:06 AM, Roland Liebl wrote:
61 FETCH (UID 30234 RFC822.SIZE 62927 FLAGS (\Seen) INTERNALDATE "16-Dec-2011 13:45:26 +0100" ...
So, the INTERNALDATE is returned to Roundcube.
We're using SORT not FETCH for sorting.
Are you sure? Below a log generated by IMAP-Access of Roundcube.
The very first Request is SORT and then you FETCH the messages according to the order of the returned UIDs. The Order is wrong. The message with the missing date header is UID 26. It is the youngest message in this Mailbox and should be the very last in the row. Nethertheless hMailserver returns the correct Internaldate, so correct sorting should be possible.
Any other thoughts? FYI, Thunderbird sorting is ok.
Maybe Thunderbird doesn't use SORT command.
"IMAPD" 1535560 11860 "2011-12-19 06:18:30.584" "127.0.0.1" "SENT: * SORT 26 13 12 11 10 9 8 7 6 5 4 3 2 1 14 15 16 17 18 24 19 20 21 22 23 25[nl]A0007 OK Search completed" "IMAPD" 1535560 11860 "2011-12-19 06:18:30.600" "127.0.0.1" "RECEIVED: A0008 FETCH 26,13,12,11,10,9,8,7,6,5,4,3,2,1,14,15,16,17,18,24,19,20,21,22,23,25 (UID RFC822.SIZE FLAGS INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)])" "IMAPD" 1535560 11860 "2011-12-19 06:18:30.600" "127.0.0.1" "SENT: * 26 FETCH (UID 30295 RFC822.SIZE 62927 FLAGS (\Seen) INTERNALDATE "16-Dec-2011 13:45:26 +0100" BODY[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)] {212}" "IMAPD" 1535560 11860 "2011-12-19 06:18:30.600" "127.0.0.1" "SENT: )" "IMAPD" 1535560 11860 "2011-12-19 06:18:30.600" "127.0.0.1" "SENT: * 13 FETCH (UID 24689 RFC822.SIZE 3560 FLAGS (\Seen) INTERNALDATE " 6-Feb-2009 15:14:55 +0100" BODY[HEADER.FIELDS (DATE FROM TO SUBJECT CONTENT-TYPE CC REPLY-TO LIST-POST DISPOSITION-NOTIFICATION-TO CC USER-AGENT X-RC-ATTACHMENTCC X-RC-ATTACHMENT LIST-HELP LIST-SUBSCRIBE LIST-UNSUBSCRIBE LIST-POST LIST-OWNER LIST-ARCHIVE)] {218}" "IMAPD" 1535560 11860 "2011-12-19 06:18:30.600" "127.0.0.1" "SENT: )"
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 19.12.2011 06:26, Roland Liebl wrote:
Are you sure? Below a log generated by IMAP-Access of Roundcube.
The very first Request is SORT and then you FETCH the messages according to the order of the returned UIDs. The Order is wrong. The message with the missing date header is UID 26. It is the youngest message in this Mailbox and should be the very last in the row. Nethertheless hMailserver returns the correct Internaldate, so correct sorting should be possible.
- SORT 26 13 12 11 10 9 8 7 6 5 4 3 2 1 14 15 16 17 18 24 19 20 21 22 23
25
Are you saying that messages are displayed on the list in different order than SORT reponse here?
Am 19.12.2011 01:08, schrieb A.L.E.C:
On 19.12.2011 06:26, Roland Liebl wrote:
Are you sure? Below a log generated by IMAP-Access of Roundcube.
The very first Request is SORT and then you FETCH the messages according to the order of the returned UIDs. The Order is wrong. The message with the missing date header is UID 26. It is the youngest message in this Mailbox and should be the very last in the row. Nethertheless hMailserver returns the correct Internaldate, so correct sorting should be possible.
- SORT 26 13 12 11 10 9 8 7 6 5 4 3 2 1 14 15 16 17 18 24 19 20 21
22 23 25
Are you saying that messages are displayed on the list in different order than SORT reponse here?
No, I see it is a bug in hMailserver (http://www.hmailserver.com/forum/viewtopic.php?f=7&t=21744).
But what I tried to say is, that INTERNALDATE is returned ok. So you could sort on INTERNALDATE after FETCH and then display the stuff. It looks like don't have problems with wrong UID order (Thunderbird at least doesn't have this issue).
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 19.12.2011 08:16, Roland Liebl wrote:
Are you saying that messages are displayed on the list in different order than SORT reponse here?
No, I see it is a bug in hMailserver (http://www.hmailserver.com/forum/viewtopic.php?f=7&t=21744).
But what I tried to say is, that INTERNALDATE is returned ok. So you could sort on INTERNALDATE after FETCH and then display the stuff. It looks like don't have problems with wrong UID order (Thunderbird at least doesn't have this issue).
Then Thunderbird doesn't use SORT for sorting. Roundcube trusts in server responses. To re-sort messages we would need to fetch Date/INTERNAL date value for all messages in a folder which wouldn't be good for performance. This is exactly what we do when SORT is not supported by the server.
Then Thunderbird doesn't use SORT for sorting. Roundcube trusts in server responses. To re-sort messages we would need to fetch Date/INTERNAL date value for all messages in a folder which wouldn't be good for performance. This is exactly what we do when SORT is not supported by the server.
OK, but in this case there should be a config option not to use SORT even if server reports CAPABILITY SORT.
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 2011-12-19 7:50, Roland Liebl wrote:
Then Thunderbird doesn't use SORT for sorting. Roundcube trusts in server responses. To re-sort messages we would need to fetch Date/INTERNAL date value for all messages in a folder which wouldn't be good for performance. This is exactly what we do when SORT is not supported by the server.
OK, but in this case there should be a config option not to use SORT even if server reports CAPABILITY SORT.
IMO, if the server reports a SORT capability, it should be trusted and the SORT response should be used as it is provided by the server to Roundcube.
If the server doesn't know how what a SORT response is supposed to look like, or does it wrong somehow, it's the server that should be fixed, really.
Also, your server should allow you to suppress the SORT capability from it's CAPABILITY response, effectively causing a client (like Roundcube) not to use sort.
Kind regards,
Jeroen van Meeuwen
-
A.L.E.C -
Jeroen van Meeuwen (Kolab Systems) -
Roland Liebl