[Dovecot] Re: mail shown throught outlook, shows todays date
bclark wrote:
The interesting thing is, once I have some mail on the dovecot,
the date displayed on Mozilla is correct, but the mail shown throught
outlook, shows todays date (thats for all mail).Each mail has (at least) two dates : the date it was sent (stored
in the headers), and the date it arrived (in Maildir, the date of the
file). Most likely, Mozilla and SquirrelMail are showing the date in the
headers, and Outloo is showing the arrival date.This problem has come up a few times, I believe. As I recall, most
mail clients allow you to select which date to sort by. If you can't find the
option, it may be somewhere in this list's archives.Almost seems as Outlook (office 2000) looks at the date / time
stamp of the file it self as opposed to opening and reading the mail and
reading the necassry tags.That's my assessment, also.
If anyone could help me understand this (is this a dovecot issue), I would really appreciate it.
I don't believe it's a dovecot issue, per se.
-- Curtis Maloney cmaloney <at> cardgate.net
I've been testing Dovecot 1.0beta7 to implement IMAP for the first
time, and have had a good experience so far.
But like Curtis and Brent, I found that Outlook and Outlook Express
display "incorrect" dates on messages uploaded via APPEND. That's
because they sort messages using INTERNALDATE:
wea3 SELECT "Test Folder"
pqng UID FETCH 1:* (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER]
INTERNALDATE)
Some have created scripts to sync file timestamps with "Date"
headers, which conflicts with the concept of "INTERNALDATE". Others
ask users to add the "Date Sent" column, but those dates are only
revealed after a message is viewed.
I'd like to propose the attached patch to add an optional "outlook-
dates" IMAP workaround, which returns the message "Date:" even when
INTERNALDATE is specified.
Since "BODY.PEEK" is being called anyway, our tests didn't reveal any
performance impact. Can anyone think of a scenario this would
negatively impact? Another option might be to patch the APPEND function?
Thanks!
Rich Sandberg richs@whidbey.net
On Thu, 2006-04-27 at 13:54 -0700, richs@whidbey.net wrote:
I'd like to propose the attached patch to add an optional "outlook- dates" IMAP workaround, which returns the message "Date:" even when
INTERNALDATE is specified.
Oh, that's evil. I always want to sort using the real INTERNALDATE because Date-header can sometimes be broken (especially with spams).
Since "BODY.PEEK" is being called anyway, our tests didn't reveal any
performance impact. Can anyone think of a scenario this would
negatively impact? Another option might be to patch the APPEND function?
APPEND sounds better to me.. You could even make it get the timestamp from the first Received-header if it exists, which makes it pretty close to INTERNALDATE's idea.
On Apr 27, 2006, at 3:03 PM, Timo Sirainen wrote:
On Thu, 2006-04-27 at 13:54 -0700, richs@whidbey.net wrote:
I'd like to propose the attached patch to add an optional "outlook- dates" IMAP workaround, which returns the message "Date:" even when INTERNALDATE is specified.
Oh, that's evil. I always want to sort using the real INTERNALDATE because Date-header can sometimes be broken (especially with spams).
I admit that INTERNALDATE is a useful idea for experienced users, but
unfortunately our Outlook/OE users won't know any better.
It's unfortunate that Microsoft doesn't give users an easier choice,
or default to the more widely expected value. They could even change
"Date Received" to the actual time Outlook retrieved the message, if
an INTERNALDATE-concept was important to them.
Since "BODY.PEEK" is being called anyway, our tests didn't reveal any performance impact. Can anyone think of a scenario this would negatively impact? Another option might be to patch the APPEND
function?APPEND sounds better to me.. You could even make it get the timestamp from the first Received-header if it exists, which makes it pretty
close to INTERNALDATE's idea.
We would really like to see an APPEND patch, but we're still
concerned our file times won't match their original storage dates
unless we continually check and touch them.
Basically, as long as the message list date doesn't match the "Date:"
seen in the message, our users will be confused. Is there any chance
the optional workaround flag could make it to CVS?
Rich Sandberg richs@whidbey.net
On Apr 28, 2006, at 7:44 PM, richs@whidbey.net wrote:
APPEND sounds better to me.. You could even make it get the timestamp from the first Received-header if it exists, which makes it pretty
close to INTERNALDATE's idea.We would really like to see an APPEND patch, but we're still
concerned our file times won't match their original storage dates
unless we continually check and touch them.
Why would they change?
Basically, as long as the message list date doesn't match the
"Date:" seen in the message, our users will be confused. Is there
any chance the optional workaround flag could make it to CVS?
No. You could possibly do it as a plugin though so you don't have to
keep patching the sources.
I don't actually even see why this is a problem. Why are your users
uploading existing messages to IMAP server in the first place?
On Fri, 2006-04-28 at 14:40, Timo Sirainen wrote:
I don't actually even see why this is a problem. Why are your users
uploading existing messages to IMAP server in the first place?
Isn't that a normal practice? Some of my messages have outlived several different mail servers and I often want to move messages that I've downloaded from some pop account into a server IMAP folder where I can access it from other machines. I thought being able to move messages wherever you want them was the whole point of using IMAP. The day I decided I wanted a message in a particular server's folder has nothing to do with the message date.
-- Les Mikesell lesmikesell@gmail.com
On Apr 28, 2006, at 12:40 PM, Timo Sirainen wrote:
On Apr 28, 2006, at 7:44 PM, richs@whidbey.net wrote:
APPEND sounds better to me.. You could even make it get the
timestamp from the first Received-header if it exists, which makes it
pretty close to INTERNALDATE's idea.We would really like to see an APPEND patch, but we're still
concerned our file times won't match their original storage dates
unless we continually check and touch them.Why would they change?
Well, we know the times shouldn't change if everything is done to
preserve them. But we'd probably double-check backup restores and re-
filtered mail.
Basically, as long as the message list date doesn't match the
"Date:" seen in the message, our users will be confused. Is there
any chance the optional workaround flag could make it to CVS?No. You could possibly do it as a plugin though so you don't have
to keep patching the sources.I don't actually even see why this is a problem. Why are your users
uploading existing messages to IMAP server in the first place?
Users migrating from another provider, those switching from POP to
IMAP, and those with multiple accounts who move messages between
them. Since every message is given a current timestamp, it breaks
sort-by-date in Outlook/OE, and confuses users with (in their eyes)
mis-matched dates.
The timestamps are also changed when moving messages from one IMAP
folder to another, within the same account:
Before:
/var/mail/testformail/Maildir/.Sent Items/cur
-rw------- 1 testformail users 10219 Apr 27 13:02
1146168153.P29665Q0M142457.mail9:2,S
After:
/var/mail/testformail/Maildir/.Sent Items/cur
-rw------- 1 testformail users 10219 Apr 27 13:02
1146168153.P29665Q0M142457.mail9:2,ST
/var/mail/testformail/Maildir/.Sent Messages/cur
-rw------- 1 testformail users 10219 Apr 28 12:53
1146254028.P13186Q0M234215.mail9:2,S
It sounds like if the maildir store function were patched, it might
fix APPEND too?
It's not Dovecot's fault that Outlook/OE operates this way, but like
the nuls and idle issues, it would be nice if there were a user-
transparent fix.
Thanks,
Rich
On Fri, 2006-04-28 at 14:16 -0700, richs@whidbey.net wrote:
The timestamps are also changed when moving messages from one IMAP
folder to another, within the same account:
OK, so I guess this is the same NFS problem as reported earlier. You could probably work around it by moving utime() call after close() call in lib-storage/index/maildir/maildir-save.c
I don't see this problem with 2.6.16 kernel so I think it's fixed already in kernel side.
On Thu, Apr 27, 2006 at 01:54:30PM -0700, richs@whidbey.net wrote:
I'd like to propose the attached patch to add an optional "outlook- dates" IMAP workaround, which returns the message "Date:" even when
INTERNALDATE is specified.Since "BODY.PEEK" is being called anyway, our tests didn't reveal any
performance impact. Can anyone think of a scenario this would
negatively impact? Another option might be to patch the APPEND function?
hey, cool.. I was just about to start looking at this problem myself as I have a number of Outlook users here (and I have been using Outlook a bit myself for test purposes, and noticed this too.)
thanks ;)
grant.
participants (4)
-
grant beattie
-
Les Mikesell
-
richs＠whidbey.net
-
Timo Sirainen