A BUGNOTE has been added to this bug.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000079
======================================================================
Reported By: scocking
Assigned To: ilja
======================================================================
Project: DBMail
Bug ID: 79
Category: IMAP daemon
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
======================================================================
Date Submitted: 30-Aug-04 12:39 CEST
Last Modified: 08-Sep-04 10:36 CEST
======================================================================
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.
======================================================================
----------------------------------------------------------------------
ilja - 03-Sep-04 14:00 CEST
----------------------------------------------------------------------
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 CEST
----------------------------------------------------------------------
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 CEST
----------------------------------------------------------------------
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.
Bug History
Date Modified Username Field Change
======================================================================
30-Aug-04 12:39scocking New Bug
31-Aug-04 12:18ilja ETA none => < 1 day
31-Aug-04 12:18ilja Assigned To => ilja
31-Aug-04 12:18ilja Projection none => minor fix
31-Aug-04 12:18ilja Status new => confirmed
03-Sep-04 14:00ilja Bugnote Added: 0000216
03-Sep-04 14:00ilja Resolution open => fixed
03-Sep-04 14:00ilja Status confirmed => resolved
08-Sep-04 10:15scocking Bugnote Added: 0000225
08-Sep-04 10:15scocking Resolution fixed => reopened
08-Sep-04 10:15scocking Status resolved => feedback
08-Sep-04 10:36ilja Bugnote Added: 0000227
======================================================================
