Another sample - different box still 2.3.x - this is from an imaptest
inserted email.
1 OK LOGIN completed
2 select inbx
2 NO specified mailbox does not exist
3 select inbox
* 21 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Deleted \Flagged \Draft NonJunk $Label2
$Label4 $Label5 $Label1 $Label3)
* OK [PERMANENTFLAGS (\Seen \Answered \Deleted \Flagged \Draft NonJunk
$Label2 $Label4 $Label5 $Label1 $Label3 \*)]
* OK [UIDNEXT 108234] Predicted next UID
* OK [UIDVALIDITY 43] UID value
* OK [UNSEEN 2] first unseen message
3 OK [READ-WRITE] SELECT completed
1 fetch 1 (INTERNALDATE UID)
* 1 FETCH (INTERNALDATE "01-Aug-2002 05:48:41 -0700" UID 108135)
1 OK FETCH completed
mysql> select * from dbmail_messages where message_idnr='108135';
+--------------+--------------+----------------+-----------+---------------+--------------+--------------+-------------+------------+----------------------------------+--------+---------------+
| message_idnr | mailbox_idnr | physmessage_id | seen_flag |
answered_flag | deleted_flag | flagged_flag | recent_flag | draft_flag |
unique_id | status | backup_status |
+--------------+--------------+----------------+-----------+---------------+--------------+--------------+-------------+------------+----------------------------------+--------+---------------+
| 108135 | 43 | 23355 | 0 |
1 | 0 | 1 | 0 | 0 |
67dc3d3e356eecf9069c1fa8f290c5d3 | 1 | 0 |
+--------------+--------------+----------------+-----------+---------------+--------------+--------------+-------------+------------+----------------------------------+--------+---------------+
1 row in set (0.00 sec)
mysql> select * from dbmail_physmessage where id=23355;
+-------+-------------+---------+---------------------+
| id | messagesize | rfcsize | internal_date |
+-------+-------------+---------+---------------------+
| 23355 | 1336 | 1375 | 2002-08-01 05:48:41 |
+-------+-------------+---------+---------------------+
1 row in set (0.00 sec)
Source message headers from dovecot-crlf:
From [EMAIL PROTECTED] Wed Jul 31 22:48:41 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 31 Jul 2002 22:48:41
+0300 (EEST)
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
by danu.procontrol.fi (Postfix) with ESMTP id F141123829
for <[EMAIL PROTECTED]>; Wed, 31 Jul 2002 22:48:40 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
id 42ED44C0A0; Wed, 31 Jul 2002 22:48:40 +0300 (EEST)
Date: Wed, 31 Jul 2002 22:48:39 +0300
From: Timo Sirainen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [dovecot] v0.95 released
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 3
X-ecartis-version: Ecartis v1.0.0
Sender: [EMAIL PROTECTED]
Errors-to: [EMAIL PROTECTED]
X-original-sender: [EMAIL PROTECTED]
Precedence: bulk
X-list: dovecot
X-UID: 3
Status: O
Jonathan Feally wrote:
Ok - so what I am seeing is with message insertion via lmtpd care of
postfx.
Sample e-mail is delivered at 2008-12-01 00:00:00 Local Time (-0800 in
this case)
dbmail_phymessage.internal_date is set to 2008-12-01 08:00:00 (Thus
converted/adjusted to GMT +0000)
Imap client then does a fetch and requests INTERNALDATE
INTERNALDATE is returned to client as "01-Dec-2008 08:00:00 -0800"
Client is set for TZ -0800, thus it makes no correction to the date
displayed on list of emails as it thinks that the email was received
at the time it was told - which is 8 hours into the future.
So what I see on date_sql2imap is a section that deals with adding the
timezone offset as either the local hosts tz offset via the %z date
option or if unavailable - ie Solaris - it just adds +0000. Since we
are storing the email as gmt, I would think that we would simply
return +0000 every time and let the client do the proper adjustment. I
do not see anything that would adjust the raw date/time to be non-GMT
to match that of the system tz offset.
Microsoft clients love to use the internaldate as the actual received
date, while tbird uses the Date header of the envelope.
I was not having this issue with the 2.2.x series with the same pda
phone, same database settings, same host settings. Only thing changed
was the dbmail.
-Jon
Paul J Stevens wrote:
Jonathan Feally wrote:
Is anyone experiencing an issue with the internal date being returned
wrong for messages on IMAP?
I am running FreeBSD, MySQL 5.1 delivered via postfix LMTP. Date on db
row is corrected for TZ from -0800 (local machine time and zone) to
+0000, but when recalled it is taken as is and the -0800 added to it,
thus my PPC phone shows all emails as received as of +0000 time because
it TZ is matching that of the client.
I'm thinking that the correct internal date to be stored in the
database
is the TZ=0000 adjusted time. So it would appear that either the
date_sql2imap(), which is only called to translate the db date to imap
format is expecting the date retrieved to be local time and use the
local tz.
So which TZ should the date be stored in?
GMT
we're relying on g_mime_utils_header_decode_date to give us the GMT time
equivalent. Maybe I misunderstood some of the issues involved here, but
this is the first complaint in years, so it could be something bsd
specific.
I've worked around the problem by making it return +0000 instead of the
local tz, but is this the correct way that we should solve this issue?
-Jon
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
