[Dovecot] Sent Date/time vs Received Date/time

[Charles Marcus]

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 at 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