The following issue has been CLOSED
======================================================================
http://www.dbmail.org/mantis/view.php?id=79
======================================================================
Reported By: scocking
Assigned To:
======================================================================
Project: DBMail
Issue ID: 79
Category: IMAP daemon
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Resolution: reopened
Fixed in Version:
======================================================================
Date Submitted: 30-Aug-04 12:39 CEST
Last Modified: 14-Feb-06 16:49 CET
======================================================================
Summary: INTERNALDATE reponses do not conform to RFC
Description:
The SnapperMail IMAP client is extremely strict in its IMAP protocol
adherence, and requires that INTERNALDATE responses are formatted in
"dd-mmm-yyyy hh:mm:ss +zzzz" format as per the RFC. DBmail always
responds without the " +zzzz" timezone.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0000211 date_slq2imap does not output RFC compl...
======================================================================
----------------------------------------------------------------------
ilja - 03-Sep-04 14:00
----------------------------------------------------------------------
fixed by doing the following:
instead of using array magic etc, the two date functions date_imap2sql()
and date_sql2imap() now use strptime() and strftime() to parse and format
the date & time. date_sql2imap() outputs the timezone information with the
date and time.
fix has been applied to HEAD, dbmail_2_0_branch. A patch has been prepared
for dbmail_1_2_branch.
----------------------------------------------------------------------
scocking - 08-Sep-04 10:15
----------------------------------------------------------------------
The supplied fix sends a timezone in its INTERNALDATE response, but the
timezone is incorrect. The timezone presented is daylight time, when
local time is not.
An example seen by an IMAP client follows:
0295 > * 53 FETCH (UID 1290296 FLAGS (\Seen \Answered \Recent) ENVELOPE
("Wed, 8 Sep 2004 17:29:45 +1000" "Email subject" (({12} NIL "email"
"domain.com")) (({12} NIL "email" "domain.com")) (({12} NIL "email"
"domain.com")) (({15} NIL "simon" "mailguard.com.au")) NIL NIL NIL
"<[EMAIL PROTECTED]>")
BODY[HEADER.FIELDS (REFERENCES)] {2} INTERNALDATE "08-Sep-2004 17:33:11
+1100" <snip>
The correct UTC offset for this location is +1000. +1100 is our daylight
offset.
I have triple-checked the server's timezone settings, and they're correct.
All other software on this machine reports correct time. E.g.
# date -R
Wed, 8 Sep 2004 18:14:27 +1000
(I had a quick crack at fixing this myself. My system documentation
doesn't show a tm_gmtoff member to struct tm, and I've never seen that
myself. Could this be the culprit?)
Simon.
----------------------------------------------------------------------
ilja - 08-Sep-04 10:36
----------------------------------------------------------------------
Hmm.. I just checked. It works here (I get +0100, which is correct here).
So, you don't have tm_gmtoff in your tm struct. What system are you
running? tm_gmtoff is a BSD & GNU extension.
----------------------------------------------------------------------
ilja - 08-Sep-04 13:37
----------------------------------------------------------------------
I'm getting more and more confused on how timezone stuff should work...
----------------------------------------------------------------------
ilja - 08-Sep-04 14:17
----------------------------------------------------------------------
hmm, of course it works correct here. We _are_ on daylights savings time.
Hmm, I've just found a bug here. I managed to screw up something. I
correctly get +0200 now. The bug's not in the patch I sent earlier.
Anyway. I don't know what we should do here. I've posted a question on
Usenet in comp.lang.c, perhaps we'll get a useful answer there.
----------------------------------------------------------------------
ilja - 15-Sep-04 16:32
----------------------------------------------------------------------
I haven't received any useful information from comp.lang.c...
I'm currently at a loss how to solve this..
----------------------------------------------------------------------
aaron - 15-Sep-04 17:23
----------------------------------------------------------------------
What if we just ask the database for a formatted time response?
----------------------------------------------------------------------
ilja - 15-Sep-04 17:28
----------------------------------------------------------------------
Of course!
We only need to find the places where we ask the database for an
INTERNALDATE, but I'm thinking we only ask for it in this IMAP code..
It might just work. I only hope that our way of saving the INTERNALDATE
(without timezone) doesn't stand in the way.
Ilja
----------------------------------------------------------------------
ilja - 16-Sep-04 11:53
----------------------------------------------------------------------
Last option doesn't work.. Back to square 1
----------------------------------------------------------------------
paul - 29-Mar-05 20:29
----------------------------------------------------------------------
I've done a (hopefully) portable version of date_sql2imap that does not
rely on GNU extensions. It uses tzset(3) to determine the gmt offset, and
uses the tm_isdst field in tm structs to add a 1 hour offset if dst is
relevant for the time being parsed. I'm pretty sure this will work!
I'm uploading the test implementation...
----------------------------------------------------------------------
paul - 31-May-05 14:41
----------------------------------------------------------------------
I've reverted my earlier fix back to using localtime(3) for 2.0 and trunk.
This will work for linux. For netbsd it will 1hour offsets if DST(now) !=
DST(then). So ymmv. My freebsd xen domain keeps crashing, so I can test
freebsd.
----------------------------------------------------------------------
paul - 14-Feb-06 16:49
----------------------------------------------------------------------
I'm closing this bug. Feel free to re-submit it if required.
Issue History
Date Modified Username Field Change
======================================================================
30-Aug-04 12:39 scocking New Issue
31-Aug-04 12:18 ilja Assigned To => ilja
31-Aug-04 12:18 ilja Status new => confirmed
31-Aug-04 12:18 ilja Projection none => minor fix
31-Aug-04 12:18 ilja ETA none => < 1 day
03-Sep-04 14:00 ilja Status confirmed => resolved
03-Sep-04 14:00 ilja Resolution open => fixed
03-Sep-04 14:00 ilja Note Added: 0000216
08-Sep-04 10:15 scocking Status resolved => feedback
08-Sep-04 10:15 scocking Resolution fixed => reopened
08-Sep-04 10:15 scocking Note Added: 0000225
08-Sep-04 10:36 ilja Note Added: 0000227
08-Sep-04 13:37 ilja Note Added: 0000228
08-Sep-04 14:17 ilja Note Added: 0000229
15-Sep-04 16:32 ilja Note Added: 0000249
15-Sep-04 16:33 ilja Priority normal => high
15-Sep-04 16:33 ilja ETA < 1 day => none
15-Sep-04 17:23 aaron Note Added: 0000252
15-Sep-04 17:28 ilja Note Added: 0000253
16-Sep-04 11:53 ilja Note Added: 0000266
23-Nov-04 23:11 michaelg Issue Monitored: michaelg
29-Nov-04 11:20 ilja Assigned To ilja =>
29-Mar-05 20:29 paul Note Added: 0000640
29-Mar-05 20:29 paul File Added: test_imap_date.c
31-May-05 14:41 paul Note Added: 0000716
31-May-05 14:53 paul Priority high => normal
31-May-05 14:53 paul Status feedback => confirmed
30-Jun-05 15:49 paul Relationship added has duplicate 0000211
14-Feb-06 16:49 paul Status confirmed => closed
14-Feb-06 16:49 paul Note Added: 0001007
======================================================================
