[Dbmail-dev] [DBMail 0000471]: OR SEARCH not working: SEARCH OR FROM "alarm" SUBJECT "alarm"
The following issue has been ASSIGNED. == http://www.dbmail.org/mantis/view.php?id=471 == Reported By:lkneschke Assigned To:paul == Project:DBMail Issue ID: 471 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: assigned target: == Date Submitted: 10-Dec-06 22:56 CET Last Modified: 11-Dec-06 10:09 CET == Summary:OR SEARCH not working: SEARCH OR FROM "alarm" SUBJECT "alarm" Description: This search SEARCH OR FROM "alarm" SUBJECT "alarm" should report 3 messages. But it returns no messages. Seems like the result get's always AND'ED. I'm very sure that the search filter is syntactical correct, because i tested it against a cyrus imap server. Find the level 5 log below. Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Info:[imap] imap4.c,IMAPClientHandler(+200): COMMAND: [A0008 SEARCH OR FROM "alarm" SUBJECT "alarm"] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[0]: 'OR' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[1]: 'FROM' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[2]: 'alarm' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[3]: 'SUBJECT' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[4]: 'alarm' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Info:[imap] imap4.c,IMAPClientHandler(+313): Executing command search... Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4222): checking ACL [read_flag] for user [4] on mailbox [6] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4232): mailbox [6] is owned by user [4], is that also [4]? Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4236): mailbox [6] is owned by user [4], giving all rights Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages WHERE mailbox_idnr = 6 AND status IN (0,1) ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135756168] [1] type [2] field [] search [1:*] at depth [1] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135760432] [1] type [15] field [] search [] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135764696] [0] type [5] field [from] search [alarm] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135768960] [0] type [5] field [subject] search [alarm] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,dbmail_mailbox_get_set(+1229): [1:*] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[misc] misc.c,g_tree_merge(+1206): a[0] [OR] b[11] -> a[11] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135756168] depth [1] type [2] rows [11] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id JOIN dbmail_headername n ON v.headername_id=n.id WHERE mailbox_idnr = 6 AND status IN (0,1) AND headername LIKE 'from' AND headervalue LIKE '%alarm%' ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135764696] depth [3] type [5] rows [3] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id JOIN dbmail_headername n ON v.headername_id=n.id WHERE mailbox_idnr = 6 AND status IN (0,1) AND headername LIKE 'subject' AND headervalue LIKE '%alarm%' ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135768960] depth [3] type [5] rows [0] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbo
[Dbmail-dev] [DBMail 0000471]: OR SEARCH not working: SEARCH OR FROM "alarm" SUBJECT "alarm"
A NOTE has been added to this issue. == http://www.dbmail.org/mantis/view.php?id=471 == Reported By:lkneschke Assigned To:paul == Project:DBMail Issue ID: 471 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: assigned target: == Date Submitted: 10-Dec-06 22:56 CET Last Modified: 11-Dec-06 10:31 CET == Summary:OR SEARCH not working: SEARCH OR FROM "alarm" SUBJECT "alarm" Description: This search SEARCH OR FROM "alarm" SUBJECT "alarm" should report 3 messages. But it returns no messages. Seems like the result get's always AND'ED. I'm very sure that the search filter is syntactical correct, because i tested it against a cyrus imap server. Find the level 5 log below. Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Info:[imap] imap4.c,IMAPClientHandler(+200): COMMAND: [A0008 SEARCH OR FROM "alarm" SUBJECT "alarm"] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[0]: 'OR' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[1]: 'FROM' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[2]: 'alarm' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[3]: 'SUBJECT' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[4]: 'alarm' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Info:[imap] imap4.c,IMAPClientHandler(+313): Executing command search... Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4222): checking ACL [read_flag] for user [4] on mailbox [6] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4232): mailbox [6] is owned by user [4], is that also [4]? Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4236): mailbox [6] is owned by user [4], giving all rights Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages WHERE mailbox_idnr = 6 AND status IN (0,1) ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135756168] [1] type [2] field [] search [1:*] at depth [1] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135760432] [1] type [15] field [] search [] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135764696] [0] type [5] field [from] search [alarm] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135768960] [0] type [5] field [subject] search [alarm] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,dbmail_mailbox_get_set(+1229): [1:*] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[misc] misc.c,g_tree_merge(+1206): a[0] [OR] b[11] -> a[11] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135756168] depth [1] type [2] rows [11] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id JOIN dbmail_headername n ON v.headername_id=n.id WHERE mailbox_idnr = 6 AND status IN (0,1) AND headername LIKE 'from' AND headervalue LIKE '%alarm%' ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135764696] depth [3] type [5] rows [3] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id JOIN dbmail_headername n ON v.headername_id=n.id WHERE mailbox_idnr = 6 AND status IN (0,1) AND headername LIKE 'subject' AND headervalue LIKE '%alarm%' ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135768960] depth [3] type [5] rows [0] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.
[Dbmail-dev] [DBMail 0000471]: OR SEARCH not working: SEARCH OR FROM "alarm" SUBJECT "alarm"
A NOTE has been added to this issue. == http://www.dbmail.org/mantis/view.php?id=471 == Reported By:lkneschke Assigned To:paul == Project:DBMail Issue ID: 471 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: assigned target: == Date Submitted: 10-Dec-06 22:56 CET Last Modified: 11-Dec-06 11:23 CET == Summary:OR SEARCH not working: SEARCH OR FROM "alarm" SUBJECT "alarm" Description: This search SEARCH OR FROM "alarm" SUBJECT "alarm" should report 3 messages. But it returns no messages. Seems like the result get's always AND'ED. I'm very sure that the search filter is syntactical correct, because i tested it against a cyrus imap server. Find the level 5 log below. Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Info:[imap] imap4.c,IMAPClientHandler(+200): COMMAND: [A0008 SEARCH OR FROM "alarm" SUBJECT "alarm"] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[0]: 'OR' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[1]: 'FROM' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[2]: 'alarm' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[3]: 'SUBJECT' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[imapsession] dbmail-imapsession.c,build_args_array_ext(+2132): arg[4]: 'alarm' Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Info:[imap] imap4.c,IMAPClientHandler(+313): Executing command search... Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4222): checking ACL [read_flag] for user [4] on mailbox [6] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4232): mailbox [6] is owned by user [4], is that also [4]? Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[db] db.c,db_acl_has_right(+4236): mailbox [6] is owned by user [4], giving all rights Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages WHERE mailbox_idnr = 6 AND status IN (0,1) ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135756168] [1] type [2] field [] search [1:*] at depth [1] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135760432] [1] type [15] field [] search [] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135764696] [0] type [5] field [from] search [alarm] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,append_search(+521): [135768960] [0] type [5] field [subject] search [alarm] at depth [2] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,dbmail_mailbox_get_set(+1229): [1:*] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[misc] misc.c,g_tree_merge(+1206): a[0] [OR] b[11] -> a[11] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135756168] depth [1] type [2] rows [11] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id JOIN dbmail_headername n ON v.headername_id=n.id WHERE mailbox_idnr = 6 AND status IN (0,1) AND headername LIKE 'from' AND headervalue LIKE '%alarm%' ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135764696] depth [3] type [5] rows [3] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[sql] dbmysql.c,db_query(+286): query [SELECT message_idnr FROM dbmail_messages m JOIN dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue v ON v.physmessage_id=p.id JOIN dbmail_headername n ON v.headername_id=n.id WHERE mailbox_idnr = 6 AND status IN (0,1) AND headername LIKE 'subject' AND headervalue LIKE '%alarm%' ORDER BY message_idnr] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.c,_do_search(+1384): [135768960] depth [3] type [5] rows [0] Dec 5 20:32:32 ubuntu dbmail/imap4d[22969]: Debug:[mailbox] dbmail-mailbox.
[Dbmail-dev] [DBMail 0000462]: imap daemon appears to leak memory on FETCH command
A NOTE has been added to this issue. == http://www.dbmail.org/mantis/view.php?id=462 == Reported By:fehuq Assigned To: == Project:DBMail Issue ID: 462 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: new target: == Date Submitted: 29-Nov-06 15:13 CET Last Modified: 11-Dec-06 15:00 CET == Summary:imap daemon appears to leak memory on FETCH command Description: I delivered several thousand messages to an account on a test server, and set up an IMAP account in Thunderbird to access it. Thunderbird ran its junkmail controls on the folder, which issues a FETCH command for each message. I noticed later that the dbmail-imapd child process handling my connection had used almost all of the system's free memory and swap. As best as I can tell, the process usually doesn't free memory used after a message is fetched. I'm attaching a text file containing top's output of the process at 3 second intervals. The memory usage does drop a bit in some of the intervals, but overall it gets large fairly fast. Killing, or having dbmail restart the child process after 1 connection does successfully free the memory, though. The pop server does not show the same behavior. == Relationships ID Summary -- has duplicate 469 dbmail-imapd fetches all available memory == -- fehuq - 29-Nov-06 15:24 -- I should have added about the top output that it's just a small sample, over the course of about a minute and a half of a new process as I fetch all the messages. It's not meant to show a process using all system memory. -- aaron - 09-Dec-06 06:09 -- Using the fetches you've shown and running through 'valgrind dbmail-imapd -n' and typing them in by hand, against my testing database, I found no active leaks. Maybe the leaks depend upon the messages themselves? (*ugh*) -- Valen - 09-Dec-06 08:45 -- I have a system that exhibits this symptom, I don't have the skill to run the test but dbmail can be built on the system (and has been in the past) if an admin wants to login and check it out let me know. -- paul - 09-Dec-06 18:46 -- I've been busy running valgrind, and I can't find *any* significant leaks either. But I am working on reducing memory usage in dbmail-message.c by doing less copying which may affect this bug when I merge that change. -- Valen - 10-Dec-06 01:40 -- attached files with memory graph from massif, this is the result of copying 100 emails with imapcopy -- Valen - 10-Dec-06 06:26 -- found perhaps the causes of the problems and i got debug turned on so it should be extra helpfull. Called from: 41.8% : 0x4128031: g_malloc (in /usr/lib/libglib-2.0.so.0.1000.2) 24.8% : 0x401C3EB: posix_memalign (vg_replace_malloc.c:384) 15.4% : 0x4127F1E: g_realloc (in /usr/lib/libglib-2.0.so.0.1000.2) 11.0% : 0x4434D69: my_realloc (in /usr/lib/libmysqlclient.so.15.0.0) 1.8% : 0x4434B86: my_malloc (in /usr/lib/libmysqlclient.so.15.0.0) 1.8% : 0x443B415: my_once_alloc (in /usr/lib/libmysqlclient.so.15.0.0) 0.7% : 0x4127FB9: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1000.2) and 33 other insignificant places == 1 === Context accounted for 41.8% of measured spacetime 0x4128031: g_malloc (in /usr/lib/libglib-2.0.so.0.1000.2) Called from: 33.4% : 0x8052491: mopen (memblock.c:64) 19.8% : 0x805255E: __m_blkadd (memblock.c:435) 1.5%
[Dbmail-dev] [DBMail 0000462]: imap daemon appears to leak memory on FETCH command
A NOTE has been added to this issue. == http://www.dbmail.org/mantis/view.php?id=462 == Reported By:fehuq Assigned To: == Project:DBMail Issue ID: 462 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: new target: == Date Submitted: 29-Nov-06 15:13 CET Last Modified: 11-Dec-06 15:01 CET == Summary:imap daemon appears to leak memory on FETCH command Description: I delivered several thousand messages to an account on a test server, and set up an IMAP account in Thunderbird to access it. Thunderbird ran its junkmail controls on the folder, which issues a FETCH command for each message. I noticed later that the dbmail-imapd child process handling my connection had used almost all of the system's free memory and swap. As best as I can tell, the process usually doesn't free memory used after a message is fetched. I'm attaching a text file containing top's output of the process at 3 second intervals. The memory usage does drop a bit in some of the intervals, but overall it gets large fairly fast. Killing, or having dbmail restart the child process after 1 connection does successfully free the memory, though. The pop server does not show the same behavior. == Relationships ID Summary -- has duplicate 469 dbmail-imapd fetches all available memory == -- fehuq - 29-Nov-06 15:24 -- I should have added about the top output that it's just a small sample, over the course of about a minute and a half of a new process as I fetch all the messages. It's not meant to show a process using all system memory. -- aaron - 09-Dec-06 06:09 -- Using the fetches you've shown and running through 'valgrind dbmail-imapd -n' and typing them in by hand, against my testing database, I found no active leaks. Maybe the leaks depend upon the messages themselves? (*ugh*) -- Valen - 09-Dec-06 08:45 -- I have a system that exhibits this symptom, I don't have the skill to run the test but dbmail can be built on the system (and has been in the past) if an admin wants to login and check it out let me know. -- paul - 09-Dec-06 18:46 -- I've been busy running valgrind, and I can't find *any* significant leaks either. But I am working on reducing memory usage in dbmail-message.c by doing less copying which may affect this bug when I merge that change. -- Valen - 10-Dec-06 01:40 -- attached files with memory graph from massif, this is the result of copying 100 emails with imapcopy -- Valen - 10-Dec-06 06:26 -- found perhaps the causes of the problems and i got debug turned on so it should be extra helpfull. Called from: 41.8% : 0x4128031: g_malloc (in /usr/lib/libglib-2.0.so.0.1000.2) 24.8% : 0x401C3EB: posix_memalign (vg_replace_malloc.c:384) 15.4% : 0x4127F1E: g_realloc (in /usr/lib/libglib-2.0.so.0.1000.2) 11.0% : 0x4434D69: my_realloc (in /usr/lib/libmysqlclient.so.15.0.0) 1.8% : 0x4434B86: my_malloc (in /usr/lib/libmysqlclient.so.15.0.0) 1.8% : 0x443B415: my_once_alloc (in /usr/lib/libmysqlclient.so.15.0.0) 0.7% : 0x4127FB9: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1000.2) and 33 other insignificant places == 1 === Context accounted for 41.8% of measured spacetime 0x4128031: g_malloc (in /usr/lib/libglib-2.0.so.0.1000.2) Called from: 33.4% : 0x8052491: mopen (memblock.c:64) 19.8% : 0x805255E: __m_blkadd (memblock.c:435) 1.5%
[Dbmail-dev] [DBMail 0000472]: GLib-CRITICAL
The following issue has been SUBMITTED. == http://www.dbmail.org/mantis/view.php?id=472 == Reported By:zul Assigned To: == Project:DBMail Issue ID: 472 Category: General Reproducibility:always Severity: minor Priority: normal Status: new target: == Date Submitted: 11-Dec-06 22:25 CET Last Modified: 11-Dec-06 22:25 CET == Summary:GLib-CRITICAL Description: fester0-netsrv:~# echo "test"|dbmail-smtp -d [EMAIL PROTECTED] (process:9212): GLib-CRITICAL **: g_string_free: assertion `string != NULL' failed I saw this error with dbmail-smtp and dbmail-sievecmd. Dbmail was install from debs with modified depends. I saw this error with dbmail compiled from source too (CFLAGS='march=amd64') on the same arch/OS. This issue are NOT crush delivery process. == Issue History Date Modified Username FieldChange == 11-Dec-06 22:25 zulNew Issue == ___ Dbmail-dev mailing list [EMAIL PROTECTED] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000472]: GLib-CRITICAL
A NOTE has been added to this issue. == http://www.dbmail.org/mantis/view.php?id=472 == Reported By:zul Assigned To: == Project:DBMail Issue ID: 472 Category: General Reproducibility:always Severity: minor Priority: normal Status: new target: == Date Submitted: 11-Dec-06 22:25 CET Last Modified: 11-Dec-06 22:40 CET == Summary:GLib-CRITICAL Description: fester0-netsrv:~# echo "test"|dbmail-smtp -d [EMAIL PROTECTED] (process:9212): GLib-CRITICAL **: g_string_free: assertion `string != NULL' failed I saw this error with dbmail-smtp and dbmail-sievecmd. Dbmail was install from debs with modified depends. I saw this error with dbmail compiled from source too (CFLAGS='march=amd64') on the same arch/OS. This issue are NOT crush delivery process. == -- zul - 11-Dec-06 22:40 -- oops. dbmail 2.2.1 of course Issue History Date Modified Username FieldChange == 11-Dec-06 22:25 zulNew Issue 11-Dec-06 22:40 zulNote Added: 0001672 == ___ Dbmail-dev mailing list [EMAIL PROTECTED] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000195]: autoconf detection of ldap headers and libraries fails on netbsd
A NOTE has been added to this issue. == http://www.dbmail.org/mantis/view.php?id=195 == Reported By:paul Assigned To:paul == Project:DBMail Issue ID: 195 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: assigned target: == Date Submitted: 13-Apr-05 15:49 CEST Last Modified: 12-Dec-06 08:11 CET == Summary:autoconf detection of ldap headers and libraries fails on netbsd Description: acinclude.m4 needs to be fixed to scan more intelligently for the includes and libs required by --with-auth-ldap. == -- aaron - 13-May-06 08:09 -- This is fine in SVN trunk since who knows how long ago! Any other interesting paths that are needed should just be added to ldapheaderpaths in configure.in. -- paul - 13-May-06 10:21 -- Aaron, Have you tested on netbsd? Or any *bsd? The ldap autoconf macros do *not* work as they should on netbsd. Even if I fix the ldapheaderpaths so DBMAIL_AUTH_CONF works, DBMAIL_CHECK_LDAP_LIBS still fail. Doesn't look too hard, but I havent fixed it yet. -- aaron - 12-Dec-06 08:11 -- DBMAIL_CHECK_SIEVE_LIBS is also broken in the same way. Needs fixing! Working on it now, should have a fix later this week! Issue History Date Modified Username FieldChange == 13-Apr-05 15:49 paul New Issue 13-May-06 08:09 aaron Status assigned => resolved 13-May-06 08:09 aaron Fixed in Version => SVN Trunk 13-May-06 08:09 aaron Resolution open => fixed 13-May-06 08:09 aaron Note Added: 0001172 13-May-06 10:21 paul Note Added: 0001174 13-May-06 10:21 paul Status resolved => assigned 13-May-06 10:21 paul Resolution fixed => reopened 13-May-06 10:21 paul Fixed in Version SVN Trunk => 12-Dec-06 08:11 aaron Note Added: 0001673 == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000195]: autoconf detection of ldap headers and libraries fails on netbsd
The following issue has been ASSIGNED. == http://www.dbmail.org/mantis/view.php?id=195 == Reported By:paul Assigned To:aaron == Project:DBMail Issue ID: 195 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: assigned target: == Date Submitted: 13-Apr-05 15:49 CEST Last Modified: 12-Dec-06 08:11 CET == Summary:autoconf detection of ldap headers and libraries fails on netbsd Description: acinclude.m4 needs to be fixed to scan more intelligently for the includes and libs required by --with-auth-ldap. == -- aaron - 13-May-06 08:09 -- This is fine in SVN trunk since who knows how long ago! Any other interesting paths that are needed should just be added to ldapheaderpaths in configure.in. -- paul - 13-May-06 10:21 -- Aaron, Have you tested on netbsd? Or any *bsd? The ldap autoconf macros do *not* work as they should on netbsd. Even if I fix the ldapheaderpaths so DBMAIL_AUTH_CONF works, DBMAIL_CHECK_LDAP_LIBS still fail. Doesn't look too hard, but I havent fixed it yet. -- aaron - 12-Dec-06 08:11 -- DBMAIL_CHECK_SIEVE_LIBS is also broken in the same way. Needs fixing! Working on it now, should have a fix later this week! Issue History Date Modified Username FieldChange == 13-Apr-05 15:49 paul New Issue 13-May-06 08:09 aaron Status assigned => resolved 13-May-06 08:09 aaron Fixed in Version => SVN Trunk 13-May-06 08:09 aaron Resolution open => fixed 13-May-06 08:09 aaron Note Added: 0001172 13-May-06 10:21 paul Note Added: 0001174 13-May-06 10:21 paul Status resolved => assigned 13-May-06 10:21 paul Resolution fixed => reopened 13-May-06 10:21 paul Fixed in Version SVN Trunk => 12-Dec-06 08:11 aaron Note Added: 0001673 12-Dec-06 08:11 aaron Assigned To paul => aaron == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000472]: GLib-CRITICAL
The following issue has been set as DUPLICATE OF issue 461. == http://www.dbmail.org/mantis/view.php?id=472 == Reported By:zul Assigned To: == Project:DBMail Issue ID: 472 Category: General Reproducibility:always Severity: minor Priority: normal Status: new target: == Date Submitted: 11-Dec-06 22:25 CET Last Modified: 12-Dec-06 09:35 CET == Summary:GLib-CRITICAL Description: fester0-netsrv:~# echo "test"|dbmail-smtp -d [EMAIL PROTECTED] (process:9212): GLib-CRITICAL **: g_string_free: assertion `string != NULL' failed I saw this error with dbmail-smtp and dbmail-sievecmd. Dbmail was install from debs with modified depends. I saw this error with dbmail compiled from source too (CFLAGS='march=amd64') on the same arch/OS. This issue are NOT crush delivery process. == Relationships ID Summary -- duplicate of461 dbmail-smtp dies with segmentation faul... == -- zul - 11-Dec-06 22:40 -- oops. dbmail 2.2.1 of course Issue History Date Modified Username FieldChange == 11-Dec-06 22:25 zulNew Issue 11-Dec-06 22:40 zulNote Added: 0001672 12-Dec-06 09:35 paul Relationship added duplicate of 461 == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000461]: dbmail-smtp dies with segmentation fault (11) upon delivery of messages with certain headers...
The issue 472 has been set as DUPLICATE OF the following issue. == http://www.dbmail.org/mantis/view.php?id=461 == Reported By:johnke Assigned To:aaron == Project:DBMail Issue ID: 461 Category: PIPE delivery (dbmail-smtp) Reproducibility:always Severity: major Priority: normal Status: resolved target: Resolution: fixed Fixed in Version: 2.2 branch == Date Submitted: 28-Nov-06 23:21 CET Last Modified: 09-Dec-06 02:40 CET == Summary:dbmail-smtp dies with segmentation fault (11) upon delivery of messages with certain headers... Description: When delivering messages to DBMail via dbmail-smtp with certain header characteristics (seems to be headers with no content and headers with certain lengths) dbmail-smtp will segfault. Varying the length of any header or its contents beneath the empty header (like "To: [empty]") will cause the message to be delivered. Only certain header lengths will cause the segfault to occur. The attached message will cause a segfault on one of our 32-bit, nearly-identical mail systems but not another one until any header is lengthened by a few characters. This is untested on 64-bit systems. == Relationships ID Summary -- has duplicate 472 GLib-CRITICAL == -- johnke - 28-Nov-06 23:26 -- The end-of-line convention used in the base64-encoded portion of the message is not the cause of the issue. The original message used standard \n EOL and caused the same segfaults. The body of this message was generated simply to reproduce the size and basic content of the original. -- stsch - 09-Dec-06 01:06 -- I can reproduce this behavior on OpenBSD/amd64 . When delivering messages which contain empty mail-header like the uploaded message, then dbmail-smtpd mostly dies - but not always ! It seems that is not a good idea to feed imap_cleanup_address(const char *a) with empty(?) values. The uploaded patch ( see file misc_c.patch ) fixed the problem for me. -- aaron - 09-Dec-06 02:40 -- I took a slightly different approach to avoid the strlen call. Added two test cases to cover zero length and null inputs to imap_cleanup_address. Now in SVN Issue History Date Modified Username FieldChange == 28-Nov-06 23:21 johnke New Issue 28-Nov-06 23:21 johnke File Added: messageFile.bz2 28-Nov-06 23:26 johnke Note Added: 0001632 09-Dec-06 00:35 stsch File Added: misc_c.patch 09-Dec-06 01:06 stsch Note Added: 0001658 09-Dec-06 02:40 aaron Status new => resolved 09-Dec-06 02:40 aaron Fixed in Version => 2.2 branch 09-Dec-06 02:40 aaron Resolution open => fixed 09-Dec-06 02:40 aaron Assigned To => aaron 09-Dec-06 02:40 aaron Note Added: 0001659 12-Dec-06 09:35 paul Relationship added has duplicate 472 == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000472]: GLib-CRITICAL
The following issue has been RESOLVED. == http://www.dbmail.org/mantis/view.php?id=472 == Reported By:zul Assigned To:paul == Project:DBMail Issue ID: 472 Category: General Reproducibility:always Severity: minor Priority: normal Status: resolved target: Resolution: fixed Fixed in Version: == Date Submitted: 11-Dec-06 22:25 CET Last Modified: 12-Dec-06 09:36 CET == Summary:GLib-CRITICAL Description: fester0-netsrv:~# echo "test"|dbmail-smtp -d [EMAIL PROTECTED] (process:9212): GLib-CRITICAL **: g_string_free: assertion `string != NULL' failed I saw this error with dbmail-smtp and dbmail-sievecmd. Dbmail was install from debs with modified depends. I saw this error with dbmail compiled from source too (CFLAGS='march=amd64') on the same arch/OS. This issue are NOT crush delivery process. == Relationships ID Summary -- duplicate of461 dbmail-smtp dies with segmentation faul... == -- zul - 11-Dec-06 22:40 -- oops. dbmail 2.2.1 of course -- paul - 12-Dec-06 09:36 -- this is a dupe so I'm closing Issue History Date Modified Username FieldChange == 11-Dec-06 22:25 zulNew Issue 11-Dec-06 22:40 zulNote Added: 0001672 12-Dec-06 09:35 paul Relationship added duplicate of 461 12-Dec-06 09:36 paul Duplicate ID 0 => 461 12-Dec-06 09:36 paul Status new => resolved 12-Dec-06 09:36 paul Resolution open => fixed 12-Dec-06 09:36 paul Assigned To => paul 12-Dec-06 09:36 paul Note Added: 0001674 == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000473]: SEARCH with CHARSET not working
The following issue has been SUBMITTED. == http://www.dbmail.org/mantis/view.php?id=473 == Reported By:lkneschke Assigned To: == Project:DBMail Issue ID: 473 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: new target: == Date Submitted: 12-Dec-06 09:47 CET Last Modified: 12-Dec-06 09:47 CET == Summary:SEARCH with CHARSET not working Description: Hello! When executing the search command, you can also define a charset like this: SEARCH CHARSET UTF-8 SUBJECT "some utf-8 encoded search string" Unfortunately, DBMAIL again thinks that we sent some invalid chars and returns nothing. I think that the check for valid chars needs to get reworked somehow. If we can support only US-ASCII searches, the RFC says that the imap server should return a useful response, if the the charset is not supported. The response should contain the supported charsets. == Issue History Date Modified Username FieldChange == 12-Dec-06 09:47 lkneschke New Issue == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000473]: SEARCH with CHARSET not working
The following issue has been RESOLVED. == http://www.dbmail.org/mantis/view.php?id=473 == Reported By:lkneschke Assigned To:paul == Project:DBMail Issue ID: 473 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: resolved target: Resolution: fixed Fixed in Version: 2.2.2 == Date Submitted: 12-Dec-06 09:47 CET Last Modified: 12-Dec-06 10:31 CET == Summary:SEARCH with CHARSET not working Description: Hello! When executing the search command, you can also define a charset like this: SEARCH CHARSET UTF-8 SUBJECT "some utf-8 encoded search string" Unfortunately, DBMAIL again thinks that we sent some invalid chars and returns nothing. I think that the check for valid chars needs to get reworked somehow. If we can support only US-ASCII searches, the RFC says that the imap server should return a useful response, if the the charset is not supported. The response should contain the supported charsets. == -- paul - 12-Dec-06 10:31 -- I've removed the check altogether. rev 2394 Issue History Date Modified Username FieldChange == 12-Dec-06 09:47 lkneschke New Issue 12-Dec-06 10:31 paul Note Added: 0001675 12-Dec-06 10:31 paul Assigned To => paul 12-Dec-06 10:31 paul Status new => resolved 12-Dec-06 10:31 paul Resolution open => fixed 12-Dec-06 10:31 paul Fixed in Version => 2.2.2 == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000473]: SEARCH with CHARSET not working
The following issue has been REOPENED. == http://www.dbmail.org/mantis/view.php?id=473 == Reported By:lkneschke Assigned To:paul == Project:DBMail Issue ID: 473 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: feedback target: == Date Submitted: 12-Dec-06 09:47 CET Last Modified: 12-Dec-06 12:46 CET == Summary:SEARCH with CHARSET not working Description: Hello! When executing the search command, you can also define a charset like this: SEARCH CHARSET UTF-8 SUBJECT "some utf-8 encoded search string" Unfortunately, DBMAIL again thinks that we sent some invalid chars and returns nothing. I think that the check for valid chars needs to get reworked somehow. If we can support only US-ASCII searches, the RFC says that the imap server should return a useful response, if the the charset is not supported. The response should contain the supported charsets. == -- paul - 12-Dec-06 10:31 -- I've removed the check altogether. rev 2394 -- lkneschke - 12-Dec-06 12:46 -- The problem is not solved completly. Now i can execute something like this: UID SEARCH CHARSET UTF-8 SUBJECT "ö" But dbmail does not find any message. Because the sql query is like this: SELECT message_idnr ... AND headername LIKE 'subject' AND headervalue LIKE '%ö%' ORDER BY message_idnr And the value in the database is like this: +---++-+--+ | headername_id | physmessage_id | id | headervalue | +---++-+--+ | 7 | 29 | 393 | Test mit =?iso-8859-1?q?=D6?= Attachment | +---++-+--+ As you can see, the headervalue is still quotedprintable, which does not allow to find something which contains other then US-ASCII characters. I did not have a look at it, but i'm sure that the full text search over the body will have the same problem. Maybe it would be a good idea, to have the encode the headervalues from quoted printable and store them UFT-8 encoded in a additional row. Then we would be able to use this additional row for searching. Issue History Date Modified Username FieldChange == 12-Dec-06 09:47 lkneschke New Issue 12-Dec-06 10:31 paul Note Added: 0001675 12-Dec-06 10:31 paul Assigned To => paul 12-Dec-06 10:31 paul Status new => resolved 12-Dec-06 10:31 paul Resolution open => fixed 12-Dec-06 10:31 paul Fixed in Version => 2.2.2 12-Dec-06 12:46 lkneschke Status resolved => feedback 12-Dec-06 12:46 lkneschke Resolution fixed => reopened 12-Dec-06 12:46 lkneschke Note Added: 0001676 == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0000065]: LDAP Authentications needs to be fixed.
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_page.php?bug_id=065 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 65 Category: Authentication layer Reproducibility:N/A Severity: major Priority: normal Status: new == Date Submitted: 18-Aug-04 14:35 CEST Last Modified: 18-Aug-04 14:35 CEST == Summary:LDAP Authentications needs to be fixed. Description: LDAP Authentication currently does not work. Mostly because most other code hasn't been written with the LDAP authentication in mind. == Bug History Date Modified Username FieldChange == 18-Aug-04 14:35ilja New Bug ==
[Dbmail-dev] [DBMail 0000065]: LDAP Authentications needs to be fixed.
The following bug has been CONFIRMED. == http://www.dbmail.org/mantis/bug_view_page.php?bug_id=065 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 65 Category: Authentication layer Reproducibility:N/A Severity: major Priority: normal Status: confirmed == Date Submitted: 18-Aug-04 14:35 CEST Last Modified: 18-Aug-04 14:41 CEST == Summary:LDAP Authentications needs to be fixed. Description: LDAP Authentication currently does not work. Mostly because most other code hasn't been written with the LDAP authentication in mind. == Bug History Date Modified Username FieldChange == 18-Aug-04 14:35ilja New Bug 18-Aug-04 14:41ilja Status new => confirmed 18-Aug-04 14:41ilja version => CVS HEAD ==
[Dbmail-dev] [DBMail 0000004]: fix TO header for BTS
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=004 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 4 Category: www.dbmail.org website Reproducibility:always Severity: minor Priority: normal Status: assigned == Date Submitted: 09-Jul-04 10:38 CEST Last Modified: 18-Aug-04 15:47 CEST == Summary:fix TO header for BTS Description: The standard To header for this bug tracking system is to [EMAIL PROTECTED] I think bug reports should also be submitted to the list by default as well. Dan == -- ilja - 09-Jul-04 14:23 CEST -- We need to know if people on the dev-list really want this. I can see that it might be important to show that the bugtracker is alive and things are being changed and fixed. -- aaron - 14-Jul-04 03:24 CEST -- It's a pretty good idea, the one thing I'd be concerned about is coordinating discussions between the mailing lists and the bug tracker. Bug History Date Modified Username FieldChange == 09-Jul-04 10:38danweber New Bug 09-Jul-04 14:23ilja Bugnote Added: 003 09-Jul-04 14:23ilja Status new => feedback 14-Jul-04 03:24aaron Bugnote Added: 051 18-Aug-04 15:47ilja Assigned To => ilja 18-Aug-04 15:47ilja Status feedback => assigned ==
[Dbmail-dev] [DBMail 0000004]: fix TO header for BTS
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=004 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 4 Category: www.dbmail.org website Reproducibility:always Severity: minor Priority: normal Status: resolved Resolution: fixed == Date Submitted: 09-Jul-04 10:38 CEST Last Modified: 18-Aug-04 15:48 CEST == Summary:fix TO header for BTS Description: The standard To header for this bug tracking system is to [EMAIL PROTECTED] I think bug reports should also be submitted to the list by default as well. Dan == -- ilja - 09-Jul-04 14:23 CEST -- We need to know if people on the dev-list really want this. I can see that it might be important to show that the bugtracker is alive and things are being changed and fixed. -- aaron - 14-Jul-04 03:24 CEST -- It's a pretty good idea, the one thing I'd be concerned about is coordinating discussions between the mailing lists and the bug tracker. -- ilja - 18-Aug-04 15:48 CEST -- all bug updates are sent to dbmail-dev@dbmail.org Bug History Date Modified Username FieldChange == 09-Jul-04 10:38danweber New Bug 09-Jul-04 14:23ilja Bugnote Added: 003 09-Jul-04 14:23ilja Status new => feedback 14-Jul-04 03:24aaron Bugnote Added: 051 18-Aug-04 15:47ilja Assigned To => ilja 18-Aug-04 15:47ilja Status feedback => assigned 18-Aug-04 15:48ilja Bugnote Added: 165 18-Aug-04 15:48ilja Resolution open => fixed 18-Aug-04 15:48ilja Status assigned => resolved ==
[Dbmail-dev] [DBMail 0000004]: fix TO header for BTS
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=004 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 4 Category: www.dbmail.org website Reproducibility:always Severity: minor Priority: normal Status: closed == Date Submitted: 09-Jul-04 10:38 CEST Last Modified: 18-Aug-04 15:48 CEST == Summary:fix TO header for BTS Description: The standard To header for this bug tracking system is to [EMAIL PROTECTED] I think bug reports should also be submitted to the list by default as well. Dan == -- ilja - 09-Jul-04 14:23 CEST -- We need to know if people on the dev-list really want this. I can see that it might be important to show that the bugtracker is alive and things are being changed and fixed. -- aaron - 14-Jul-04 03:24 CEST -- It's a pretty good idea, the one thing I'd be concerned about is coordinating discussions between the mailing lists and the bug tracker. -- ilja - 18-Aug-04 15:48 CEST -- all bug updates are sent to dbmail-dev@dbmail.org Bug History Date Modified Username FieldChange == 09-Jul-04 10:38danweber New Bug 09-Jul-04 14:23ilja Bugnote Added: 003 09-Jul-04 14:23ilja Status new => feedback 14-Jul-04 03:24aaron Bugnote Added: 051 18-Aug-04 15:47ilja Assigned To => ilja 18-Aug-04 15:47ilja Status feedback => assigned 18-Aug-04 15:48ilja Bugnote Added: 165 18-Aug-04 15:48ilja Resolution open => fixed 18-Aug-04 15:48ilja Status assigned => resolved 18-Aug-04 15:48ilja Status resolved => closed ==
[Dbmail-dev] [DBMail 0000008]: Optional compression of stored mails
The following bug has been ASSIGNED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=008 == Reported By:Dead2 Assigned To:danweber == Project:DBMail Bug ID: 8 Category: General Reproducibility:always Severity: feature Priority: normal Status: closed == Date Submitted: 09-Jul-04 12:55 CEST Last Modified: 18-Aug-04 18:53 CEST == Summary:Optional compression of stored mails Description: When headers are separated from messageblks we can do interesting things to the messageblks. For example we can compress them. dbmail-[smtp/lmtp] should compress the messagebody before inserting them into the database. dbmail-[pop3/imap] and webmail clients should then decompress them before sending them to the clients. Compression should be done by zlib for portability. It should also be possible to specifiy the level of compression to be used. This should be optional for several reasons: -Harder to implement for special 3rd party programs -Backwards compatability -The admin might judge that he does not need compression for various reasons. The advantages of compressing them in the dbmail daemon instead of the buildt-in postgres compression: -Better scalability, since the database needs less cpu, the daemon programs can be put on other computers to achive better scaling, but the database is a bottleneck. -Saving space on database server Disadvantages: -Much harder to perform full-text searches in the message bodys. (Headers/subject not affected) -Slower insertion/retrieval of mails This should probably not go in before 2.2, possibly 2.1? == -- ilja - 09-Jul-04 14:44 CEST -- There's discussion on this feature in dbmail-dev. It might be interesting. -- danweber - 13-Aug-04 14:52 CEST -- MySQL is able to do this. You don't need to compress the data, but MySQL will compress the table. Dan -- danweber - 18-Aug-04 18:53 CEST -- closing bug because this can happen due to your backend (if using mysql) The problem of compression at the message level is that decompressing for people who are downloading 1000 messages with thousands of users is a bad plan. -- Dan Bug History Date Modified Username FieldChange == 09-Jul-04 12:55Dead2 New Bug 09-Jul-04 14:44ilja Bugnote Added: 010 09-Jul-04 14:44ilja Status new => acknowledged 13-Aug-04 14:52danweber Bugnote Added: 159 18-Aug-04 18:53danweber Bugnote Added: 166 18-Aug-04 18:53danweber Assigned To => danweber 18-Aug-04 18:53danweber Reproducibility N/A => always 18-Aug-04 18:53danweber Resolution open => suspended 18-Aug-04 18:53danweber Status acknowledged => closed ==
[Dbmail-dev] [DBMail 0000004]: fix TO header for BTS
The following bug has been REOPENED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=004 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 4 Category: www.dbmail.org website Reproducibility:always Severity: minor Priority: normal Status: feedback == Date Submitted: 09-Jul-04 10:38 CEST Last Modified: 18-Aug-04 19:09 CEST == Summary:fix TO header for BTS Description: The standard To header for this bug tracking system is to [EMAIL PROTECTED] I think bug reports should also be submitted to the list by default as well. Dan == -- ilja - 09-Jul-04 14:23 CEST -- We need to know if people on the dev-list really want this. I can see that it might be important to show that the bugtracker is alive and things are being changed and fixed. -- aaron - 14-Jul-04 03:24 CEST -- It's a pretty good idea, the one thing I'd be concerned about is coordinating discussions between the mailing lists and the bug tracker. -- ilja - 18-Aug-04 15:48 CEST -- all bug updates are sent to dbmail-dev@dbmail.org -- danweber - 18-Aug-04 19:09 CEST -- dbmail-dev is getting flooded with updates. How about a new mailing list dbmail-bugs Bug History Date Modified Username FieldChange == 09-Jul-04 10:38danweber New Bug 09-Jul-04 14:23ilja Bugnote Added: 003 09-Jul-04 14:23ilja Status new => feedback 14-Jul-04 03:24aaron Bugnote Added: 051 18-Aug-04 15:47ilja Assigned To => ilja 18-Aug-04 15:47ilja Status feedback => assigned 18-Aug-04 15:48ilja Bugnote Added: 165 18-Aug-04 15:48ilja Resolution open => fixed 18-Aug-04 15:48ilja Status assigned => resolved 18-Aug-04 15:48ilja Status resolved => closed 18-Aug-04 19:09danweber Bugnote Added: 167 18-Aug-04 19:09danweber Resolution fixed => reopened 18-Aug-04 19:09danweber Status closed => feedback ==
[Dbmail-dev] [DBMail 0000004]: fix TO header for BTS
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=004 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 4 Category: www.dbmail.org website Reproducibility:always Severity: minor Priority: normal Status: feedback == Date Submitted: 09-Jul-04 10:38 CEST Last Modified: 18-Aug-04 19:46 CEST == Summary:fix TO header for BTS Description: The standard To header for this bug tracking system is to [EMAIL PROTECTED] I think bug reports should also be submitted to the list by default as well. Dan == -- ilja - 09-Jul-04 14:23 CEST -- We need to know if people on the dev-list really want this. I can see that it might be important to show that the bugtracker is alive and things are being changed and fixed. -- aaron - 14-Jul-04 03:24 CEST -- It's a pretty good idea, the one thing I'd be concerned about is coordinating discussions between the mailing lists and the bug tracker. -- ilja - 18-Aug-04 15:48 CEST -- all bug updates are sent to dbmail-dev@dbmail.org -- danweber - 18-Aug-04 19:09 CEST -- dbmail-dev is getting flooded with updates. How about a new mailing list dbmail-bugs -- aaron - 18-Aug-04 19:46 CEST -- I'm OK with the tons of messages, no different than if each bug was instead a thread on the mailing list -- and better, in fact, because threads on the mailing list get read by more than just the two or three people involved in a bug, so there's a greater likelihood of getting more input and more creative thinking. Bug History Date Modified Username FieldChange == 09-Jul-04 10:38danweber New Bug 09-Jul-04 14:23ilja Bugnote Added: 003 09-Jul-04 14:23ilja Status new => feedback 14-Jul-04 03:24aaron Bugnote Added: 051 18-Aug-04 15:47ilja Assigned To => ilja 18-Aug-04 15:47ilja Status feedback => assigned 18-Aug-04 15:48ilja Bugnote Added: 165 18-Aug-04 15:48ilja Resolution open => fixed 18-Aug-04 15:48ilja Status assigned => resolved 18-Aug-04 15:48ilja Status resolved => closed 18-Aug-04 19:09danweber Bugnote Added: 167 18-Aug-04 19:09danweber Resolution fixed => reopened 18-Aug-04 19:09danweber Status closed => feedback 18-Aug-04 19:46aaron Bugnote Added: 168 ==
[Dbmail-dev] [DBMail 0000004]: fix TO header for BTS
The following bug has been CLOSED == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=004 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 4 Category: www.dbmail.org website Reproducibility:always Severity: minor Priority: normal Status: closed == Date Submitted: 09-Jul-04 10:38 CEST Last Modified: 19-Aug-04 09:51 CEST == Summary:fix TO header for BTS Description: The standard To header for this bug tracking system is to [EMAIL PROTECTED] I think bug reports should also be submitted to the list by default as well. Dan == -- ilja - 09-Jul-04 14:23 CEST -- We need to know if people on the dev-list really want this. I can see that it might be important to show that the bugtracker is alive and things are being changed and fixed. -- aaron - 14-Jul-04 03:24 CEST -- It's a pretty good idea, the one thing I'd be concerned about is coordinating discussions between the mailing lists and the bug tracker. -- ilja - 18-Aug-04 15:48 CEST -- all bug updates are sent to dbmail-dev@dbmail.org -- danweber - 18-Aug-04 19:09 CEST -- dbmail-dev is getting flooded with updates. How about a new mailing list dbmail-bugs -- aaron - 18-Aug-04 19:46 CEST -- I'm OK with the tons of messages, no different than if each bug was instead a thread on the mailing list -- and better, in fact, because threads on the mailing list get read by more than just the two or three people involved in a bug, so there's a greater likelihood of getting more input and more creative thinking. -- ilja - 19-Aug-04 09:51 CEST -- I agree with Aaron. Having a separate bug-list will not help getting bugs fixed. Bug reports and updates belong on the dev-list. Bug History Date Modified Username FieldChange == 09-Jul-04 10:38danweber New Bug 09-Jul-04 14:23ilja Bugnote Added: 003 09-Jul-04 14:23ilja Status new => feedback 14-Jul-04 03:24aaron Bugnote Added: 051 18-Aug-04 15:47ilja Assigned To => ilja 18-Aug-04 15:47ilja Status feedback => assigned 18-Aug-04 15:48ilja Bugnote Added: 165 18-Aug-04 15:48ilja Resolution open => fixed 18-Aug-04 15:48ilja Status assigned => resolved 18-Aug-04 15:48ilja Status resolved => closed 18-Aug-04 19:09danweber Bugnote Added: 167 18-Aug-04 19:09danweber Resolution fixed => reopened 18-Aug-04 19:09danweber Status closed => feedback 18-Aug-04 19:46aaron Bugnote Added: 168 19-Aug-04 09:51ilja Bugnote Added: 169 19-Aug-04 09:51ilja Status feedback => closed ==
[Dbmail-dev] [DBMail 0000057]: direct mailforwarding with [EMAIL PROTECTED]
==
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=057
==
Reported By:maXXmaster
Assigned To:aaron
==
Project:DBMail
Bug ID: 57
Category: PIPE delivery (dbmail-smtp)
Reproducibility:N/A
Severity: feature
Priority: normal
Status: acknowledged
==
Date Submitted: 23-Jul-04 23:37 CEST
Last Modified: 19-Aug-04 11:39 CEST
==
Summary:direct mailforwarding with [EMAIL PROTECTED]
Description:
it doesn't seem that there is a way to store "special" mails like spam to a
different folder than INBOX when pipeing the message to dbmail-smtp. i'm
not sure if it is an imap-standard, but many imapservers allow you to send
a message to [EMAIL PROTECTED]
is there a way to realise that?
==
--
danweber - 24-Jul-04 03:38 CEST
--
Yes we need this feature added so we can start using tmda with exim too.
--
aaron - 24-Jul-04 17:05 CEST
--
There's a command line option to specify an alternate mailbox along with
the destination address:
dbmail -m mailbox {-t [headerfield] | -d [emailaddress]}
If there's a way to make this work with Exim, it would be much easier to
document such a method rather than adding new support for the
username+mailbox syntax.
--
maXXmaster - 25-Jul-04 20:40 CEST
--
i actually wanted to use it with amavis-new which is able to append an
foldername after the mailadress (incase of spam or viruses).. i'll
probably have to find a way to make it work with the -m mailboxname
option,..
let's see ;o)
edited on: 25-Jul-04 20:40
--
aaron - 25-Jul-04 20:44 CEST
--
Ok, keep us posted. Interfacing with other parts of the mail system is,
quite naturally, a high priority :-)
Is there a published standard advocating for this hack, btw? Some de facto
rule book that we can follow if it turns out to be necessary to support
this syntax?
--
maXXmaster - 25-Jul-04 22:56 CEST
--
well, not really,.. at least i couldn't find one within the last hour. my
(probably) working solution is to use the following chain:
postfix (:25) -> amavis-new (:10024) -> postfix#2 (:10025) -> procmail (->
script which does the conversion from [EMAIL PROTECTED] to the
dbmail-smtp syntax you mentioned) -> dbmail
maybe i can write more about the necessary configurations tomorrow.
--
maXXmaster - 26-Jul-04 11:52 CEST
--
i tried some things and came up with quite a good solution.
i use a small (php)script insted of the dbmail-smtp program in postfix
(inside master.cf) to extract the +folder from the emailaddress and pipe
it to dbmail-smtp. the only problem is, that dbmail-smtp cannot add
messages to a special mailbox, if i want to forward them to an
emailaddress. it just works with direct usernames (user -u markus vs -d
[EMAIL PROTECTED])
so either i ask the dbmail-database which useralias i should use for
special mailaddresses (that is exactly what dbmail-smtp should actually
do), or some of you guys add a few lines to make dbmail-smtp work with
mailboxes AND emailaddresses or to make it work with [EMAIL PROTECTED]
any suggestions? =)
edited on: 26-Jul-04 11:52
--
maXXmaster - 26-Jul-04 13:00 CEST
--
> Is there a published standard advocating for this hack, btw?
> Some de facto rule book that we can follow if it turns out
> to be necessary to support this syntax?
yes, there is. i found an rfc which "specifies" the [EMAIL PROTECTED]
syntax.
it can be found here:
http://www.ietf.org/rfc/rfc3598.txt
i hope that is enough information to the syntax ;o)
---
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
The following bug has been SUBMITTED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 19-Aug-04 14:03 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 19-Aug-04 20:21 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron Bugnote Added: 170 ==
[Dbmail-dev] [DBMail 0000067]: messages that cannot be parsed have standard header with hardcoded sender
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=067 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 67 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 20-Aug-04 11:28 CEST Last Modified: 20-Aug-04 11:28 CEST == Summary:messages that cannot be parsed have standard header with hardcoded sender Description: Messages that cannot be parsed by our message parser get sent to the client with a message that they cannot be parsed, but this message is sent from [EMAIL PROTECTED] This address is hardcoded. It should be configurable == Bug History Date Modified Username FieldChange == 20-Aug-04 11:28ilja New Bug ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 20-Aug-04 12:32 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron Bugnote Added: 170 20-Aug-04 12:32ilja Bugnote Added: 171 ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 20-Aug-04 13:58 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron Bugnote Added: 170 20-Aug-04 12:32ilja Bugnote Added: 171 20-Aug-04 13:58ilja Bugnote Added: 172 ==
[Dbmail-dev] [DBMail 0000067]: messages that cannot be parsed have standard header with hardcoded sender
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=067
==
Reported By:ilja
Assigned To:
==
Project:DBMail
Bug ID: 67
Category: IMAP daemon
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 20-Aug-04 11:28 CEST
Last Modified: 20-Aug-04 14:55 CEST
==
Summary:messages that cannot be parsed have standard header
with hardcoded sender
Description:
Messages that cannot be parsed by our message parser get sent to the client
with a message that they cannot be parsed, but this message is sent from
[EMAIL PROTECTED] This address is hardcoded. It should be
configurable
==
--
ilja - 20-Aug-04 14:55 CEST
--
It's quite easy to get the Postmaster's address from the config file.
field_t postmaster;
GetConfigValue("POSTMASTER", "SMTP", postmaster);
strncpy(mr.value, postmaster, MIME_VALUE_MAX - 1);
Will probably do the trick.
This does not give the user an explanation of what went wrong though. This
might still be added.
Bug History
Date Modified Username FieldChange
==
20-Aug-04 11:28ilja New Bug
20-Aug-04 14:55ilja Bugnote Added: 173
==
[Dbmail-dev] [DBMail 0000067]: messages that cannot be parsed have standard header with hardcoded sender
The following bug has been CONFIRMED.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=067
==
Reported By:ilja
Assigned To:
==
Project:DBMail
Bug ID: 67
Category: IMAP daemon
Reproducibility:always
Severity: minor
Priority: normal
Status: confirmed
==
Date Submitted: 20-Aug-04 11:28 CEST
Last Modified: 20-Aug-04 14:55 CEST
==
Summary:messages that cannot be parsed have standard header
with hardcoded sender
Description:
Messages that cannot be parsed by our message parser get sent to the client
with a message that they cannot be parsed, but this message is sent from
[EMAIL PROTECTED] This address is hardcoded. It should be
configurable
==
--
ilja - 20-Aug-04 14:55 CEST
--
It's quite easy to get the Postmaster's address from the config file.
field_t postmaster;
GetConfigValue("POSTMASTER", "SMTP", postmaster);
strncpy(mr.value, postmaster, MIME_VALUE_MAX - 1);
Will probably do the trick.
This does not give the user an explanation of what went wrong though. This
might still be added.
Bug History
Date Modified Username FieldChange
==
20-Aug-04 11:28ilja New Bug
20-Aug-04 14:55ilja Bugnote Added: 173
20-Aug-04 14:55ilja Status new => confirmed
==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
The following bug has been CONFIRMED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: confirmed == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 20-Aug-04 14:56 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron Bugnote Added: 170 20-Aug-04 12:32ilja Bugnote Added: 171 20-Aug-04 13:58ilja Bugnote Added: 172 20-Aug-04 14:56ilja Status new => confirmed ==
[Dbmail-dev] [DBMail 0000067]: messages that cannot be parsed have standard header with hardcoded sender
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=067
==
Reported By:ilja
Assigned To:
==
Project:DBMail
Bug ID: 67
Category: IMAP daemon
Reproducibility:always
Severity: minor
Priority: normal
Status: confirmed
==
Date Submitted: 20-Aug-04 11:28 CEST
Last Modified: 20-Aug-04 15:30 CEST
==
Summary:messages that cannot be parsed have standard header
with hardcoded sender
Description:
Messages that cannot be parsed by our message parser get sent to the client
with a message that they cannot be parsed, but this message is sent from
[EMAIL PROTECTED] This address is hardcoded. It should be
configurable
==
--
ilja - 20-Aug-04 14:55 CEST
--
It's quite easy to get the Postmaster's address from the config file.
field_t postmaster;
GetConfigValue("POSTMASTER", "SMTP", postmaster);
strncpy(mr.value, postmaster, MIME_VALUE_MAX - 1);
Will probably do the trick.
This does not give the user an explanation of what went wrong though. This
might still be added.
--
ilja - 20-Aug-04 15:30 CEST
--
rfcmsg.c.patch holds a patch for rfcmsg.c that should set the Postmaster's
address as From: address. This address is taken from dbmail.conf
Bug History
Date Modified Username FieldChange
==
20-Aug-04 11:28ilja New Bug
20-Aug-04 14:55ilja Bugnote Added: 173
20-Aug-04 14:55ilja Status new => confirmed
20-Aug-04 15:29ilja File Added: rfcmsg.c.patch
20-Aug-04 15:30ilja Bugnote Added: 174
==
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To: == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: normal Status: new == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 20-Aug-04 16:26 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug ==
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To: == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: normal Status: new == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 20-Aug-04 16:54 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == -- ilja - 20-Aug-04 16:54 CEST -- The problem doesn't appear to come from forward.c. It seems to come from the place where the from address is set. I'll go on searching from lmtpc. I'll have a good look. Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug 20-Aug-04 16:54ilja Bugnote Added: 175 ==
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
== http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To: == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: high Status: new == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 20-Aug-04 16:55 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == -- ilja - 20-Aug-04 16:54 CEST -- The problem doesn't appear to come from forward.c. It seems to come from the place where the from address is set. I'll go on searching from lmtpc. I'll have a good look. Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug 20-Aug-04 16:54ilja Bugnote Added: 175 20-Aug-04 16:55ilja ETA none => < 1 day 20-Aug-04 16:55ilja Priority normal => high 20-Aug-04 16:55ilja Projection none => minor fix ==
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To:ilja == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: high Status: assigned == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 20-Aug-04 16:55 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == -- ilja - 20-Aug-04 16:54 CEST -- The problem doesn't appear to come from forward.c. It seems to come from the place where the from address is set. I'll go on searching from lmtpc. I'll have a good look. Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug 20-Aug-04 16:54ilja Bugnote Added: 175 20-Aug-04 16:55ilja ETA none => < 1 day 20-Aug-04 16:55ilja Priority normal => high 20-Aug-04 16:55ilja Projection none => minor fix 20-Aug-04 16:55ilja Assigned To => ilja 20-Aug-04 16:55ilja Status new => assigned ==
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To:ilja == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: high Status: assigned == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 20-Aug-04 17:33 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == -- ilja - 20-Aug-04 16:54 CEST -- The problem doesn't appear to come from forward.c. It seems to come from the place where the from address is set. I'll go on searching from lmtpc. I'll have a good look. -- thafreak - 20-Aug-04 17:33 CEST -- I'm not sure if this will help, but here is the header from one of the emails causing the problem: - Message-ID: <[EMAIL PROTECTED]> Date: Wed, 18 Aug 2004 16:07:11 -0400 From: Darren Brink <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Warren <[EMAIL PROTECTED]> Subject: Sara Lee Conversion Content-Type: multipart/mixed; boundary="090805070508060702070403" This is a multi-part message in MIME format. --090805070508060702070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit - Also, there is a vcard attached to the email by thunderbird...again not sure if either of these would make a difference, but the problem only apears sometimes...which may be cause by something in the email itself... Hope that helps. Doug Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug 20-Aug-04 16:54ilja Bugnote Added: 175 20-Aug-04 16:55ilja ETA none => < 1 day 20-Aug-04 16:55ilja Priority normal => high 20-Aug-04 16:55ilja Projection none => minor fix 20-Aug-04 16:55ilja Assigned To => ilja 20-Aug-04 16:55ilja Status new => assigned 20-Aug-04 17:33thafreak Bugnote Added: 176 ==
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To:ilja == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: high Status: resolved Resolution: fixed == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 20-Aug-04 17:37 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == -- ilja - 20-Aug-04 16:54 CEST -- The problem doesn't appear to come from forward.c. It seems to come from the place where the from address is set. I'll go on searching from lmtpc. I'll have a good look. -- thafreak - 20-Aug-04 17:33 CEST -- I'm not sure if this will help, but here is the header from one of the emails causing the problem: - Message-ID: <[EMAIL PROTECTED]> Date: Wed, 18 Aug 2004 16:07:11 -0400 From: Darren Brink <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Warren <[EMAIL PROTECTED]> Subject: Sara Lee Conversion Content-Type: multipart/mixed; boundary="090805070508060702070403" This is a multi-part message in MIME format. --090805070508060702070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit - Also, there is a vcard attached to the email by thunderbird...again not sure if either of these would make a difference, but the problem only apears sometimes...which may be cause by something in the email itself... Hope that helps. Doug -- ilja - 20-Aug-04 17:37 CEST -- This was an off by one error... current CVS should fix it. Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug 20-Aug-04 16:54ilja Bugnote Added: 175 20-Aug-04 16:55ilja ETA none => < 1 day 20-Aug-04 16:55ilja Priority normal => high 20-Aug-04 16:55ilja Projection none => minor fix 20-Aug-04 16:55ilja Assigned To => ilja 20-Aug-04 16:55ilja Status new => assigned 20-Aug-04 17:33thafreak Bugnote Added: 176 20-Aug-04 17:37ilja Bugnote Added: 177 20-Aug-04 17:37ilja Resolution open => fixed 20-Aug-04 17:37ilja Status assigned => resolved ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: confirmed == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 20-Aug-04 18:13 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron Bugnote Added: 170 20-Aug-04 12:32ilja Bugnote Added: 171 20-Aug-04 13:58ilja Bugnote Added: 172 20-Aug-04 14:56ilja Status new => confirmed 20-Aug-04 18:
[Dbmail-dev] [DBMail 0000069]: Error in MySQL InnoDB-Migration script
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=069 == Reported By:va1210 Assigned To: == Project:DBMail Bug ID: 69 Category: Authentication layer Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 22-Aug-04 18:18 CEST Last Modified: 22-Aug-04 18:18 CEST == Summary:Error in MySQL InnoDB-Migration script Description: The foreign key reference in the InnoDB-migration script for MySQL has an error in the "alter messageblks table"-section. The line REFERENCES physmessage_id (id) Should in fact say REFERENCES dbmail_physmessage (id) The reference error makes it impossible for mails to be inserted into the database as the reference always returns an error. == Bug History Date Modified Username FieldChange == 22-Aug-04 18:18va1210 New Bug ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
The following bug has been SUBMITTED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To: == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 23-Aug-04 01:43 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: confirmed == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 23-Aug-04 01:46 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. -- danweber - 23-Aug-04 01:46 CEST -- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. Bug History Date Modified Username FieldChange == 19-Aug-04 14:03ilja New Bug 19-Aug-04 20:21aaron
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: confirmed == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 23-Aug-04 06:36 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. -- danweber - 23-Aug-04 01:46 CEST -- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. -- aaron - 23-Aug-04 06:36 CEST -- Dan, is this unresolved with the suggested fix applied, or just in current CVS? I don't
[Dbmail-dev] [DBMail 0000069]: Error in MySQL InnoDB-Migration script
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=069 == Reported By:va1210 Assigned To:ilja == Project:DBMail Bug ID: 69 Category: Authentication layer Reproducibility:always Severity: major Priority: normal Status: assigned == Date Submitted: 22-Aug-04 18:18 CEST Last Modified: 23-Aug-04 10:54 CEST == Summary:Error in MySQL InnoDB-Migration script Description: The foreign key reference in the InnoDB-migration script for MySQL has an error in the "alter messageblks table"-section. The line REFERENCES physmessage_id (id) Should in fact say REFERENCES dbmail_physmessage (id) The reference error makes it impossible for mails to be inserted into the database as the reference always returns an error. == Bug History Date Modified Username FieldChange == 22-Aug-04 18:18va1210 New Bug 23-Aug-04 10:54ilja Assigned To => ilja 23-Aug-04 10:54ilja Status new => assigned ==
[Dbmail-dev] [DBMail 0000069]: Error in MySQL InnoDB-Migration script
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=069 == Reported By:va1210 Assigned To:ilja == Project:DBMail Bug ID: 69 Category: Authentication layer Reproducibility:always Severity: major Priority: normal Status: resolved Resolution: fixed == Date Submitted: 22-Aug-04 18:18 CEST Last Modified: 23-Aug-04 11:32 CEST == Summary:Error in MySQL InnoDB-Migration script Description: The foreign key reference in the InnoDB-migration script for MySQL has an error in the "alter messageblks table"-section. The line REFERENCES physmessage_id (id) Should in fact say REFERENCES dbmail_physmessage (id) The reference error makes it impossible for mails to be inserted into the database as the reference always returns an error. == -- ilja - 23-Aug-04 11:32 CEST -- fixed applied (both in TRUNK and dbmail_2_0_branch) Bug History Date Modified Username FieldChange == 22-Aug-04 18:18va1210 New Bug 23-Aug-04 10:54ilja Assigned To => ilja 23-Aug-04 10:54ilja Status new => assigned 23-Aug-04 11:32ilja Bugnote Added: 181 23-Aug-04 11:32ilja Resolution open => fixed 23-Aug-04 11:32ilja Status assigned => resolved ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To: == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 23-Aug-04 13:32 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: trivial Priority: normal Status: new == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 23-Aug-04 14:11 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 23-Aug-04 14:16 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: trivial Priority: normal Status: assigned == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 23-Aug-04 14:24 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug 23-Aug-04 14:24ilja Assigned To => ilja 23-Aug-04 14:24ilja Status new => assigned ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: trivial Priority: normal Status: assigned == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 23-Aug-04 14:24 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == -- ilja - 23-Aug-04 14:24 CEST -- Agreed. It should be removed. I'll get on it. Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug 23-Aug-04 14:24ilja Assigned To => ilja 23-Aug-04 14:24ilja Status new => assigned 23-Aug-04 14:24ilja Bugnote Added: 183 ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: trivial Priority: normal Status: resolved Resolution: fixed == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 23-Aug-04 14:32 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == -- ilja - 23-Aug-04 14:24 CEST -- Agreed. It should be removed. I'll get on it. -- ilja - 23-Aug-04 14:32 CEST -- dbmail-readvut is removed. All references to it are removed from build-scripts. Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug 23-Aug-04 14:24ilja Assigned To => ilja 23-Aug-04 14:24ilja Status new => assigned 23-Aug-04 14:24ilja Bugnote Added: 183 23-Aug-04 14:32ilja Bugnote Added: 184 23-Aug-04 14:32ilja Resolution open => fixed 23-Aug-04 14:32ilja Status assigned => resolved ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 23-Aug-04 14:35 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: assigned == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 23-Aug-04 14:44 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. -- danweber - 23-Aug-04 01:46 CEST -- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. -- aaron - 23-Aug-04 06:36 CEST -- Dan, is this unresolved with the suggested fix applied, or just in current CVS? I
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 23-Aug-04 15:10 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: assigned == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 23-Aug-04 15:19 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. -- danweber - 23-Aug-04 01:46 CEST -- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. -- aaron - 23-Aug-04 06:36 CEST -- Dan, is this unresolved with the suggested fix applied, or just in current CVS? I
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: resolved Resolution: fixed == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 23-Aug-04 15:20 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. -- danweber - 23-Aug-04 01:46 CEST -- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. -- aaron - 23-Aug-04 06:36 CEST -- Dan, is this unresolved with the suggested fix a
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 23-Aug-04 16:03 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
The following bug has been CONFIRMED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 23-Aug-04 16:04 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed ==
[Dbmail-dev] [DBMail 0000073]: ACL is broken. It doesn't implement the 'anyone' user.
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=073 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 73 Category: IMAP daemon Reproducibility:always Severity: major Priority: high Status: assigned == Date Submitted: 23-Aug-04 16:56 CEST Last Modified: 23-Aug-04 16:56 CEST == Summary:ACL is broken. It doesn't implement the 'anyone' user. Description: ACL should implement the 'anyone' user. Giving rights to anyone will give rights to all users on the server to a certain mailbox. == Bug History Date Modified Username FieldChange == 23-Aug-04 16:56ilja New Bug ==
[Dbmail-dev] [DBMail 0000074]: FETCH MSGNUM (RFC822.HEADER) returns headers in wrong order.
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=074 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 74 Category: IMAP daemon Reproducibility:always Severity: feature Priority: low Status: new == Date Submitted: 23-Aug-04 17:06 CEST Last Modified: 23-Aug-04 17:06 CEST == Summary:FETCH MSGNUM (RFC822.HEADER) returns headers in wrong order. Description: FETCH MSGNUM (RFC822.HEADER) always returns headers in wrong order. This is not a big problem. Headers do not have to be in a specific order. == Bug History Date Modified Username FieldChange == 23-Aug-04 17:06ilja New Bug ==
[Dbmail-dev] [DBMail 0000075]: IMAP message parser sometimes chokes on message that are probably allright.
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=075 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 75 Category: IMAP daemon Reproducibility:sometimes Severity: minor Priority: normal Status: new == Date Submitted: 23-Aug-04 17:07 CEST Last Modified: 23-Aug-04 17:07 CEST == Summary:IMAP message parser sometimes chokes on message that are probably allright. Description: IMAP message parser sometimes chokes on message that are probably allright. Best way to solve this would be to replace the message parser by a parser that works allright (maybe using gmime?) == Bug History Date Modified Username FieldChange == 23-Aug-04 17:07ilja New Bug ==
[Dbmail-dev] [DBMail 0000076]: messages with only 1 header line, with no body are not accepted
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=076 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 76 Category: general delivery Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 23-Aug-04 17:10 CEST Last Modified: 23-Aug-04 17:10 CEST == Summary:messages with only 1 header line, with no body are not accepted Description: Messages with only a header only get accepted when they have more than 1 header line. If messages with only headers should get accepted, they should probably also be accepted if they have only one line of headers. In practice, this bug is not really a problem, but it should be taken care of nonetheless. == Bug History Date Modified Username FieldChange == 23-Aug-04 17:10ilja New Bug ==
[Dbmail-dev] [DBMail 0000076]: messages with only 1 header line, with no body are not accepted
The following bug has been CONFIRMED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=076 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 76 Category: general delivery Reproducibility:always Severity: minor Priority: low Status: confirmed == Date Submitted: 23-Aug-04 17:10 CEST Last Modified: 23-Aug-04 17:15 CEST == Summary:messages with only 1 header line, with no body are not accepted Description: Messages with only a header only get accepted when they have more than 1 header line. If messages with only headers should get accepted, they should probably also be accepted if they have only one line of headers. In practice, this bug is not really a problem, but it should be taken care of nonetheless. == Bug History Date Modified Username FieldChange == 23-Aug-04 17:10ilja New Bug 23-Aug-04 17:15ilja Status new => confirmed ==
[Dbmail-dev] [DBMail 0000075]: IMAP message parser sometimes chokes on message that are probably allright.
The following bug has been CONFIRMED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=075 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 75 Category: IMAP daemon Reproducibility:sometimes Severity: minor Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 17:07 CEST Last Modified: 23-Aug-04 17:15 CEST == Summary:IMAP message parser sometimes chokes on message that are probably allright. Description: IMAP message parser sometimes chokes on message that are probably allright. Best way to solve this would be to replace the message parser by a parser that works allright (maybe using gmime?) == Bug History Date Modified Username FieldChange == 23-Aug-04 17:07ilja New Bug 23-Aug-04 17:15ilja Status new => confirmed ==
[Dbmail-dev] [DBMail 0000074]: FETCH MSGNUM (RFC822.HEADER) returns headers in wrong order.
The following bug has been CONFIRMED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=074 == Reported By:ilja Assigned To: == Project:DBMail Bug ID: 74 Category: IMAP daemon Reproducibility:always Severity: feature Priority: low Status: confirmed == Date Submitted: 23-Aug-04 17:06 CEST Last Modified: 23-Aug-04 17:16 CEST == Summary:FETCH MSGNUM (RFC822.HEADER) returns headers in wrong order. Description: FETCH MSGNUM (RFC822.HEADER) always returns headers in wrong order. This is not a big problem. Headers do not have to be in a specific order. == Bug History Date Modified Username FieldChange == 23-Aug-04 17:06ilja New Bug 23-Aug-04 17:16ilja Status new => confirmed ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 23-Aug-04 18:07 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? -- aaron - 23-Aug-04 18:07 CEST -- I've been opposed to moving the man pages because things like MySQL are all man.1, with the logic being that if the system is nothing but a smoking pile of disks, mysql isn't going to be the sort of admin tool that will recover it. But if there's a concensus to move to man.8, I'm not going to worry too much. Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed 23-Aug-04 18:07aaron Bugnote Added: 190 ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To: == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 23-Aug-04 18:11 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. -- aaron - 23-Aug-04 18:11 CEST -- Actually, pipelining means that neither side should block or wait for anything during the RCPT stage. So both behaviors are slightly wrong. Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 23-Aug-04 18:11aaron Bugnote Added: 191 ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
The following bug has been REOPENED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: trivial Priority: normal Status: feedback == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 23-Aug-04 21:36 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == -- ilja - 23-Aug-04 14:24 CEST -- Agreed. It should be removed. I'll get on it. -- ilja - 23-Aug-04 14:32 CEST -- dbmail-readvut is removed. All references to it are removed from build-scripts. -- aaron - 23-Aug-04 21:36 CEST -- Well it wasn't undocumented, I wrote a man page for it. So if you're removing the binary, be sure to scrap the man page, too. Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug 23-Aug-04 14:24ilja Assigned To => ilja 23-Aug-04 14:24ilja Status new => assigned 23-Aug-04 14:24ilja Bugnote Added: 183 23-Aug-04 14:32ilja Bugnote Added: 184 23-Aug-04 14:32ilja Resolution open => fixed 23-Aug-04 14:32ilja Status assigned => resolved 23-Aug-04 21:36aaron Bugnote Added: 192 23-Aug-04 21:36aaron Resolution fixed => reopened 23-Aug-04 21:36aaron Status resolved => feedback ==
[Dbmail-dev] [DBMail 0000077]: dbmail-users segfault if password on command line is empty
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=077 == Reported By:sena Assigned To: == Project:DBMail Bug ID: 77 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 24-Aug-04 11:53 CEST Last Modified: 24-Aug-04 11:53 CEST == Summary:dbmail-users segfault if password on command line is empty Description: boom == Bug History Date Modified Username FieldChange == 24-Aug-04 11:53sena New Bug ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
The following bug has been RESOLVED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: trivial Priority: normal Status: resolved Resolution: fixed == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 24-Aug-04 18:24 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == -- ilja - 23-Aug-04 14:24 CEST -- Agreed. It should be removed. I'll get on it. -- ilja - 23-Aug-04 14:32 CEST -- dbmail-readvut is removed. All references to it are removed from build-scripts. -- aaron - 23-Aug-04 21:36 CEST -- Well it wasn't undocumented, I wrote a man page for it. So if you're removing the binary, be sure to scrap the man page, too. -- aaron - 24-Aug-04 18:24 CEST -- Turns out I made everyone's life easier by forgetting to commit the manpage I wrote! Off to the bitbucket... Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug 23-Aug-04 14:24ilja Assigned To => ilja 23-Aug-04 14:24ilja Status new => assigned 23-Aug-04 14:24ilja Bugnote Added: 183 23-Aug-04 14:32ilja Bugnote Added: 184 23-Aug-04 14:32ilja Resolution open => fixed 23-Aug-04 14:32ilja Status assigned => resolved 23-Aug-04 21:36aaron Bugnote Added: 192 23-Aug-04 21:36aaron Resolution fixed => reopened 23-Aug-04 21:36aaron Status resolved => feedback 24-Aug-04 18:24aaron Bugnote Added: 193 24-Aug-04 18:24aaron Resolution reopened => fixed 24-Aug-04 18:24aaron Status feedback => resolved ==
[Dbmail-dev] [DBMail 0000077]: dbmail-users segfault if password on command line is empty
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=077 == Reported By:sena Assigned To: == Project:DBMail Bug ID: 77 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 24-Aug-04 11:53 CEST Last Modified: 24-Aug-04 18:26 CEST == Summary:dbmail-users segfault if password on command line is empty Description: boom == -- aaron - 24-Aug-04 18:26 CEST -- I don't see this failing in the latest 2_0 CVS. Are you on a different branch or an earlier revision? Bug History Date Modified Username FieldChange == 24-Aug-04 11:53sena New Bug 24-Aug-04 18:26aaron Bugnote Added: 194 ==
[Dbmail-dev] [DBMail 0000077]: dbmail-users segfault if password on command line is empty
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=077 == Reported By:sena Assigned To: == Project:DBMail Bug ID: 77 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 24-Aug-04 11:53 CEST Last Modified: 24-Aug-04 18:48 CEST == Summary:dbmail-users segfault if password on command line is empty Description: boom == -- aaron - 24-Aug-04 18:26 CEST -- I don't see this failing in the latest 2_0 CVS. Are you on a different branch or an earlier revision? -- danweber - 24-Aug-04 18:48 CEST -- Could you grab a core dump file and send it to the mailing list? Dan Bug History Date Modified Username FieldChange == 24-Aug-04 11:53sena New Bug 24-Aug-04 18:26aaron Bugnote Added: 194 24-Aug-04 18:48danweber Bugnote Added: 195 ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 24-Aug-04 18:49 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? -- aaron - 23-Aug-04 18:07 CEST -- I've been opposed to moving the man pages because things like MySQL are all man.1, with the logic being that if the system is nothing but a smoking pile of disks, mysql isn't going to be the sort of admin tool that will recover it. But if there's a concensus to move to man.8, I'm not going to worry too much. -- danweber - 24-Aug-04 18:49 CEST -- I have been saying this for ages. *sigh* I was the one who told you Paul ;) Dan Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed 23-Aug-04 18:07aaron Bugnote Added: 190 24-Aug-04 18:49danweber Bugnote Added: 196 ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To: == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 24-Aug-04 18:50 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. -- aaron - 23-Aug-04 18:11 CEST -- Actually, pipelining means that neither side should block or wait for anything during the RCPT stage. So both behaviors are slightly wrong. -- danweber - 24-Aug-04 18:50 CEST -- Its good practice to send a response after rcpt. This way it allows a compatible smtp client to be used with it, like python. Dan Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 23-Aug-04 18:11aaron Bugnote Added: 191 24-Aug-04 18:50danweber Bugnote Added: 197 ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 24-Aug-04 19:18 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? -- aaron - 23-Aug-04 18:07 CEST -- I've been opposed to moving the man pages because things like MySQL are all man.1, with the logic being that if the system is nothing but a smoking pile of disks, mysql isn't going to be the sort of admin tool that will recover it. But if there's a concensus to move to man.8, I'm not going to worry too much. -- danweber - 24-Aug-04 18:49 CEST -- I have been saying this for ages. *sigh* I was the one who told you Paul ;) Dan -- paul - 24-Aug-04 19:18 CEST -- Yeah, Dan. You were right. But instead of fixing it for the debian packages only I thought it would be easier to file a bug upstream. Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed 23-Aug-04 18:07aaron Bugnote Added: 190 24-Aug-04 18:49danweber Bugnote Added: 196 24-Aug-04 19:18paul Bugnote Added: 198 ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To: == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 24-Aug-04 19:28 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. -- aaron - 23-Aug-04 18:11 CEST -- Actually, pipelining means that neither side should block or wait for anything during the RCPT stage. So both behaviors are slightly wrong. -- danweber - 24-Aug-04 18:50 CEST -- Its good practice to send a response after rcpt. This way it allows a compatible smtp client to be used with it, like python. Dan -- aaron - 24-Aug-04 19:28 CEST -- Oh, that's a good point. LMTP is a dialect of SMTP, the only difference is the HELO/EHLO/LHLO greeting. Simple scripts that speak simple SMTP can be easily modified to work with LMTP, but adding in the pipelining is more hassle than needed, since the particular behavior we are using isn't quite correct anyhow. So I agree we should change the responses to happen immediately following each RCPT. I'll post a patch this evening. Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 23-Aug-04 18:11aaron Bugnote Added: 191 24-Aug-04 18:50danweber Bugnote Added: 197 24-Aug-04 19:28aaron Bugnote Added: 199 ==
[Dbmail-dev] [DBMail 0000077]: dbmail-users segfault if password on command line is empty
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=077 == Reported By:sena Assigned To: == Project:DBMail Bug ID: 77 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 24-Aug-04 11:53 CEST Last Modified: 25-Aug-04 11:00 CEST == Summary:dbmail-users segfault if password on command line is empty Description: boom == -- aaron - 24-Aug-04 18:26 CEST -- I don't see this failing in the latest 2_0 CVS. Are you on a different branch or an earlier revision? -- danweber - 24-Aug-04 18:48 CEST -- Could you grab a core dump file and send it to the mailing list? Dan -- sena - 25-Aug-04 11:00 CEST -- I updated my CVS tree and the bug is gone. Sorry. Bug History Date Modified Username FieldChange == 24-Aug-04 11:53sena New Bug 24-Aug-04 18:26aaron Bugnote Added: 194 24-Aug-04 18:48danweber Bugnote Added: 195 25-Aug-04 11:00sena Bugnote Added: 200 ==
[Dbmail-dev] [DBMail 0000077]: dbmail-users segfault if password on command line is empty
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=077 == Reported By:sena Assigned To:ilja == Project:DBMail Bug ID: 77 Category: Command-Line programs (dbmail-adduser, dbmail-maintenance) Reproducibility:always Severity: crash Priority: normal Status: resolved Resolution: not a bug == Date Submitted: 24-Aug-04 11:53 CEST Last Modified: 25-Aug-04 11:04 CEST == Summary:dbmail-users segfault if password on command line is empty Description: boom == -- aaron - 24-Aug-04 18:26 CEST -- I don't see this failing in the latest 2_0 CVS. Are you on a different branch or an earlier revision? -- danweber - 24-Aug-04 18:48 CEST -- Could you grab a core dump file and send it to the mailing list? Dan -- sena - 25-Aug-04 11:00 CEST -- I updated my CVS tree and the bug is gone. Sorry. -- ilja - 25-Aug-04 11:04 CEST -- bug was fixed after user updated to newest CVS. Bug History Date Modified Username FieldChange == 24-Aug-04 11:53sena New Bug 24-Aug-04 18:26aaron Bugnote Added: 194 24-Aug-04 18:48danweber Bugnote Added: 195 25-Aug-04 11:00sena Bugnote Added: 200 25-Aug-04 11:04ilja Bugnote Added: 201 25-Aug-04 11:04ilja Assigned To => ilja 25-Aug-04 11:04ilja Resolution open => not a bug 25-Aug-04 11:04ilja Status new => resolved ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To:aaron == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: assigned == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 25-Aug-04 11:04 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. -- aaron - 23-Aug-04 18:11 CEST -- Actually, pipelining means that neither side should block or wait for anything during the RCPT stage. So both behaviors are slightly wrong. -- danweber - 24-Aug-04 18:50 CEST -- Its good practice to send a response after rcpt. This way it allows a compatible smtp client to be used with it, like python. Dan -- aaron - 24-Aug-04 19:28 CEST -- Oh, that's a good point. LMTP is a dialect of SMTP, the only difference is the HELO/EHLO/LHLO greeting. Simple scripts that speak simple SMTP can be easily modified to work with LMTP, but adding in the pipelining is more hassle than needed, since the particular behavior we are using isn't quite correct anyhow. So I agree we should change the responses to happen immediately following each RCPT. I'll post a patch this evening. Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 23-Aug-04 18:11aaron Bugnote Added: 191 24-Aug-04 18:50danweber Bugnote Added: 197 24-Aug-04 19:28aaron Bugnote Added: 199 25-Aug-04 11:04ilja Assigned To => aaron 25-Aug-04 11:04ilja Status new => assigned ==
[Dbmail-dev] [DBMail 0000078]: dbmail-users -a doesn't stop when a user already exists.
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=078 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 78 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: urgent Status: assigned == Date Submitted: 25-Aug-04 11:43 CEST Last Modified: 25-Aug-04 11:43 CEST == Summary:dbmail-users -a doesn't stop when a user already exists. Description: dbmail-users -a adds a new user. If the user already exists, it should stop. Instead it goes on, and creates an INBOX for the already existing user. == Bug History Date Modified Username FieldChange == 25-Aug-04 11:43ilja New Bug ==
[Dbmail-dev] [DBMail 0000078]: dbmail-users -a doesn't stop when a user already exists.
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=078 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 78 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: urgent Status: assigned == Date Submitted: 25-Aug-04 11:43 CEST Last Modified: 25-Aug-04 11:59 CEST == Summary:dbmail-users -a doesn't stop when a user already exists. Description: dbmail-users -a adds a new user. If the user already exists, it should stop. Instead it goes on, and creates an INBOX for the already existing user. == -- ilja - 25-Aug-04 11:59 CEST -- The problem in dbmail-users is fixed in a very simple way. The problem in the database (possibility of entering several duplicate (mailbox.name, mailbox.owner_idnr) pairs is not yet fixed, but is easily fixable by adding a UNIQUE constraint. Bug History Date Modified Username FieldChange == 25-Aug-04 11:43ilja New Bug 25-Aug-04 11:59ilja Bugnote Added: 202 ==
[Dbmail-dev] [DBMail 0000078]: dbmail-users -a doesn't stop when a user already exists.
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=078 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 78 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: urgent Status: resolved Resolution: fixed == Date Submitted: 25-Aug-04 11:43 CEST Last Modified: 25-Aug-04 14:05 CEST == Summary:dbmail-users -a doesn't stop when a user already exists. Description: dbmail-users -a adds a new user. If the user already exists, it should stop. Instead it goes on, and creates an INBOX for the already existing user. == -- ilja - 25-Aug-04 11:59 CEST -- The problem in dbmail-users is fixed in a very simple way. The problem in the database (possibility of entering several duplicate (mailbox.name, mailbox.owner_idnr) pairs is not yet fixed, but is easily fixable by adding a UNIQUE constraint. -- ilja - 25-Aug-04 14:05 CEST -- both C-code and SQL-code fixed. Bug History Date Modified Username FieldChange == 25-Aug-04 11:43ilja New Bug 25-Aug-04 11:59ilja Bugnote Added: 202 25-Aug-04 14:05ilja Bugnote Added: 203 25-Aug-04 14:05ilja Resolution open => fixed 25-Aug-04 14:05ilja Status assigned => resolved ==
[Dbmail-dev] [DBMail 0000077]: dbmail-users segfault if password on command line is empty
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=077 == Reported By:sena Assigned To:ilja == Project:DBMail Bug ID: 77 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: crash Priority: normal Status: closed == Date Submitted: 24-Aug-04 11:53 CEST Last Modified: 25-Aug-04 14:05 CEST == Summary:dbmail-users segfault if password on command line is empty Description: boom == -- aaron - 24-Aug-04 18:26 CEST -- I don't see this failing in the latest 2_0 CVS. Are you on a different branch or an earlier revision? -- danweber - 24-Aug-04 18:48 CEST -- Could you grab a core dump file and send it to the mailing list? Dan -- sena - 25-Aug-04 11:00 CEST -- I updated my CVS tree and the bug is gone. Sorry. -- ilja - 25-Aug-04 11:04 CEST -- bug was fixed after user updated to newest CVS. Bug History Date Modified Username FieldChange == 24-Aug-04 11:53sena New Bug 24-Aug-04 18:26aaron Bugnote Added: 194 24-Aug-04 18:48danweber Bugnote Added: 195 25-Aug-04 11:00sena Bugnote Added: 200 25-Aug-04 11:04ilja Bugnote Added: 201 25-Aug-04 11:04ilja Assigned To => ilja 25-Aug-04 11:04ilja Resolution open => not a bug 25-Aug-04 11:04ilja Status new => resolved 25-Aug-04 14:05ilja Status resolved => closed ==
[Dbmail-dev] [DBMail 0000069]: Error in MySQL InnoDB-Migration script
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=069 == Reported By:va1210 Assigned To:ilja == Project:DBMail Bug ID: 69 Category: Authentication layer Reproducibility:always Severity: major Priority: normal Status: closed == Date Submitted: 22-Aug-04 18:18 CEST Last Modified: 25-Aug-04 14:15 CEST == Summary:Error in MySQL InnoDB-Migration script Description: The foreign key reference in the InnoDB-migration script for MySQL has an error in the "alter messageblks table"-section. The line REFERENCES physmessage_id (id) Should in fact say REFERENCES dbmail_physmessage (id) The reference error makes it impossible for mails to be inserted into the database as the reference always returns an error. == -- ilja - 23-Aug-04 11:32 CEST -- fixed applied (both in TRUNK and dbmail_2_0_branch) Bug History Date Modified Username FieldChange == 22-Aug-04 18:18va1210 New Bug 23-Aug-04 10:54ilja Assigned To => ilja 23-Aug-04 10:54ilja Status new => assigned 23-Aug-04 11:32ilja Bugnote Added: 181 23-Aug-04 11:32ilja Resolution open => fixed 23-Aug-04 11:32ilja Status assigned => resolved 25-Aug-04 14:15ilja Status resolved => closed ==
[Dbmail-dev] [DBMail 0000078]: dbmail-users -a doesn't stop when a user already exists.
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=078 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 78 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: major Priority: urgent Status: closed == Date Submitted: 25-Aug-04 11:43 CEST Last Modified: 25-Aug-04 14:16 CEST == Summary:dbmail-users -a doesn't stop when a user already exists. Description: dbmail-users -a adds a new user. If the user already exists, it should stop. Instead it goes on, and creates an INBOX for the already existing user. == -- ilja - 25-Aug-04 11:59 CEST -- The problem in dbmail-users is fixed in a very simple way. The problem in the database (possibility of entering several duplicate (mailbox.name, mailbox.owner_idnr) pairs is not yet fixed, but is easily fixable by adding a UNIQUE constraint. -- ilja - 25-Aug-04 14:05 CEST -- both C-code and SQL-code fixed. Bug History Date Modified Username FieldChange == 25-Aug-04 11:43ilja New Bug 25-Aug-04 11:59ilja Bugnote Added: 202 25-Aug-04 14:05ilja Bugnote Added: 203 25-Aug-04 14:05ilja Resolution open => fixed 25-Aug-04 14:05ilja Status assigned => resolved 25-Aug-04 14:16ilja Status resolved => closed ==
[Dbmail-dev] [DBMail 0000071]: dbmail-readvut is unused and should be removed
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=071 == Reported By:paul Assigned To:ilja == Project:DBMail Bug ID: 71 Category: Command-Line programs (dbmail-users, dbmail-util) Reproducibility:always Severity: trivial Priority: normal Status: closed == Date Submitted: 23-Aug-04 14:11 CEST Last Modified: 25-Aug-04 14:16 CEST == Summary:dbmail-readvut is unused and should be removed Description: dbmail-readvut is currently unused and undocumented. It should probably be removed. Functionality is easily provided by dbmail-user and a shell script. == -- ilja - 23-Aug-04 14:24 CEST -- Agreed. It should be removed. I'll get on it. -- ilja - 23-Aug-04 14:32 CEST -- dbmail-readvut is removed. All references to it are removed from build-scripts. -- aaron - 23-Aug-04 21:36 CEST -- Well it wasn't undocumented, I wrote a man page for it. So if you're removing the binary, be sure to scrap the man page, too. -- aaron - 24-Aug-04 18:24 CEST -- Turns out I made everyone's life easier by forgetting to commit the manpage I wrote! Off to the bitbucket... Bug History Date Modified Username FieldChange == 23-Aug-04 14:11paul New Bug 23-Aug-04 14:24ilja Assigned To => ilja 23-Aug-04 14:24ilja Status new => assigned 23-Aug-04 14:24ilja Bugnote Added: 183 23-Aug-04 14:32ilja Bugnote Added: 184 23-Aug-04 14:32ilja Resolution open => fixed 23-Aug-04 14:32ilja Status assigned => resolved 23-Aug-04 21:36aaron Bugnote Added: 192 23-Aug-04 21:36aaron Resolution fixed => reopened 23-Aug-04 21:36aaron Status resolved => feedback 24-Aug-04 18:24aaron Bugnote Added: 193 24-Aug-04 18:24aaron Resolution reopened => fixed 24-Aug-04 18:24aaron Status feedback => resolved 25-Aug-04 14:16ilja Status resolved => closed ==
[Dbmail-dev] [DBMail 0000058]: accept single connection from same host
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=058 == Reported By:danweber Assigned To:ilja == Project:DBMail Bug ID: 58 Category: IMAP daemon Reproducibility:always Severity: major Priority: urgent Status: closed == Date Submitted: 24-Jul-04 03:48 CEST Last Modified: 25-Aug-04 14:16 CEST == Summary:accept single connection from same host Description: The imap is only accepting a single connection from same host at one time, while if you are behind a nat this can be trouble some. For more information I have documented this in my own bts for personal purposes. Make the email have the following To: [EMAIL PROTECTED] Subject: -F 10 That will spew out information about the report. == -- aaron - 29-Jul-04 09:39 CEST -- ubject: one connection from same host only >Number: 10 >Notify-List: >Category: dbmail >Synopsis: one connection from same host only >Confidential: no >Severity: serious >Priority: high >Responsible:dan >State: open >Class: sw-bug >Submitter-Id: dan >Arrival-Date: Fri Jul 23 21:35:58 -0400 2004 >Last-Modified: Fri Jul 23 22:47:33 -0400 2004 >Originator: [EMAIL PROTECTED] (Dan Weber) >Release:2.0rc8-CVS HEAD >Organization: >Environment: Linux 2.6 i686 >Description: DBMail is only accepting imap connections from the same host one at a time, this can have problems if you have users behind nat both with imap accounts. >How-To-Repeat: Try opening two different instances of your mail client and see if one has problems connecting. >Fix: Unknown at this time >Release-Note: >Audit-Trail: >Unformatted: -- danweber - 02-Aug-04 13:19 CEST -- This breaks a lot of mail clients, most notably thunderbird and mutt. I can have thunderbird open, and be in console and try and open mutt, and mutt can't connect. Also Thunderbird can open multiple folders either. -- ilja - 02-Aug-04 14:31 CEST -- I'm unable to reproduce this behaviour. Using a server and logging in from 2 separate terminals using telnet does not give any problems. You should give more information on the problem. E.g. add some logs, show the same thing using telnet sessions, show your dbmail.conf. -- danweber - 15-Aug-04 19:13 CEST -- This bug does still exist, however, only when number of childs are low, and min childs match number of childs -- ilja - 16-Aug-04 11:08 CEST -- I think this is more of a configuration problem than a bug. The only thing aspect of this that you can consider a bug is that DBMail does not spawn new server daemons when there are no more idle daemon processes left. This, however, is more a structural problem than a real bug. It is solved by a patch made by Paul J Stevens, which will be added to 2.1 Bug History Date Modified Username FieldChange == 24-Jul-04 03:48danweber New Bug 28-Jul-04 22:09danweber Priority normal => high 28-Jul-04 22:09danweber Severity feature => major 28-Jul-04 22:09danweber Status new => acknowledged 29-Jul-04 09:39aaron Bugnote Added: 124 02-Aug-04 13:19danweber Bugnote Added: 129 02-Aug-04 13:19danweber Priority high => urgent 02-Aug-04 14:31ilja Bugnote Added: 130 04-Aug-04 15:48ilja Assigned To => ilja 04-Aug-04 15:48ilja Status acknowledged => a
[Dbmail-dev] [DBMail 0000068]: External forwarding broken.
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=068 == Reported By:thafreak Assigned To:ilja == Project:DBMail Bug ID: 68 Category: general delivery Reproducibility:sometimes Severity: major Priority: high Status: closed == Date Submitted: 20-Aug-04 16:26 CEST Last Modified: 25-Aug-04 14:17 CEST == Summary:External forwarding broken. Description: When a message comes in with a recipient to be forwarded externally (i.e. deliver_to is an outside emailaddress), some time after dbmail-lmtp looks up the forward address but before it opens the pipe to the sendmail command, the sender address gets garbage chars added to the end of it and therefor makes sendmail behave badly. The problem manifests itself either by sendmail refusing to deliver, or sendmail interpreting the extra chars as extra recipient addresses. == -- ilja - 20-Aug-04 16:54 CEST -- The problem doesn't appear to come from forward.c. It seems to come from the place where the from address is set. I'll go on searching from lmtpc. I'll have a good look. -- thafreak - 20-Aug-04 17:33 CEST -- I'm not sure if this will help, but here is the header from one of the emails causing the problem: - Message-ID: <[EMAIL PROTECTED]> Date: Wed, 18 Aug 2004 16:07:11 -0400 From: Darren Brink <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Warren <[EMAIL PROTECTED]> Subject: Sara Lee Conversion Content-Type: multipart/mixed; boundary="090805070508060702070403" This is a multi-part message in MIME format. --090805070508060702070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit - Also, there is a vcard attached to the email by thunderbird...again not sure if either of these would make a difference, but the problem only apears sometimes...which may be cause by something in the email itself... Hope that helps. Doug -- ilja - 20-Aug-04 17:37 CEST -- This was an off by one error... current CVS should fix it. Bug History Date Modified Username FieldChange == 20-Aug-04 16:26thafreak New Bug 20-Aug-04 16:54ilja Bugnote Added: 175 20-Aug-04 16:55ilja ETA none => < 1 day 20-Aug-04 16:55ilja Priority normal => high 20-Aug-04 16:55ilja Projection none => minor fix 20-Aug-04 16:55ilja Assigned To => ilja 20-Aug-04 16:55ilja Status new => assigned 20-Aug-04 17:33thafreak Bugnote Added: 176 20-Aug-04 17:37ilja Bugnote Added: 177 20-Aug-04 17:37ilja Resolution open => fixed 20-Aug-04 17:37ilja Status assigned => resolved 25-Aug-04 14:17ilja Status resolved => closed ==
[Dbmail-dev] [DBMail 0000066]: imapsync doesn't always work when folders are non-existent
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=066 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 66 Category: IMAP daemon Reproducibility:always Severity: minor Priority: normal Status: closed == Date Submitted: 19-Aug-04 14:03 CEST Last Modified: 25-Aug-04 14:17 CEST == Summary:imapsync doesn't always work when folders are non-existent Description: When imapsync (tool used for synchronizing accounts on different IMAP servers) runs, it tries to create create mailboxes. Before creating a mailboxes, imapsync will try to get the STATUS and SELECT the mailbox. Because the result of the command will be -1, the nfaultyresponses variable will be incremented. When nfaultyresponses reaches MAX_FAULTY_RESPONSES, the connection to the client is closed. This means that an imapsync session will almost always stop prematurely. One solution to this problem is to reset the nfaultyresponses variable to zero after a "good" request is done. Doing this solves the problem. == -- aaron - 19-Aug-04 20:21 CEST -- Could you post a trace of the communications? I'm wondering if there are other valid commands necessarily being sent between the mailbox checks. That is, would your fix also work for a program that first tested all of the mailboxes and then created the missing ones, rather than testing/creating one at a time? I like the idea of resetting the protocol error count after a successful response; the error count makes sense in the case of a horrible bizarre signal loss, but not the occassional error every few hundred responses. I'd also like to think that asking for a nonexistant mailbox is not an error at all, and does not justify incrementing the error count. -- ilja - 20-Aug-04 12:32 CEST -- In this case, valid commands are sent between the failing commands, making the simple fix work. Indeed, the fix does not work when sending a few commands in a row that all fail. I agree that these commands should not increment the error counter. The way imapcommands works at the moment stops us from making a differentiation between commands that fail and commands that cannot be parsed ok. Perhaps we should get rid of the counter altogether? -- ilja - 20-Aug-04 13:58 CEST -- T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 38 OK APPEND completed.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 39 STATUS "mail/Deleted Items" (MESSAGES).. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] 39 NO specified mailbox does not exist.. ## T 10.0.1.241:50956 -> 10.0.1.241:143 [AP] 40 SELECT "mail/Deleted Items".. ## T 10.0.1.241:143 -> 10.0.1.241:50956 [AP] * BYE [TRY RFC].. # T 10.0.1.241:143 -> 10.0.1.241:50956 [AFP] 39 OK completed.. -- aaron - 20-Aug-04 18:13 CEST -- Maybe we should do the quick-fix in that case. I think it still makes sense to disconnect after a several garbage commands in a row. -- danweber - 23-Aug-04 01:46 CEST -- I had a similar problem with this in Mozilla Thunderbird and Outlook clients. This seems to still be unresolved. -- aaron - 23-Aug-04 06:36 CEST -- Dan, is this unresolved with the suggested fix applied, or just in current CVS? I don't
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 25-Aug-04 15:30 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? -- aaron - 23-Aug-04 18:07 CEST -- I've been opposed to moving the man pages because things like MySQL are all man.1, with the logic being that if the system is nothing but a smoking pile of disks, mysql isn't going to be the sort of admin tool that will recover it. But if there's a concensus to move to man.8, I'm not going to worry too much. -- danweber - 24-Aug-04 18:49 CEST -- I have been saying this for ages. *sigh* I was the one who told you Paul ;) Dan -- paul - 24-Aug-04 19:18 CEST -- Yeah, Dan. You were right. But instead of fixing it for the debian packages only I thought it would be easier to file a bug upstream. -- ilja - 25-Aug-04 15:30 CEST -- Paul, since you have CVS write access, can you do this? Not that I'm not willing to.. I've managed to screw up the autotools setup on my Linux box (on the Mac is was already dysfunctional) and cannot use it anymore... after running automake, configure doesn't produce a Makefile that can be used by make... Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed 23-Aug-04 18:07aaron Bugnote Added: 190 24-Aug-04 18:49danweber Bugnote Added: 196 24-Aug-04 19:18paul Bugnote Added: 198 25-Aug-04 15:30ilja Bugnote Added: 204 ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To: == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: confirmed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 25-Aug-04 17:08 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? -- aaron - 23-Aug-04 18:07 CEST -- I've been opposed to moving the man pages because things like MySQL are all man.1, with the logic being that if the system is nothing but a smoking pile of disks, mysql isn't going to be the sort of admin tool that will recover it. But if there's a concensus to move to man.8, I'm not going to worry too much. -- danweber - 24-Aug-04 18:49 CEST -- I have been saying this for ages. *sigh* I was the one who told you Paul ;) Dan -- paul - 24-Aug-04 19:18 CEST -- Yeah, Dan. You were right. But instead of fixing it for the debian packages only I thought it would be easier to file a bug upstream. -- ilja - 25-Aug-04 15:30 CEST -- Paul, since you have CVS write access, can you do this? Not that I'm not willing to.. I've managed to screw up the autotools setup on my Linux box (on the Mac is was already dysfunctional) and cannot use it anymore... after running automake, configure doesn't produce a Makefile that can be used by make... -- paul - 25-Aug-04 17:08 CEST -- tag: branch_2_0 I've committed all the required changes. Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed 23-Aug-04 18:07aaron Bugnote Added: 190 24-Aug-04 18:49danweber Bugnote Added: 196 24-Aug-04 19:18paul Bugnote Added: 198 25-Aug-04 15:30ilja Bugnote
[Dbmail-dev] [DBMail 0000057]: direct mailforwarding with [EMAIL PROTECTED]
A BUGNOTE has been added to this bug.
==
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=057
==
Reported By:maXXmaster
Assigned To:aaron
==
Project:DBMail
Bug ID: 57
Category: PIPE delivery (dbmail-smtp)
Reproducibility:N/A
Severity: feature
Priority: normal
Status: acknowledged
==
Date Submitted: 23-Jul-04 23:37 CEST
Last Modified: 25-Aug-04 17:43 CEST
==
Summary:direct mailforwarding with [EMAIL PROTECTED]
Description:
it doesn't seem that there is a way to store "special" mails like spam to a
different folder than INBOX when pipeing the message to dbmail-smtp. i'm
not sure if it is an imap-standard, but many imapservers allow you to send
a message to [EMAIL PROTECTED]
is there a way to realise that?
==
--
danweber - 24-Jul-04 03:38 CEST
--
Yes we need this feature added so we can start using tmda with exim too.
--
aaron - 24-Jul-04 17:05 CEST
--
There's a command line option to specify an alternate mailbox along with
the destination address:
dbmail -m mailbox {-t [headerfield] | -d [emailaddress]}
If there's a way to make this work with Exim, it would be much easier to
document such a method rather than adding new support for the
username+mailbox syntax.
--
maXXmaster - 25-Jul-04 20:40 CEST
--
i actually wanted to use it with amavis-new which is able to append an
foldername after the mailadress (incase of spam or viruses).. i'll
probably have to find a way to make it work with the -m mailboxname
option,..
let's see ;o)
edited on: 25-Jul-04 20:40
--
aaron - 25-Jul-04 20:44 CEST
--
Ok, keep us posted. Interfacing with other parts of the mail system is,
quite naturally, a high priority :-)
Is there a published standard advocating for this hack, btw? Some de facto
rule book that we can follow if it turns out to be necessary to support
this syntax?
--
maXXmaster - 25-Jul-04 22:56 CEST
--
well, not really,.. at least i couldn't find one within the last hour. my
(probably) working solution is to use the following chain:
postfix (:25) -> amavis-new (:10024) -> postfix#2 (:10025) -> procmail (->
script which does the conversion from [EMAIL PROTECTED] to the
dbmail-smtp syntax you mentioned) -> dbmail
maybe i can write more about the necessary configurations tomorrow.
--
maXXmaster - 26-Jul-04 11:52 CEST
--
i tried some things and came up with quite a good solution.
i use a small (php)script insted of the dbmail-smtp program in postfix
(inside master.cf) to extract the +folder from the emailaddress and pipe
it to dbmail-smtp. the only problem is, that dbmail-smtp cannot add
messages to a special mailbox, if i want to forward them to an
emailaddress. it just works with direct usernames (user -u markus vs -d
[EMAIL PROTECTED])
so either i ask the dbmail-database which useralias i should use for
special mailaddresses (that is exactly what dbmail-smtp should actually
do), or some of you guys add a few lines to make dbmail-smtp work with
mailboxes AND emailaddresses or to make it work with [EMAIL PROTECTED]
any suggestions? =)
edited on: 26-Jul-04 11:52
--
maXXmaster - 26-Jul-04 13:00 CEST
--
> Is there a published standard advocating for this hack, btw?
> Some de facto rule book that we can follow if it turns out
> to be necessary to support this syntax?
yes, there is. i found an rfc which "specifies" the [EMAIL PROTECTED]
syntax.
it can be found here:
http://www.ietf.org/rfc/rfc3598.txt
i hope that is enough information to the s
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
A BUGNOTE has been added to this bug. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To:aaron == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: assigned == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 26-Aug-04 06:08 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. -- aaron - 23-Aug-04 18:11 CEST -- Actually, pipelining means that neither side should block or wait for anything during the RCPT stage. So both behaviors are slightly wrong. -- danweber - 24-Aug-04 18:50 CEST -- Its good practice to send a response after rcpt. This way it allows a compatible smtp client to be used with it, like python. Dan -- aaron - 24-Aug-04 19:28 CEST -- Oh, that's a good point. LMTP is a dialect of SMTP, the only difference is the HELO/EHLO/LHLO greeting. Simple scripts that speak simple SMTP can be easily modified to work with LMTP, but adding in the pipelining is more hassle than needed, since the particular behavior we are using isn't quite correct anyhow. So I agree we should change the responses to happen immediately following each RCPT. I'll post a patch this evening. -- aaron - 26-Aug-04 06:08 CEST -- This turns out to be fairly hard because I abstracted the list code out to a separate function, and so I'll need to un-abstract it a little bit. I'm still working on it, and expect to be done tomorrow evening. I'll commit the changes to HEAD and Ilja can patch it back to the release branch once we're 110% sure it's a correct patch. Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 23-Aug-04 18:11aaron Bugnote Added: 191 24-Aug-04 18:50danweber Bugnote Added: 197 24-Aug-04 19:28aaron Bugnote Added: 199 25-Aug-04 11:04ilja Assigned To => aaron 25-Aug-04 11:04ilja Status new => assigned 26-Aug-04 06:08aaron Bugnote Added: 207 ==
[Dbmail-dev] [DBMail 0000070]: Fails to give reponse upon completion of rcpt
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=070 == Reported By:danweber Assigned To:aaron == Project:DBMail Bug ID: 70 Category: LMTP daemon Reproducibility:always Severity: major Priority: normal Status: resolved Resolution: fixed == Date Submitted: 23-Aug-04 01:43 CEST Last Modified: 29-Aug-04 11:11 CEST == Summary:Fails to give reponse upon completion of rcpt Description: A responce is needed directly after rcpt command. Otherwise its incompatible with the rfc, and it also makes python hang.I stumbled upon this when I was adding lmtp support for mailbox2dbmail. == -- ilja - 23-Aug-04 13:32 CEST -- AFAIK the client _should_ support pipelining, which means the respons comes after the DATA command, not after every RCPT command. -- aaron - 23-Aug-04 18:11 CEST -- Actually, pipelining means that neither side should block or wait for anything during the RCPT stage. So both behaviors are slightly wrong. -- danweber - 24-Aug-04 18:50 CEST -- Its good practice to send a response after rcpt. This way it allows a compatible smtp client to be used with it, like python. Dan -- aaron - 24-Aug-04 19:28 CEST -- Oh, that's a good point. LMTP is a dialect of SMTP, the only difference is the HELO/EHLO/LHLO greeting. Simple scripts that speak simple SMTP can be easily modified to work with LMTP, but adding in the pipelining is more hassle than needed, since the particular behavior we are using isn't quite correct anyhow. So I agree we should change the responses to happen immediately following each RCPT. I'll post a patch this evening. -- aaron - 26-Aug-04 06:08 CEST -- This turns out to be fairly hard because I abstracted the list code out to a separate function, and so I'll need to un-abstract it a little bit. I'm still working on it, and expect to be done tomorrow evening. I'll commit the changes to HEAD and Ilja can patch it back to the release branch once we're 110% sure it's a correct patch. -- aaron - 29-Aug-04 11:11 CEST -- Fixed in HEAD. Refactoring turned up two memory leaks, too. Bug History Date Modified Username FieldChange == 23-Aug-04 01:43danweber New Bug 23-Aug-04 13:32ilja Bugnote Added: 182 23-Aug-04 18:11aaron Bugnote Added: 191 24-Aug-04 18:50danweber Bugnote Added: 197 24-Aug-04 19:28aaron Bugnote Added: 199 25-Aug-04 11:04ilja Assigned To => aaron 25-Aug-04 11:04ilja Status new => assigned 26-Aug-04 06:08aaron Bugnote Added: 207 29-Aug-04 11:11aaron Bugnote Added: 208 29-Aug-04 11:11aaron Resolution open => fixed 29-Aug-04 11:11aaron Status assigned => resolved ==
[Dbmail-dev] [DBMail 0000072]: man pages in wrong section
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=072 == Reported By:paul Assigned To:aaron == Project:DBMail Bug ID: 72 Category: installation scripts Reproducibility:always Severity: feature Priority: normal Status: resolved Resolution: fixed == Date Submitted: 23-Aug-04 14:16 CEST Last Modified: 29-Aug-04 11:12 CEST == Summary:man pages in wrong section Description: Man pages are currently all in section 1, whereas they all belong in section 8 with the possible exception of dbmail-smtp == -- ilja - 23-Aug-04 14:35 CEST -- Makes sense: section 1 is for user commands section 8 is for admin commands. I don't know about dbmail-smtp though.. It makes sense to put it in section 1, but it will probably never be run by users. So section 8 will perhaps be more appropriate.. -- paul - 23-Aug-04 15:10 CEST -- Given the fact that dbmail-smtp may very well be run from .procmailrc or command-line (cat oldmailbox|formail -ds /usr/sbin/dbmail-smtp -u mydbmailuser), I'd say that users may indeed run dbmail-smtp. -- ilja - 23-Aug-04 16:03 CEST -- Good point. We might as well move the man pages to the appropriate section then. All pages in section 8, except for dbmail-smtp Things to do: * change manpage source. (change 1 after title to 8) * change manpage extension to .8 * change man/Makefile.am to new filenames * automake && autoreconf anything else? -- aaron - 23-Aug-04 18:07 CEST -- I've been opposed to moving the man pages because things like MySQL are all man.1, with the logic being that if the system is nothing but a smoking pile of disks, mysql isn't going to be the sort of admin tool that will recover it. But if there's a concensus to move to man.8, I'm not going to worry too much. -- danweber - 24-Aug-04 18:49 CEST -- I have been saying this for ages. *sigh* I was the one who told you Paul ;) Dan -- paul - 24-Aug-04 19:18 CEST -- Yeah, Dan. You were right. But instead of fixing it for the debian packages only I thought it would be easier to file a bug upstream. -- ilja - 25-Aug-04 15:30 CEST -- Paul, since you have CVS write access, can you do this? Not that I'm not willing to.. I've managed to screw up the autotools setup on my Linux box (on the Mac is was already dysfunctional) and cannot use it anymore... after running automake, configure doesn't produce a Makefile that can be used by make... -- paul - 25-Aug-04 17:08 CEST -- tag: branch_2_0 I've committed all the required changes. -- aaron - 29-Aug-04 11:12 CEST -- Paul committed the changes, so this is closed now. Bug History Date Modified Username FieldChange == 23-Aug-04 14:16paul New Bug 23-Aug-04 14:35ilja Bugnote Added: 185 23-Aug-04 15:10paul Bugnote Added: 186 23-Aug-04 16:03ilja Bugnote Added: 189 23-Aug-04 16:04ilja Status new => confirmed 23-
[Dbmail-dev] [DBMail 0000079]: INTERNALDATE reponses do not conform to RFC
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=079 == Reported By:scocking Assigned To: == Project:DBMail Bug ID: 79 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 30-Aug-04 12:39 CEST Last Modified: 30-Aug-04 12:39 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- hh:mm:ss +" format as per the RFC. DBmail always responds without the " +" timezone. == Bug History Date Modified Username FieldChange == 30-Aug-04 12:39scocking New Bug ==
[Dbmail-dev] [DBMail 0000080]: Extraneous whitespace included in FETCH responses violates RFC
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=080 == Reported By:scocking Assigned To: == Project:DBMail Bug ID: 80 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 30-Aug-04 12:49 CEST Last Modified: 30-Aug-04 12:49 CEST == Summary:Extraneous whitespace included in FETCH responses violates RFC Description: The SnapperMail IMAP client reports IMAP protocol errors with many FETCH responses provided by DBmail. The problem appears to be extraneous whitespace provided at the end of DBmail's FETCH response. == Bug History Date Modified Username FieldChange == 30-Aug-04 12:49scocking New Bug ==
[Dbmail-dev] [DBMail 0000080]: Extraneous whitespace included in FETCH responses violates RFC
A BUGNOTE has been added to this bug. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=080 == Reported By:scocking Assigned To: == Project:DBMail Bug ID: 80 Category: IMAP daemon Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 30-Aug-04 12:49 CEST Last Modified: 30-Aug-04 14:35 CEST == Summary:Extraneous whitespace included in FETCH responses violates RFC Description: The SnapperMail IMAP client reports IMAP protocol errors with many FETCH responses provided by DBmail. The problem appears to be extraneous whitespace provided at the end of DBmail's FETCH response. == -- ilja - 30-Aug-04 14:35 CEST -- If I apply the following diff, it seems to be corrected: Index: imaputil.c === RCS file: /cvsroot-dbmail/dbmail/imaputil.c,v retrieving revision 1.74 diff -r1.74 imaputil.c 171c171 < fprintf(outstream, " %llu ", --- > fprintf(outstream, " %llu", 175c175 < fprintf(outstream, " %llu ", --- > fprintf(outstream, " %llu", 216c216 < fprintf(outstream, "%llu", --- > fprintf(outstream, " %llu", 219c219 < fprintf(outstream, "%llu", msg->bodylines); --- > fprintf(outstream, " %llu", msg->bodylines); Ilja Bug History Date Modified Username FieldChange == 30-Aug-04 12:49scocking New Bug 30-Aug-04 14:35ilja Bugnote Added: 210 ==
