|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
DBMail 2.2.12 released-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Greetings, I've just uploaded dbmail 2.2.12, the latest production release. Changes: * Backport IPv6 support * Remove generated autoconf files from the release. Please install automake-1.9 and run autoreconf -i before running configure * Backport the fix for duplicate mailboxes in LIST/LSUB responses * Backport for internaldate as UTC * Fix for file descriptor leakage Changelog: http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/log/?id=v2.2.12 Download: http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/snapshot/dbmail-2.2.12.tar.bz2 - -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrM9qEACgkQ8iITvBH4zTHxFQCeIjQlICjNmWwhFLtrK87dBbxi FtYAnAqWPbywRN5HTaPnLU/hBnnZ98lx =HAph -----END PGP SIGNATURE----- _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: [Dbmail-dev] DBMail 2.2.12 releasedPaul J Stevens wrote:
--
Vapour Forge
Jake Anderson Project Manager
_______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
|
|
|
Re: DBMail 2.2.12 releasedOn Wednesday 07 October 2009 03:14:32 pm Paul J Stevens wrote:
> Greetings, > > I've just uploaded dbmail 2.2.12, the latest production release. > > Changes: > > * Backport IPv6 support > * Remove generated autoconf files from the release. Please install > automake-1.9 and run autoreconf -i before running configure > * Backport the fix for duplicate mailboxes in LIST/LSUB responses > * Backport for internaldate as UTC > * Fix for file descriptor leakage > > Changelog: > http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/log/?id=v2.2.12 > > Download: > http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/snapshot/dbmail-2.2.12.tar.b > z2 > It looks like this version broke POP before SMTP. I am not getting an update on the time stamp in the database when people check their email. Thanks. -- Bret Baptist Senior Network Administrator bbaptist@... Internet Exposure, Inc. http://www.iexposure.com (612) 676-1946 x117 Providing Internet Services since 1995 Web Development ~ Search Engine Marketing ~ Web Analytics Network Security ~ On Demand Tech Support ~ E-Mail Marketing _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedOn Thursday 08 October 2009 10:05:10 am Bret Baptist wrote:
> On Wednesday 07 October 2009 03:14:32 pm Paul J Stevens wrote: > > Greetings, > > > > I've just uploaded dbmail 2.2.12, the latest production release. > > > > Changes: > > > > * Backport IPv6 support > > * Remove generated autoconf files from the release. Please install > > automake-1.9 and run autoreconf -i before running configure > > * Backport the fix for duplicate mailboxes in LIST/LSUB responses > > * Backport for internaldate as UTC > > * Fix for file descriptor leakage > > > > Changelog: > > http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/log/?id=v2.2.12 > > > > Download: > > http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/snapshot/dbmail-2.2.12.tar > >.b z2 > > It looks like this version broke POP before SMTP. I am not getting an > update on the time stamp in the database when people check their email. > Also looks like the "internaldate as UTC" is causing issues with Mac Mail and older Outlook clients. They are subtracting the time zone offset from the received time. > Thanks. > -- Bret Baptist Senior Network Administrator bbaptist@... Internet Exposure, Inc. http://www.iexposure.com (612) 676-1946 x117 Providing Internet Services since 1995 Web Development ~ Search Engine Marketing ~ Web Analytics Network Security ~ On Demand Tech Support ~ E-Mail Marketing _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedBret Baptist wrote:
> It looks like this version broke POP before SMTP. I am not getting an update > on the time stamp in the database when people check their email. Bret, I can't reproduce this. I'm getting updates just fine. What is your BINDIP setup? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedBret Baptist wrote:
> Also looks like the "internaldate as UTC" is causing issues with Mac Mail and > older Outlook clients. They are subtracting the time zone offset from the > received time. Does this happen only for pre-2.2.12 inserted email? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedOn Thursday 08 October 2009 12:29:24 pm Paul J Stevens wrote:
> Bret Baptist wrote: > > Also looks like the "internaldate as UTC" is causing issues with Mac Mail > > and older Outlook clients. They are subtracting the time zone offset > > from the received time. > > Does this happen only for pre-2.2.12 inserted email? > It looks like it is happening for post 2.2.12 inserted email. Perhaps only with IMAP clients, but I was not able to confirm before I rolled back to 2.2.11. Thanks. -- Bret Baptist Senior Network Administrator bbaptist@... Internet Exposure, Inc. http://www.iexposure.com (612) 676-1946 x117 Providing Internet Services since 1995 Web Development ~ Search Engine Marketing ~ Web Analytics Network Security ~ On Demand Tech Support ~ E-Mail Marketing _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedOn Thursday 08 October 2009 12:28:41 pm Paul J Stevens wrote:
> Bret Baptist wrote: > > It looks like this version broke POP before SMTP. I am not getting an > > update on the time stamp in the database when people check their email. > > Bret, > > I can't reproduce this. I'm getting updates just fine. > > What is your BINDIP setup? > Is what I have in there now. Thanks. -- Bret Baptist Senior Network Administrator bbaptist@... Internet Exposure, Inc. http://www.iexposure.com (612) 676-1946 x117 Providing Internet Services since 1995 Web Development ~ Search Engine Marketing ~ Web Analytics Network Security ~ On Demand Tech Support ~ E-Mail Marketing _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedBret Baptist wrote:
> On Thursday 08 October 2009 12:29:24 pm Paul J Stevens wrote: >> Bret Baptist wrote: >>> Also looks like the "internaldate as UTC" is causing issues with Mac Mail >>> and older Outlook clients. They are subtracting the time zone offset >>> from the received time. >> Does this happen only for pre-2.2.12 inserted email? >> > > It looks like it is happening for post 2.2.12 inserted email. Perhaps only > with IMAP clients, but I was not able to confirm before I rolled back to > 2.2.11. Jon, Any ideas here? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedPaul J Stevens wrote:
> >> It looks like it is happening for post 2.2.12 inserted email. Perhaps only >> with IMAP clients, but I was not able to confirm before I rolled back to >> 2.2.11. >> > > Jon, > > Any ideas here? > > Oh thanks for passing the ball to me. What timezone is the server set for? Also is this a pipe or lmtp insertion? If you do a simple select on dbmail_phymessage for both a before and after 2.2.12 upgrade messages, how does that compare to the received header timestamp? They should be pretty close once the timezone adjustment is made. The correct operation would be to have the UTC timestamp stored in the database. When read from the database, it is not adjusted other than to add +0000 for a timestamp to the reformatted time. The patches http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=296c72b96ad148a812a0c681271bca52ca10c226 http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=01032167d087d675b92f6cca16527726db06ee84 only dealt with the reading part, not with insertion. So you should not be having an issue with this change. I will quickly test it out though to see if there is any difference for me. -Jon -- Scanned for viruses and dangerous content by MailScanner _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedOn 10/07/2009 11:14 PM, Paul J Stevens wrote:
> I've just uploaded dbmail 2.2.12, the latest production release. Attached is cplogs patch for 2.2.12. Regards, -- Aleksander Kamenik System Administrator Krediidiinfo AS an Experian Company Phone: +372 665 9649 Email: aleksander@... http://www.krediidiinfo.ee/ http://www.experiangroup.com/ diff -Naur dbmail-2.2.12/db.c dbmail-2.2.12_cplogs/db.c --- dbmail-2.2.12/db.c 2009-10-07 22:44:07.000000000 +0300 +++ dbmail-2.2.12_cplogs/db.c 2009-10-08 23:43:03.000000000 +0300 @@ -2567,7 +2567,7 @@ } dbmail_message_store(message); - result = db_copymsg(message->id, mailbox_idnr, user_idnr, msg_idnr); + result = db_copymsg(message->id, 0, mailbox_idnr, user_idnr, msg_idnr); db_delete_message(message->id); dbmail_message_free(message); @@ -3797,7 +3797,32 @@ return size; } -int db_copymsg(u64_t msg_idnr, u64_t mailbox_to, u64_t user_idnr, +gboolean db_getmailbox_flag(u64_t mailbox_idnr, const char *flagname) +{ + gboolean flag = FALSE; + + char query[DEF_QUERYSIZE]; + memset(query,0,DEF_QUERYSIZE); + + g_return_val_if_fail(mailbox_idnr, 0); + + snprintf(query, DEF_QUERYSIZE, "SELECT %s FROM %smailboxes WHERE mailbox_idnr = %llu", flagname, DBPFX, mailbox_idnr); + + if(db_query(query) == -1) + return flag; + + if (db_num_rows() == 0) { + TRACE(TRACE_ERROR, "invalid mailbox id (%lld) specified or [%s] doesnt exist", mailbox_idnr, flagname); + db_free_result(); + return flag; + } + flag = db_get_result_bool(0,0); + db_free_result(); + return flag; +} + + +int db_copymsg(u64_t msg_idnr, u64_t mailbox_from, u64_t mailbox_to, u64_t user_idnr, u64_t * newmsg_idnr) { u64_t msgsize; @@ -3853,6 +3878,31 @@ return DM_EQUERY; } + if(! (mailbox_from && mailbox_to)) + return DM_EGENERAL; + + gboolean do_src = db_getmailbox_flag(mailbox_from, "cplog_flag"); + gboolean do_dst = db_getmailbox_flag(mailbox_to, "cplog_flag"); + gboolean to_trash = db_getmailbox_flag(mailbox_to, "trash_flag"); + + if( do_src && (! to_trash) ) { + snprintf(query, DEF_QUERYSIZE, "INSERT INTO %scplogs " + "(message_idnr, mailbox_idnr, direction) " + "VALUES ('%llu','%llu','0')", + DBPFX, *newmsg_idnr, mailbox_from); + if(db_query(query) == -1) + return DM_EQUERY; + } + + if( do_dst ) { + snprintf(query,DEF_QUERYSIZE, "INSERT INTO %scplogs " + "(message_idnr, mailbox_idnr, direction) " + "VALUES ('%llu', '%llu', '1')", + DBPFX, *newmsg_idnr, mailbox_to); + if(db_query(query) == -1) + return DM_EQUERY; + } + return DM_EGENERAL; } diff -Naur dbmail-2.2.12/db.h dbmail-2.2.12_cplogs/db.h --- dbmail-2.2.12/db.h 2009-10-07 22:44:07.000000000 +0300 +++ dbmail-2.2.12_cplogs/db.h 2009-10-08 23:43:03.000000000 +0300 @@ -949,6 +949,12 @@ int db_getmailbox(mailbox_t * mb); /** + * \brief get flag from mailbox by-name as boolean value + * + */ +gboolean db_getmailbox_flag(u64_t mailbox_idnr, const char *flagname); + +/** * \brief find owner of a mailbox * \param mboxid id of mailbox * \param owner_id will hold owner of mailbox after return @@ -1101,7 +1107,7 @@ * - -1 on failure * - 0 on success */ -int db_copymsg(u64_t msg_idnr, u64_t mailbox_to, +int db_copymsg(u64_t msg_idnr, u64_t mailbox_from, u64_t mailbox_to, u64_t user_idnr, u64_t * newmsg_idnr); /** diff -Naur dbmail-2.2.12/dbmail-imapsession.h dbmail-2.2.12_cplogs/dbmail-imapsession.h --- dbmail-2.2.12/dbmail-imapsession.h 2009-10-07 22:44:07.000000000 +0300 +++ dbmail-2.2.12_cplogs/dbmail-imapsession.h 2009-10-08 23:43:03.000000000 +0300 @@ -43,7 +43,8 @@ } cmd_store_t; typedef struct { - u64_t mailbox_id; + u64_t src_box_id; + u64_t dst_box_id; } cmd_copy_t; typedef int (*IMAP_COMMAND_HANDLER) (struct ImapSession *); diff -Naur dbmail-2.2.12/imapcommands.c dbmail-2.2.12_cplogs/imapcommands.c --- dbmail-2.2.12/imapcommands.c 2009-10-07 22:44:07.000000000 +0300 +++ dbmail-2.2.12_cplogs/imapcommands.c 2009-10-08 23:43:03.000000000 +0300 @@ -1743,7 +1743,7 @@ u64_t newid; int result; - result = db_copymsg(*id, cmd->mailbox_id, ud->userid, &newid); + result = db_copymsg(*id, cmd->src_box_id, cmd->dst_box_id, ud->userid, &newid); if (result == -1) { dbmail_imap_session_printf(self, "* BYE internal dbase error\r\n"); db_rollback_transaction(); @@ -1761,22 +1761,24 @@ int _ic_copy(struct ImapSession *self) { imap_userdata_t *ud = (imap_userdata_t *) self->ci->userData; - u64_t destmboxid; int result; - mailbox_t destmbox; + mailbox_t dst_box; + u64_t dst_box_id, src_box_id; cmd_copy_t cmd; - memset(&destmbox, 0, sizeof(destmbox)); + memset(&dst_box, 0, sizeof(dst_box)); + + src_box_id = ud->mailbox.uid; if (!check_state_and_args(self, "COPY", 2, 2, IMAPCS_SELECTED)) return 1; /* error, return */ /* check if destination mailbox exists */ - if (db_findmailbox(self->args[self->args_idx+1], ud->userid, &destmboxid) == -1) { + if (db_findmailbox(self->args[self->args_idx+1], ud->userid, &dst_box_id) == -1) { dbmail_imap_session_printf(self, "* BYE internal dbase error\r\n"); return -1; /* fatal */ } - if (destmboxid == 0) { + if (dst_box_id == 0) { /* error: cannot select mailbox */ dbmail_imap_session_printf(self, "%s NO [TRYCREATE] specified mailbox does not exist\r\n", @@ -1795,8 +1797,8 @@ return 1; } // check if user has right to COPY to destination mailbox - destmbox.uid = destmboxid; - result = acl_has_right(&destmbox, ud->userid, ACL_RIGHT_INSERT); + dst_box.uid = dst_box_id; + result = acl_has_right(&dst_box, ud->userid, ACL_RIGHT_INSERT); if (result < 0) { dbmail_imap_session_printf(self, "* BYE internal database error\r\n"); return -1; /* fatal */ @@ -1807,7 +1809,9 @@ return 1; } - cmd.mailbox_id = destmboxid; + cmd.src_box_id = src_box_id; + cmd.dst_box_id = dst_box_id; + self->cmd = &cmd; if (db_begin_transaction() < 0) diff -Naur dbmail-2.2.12/sort.c dbmail-2.2.12_cplogs/sort.c --- dbmail-2.2.12/sort.c 2009-10-07 22:44:07.000000000 +0300 +++ dbmail-2.2.12_cplogs/sort.c 2009-10-08 23:43:03.000000000 +0300 @@ -182,7 +182,7 @@ } // Ok, we have the ACL right, time to deliver the message. - switch (db_copymsg(message->id, mboxidnr, useridnr, &newmsgidnr)) { + switch (db_copymsg(message->id, 0, mboxidnr, useridnr, &newmsgidnr)) { case -2: TRACE(TRACE_DEBUG, "error copying message to user [%llu]," "maxmail exceeded", useridnr); diff -Naur dbmail-2.2.12/sql/mysql/2_2_x-2_3_0.mysql dbmail-2.2.12_cplogs/sql/mysql/2_2_x-2_3_0.mysql --- dbmail-2.2.12/sql/mysql/2_2_x-2_3_0.mysql 1970-01-01 03:00:00.000000000 +0300 +++ dbmail-2.2.12_cplogs/sql/mysql/2_2_x-2_3_0.mysql 2009-10-08 23:43:03.000000000 +0300 @@ -0,0 +1,19 @@ + +DROP TABLE IF EXISTS dbmail_cplogs; +CREATE TABLE `dbmail_cplogs` ( + `id` bigint(21) NOT NULL auto_increment, + `message_idnr` bigint(21) NOT NULL, + `mailbox_idnr` bigint(21) NOT NULL, + `direction` tinyint(1) NOT NULL, + PRIMARY KEY (`id`), + FOREIGN KEY (message_idnr) + REFERENCES dbmail_messages(message_idnr) + ON UPDATE CASCADE ON DELETE CASCADE, + FOREIGN KEY (mailbox_idnr) + REFERENCES dbmail_mailboxes(mailbox_idnr) + ON UPDATE CASCADE ON DELETE CASCADE +) ENGINE=InnoDB; + + +ALTER TABLE dbmail_mailboxes ADD cplog_flag tinyint(1) NOT NULL default '0'; +ALTER TABLE dbmail_mailboxes ADD trash_flag tinyint(1) NOT NULL default '0'; diff -Naur dbmail-2.2.12/sql/sqlite/2_2_x-2_3_0.sqlite dbmail-2.2.12_cplogs/sql/sqlite/2_2_x-2_3_0.sqlite --- dbmail-2.2.12/sql/sqlite/2_2_x-2_3_0.sqlite 1970-01-01 03:00:00.000000000 +0300 +++ dbmail-2.2.12_cplogs/sql/sqlite/2_2_x-2_3_0.sqlite 2009-10-08 23:43:03.000000000 +0300 @@ -0,0 +1,81 @@ + +-- support faster FETCH commands by caching BODYSTRUCTURE and ENVELOPE information + +CREATE TABLE dbmail_cplogs ( + id INTEGER NOT NULL PRIMARY KEY, + message_idnr INTEGER NOT NULL, + mailbox_idnr INTEGER NOT NULL, + direction boolean default '0' NOT NULL +); + +-- FOREIGN KEY (message_idnr) +-- REFERENCES dbmail_messages(message_idnr) +-- ON UPDATE CASCADE ON DELETE CASCADE, + +CREATE TRIGGER fk_insert_cplogs_message_idnr + BEFORE INSERT ON dbmail_cplogs + FOR EACH ROW BEGIN + SELECT CASE + WHEN (new.message_idnr IS NOT NULL) + AND ((SELECT message_idnr FROM dbmail_messages WHERE message_idnr = new.message_idnr) IS NULL) + THEN RAISE (ABORT, 'insert on table "dbmail_cplogs" violates foreign key constraint "fk_insert_cplogs_message_idnr"') + END; + END; +CREATE TRIGGER fk_update1_cplogs_message_idnr + BEFORE UPDATE ON dbmail_cplogs + FOR EACH ROW BEGIN + SELECT CASE + WHEN (new.message_idnr IS NOT NULL) + AND ((SELECT message_idnr FROM dbmail_messages WHERE message_idnr = new.message_idnr) IS NULL) + THEN RAISE (ABORT, 'update on table "dbmail_cplogs" violates foreign key constraint "fk_update1_cplogs_message_idnr"') + END; + END; +CREATE TRIGGER fk_update2_cplogs_message_idnr + AFTER UPDATE ON dbmail_messages + FOR EACH ROW BEGIN + UPDATE dbmail_cplogs SET message_idnr = new.message_idnr WHERE message_idnr = OLD.message_idnr; + END; +CREATE TRIGGER fk_delete_cplogs_message_idnr + BEFORE DELETE ON dbmail_messages + FOR EACH ROW BEGIN + DELETE FROM dbmail_cplogs WHERE message_idnr = OLD.message_idnr; + END; + +-- FOREIGN KEY (mailbox_idnr) +-- REFERENCES dbmail_mailboxes(mailbox_idnr) +-- ON UPDATE CASCADE ON DELETE CASCADE, + +CREATE TRIGGER fk_insert_cplogs_mailbox_idnr + BEFORE INSERT ON dbmail_cplogs + FOR EACH ROW BEGIN + SELECT CASE + WHEN (new.mailbox_idnr IS NOT NULL) + AND ((SELECT mailbox_idnr FROM dbmail_mailboxes WHERE mailbox_idnr = new.mailbox_idnr) IS NULL) + THEN RAISE (ABORT, 'insert on table "dbmail_cplogs" violates foreign key constraint "fk_insert_cplogs_mailbox_idnr"') + END; + END; +CREATE TRIGGER fk_update1_cplogs_mailbox_idnr + BEFORE UPDATE ON dbmail_cplogs + FOR EACH ROW BEGIN + SELECT CASE + WHEN (new.mailbox_idnr IS NOT NULL) + AND ((SELECT mailbox_idnr FROM dbmail_mailboxes WHERE mailbox_idnr = new.mailbox_idnr) IS NULL) + THEN RAISE (ABORT, 'update on table "dbmail_cplogs" violates foreign key constraint "fk_update1_cplogs_mailbox_idnr"') + END; + END; +CREATE TRIGGER fk_update2_cplogs_mailbox_idnr + AFTER UPDATE ON dbmail_mailboxes + FOR EACH ROW BEGIN + UPDATE dbmail_cplogs SET mailbox_idnr = new.mailbox_idnr WHERE mailbox_idnr = OLD.mailbox_idnr; + END; +CREATE TRIGGER fk_delete_cplogs_mailbox_idnr + BEFORE DELETE ON dbmail_mailboxes + FOR EACH ROW BEGIN + DELETE FROM dbmail_cplogs WHERE mailbox_idnr = OLD.mailbox_idnr; + END; + + + +ALTER TABLE dbmail_mailboxes ADD cplog_flag BOOLEAN DEFAULT '0' NOT NULL; +ALTER TABLE dbmail_mailboxes ADD trash_flag BOOLEAN DEFAULT '0' NOT NULL; + _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 internal date offset wrongJonathan Feally wrote:
> The correct operation would be to have the UTC timestamp stored in the > database. When read from the database, it is not adjusted other than to > add +0000 for a timestamp to the reformatted time. The patches > http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=296c72b96ad148a812a0c681271bca52ca10c226 > http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=01032167d087d675b92f6cca16527726db06ee84 > > only dealt with the reading part, not with insertion. So you should not > be having an issue with this change. I will quickly test it out though > to see if there is any difference for me. > > -Jon 2.2.11 - Date inserted is wrong, ie local time - thus adding the timezone offset of the same as that of the insertion yields a valid internaldate and matching when it was received. 2.2.12 - Date inserted is wrong, ie local time - returned time is then off by the timezone offset from insertion. 2.3.5+ - Date inserted is UTC - returned time is then correct as we don't tweak it, just add +0000 to it reformatted. 2.3.5+ uses dbmail_message_new() to create a new message in which the internal_date is set to the current time, not done via the SQL_CURRENT_TIMESTAMP. 2.2.x is not having internal_date set, thus the fall back is to use SQL_CURRENT_TIMESTAMP. So if the database server is not UTC, then time will be wrong. I've run out of brain power for tonight to do up a patch. Maybe you can take a look at the internal date being set on dbmail-message.c line 884 Paul? -Jon -- Scanned for viruses and dangerous content by MailScanner _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 internal date offset wrongJonathan Feally wrote:
> Jonathan Feally wrote: >> The correct operation would be to have the UTC timestamp stored in the >> database. When read from the database, it is not adjusted other than to >> add +0000 for a timestamp to the reformatted time. The patches >> http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=296c72b96ad148a812a0c681271bca52ca10c226 >> http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=01032167d087d675b92f6cca16527726db06ee84 >> >> only dealt with the reading part, not with insertion. So you should not >> be having an issue with this change. I will quickly test it out though >> to see if there is any difference for me. >> >> -Jon > And the results: (insertion with lmtp) > 2.2.11 - Date inserted is wrong, ie local time - thus adding the > timezone offset of the same as that of the insertion yields a valid > internaldate and matching when it was received. > 2.2.12 - Date inserted is wrong, ie local time - returned time is then > off by the timezone offset from insertion. > 2.3.5+ - Date inserted is UTC - returned time is then correct as we > don't tweak it, just add +0000 to it reformatted. > > 2.3.5+ uses dbmail_message_new() to create a new message in which the > internal_date is set to the current time, not done via the > SQL_CURRENT_TIMESTAMP. > 2.2.x is not having internal_date set, thus the fall back is to use > SQL_CURRENT_TIMESTAMP. So if the database server is not UTC, then time > will be wrong. > > > I've run out of brain power for tonight to do up a patch. Maybe you can > take a look at the internal date being set on dbmail-message.c line 884 Thanks a lot Jon, your triage put me on the right track. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 internal date offset wrongOn Friday 09 October 2009 02:19:47 am Paul J Stevens wrote:
> Jonathan Feally wrote: > > Jonathan Feally wrote: > >> The correct operation would be to have the UTC timestamp stored in the > >> database. When read from the database, it is not adjusted other than to > >> add +0000 for a timestamp to the reformatted time. The patches > >> http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=2 > >>96c72b96ad148a812a0c681271bca52ca10c226 > >> http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=0 > >>1032167d087d675b92f6cca16527726db06ee84 > >> > >> only dealt with the reading part, not with insertion. So you should not > >> be having an issue with this change. I will quickly test it out though > >> to see if there is any difference for me. > >> > >> -Jon > > > > And the results: (insertion with lmtp) > > 2.2.11 - Date inserted is wrong, ie local time - thus adding the > > timezone offset of the same as that of the insertion yields a valid > > internaldate and matching when it was received. > > 2.2.12 - Date inserted is wrong, ie local time - returned time is then > > off by the timezone offset from insertion. > > 2.3.5+ - Date inserted is UTC - returned time is then correct as we > > don't tweak it, just add +0000 to it reformatted. > > > > 2.3.5+ uses dbmail_message_new() to create a new message in which the > > internal_date is set to the current time, not done via the > > SQL_CURRENT_TIMESTAMP. > > 2.2.x is not having internal_date set, thus the fall back is to use > > SQL_CURRENT_TIMESTAMP. So if the database server is not UTC, then time > > will be wrong. > > > > > > I've run out of brain power for tonight to do up a patch. Maybe you can > > take a look at the internal date being set on dbmail-message.c line 884 > > Thanks a lot Jon, your triage put me on the right track. > To answer Jon's questions: Timezone: CDT Insertion: LMTP I am not able to do a comparison on the message before and after the upgrade. Sorry for the delay here, do you need any further testing from me? Thanks. -- Bret Baptist Senior Network Administrator bbaptist@... Internet Exposure, Inc. http://www.iexposure.com (612) 676-1946 x117 Providing Internet Services since 1995 Web Development ~ Search Engine Marketing ~ Web Analytics Network Security ~ On Demand Tech Support ~ E-Mail Marketing _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedOn Thursday 08 October 2009 12:28:41 pm Paul J Stevens wrote:
> Bret Baptist wrote: > > It looks like this version broke POP before SMTP. I am not getting an > > update on the time stamp in the database when people check their email. > > Bret, > > I can't reproduce this. I'm getting updates just fine. > > What is your BINDIP setup? > In addition it is not creating new entries for me either. Thanks. -- Bret Baptist Senior Network Administrator bbaptist@... Internet Exposure, Inc. http://www.iexposure.com (612) 676-1946 x117 Providing Internet Services since 1995 Web Development ~ Search Engine Marketing ~ Web Analytics Network Security ~ On Demand Tech Support ~ E-Mail Marketing _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedBret Baptist wrote:
> Also looks like the "internaldate as UTC" is causing issues with Mac Mail and > older Outlook clients. They are subtracting the time zone offset from the > received time. I can confirm this. After upgrade to 2.2.12 MS Outlook 2000 user complained that incoming email have correct date when they come in and are unread. However after reading the message the dates change 3 hours which is the local difference with UTC. Regards, -- Aleksander Kamenik System Administrator Krediidiinfo AS an Experian Company Phone: +372 665 9649 Email: aleksander@... http://www.krediidiinfo.ee/ http://www.experiangroup.com/ _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedAleksander Kamenik wrote:
> Bret Baptist wrote: > >> Also looks like the "internaldate as UTC" is causing issues with Mac Mail and >> older Outlook clients. They are subtracting the time zone offset from the >> received time. >> > > I can confirm this. After upgrade to 2.2.12 MS Outlook 2000 user > complained that incoming email have correct date when they come in and > are unread. However after reading the message the dates change 3 hours > which is the local difference with UTC. > > Regards, > > Paul, Can we get a 2.2.12.1 release because of the bugs and missing configure related files? -Jon -- Scanned for viruses and dangerous content by MailScanner _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedJonathan Feally wrote:
> We have fixed this in the git tree. > > Paul, > Can we get a 2.2.12.1 release because of the bugs and missing configure > related files? Hi Paul, I've promised at that time to my users that the date issue would be fixed soon. Is there going to be a new release soon or should I install from git? Regards, -- Aleksander Kamenik System Administrator Krediidiinfo AS an Experian Company Phone: +372 665 9649 Email: aleksander@... http://www.krediidiinfo.ee/ http://www.experiangroup.com/ _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
|
|
Re: DBMail 2.2.12 releasedAleksander Kamenik wrote:
> Jonathan Feally wrote: >> We have fixed this in the git tree. >> >> Paul, >> Can we get a 2.2.12.1 release because of the bugs and missing configure >> related files? > > Hi Paul, > > I've promised at that time to my users that the date issue would be > fixed soon. Is there going to be a new release soon or should I install > from git? I just uploaded 2.2.13. I won't have time today for formal announcements. debian/stable debs are forthcoming though. FYI, this release mainly fixes the UTC offset regression. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list DBmail@... http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |