Ben, I don't know if the problem I see with Zimbra imap server is related to this. For testing of copying a huge folder between servers, a few years ago a tb user sent me a very large mbox file saved from tb that I imported into Local Folders and then copied to gmail imap server. Everything looked ok on gmail at that point. I've copied this email set to several imap servers from gmail and, once I got a successful copy, the messages all looked correct at the destination. Now recently I tried copying the same messages from gmail to a locally running Zimbra imap server. The messages all seem to arrive OK and are all present but some the Date values in the summary list for the Zimbra account show only the time of the copy and no day/month/year of the actual message.
I think the lack of complete Date has something to do with the "From " and "X-Mozilla-Keys" headers that are somehow present in the gmail source messages derived from Local Folders. I only see these on gmail messages that I copied from Local Folders and not on gmail messages that come in normally.
After copying 200 gmail messages from this set to the local zimbra server, to obtain the information for the email summary, tb asks Zimbra for a set of message headers that includes the DATE header and zimbra responds like this for each of the 200 message with multiple lines of data:
```
Zimbra: * 43 FETCH (UID 33384 RFC822.SIZE 11410 BODY[HEADER.FIELDS (FROM TO CC BCC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE REPLY-TO)] {404}
Zimbra: From
Zimbra: Date: Thu, 16 Jun 2016 17:50:13 -0400
Zimbra: (Other requested headers sent...)
:
```
Note that zimbra always sends the not-requested "From " line first. The 2nd line returned above is the correct "Date" header but for other messages the order of the returned headers varies and the 2nd one is usually not "Date" but something else with "Date" header later on. It appears that the date displayed in the summary is only shown as the current time when Zimbra returns the "Date" header right after the bogus "From ".
For example this works OK and doesn't corrupt the summary:
```
Zimbra: * 3 FETCH (UID 33344 RFC822.SIZE 16163 BODY[HEADER.FIELDS (FROM TO CC BCC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE REPLY-TO)] {415}
Zimbra: From
Zimbra: From: "Guy Lombardo" <guy@louisville.edu>
Zimbra To: "surferdude@nmr.mgh.harvard.edu" <surferdude@nmr.mgh.harvard.edu>
Zimbra: Date: Wed, 17 Apr 2019 16:20:59 +0000
:
```
In this case, the bogus "From " is still transmitted by Zimbra but the "Date" header is not right after the "From " and the message summary displays OK with the correct date. The "From" in the summary is also OK even though it was transmitted right after the bogus "From ".
At this time I'm not sure if the problem is due the bogus "From " or the zimbra server or a tb parsing problem. So maybe this should be a new bug.
Bug 1719121 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Edit: This comment probably doesn't really belong in this bug so I've moved it here: bug 1741748. Ben, I don't know if the problem I see with Zimbra imap server is related to this. For testing of copying a huge folder between servers, a few years ago a tb user sent me a very large mbox file saved from tb that I imported into Local Folders and then copied to gmail imap server. Everything looked ok on gmail at that point. I've copied this email set to several imap servers from gmail and, once I got a successful copy, the messages all looked correct at the destination. Now recently I tried copying the same messages from gmail to a locally running Zimbra imap server. The messages all seem to arrive OK and are all present but some the Date values in the summary list for the Zimbra account show only the time of the copy and no day/month/year of the actual message. I think the lack of complete Date has something to do with the "From " and "X-Mozilla-Keys" headers that are somehow present in the gmail source messages derived from Local Folders. I only see these on gmail messages that I copied from Local Folders and not on gmail messages that come in normally. After copying 200 gmail messages from this set to the local zimbra server, to obtain the information for the email summary, tb asks Zimbra for a set of message headers that includes the DATE header and zimbra responds like this for each of the 200 message with multiple lines of data: ``` Zimbra: * 43 FETCH (UID 33384 RFC822.SIZE 11410 BODY[HEADER.FIELDS (FROM TO CC BCC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE REPLY-TO)] {404} Zimbra: From Zimbra: Date: Thu, 16 Jun 2016 17:50:13 -0400 Zimbra: (Other requested headers sent...) : ``` Note that zimbra always sends the not-requested "From " line first. The 2nd line returned above is the correct "Date" header but for other messages the order of the returned headers varies and the 2nd one is usually not "Date" but something else with "Date" header later on. It appears that the date displayed in the summary is only shown as the current time when Zimbra returns the "Date" header right after the bogus "From ". For example this works OK and doesn't corrupt the summary: ``` Zimbra: * 3 FETCH (UID 33344 RFC822.SIZE 16163 BODY[HEADER.FIELDS (FROM TO CC BCC SUBJECT DATE MESSAGE-ID PRIORITY X-PRIORITY REFERENCES NEWSGROUPS IN-REPLY-TO CONTENT-TYPE REPLY-TO)] {415} Zimbra: From Zimbra: From: "Guy Lombardo" <guy@louisville.edu> Zimbra To: "surferdude@nmr.mgh.harvard.edu" <surferdude@nmr.mgh.harvard.edu> Zimbra: Date: Wed, 17 Apr 2019 16:20:59 +0000 : ``` In this case, the bogus "From " is still transmitted by Zimbra but the "Date" header is not right after the "From " and the message summary displays OK with the correct date. The "From" in the summary is also OK even though it was transmitted right after the bogus "From ". At this time I'm not sure if the problem is due the bogus "From " or the zimbra server or a tb parsing problem. So maybe this should be a new bug.