[Dovecot] Sent Date/time vs Received Date/time
On 8/20/2008, Nicolas KOWALSKI (nicolas.kowalski@gmail.com) wrote:
The alpine documentation states about 'Arrival' sorting:
" The Arrival sort option arranges messages in the MESSAGE INDEX in the order that they exist in the folder. This is usually the same as the order in which they arrived. This option is comparable to not sorting the messages at all. "
It is the same (non-)ordering available in Mozilla mail clients, with the 'Order Received' option.
Ok, this is something that I have thought about from time to time.
I know that every message has a 'received' header, which is basically the date/time stamp of the SENDERS CLIENT - so if their system's time is off, that date/time header will be off.
So, where does this 'Order Received' column in TBird get its info from? I'm guessing it is a TBird thing, like an internal index number?
In my mind, there should be two primary date/time columns:
Sent Date/Time = Date/time of the Client system when message was sent (this is already there as the plain 'Date' column)
and
Received Date/Time = Date/time the receiving SERVER DELIVERED it
I can see the benefit for the third 'Client' side Date/time stamp, which is the current 'Order Received' in TBird.
I'd like to see support added for grabbing the last date/time from the LDA that delivers the message, but that obviously request is for the TBird devs (or most likely an extension request), but...
The main question is - is there a proper IMAP/RFC for providing/getting this date/time?
--
Best regards,
Charles
On Wed, Aug 20, 2008 at 08:43:02AM -0400, Charles Marcus wrote:
In my mind, there should be two primary date/time columns:
Sent Date/Time = Date/time of the Client system when message was sent (this is already there as the plain 'Date' column)
and
Received Date/Time = Date/time the receiving SERVER DELIVERED it
[...]
The main question is - is there a proper IMAP/RFC for providing/getting this date/time?
I think this is called INTERNALDATE in the IMAP world (see rfc2060).
-- Nicolas
Charles Marcus wrote:
On 8/20/2008, Nicolas KOWALSKI (nicolas.kowalski@gmail.com) wrote:
The alpine documentation states about 'Arrival' sorting:
" The Arrival sort option arranges messages in the MESSAGE INDEX in the order that they exist in the folder. This is usually the same as the order in which they arrived. This option is comparable to not sorting the messages at all. "
It is the same (non-)ordering available in Mozilla mail clients, with the 'Order Received' option.
Ok, this is something that I have thought about from time to time.
I know that every message has a 'received' header, which is basically the date/time stamp of the SENDERS CLIENT - so if their system's time is off, that date/time header will be off.
So, where does this 'Order Received' column in TBird get its info from? I'm guessing it is a TBird thing, like an internal index number?
the order of putting the message in the folder. this has nothing to do with dates contained in the message. if you manually move an old message to another folder, you'll see it last in the new folder.
In my mind, there should be two primary date/time columns:
Sent Date/Time = Date/time of the Client system when message was sent (this is already there as the plain 'Date' column)
and
Received Date/Time = Date/time the receiving SERVER DELIVERED it
Parsing Received headers is not a science. so this would create unnecessary (IMHO) problems for MUA developpers. the "delivery" time is sufficient (if all mail goes to the same fielsystem).
I can see the benefit for the third 'Client' side Date/time stamp, which is the current 'Order Received' in TBird.
I'd like to see support added for grabbing the last date/time from the LDA that delivers the message, but that obviously request is for the TBird devs (or most likely an extension request), but...
The main question is - is there a proper IMAP/RFC for providing/getting this date/time?
Hey mouss,
Still waiting on your comments on the new vacation.pl for postfixadmin - had a chance to take a look yet?
On 8/20/2008, mouss (mouss@netoyen.net) wrote:
So, where does this 'Order Received' column in TBird get its info from? I'm guessing it is a TBird thing, like an internal index number?
the order of putting the message in the folder. this has nothing to do with dates contained in the message. if you manually move an old message to another folder, you'll see it last in the new folder.
If you sort them by 'Order Received'. If you sort them by the standard 'Date' column (I'm talking TBird-speak here), then they are sorted by the Date/time that the Senders CLIENT thought it was when they sent their message. I am on more than a few lists where people have their clocks screwed up - most often its a DST issue, but sometimes its a time-zone issue - and more rare, their clock is off by weeks or more - and these messages get sorted OUT of order.
When I enable the 'Order Received' column, that will fix those issues, but then - as you pointed out - messages that have been moved from one folder to another are now out of order.
Again... this is why I mentioned using the actual date/time that MY MAILSERVER received the message (of course this requires that its clock be correct, but it always is, so not an issue for me).
Parsing Received headers is not a science. so this would create unnecessary (IMHO) problems for MUA developpers. the "delivery" time is sufficient (if all mail goes to the same fielsystem).
For the reasons I outlined above, I disagree...
I think having an MUA with the ability to parse the actual Received date/time would be very handy...
The RFC for this apparently is 2060, but:
2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This is not the date and time in the [RFC-822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined.
It sounds like this INTERNALDATE changes... I'd like something that is from the message headers - ie, that doesn't change - so that sorting will *always* be what I want/expect, even if I move messages from one IMAP server to another...
--
Best regards,
Charles
On Wed, 2008-08-20 at 17:06 -0400, Charles Marcus wrote:
The RFC for this apparently is 2060, but:
You should be looking at 3501 :)
2.3.3. Internal Date Message Attribute
It sounds like this INTERNALDATE changes... I'd like something that is from the message headers - ie, that doesn't change - so that sorting will *always* be what I want/expect, even if I move messages from one IMAP server to another...
INTERNALDATE is stored in message's mtime with maildir. It's preserved when COPYing a message to another mailbox. Whether it's preserved when a client copies it between different IMAP accounts depends on the client - APPEND command anyway supports INTERNALDATE parameter.
Evolution's "Received" field means the same as INTERNALDATE and I always use it to order my messages. Works fine.
Charles Marcus wrote:
Hey mouss,
<OT>
Still waiting on your comments on the new vacation.pl for postfixadmin - had a chance to take a look yet?
not yet. sorry. </OT>
On 8/20/2008, mouss (mouss@netoyen.net) wrote:
So, where does this 'Order Received' column in TBird get its info from? I'm guessing it is a TBird thing, like an internal index number?
the order of putting the message in the folder. this has nothing to do with dates contained in the message. if you manually move an old message to another folder, you'll see it last in the new folder.
If you sort them by 'Order Received'. If you sort them by the standard 'Date' column (I'm talking TBird-speak here), then they are sorted by the Date/time that the Senders CLIENT thought it was when they sent their message. I am on more than a few lists where people have their clocks screwed up - most often its a DST issue, but sometimes its a time-zone issue - and more rare, their clock is off by weeks or more - and these messages get sorted OUT of order.
same problem with spam sent with ratware. I rarely use "sort by date". on list folders, I generally use a threading view.
Anyway, I don't find this to be a critical problem, so I don't really care.
When I enable the 'Order Received' column, that will fix those issues, but then - as you pointed out - messages that have been moved from one folder to another are now out of order.
yes. I didn't check other MUAs.
Again... this is why I mentioned using the actual date/time that MY MAILSERVER received the message (of course this requires that its clock be correct, but it always is, so not an issue for me).
Parsing Received headers is not a science. so this would create unnecessary (IMHO) problems for MUA developpers. the "delivery" time is sufficient (if all mail goes to the same fielsystem).
For the reasons I outlined above, I disagree...
I think having an MUA with the ability to parse the actual Received date/time would be very handy...
you are saying so because you use postfix which Received headers are easy to parse. Now take a look at the spamassassin code that parses received headers and you'll see what nightmare it is. not something a developper would "expose" to users (we're talking about TB, which is intended for the "general public").
[snip]
It sounds like this INTERNALDATE changes... I'd like something that is from the message headers - ie, that doesn't change - so that sorting will *always* be what I want/expect, even if I move messages from one IMAP server to another...
If I'm not wrong, TB (and maybe other MUAs) implements "move" by creating a new copy (so a new and unrelated file is created) and then deleting the old one. This explains why one sometimes gets out of quota (or disk space) when trying to "delete" mail ("move" to Trash). anyway, this causes a new filename, which breaks the order (even if you do ls in your cur/ subdir).
participants (4)
-
Charles Marcus
-
mouss
-
Nicolas KOWALSKI
-
Timo Sirainen