After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 592057 - Headers missing, Date: header corrupt
Headers missing, Date: header corrupt
Status: RESOLVED FIXED
Product: evolution-mapi
Classification: Applications
Component: Mail
0.27.x
Other Linux
: Normal normal
: 0.28
Assigned To: Johnny Jacob
evolution-mapi-maint
evolution-mapi[oxcmail]
Depends on:
Blocks:
 
 
Reported: 2009-08-17 10:51 UTC by David Woodhouse
Modified: 2009-10-06 17:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use PR_TRANSPORT_MESSAGE_HEADERS (3.85 KB, patch)
2009-08-26 07:16 UTC, Johnny Jacob
committed Details | Review

Description David Woodhouse 2009-08-17 10:51:41 UTC
All messages in my Exchange folders seem to have their Date: header mangled -- the time zone is set to +0000 in all of them.

The correct information is visible in Outlook, if I ask it to show me the "Internet headers" of the email. In fact, those other headers _all_ seem to be absent from the mail in Evolution if I ask it to show all headers or hit Ctrl-U.
Comment 1 David Woodhouse 2009-08-17 14:28:01 UTC
The strange Date: header is still there in 0.27.5. It seems to be using the date in the last Received: header, instead of the one in the Date: header.

It's stranger even than that, though -- as an example, where the last Received: header says 'Fri, 14 Aug 2009 09:34:39 +0100', Evolution is reporting the date as 09:34:39 +0000.
Comment 2 David Woodhouse 2009-08-18 15:42:39 UTC
It looks like we should be fetching PR_TRANSPORT_MESSAGE_HEADERS from the server, rather than trying to recreate various headers from other information.
Comment 3 Johnny Jacob 2009-08-18 16:04:03 UTC
mmm .. kinda. To be more specific we need to implement MimeReaders/Writers based on docs (OXCMAIL). Hopefully we'll get that done by 0.30 . But before that i'll cook up a patch for this.
Comment 4 David Woodhouse 2009-08-19 10:50:22 UTC
If I understand you correctly, you're suggesting that we should be using the PidTagMimeSkeleton property?  In my case (Exchange 2007), that always seems to be empty.
Comment 5 Johnny Jacob 2009-08-26 07:16:59 UTC
Created attachment 141726 [details] [review]
Use PR_TRANSPORT_MESSAGE_HEADERS

It is a big mess in there right now. Not disturbing the code much for 0.28
Comment 6 Johnny Jacob 2009-08-26 07:17:31 UTC
(In reply to comment #2)
> It looks like we should be fetching PR_TRANSPORT_MESSAGE_HEADERS from the
> server, rather than trying to recreate various headers from other information.

Seems to be the right way to do this. Thanks.
Comment 7 Johnny Jacob 2009-08-28 04:16:36 UTC
Comment on attachment 141726 [details] [review]
Use PR_TRANSPORT_MESSAGE_HEADERS

Pushed to master
Comment 8 Johnny Jacob 2009-08-28 04:16:52 UTC
Closing as fixed.
Comment 9 Milan Crha 2009-09-11 17:05:46 UTC
Created commit 74850ba in ema master (0.29.1+)
Created commit 07870c0 in ema gnome-2-28 (0.27.93+)

Not all messages have the Transport Headers, also my 2k3 server doesn't like that property. I also added a _UNICODE version to be fetched and used, just to be sure.

I noticed the code is skipping some parts in favour of transport headers. Those should be changed accordingly, I guess?
Comment 10 David Woodhouse 2009-10-06 11:34:28 UTC
There's still something odd going on. I'm trying the evolution and evolution-mapi builds from Fedora 12 (rawhide).

In the folder index (not the preview pane itself), sender addresses are odd, and inconsistently so. For example, an email which has its From: header almost correctly displayed in the preview pane as:
 From: Lastname, Firstname <first.last@company.com>
... is displayed in the folder index as 'Lastname Firstname <Lastname Firstname>'
instead of having a real email address inside the <...>.

(Strictly speaking the From: display in the preview pane is wrong too, because that 'Lastname, Firstname' should be in quotes. But that's an ancient evo bug.)

Another mail from _outside_ the company is actually:
 From: Last First <foo@gmail.com>
... but appears in the folder index as 'Last First <foogmail.com>' without the @ sign. All external mail seems to be like this, at first glance.

Internal mail seems to either take the first erroneous form above (<Last First>), or be displayed correctly. 

Also, the Date: header is being displayed bizarrely. For example:
 Date: 10/3/2009 05:15:40 AM (Fri, 2 Oct 2009 21:15:40 -0700).

Please tell me that's an evolution-mapi bug, and new versions of evolution aren't doing that on purpose for all mails. Is it possible to get back to how it was before? e.g.:
 Date: Fri, 2 Oct 2009 21:15:40 -0700 <I>(05:15 BST)</I>
Comment 11 Milan Crha 2009-10-06 13:22:08 UTC
(In reply to comment #10)
> Also, the Date: header is being displayed bizarrely. For example:
>  Date: 10/3/2009 05:15:40 AM (Fri, 2 Oct 2009 21:15:40 -0700).
> 
> Please tell me that's an evolution-mapi bug, and new versions of evolution
> aren't doing that on purpose for all mails. Is it possible to get back to how
> it was before? e.g.:
>  Date: Fri, 2 Oct 2009 21:15:40 -0700 <I>(05:15 BST)</I>

Only this is intentional, after the configurable date/time format change. It shows you the time in your local timezone, and in braces what was received (the real header value). The old format had it opposite, and, further more, the time in braces wasn't always correct.
Comment 12 David Woodhouse 2009-10-06 13:29:11 UTC
Hrm, should I open a separate bug for that? It seems wrong. When showing me an email, you should show me _first_ what was actually in the email.

Translating that to my localtime is helpful, but shouldn't be the _primary_ way it's displayed.

I suppose it would be OK if there was at least _some_ way to put it back how it was. But although I seem to have free rein in specifying how the localtime is displayed, there's no way to put the _real_ Date: header back to its original position.
Comment 13 Milan Crha 2009-10-06 17:28:36 UTC
(In reply to comment #12)
> Hrm, should I open a separate bug for that?

yup, please do.