6.0.0-git
2019-03-18

[#11946] No headers when viewing unread message
Summary No headers when viewing unread message
Queue IMP
Queue Version 6.0.3
Type Bug
State Not A Bug
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester azurit (at) pobox (dot) sk
Created 2013-01-10 (2258 days ago)
Due
Updated 2013-01-22 (2246 days ago)
Assigned 2013-01-21 (2247 days ago)
Resolved 2013-01-21 (2247 days ago)
Milestone
Patch No

History
2013-01-22 08:10:49 azurit (at) pobox (dot) sk Comment #24 Reply to this comment
FYI: i contacted the Courier IMAP author and here is his response:
http://sourceforge.net/mailarchive/message.php?msg_id=30382228
2013-01-21 22:15:22 azurit (at) pobox (dot) sk Comment #23 Reply to this comment
i'm very sorry, problem is fixed! thank you again
2013-01-21 22:14:12 azurit (at) pobox (dot) sk Comment #22 Reply to this comment
I tried to apply the patch on my installation and it looks like it 
didn't resolve the problem - headers are still not displayed :(
2013-01-21 22:00:57 azurit (at) pobox (dot) sk Comment #21 Reply to this comment
thank you!
2013-01-21 21:58:23 Git Commit Comment #20 Reply to this comment
Changes have been made in Git (master):

commit c249bac9500df86d05e5789c53a38dde9dd2da4c
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Jan 21 14:57:01 2013 -0700

     [mms] Ignore fetch data returned from an UID FETCH command if it 
doesn't include UID information (Bug #11946).

  .../Imap_Client/lib/Horde/Imap/Client/Socket.php   |   12 +++++++++++-
  framework/Imap_Client/package.xml                  |    2 ++
  2 files changed, 13 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/c249bac9500df86d05e5789c53a38dde9dd2da4c
2013-01-21 21:58:11 Michael Slusarz Comment #19 Reply to this comment
Although not a bug... I have tweaked Imap_Client to ignore this kind 
of broken data (UID fetch results that do not contain UID information).
2013-01-21 21:31:22 Michael Slusarz State ⇒ Not A Bug
 
2013-01-21 20:49:51 azurit (at) pobox (dot) sk Comment #18 Reply to this comment
I provided software name and version in comment #13:
Courier IMAP version 4.8.0-3 (Debian 6.0.6)
2013-01-21 20:48:15 Michael Slusarz Comment #17 Reply to this comment
isn't the command on the very first line of both files?

C: 7 UID FETCH 9 (BODY[HEADER])
Yes... my mistake.  Copy/paste error.

So now it is verified - your IMAP server is badly broken.  It is 
explicitly breaking the IMAP RFC spec.  I don't see any need to 
workaround this, because it is blatantly broken (you haven't provided 
your software/version).
2013-01-21 20:03:43 azurit (at) pobox (dot) sk Comment #16 Reply to this comment
isn't the command on the very first line of both files?

C: 7 UID FETCH 9 (BODY[HEADER])

2013-01-21 19:58:07 Michael Slusarz Comment #15
Assigned to Michael Slusarz
State ⇒ Assigned
Reply to this comment
Ahh... this is a broken IMAP response.  You did not provide the entire 
IMAP log but I am guessing that this response:

S: * 1 FETCH (UID 9 BODY[HEADER] {1409}
S: <<<FULL HEADERS>>>
S: )
S: * 1 FETCH (FLAGS (\Seen))

Was caused by this command:

a UID FETCH 9 (BODY[HEADER])

A correct response would look like:

S: * 1 FETCH (UID 9 BODY[HEADER] {1409}
S: <<<FULL HEADERS>>>
S: ) FLAGS (\Seen))

--or--

S: * 1 FETCH (UID 9 BODY[HEADER] {1409}
S: <<<FULL HEADERS>>>
S: )
S: * 1 FETCH (UID 9 FLAGS (\Seen))

So the problem is that we are asking for UID fetch results, but the 
server is throwing in some sequence-only results instead.  And this is 
not allowed if, in fact, this is called from a UID FETCH command.   
From RFC 3501 [6.8]:

       However, server implementations MUST implicitly
       include the UID message data item as part of any FETCH response
       caused by a UID command, regardless of whether a UID was specified
       as a message data item to the FETCH.

Can you verify the command that caused these responses and the IMAP 
software version used?
2013-01-18 15:42:03 azurit (at) pobox (dot) sk Comment #14 Reply to this comment
What other feedback do you need? I already uploaded raw IMAP 
communication yesterday. Thnks.
2013-01-18 15:39:29 Michael Rubinsky State ⇒ Feedback
 
2013-01-17 09:29:25 azurit (at) pobox (dot) sk New Attachment: ok.log Download
 
2013-01-17 09:29:05 azurit (at) pobox (dot) sk New Attachment: error.log Download
 
2013-01-17 09:28:18 azurit (at) pobox (dot) sk Comment #13 Reply to this comment
Attaching two files (headers are censored):

error.log
-----------
Part of IMAP communication when no headers are displayed



ok.log
--------
Part of IMAP communication where everything is ok.



As you can see, additional line 'S: * 1 FETCH (FLAGS (\Seen))' is in 
error.log. I'm using Courier IMAP version 4.8.0-3 (Debian 6.0.6).

2013-01-17 07:09:53 Michael Slusarz Comment #12 Reply to this comment
I believe that problem is doing the second 
'Horde_Imap_Client_Data_Fetch Object' right after the section with 
headers. IMP is probably considering it as a section with headers 
and, cos it's empty, is displaying no headers.
Except I (nor anybody else) can reproduce this.  Sounds like a 
potentially broken IMAP server.  You will need to post the IMAP logs 
of a successful view vs. an unsuccesful view.



To further debug this issue, we need details of the IMP -> IMAP/POP 
communication.

To enable debugging, see instructions contained in 
imp/config/backends.php (the 'debug' config parameter).

Debugging should not be enabled on a production server,   Attach/post 
only the portion of the log that directly deals with the problem 
reported (it may be simplest to clear the log file and then perform 
the event that causes the error).
2013-01-14 13:47:48 azurit (at) pobox (dot) sk Comment #11 Reply to this comment
I believe that problem is doing the second 
'Horde_Imap_Client_Data_Fetch Object' right after the section with 
headers. IMP is probably considering it as a section with headers and, 
cos it's empty, is displaying no headers.
2013-01-14 13:45:38 azurit (at) pobox (dot) sk New Attachment: unseen-message-missing-headers.txt Download
 
2013-01-14 13:45:17 azurit (at) pobox (dot) sk New Attachment: seen-message-headers-ok.txt Download
 
2013-01-14 13:44:37 azurit (at) pobox (dot) sk Comment #10 Reply to this comment
I found out that function _getHeader (from imp/lib/Contents.php) is 
returning empty headers when parameter $seen is true and when opening 
unseen message. I'm attaching two files (i censored headers and 
message text from both of them), it is the output from file 
Imap/Client/Base.php function fetch():

seen-message-headers-ok.txt
---
Already seen message, headers were displayed ok.



unseen-message-missing-headers.txt
---
Unseen message, all headers were missing as i describe the problem earlier.

2013-01-14 03:49:54 Michael Slusarz Comment #9 Reply to this comment
I noticed that also Bacis view is, partially, affected by this. When 
opening _unred_ message, no subject is displayed.
Can't reproduce this either.
2013-01-14 03:49:32 Michael Slusarz Comment #8 Reply to this comment
Any suggestions how?
You need to trace the code locally and determine *why/where* the 
header data is becoming invalid on your system.
2013-01-11 09:21:03 azurit (at) pobox (dot) sk Comment #7 Reply to this comment
I noticed that also Bacis view is, partially, affected by this. When 
opening _unred_ message, no subject is displayed.
2013-01-10 21:48:56 azurit (at) pobox (dot) sk Comment #6 Reply to this comment
I also tried to completely remove my 'prefs.local.php' so it's not 
related to my configuration.
2013-01-10 21:08:25 azurit (at) pobox (dot) sk Comment #5 Reply to this comment
Any suggestions how? I'm able to reproduce this on two separated 
servers (but they have almost the same SW). I tried Firefox 18 and 
Chrome 24. Will it help if i create you an account so you can see it 
by yourself?
2013-01-10 21:02:58 Michael Slusarz Comment #4 Reply to this comment
You need to debug locally then.
2013-01-10 20:54:05 azurit (at) pobox (dot) sk Comment #3
New Attachment: no_headers.jpg Download
Reply to this comment
Do the following:
  - login into dynamic view
  - click (at the right) Other - Hide preview
  - send yourself a new email
  - double click on new email
See attachment. Everything is showing ok after reload or when 
displaying already read message. Always reproduceable for me.
2013-01-10 20:44:20 Michael Slusarz Comment #2 Reply to this comment
Can't reproduce.
2013-01-10 18:01:54 azurit (at) pobox (dot) sk Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ No headers when viewing unread message
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
Reply to this comment
When using dynamic view with _disabled_ preview of message, try to 
open any _new_ and _unread_ message (double click on it). There will 
be no headers displayed (no subject, no sender etc.).

Saved Queries