[Dbmail-dev] [DBMail 0000087]: Possible memory leak in session and db code for pop3d
The following bug has been SUBMITTED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=087 == Reported By:ljackson Assigned To: == Project:DBMail Bug ID: 87 Category: Database layer Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 13-Sep-04 23:35 CEST Last Modified: 13-Sep-04 23:35 CEST == Summary:Possible memory leak in session and db code for pop3d Description: I have been able to reproduce in both cvs from 080304 and 2.0rc8 an issue where normal connects lists to the pop3d leaks memory, I have traced it to session code not being freed in the connection cleanup code. == Bug History Date Modified Username FieldChange == 13-Sep-04 23:35ljackson New Bug 13-Sep-04 23:35ljackson File Added: dbmail-2.0rc8.memleakmysql_pop3session.diff ==
[Dbmail-dev] [DBMail 0000085]: migration scripts contain errors
The following bug has been RESOLVED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=085 == Reported By:paul Assigned To:aaron == Project:DBMail Bug ID: 85 Category: installation scripts Reproducibility:always Severity: crash Priority: normal Status: resolved Resolution: fixed == Date Submitted: 09-Sep-04 15:43 CEST Last Modified: 14-Sep-04 00:07 CEST == Summary:migration scripts contain errors Description: After a successfull migration of a 1.2.9 installation to a 2.0.0 setup new subscriptions to mailboxes failed. Inspection reveals the migration scripts reference non-existant tables. == -- paul - 09-Sep-04 15:43 CEST -- Ilja, I've fixed this in dbmail_2_0_branch and in the trunk. -- aaron - 14-Sep-04 00:07 CEST -- Fixed by Paul. Bug History Date Modified Username FieldChange == 09-Sep-04 15:43paul New Bug 09-Sep-04 15:43paul Bugnote Added: 230 14-Sep-04 00:07aaron Bugnote Added: 235 14-Sep-04 00:07aaron Assigned To = aaron 14-Sep-04 00:07aaron Resolution open = fixed 14-Sep-04 00:07aaron Status new = resolved ==
[Dbmail-dev] DbMail CVS on FreeBSD 4.8, 4.9, 4.10 error pool.c: In function `child_reg_connected'
/usr/local/bin/bash ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.-fomit-frame-pointer -g -O2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wstrict-prototypes -c pool.c gcc -DHAVE_CONFIG_H -I. -I. -I. -fomit-frame-pointer -g -O2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wstrict-prototypes -Wp,-MD,.deps/pool.pp -c pool.c -fPIC -DPIC -o .libs/pool.o pool.c: In function `child_reg_connected': pool.c:265: syntax error before `int' pool.c:266: `key' undeclared (first use in this function) pool.c:266: (Each undeclared identifier is reported only once pool.c:266: for each function it appears in.) pool.c:262: warning: unused variable `pid' pool.c: In function `child_reg_disconnected': pool.c:278: syntax error before `int' pool.c:279: `key' undeclared (first use in this function) pool.c:275: warning: unused variable `pid' pool.c: In function `child_unregister': pool.c:298: syntax error before `int' pool.c:299: `key' undeclared (first use in this function) pool.c:295: warning: unused variable `pid' pool.c: In function `manage_stop_children': pool.c:361: syntax error before `int' pool.c:364: `stillSomeAlive' undeclared (first use in this function) pool.c:364: `cnt' undeclared (first use in this function) pool.c:368: `i' undeclared (first use in this function) pool.c:369: `chpid' undeclared (first use in this function) gmake[2]: *** [pool.lo] Error 1 gmake[2]: Leaving directory `/usr/install/new/dbmail' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/install/new/dbmail' gmake: *** [all-recursive-am] Error 2
[Dbmail-dev] sort patch now in CVS
Hi all, Following up on the performance thread I decided to checkout Leif's patch. It works great. I had to merge his code manually mostly due to Leif's indent and braces styles and the table changes since rc3, but that was no big deal. I've committed the patch to cvs-head. Please let me know how it works for you. If this hold up ok, I'll include this patch in the 2.0.0 debian packages as well. Thank you Leif. The sqmail crowd will love this. -- Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl signature.asc Description: OpenPGP digital signature
[Dbmail-dev] [DBMail 0000088]: INSTALL.postfix has an error. Should say 'reject' instead of 'bounce' on non-existent recipient
The following bug has been ASSIGNED. == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=088 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 88 Category: Documentation Reproducibility:N/A Severity: trivial Priority: low Status: assigned == Date Submitted: 14-Sep-04 12:02 CEST Last Modified: 14-Sep-04 12:02 CEST == Summary:INSTALL.postfix has an error. Should say 'reject' instead of 'bounce' on non-existent recipient Description: last line of INSTALL.postfix: s/'send a bounce'/'refuse the mail'/ will fix it. == Bug History Date Modified Username FieldChange == 14-Sep-04 12:02ilja New Bug 14-Sep-04 12:02ilja Assigned To = ilja 14-Sep-04 12:02ilja Status new = assigned ==
[Dbmail-dev] [DBMail 0000088]: INSTALL.postfix has an error. Should say 'reject' instead of 'bounce' on non-existent recipient
The following bug has been CLOSED == http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=088 == Reported By:ilja Assigned To:ilja == Project:DBMail Bug ID: 88 Category: Documentation Reproducibility:N/A Severity: trivial Priority: low Status: closed == Date Submitted: 14-Sep-04 12:02 CEST Last Modified: 14-Sep-04 12:10 CEST == Summary:INSTALL.postfix has an error. Should say 'reject' instead of 'bounce' on non-existent recipient Description: last line of INSTALL.postfix: s/'send a bounce'/'refuse the mail'/ will fix it. == Bug History Date Modified Username FieldChange == 14-Sep-04 12:02ilja New Bug 14-Sep-04 12:02ilja Assigned To = ilja 14-Sep-04 12:02ilja Status new = assigned 14-Sep-04 12:08ilja Resolution open = fixed 14-Sep-04 12:08ilja Status assigned = resolved 14-Sep-04 12:10ilja Status resolved = closed ==
[Dbmail-dev] configure problem
Hi I'm in progress to test my changes for FirebirdSQL and have a problem with ltconfig. I've changed acinclude.m4/Makefile.am/configure.in for support '--with-fbsql'. After that, I run aclocal, automake and autoconf without any parameters. There were no warnings. If I start ./configure --with-fbsql, it checks for headerfile, but it stops with '/bin/sh: buildtools/ltconfig: No such file or directory' and 'configure: error: libtool configure fails'. Does anybody has an idea what I'm doing wrong? My system is OpenBSD 3.5 with glib2-2.2.3, gmake-3.80, libiconv-1.9.1, libtool-1.3.5p3, pkgconfig-0.15.0. Thanks for your help. Dominik Fässler
Re: [Dbmail-dev] configure problem
try running autoreconf -f -i Dominik Fässler wrote: Hi I'm in progress to test my changes for FirebirdSQL and have a problem with ltconfig. I've changed acinclude.m4/Makefile.am/configure.in for support '--with-fbsql'. After that, I run aclocal, automake and autoconf without any parameters. There were no warnings. If I start ./configure --with-fbsql, it checks for headerfile, but it stops with '/bin/sh: buildtools/ltconfig: No such file or directory' and 'configure: error: libtool configure fails'. Does anybody has an idea what I'm doing wrong? My system is OpenBSD 3.5 with glib2-2.2.3, gmake-3.80, libiconv-1.9.1, libtool-1.3.5p3, pkgconfig-0.15.0. Thanks for your help. Dominik Fässler ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl
Re: [Dbmail-dev] configure problem
Hi try running autoreconf -f -i ./configure stops now with: ltconfig: you must specify a host type if you use '--no-verify'. I tried --host=386-unknown-openbsd3.5, but this would not help. Thanks for your help. Dominik Fässler
[Dbmail-dev] [DBMail 0000086]: quota exceeded causes forwards to fail
The following bug has been ACKNOWLEDGED. == http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086 == Reported By:jnorell Assigned To: == Project:DBMail Bug ID: 86 Category: PIPE delivery (dbmail-smtp) Reproducibility:always Severity: major Priority: normal Status: acknowledged == Date Submitted: 09-Sep-04 21:26 CEST Last Modified: 14-Sep-04 14:24 CEST == Summary:quota exceeded causes forwards to fail Description: When an alias lookup resolves to multiple deliver_to's with at least one local INBOX delivery and one or more external forwards, if the local mailbox is over quota the external forwards are sent an empty message rather than the real email. == -- aaron - 09-Sep-04 21:44 CEST -- I think you're exactly right about moving the quota checks to follow the forwards. Try that out and see if that patches it right up. The new delivery chain in 2.0 should not be affected, but it would be prudent to double check it against related bugs... like what happens if the *delivery user* has a quota applied, for whatever odd reason, or with combinations of within quota, above quota and non-quota accounts and forwards. -- jnorell - 11-Sep-04 01:08 CEST -- After surmounting the delivery-chain learning curve, a fix is quite simple, and that's just it (move forwards to happen before quota checks). Patch is attached, tested only in pgsql, but is working fine on our production machines so far. -- ilja - 14-Sep-04 14:14 CEST -- I can't apply the patch. It bails out when trying to patch pgsql/dbpgsql.c. Also, the patch looks a bit big. Does it change more than only the forwarding code? Jesse, can you please make a patch that applies cleanly to dbmail 1.2 CVS (not 1.2.10) Bug History Date Modified Username FieldChange == 09-Sep-04 21:26jnorellNew Bug 09-Sep-04 21:26jnorellFile Added: problem.log 09-Sep-04 21:44aaron Bugnote Added: 233 11-Sep-04 01:08jnorellBugnote Added: 234 11-Sep-04 01:08jnorellFile Added: dbmail_1_2-20040910_nullforward.patch 14-Sep-04 14:14ilja Bugnote Added: 236 14-Sep-04 14:24ilja Status new = acknowledged ==
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
I don't get it. Why doesn't freebsd like this code?
code
void manage_stop_children()
{
/*
*
* cleanup all remaining forked processes
*
*/
trace(TRACE_MESSAGE, %s,%s: General stop requested. Killing children..
,
__FILE__,__func__);
int stillSomeAlive = 1;
int i, cnt = 0;
pid_t chpid;
while (stillSomeAlive cnt 10) {
stillSomeAlive = 0;
cnt++;
/code
It appears gcc on freebsd doesn't like 'int var=0' type declarations inside
functions. Or am I missing something else here.
Someone with access to freebsd please help me out here. Ilja?
Igor Olemskoi wrote:
de/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith
-Wstrict-prototypes -c pool.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -fomit-frame-pointer -g -O2
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall
-Wpointer-arith -Wstrict-prototypes -Wp,-MD,.deps/pool.pp -c pool.c
-fPIC -DPIC -o .libs/pool.o
pool.c: In function `manage_stop_children':
pool.c:369: syntax error before `int'
pool.c:372: `stillSomeAlive' undeclared (first use in this function)
pool.c:372: (Each undeclared identifier is reported only once
pool.c:372: for each function it appears in.)
pool.c:372: `cnt' undeclared (first use in this function)
pool.c:376: `i' undeclared (first use in this function)
pool.c:377: `chpid' undeclared (first use in this function)
gmake[2]: *** [pool.lo] Error 1
gmake[2]: Leaving directory `/home/nix/projects/dbmail'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/nix/projects/dbmail'
gmake: *** [all-recursive-am] Error 2
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands___www.nfg.nl
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
On Tue, 14 Sep 2004 16:03:36 +0200, Paul J Stevens [EMAIL PROTECTED] wrote:
I don't get it. Why doesn't freebsd like this code?
code
void manage_stop_children()
{
/*
*
* cleanup all remaining forked processes
*
*/
trace(TRACE_MESSAGE, %s,%s: General stop requested. Killing
children.. ,
__FILE__,__func__);
int stillSomeAlive = 1;
int i, cnt = 0;
pid_t chpid;
while (stillSomeAlive cnt 10) {
stillSomeAlive = 0;
cnt++;
/code
It appears gcc on freebsd doesn't like 'int var=0' type declarations inside
functions. Or am I missing something else here.
Someone with access to freebsd please help me out here. Ilja?
I think it doesn't like the fact that the trace() call comes before
the variable declarations. If I compile with the '-pedantic' options,
I get the following message:
pool.c: In function `manage_stop_children':
pool.c:369: warning: ISO C89 forbids mixed declarations and code
If that's the problem, then the solution would be to put the trace()
call after all variable declarations.
BTW, I don't have a FreeBSD machine here, so I can't test it.
Ilja
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
But then, building with -pedantic triggers loads of warnings :-(
Ilja Booij wrote:
On Tue, 14 Sep 2004 16:03:36 +0200, Paul J Stevens [EMAIL PROTECTED] wrote:
I don't get it. Why doesn't freebsd like this code?
code
void manage_stop_children()
{
/*
*
* cleanup all remaining forked processes
*
*/
trace(TRACE_MESSAGE, %s,%s: General stop requested. Killing children..
,
__FILE__,__func__);
int stillSomeAlive = 1;
int i, cnt = 0;
pid_t chpid;
while (stillSomeAlive cnt 10) {
stillSomeAlive = 0;
cnt++;
/code
It appears gcc on freebsd doesn't like 'int var=0' type declarations inside
functions. Or am I missing something else here.
Someone with access to freebsd please help me out here. Ilja?
I think it doesn't like the fact that the trace() call comes before
the variable declarations. If I compile with the '-pedantic' options,
I get the following message:
pool.c: In function `manage_stop_children':
pool.c:369: warning: ISO C89 forbids mixed declarations and code
If that's the problem, then the solution would be to put the trace()
call after all variable declarations.
BTW, I don't have a FreeBSD machine here, so I can't test it.
Ilja
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands___www.nfg.nl
Re: [Dbmail-dev] ACLs: anyone user
On Sat, 11 Sep 2004 15:05:42 +0200, Thomas Mueller [EMAIL PROTECTED] wrote: Hi, I have a problem with anyone ACLs: using mutt I can change to: imaps://server/#Users/myuser/INBOX/mailbox When I try to select the folder in Thunderbirds 'manage folder subscriptions' the user isn't even listed. So 'anyone' ACLs seems to work, but 'anyone' folders aren't listed if a client asks for the folder list, is that possible? It certainly is possible.. I've just checked it and found the same symptoms. I've almost fixed it though, now code will be in CVS in 30 minutes or so (both HEAD and dbmail_2_0_branch) I'm running cvs head from yesterday (dynamic preforking works like a charm, great!). preforking sure is nice.. great work by Paul! Ilja
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
Hi Paul,
I don't get it. Why doesn't freebsd like this code?
code
void manage_stop_children()
{
/*
*
* cleanup all remaining forked processes
*
*/
trace(TRACE_MESSAGE, %s,%s: General stop requested. Killing
children.. ,
__FILE__,__func__);
int stillSomeAlive = 1;
It appears gcc on freebsd doesn't like 'int var=0' type declarations inside
functions. Or am I missing something else here.
That's not allowed in C, all declarations have to be first. C++ allows
declarations everywhere. Nevertheless 'declarations first' is a good
idea for better readability ...
Thomas
--
http://www.tmueller.com for pgp key (95702B3B)
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
I'll switch to building the debian packages with -pedantic -std=c99
I've also committed the change suggested by Ilja.
What's the score on freebsd? Anyone care to test, please?
Paul J Stevens wrote:
But then, building with -pedantic triggers loads of warnings :-(
Ilja Booij wrote:
On Tue, 14 Sep 2004 16:03:36 +0200, Paul J Stevens [EMAIL PROTECTED] wrote:
I don't get it. Why doesn't freebsd like this code?
code
void manage_stop_children()
{
/*
*
* cleanup all remaining forked processes
*
*/
trace(TRACE_MESSAGE, %s,%s: General stop requested. Killing
children.. ,
__FILE__,__func__);
int stillSomeAlive = 1;
int i, cnt = 0;
pid_t chpid;
while (stillSomeAlive cnt 10) {
stillSomeAlive = 0;
cnt++;
/code
It appears gcc on freebsd doesn't like 'int var=0' type declarations
inside
functions. Or am I missing something else here.
Someone with access to freebsd please help me out here. Ilja?
I think it doesn't like the fact that the trace() call comes before
the variable declarations. If I compile with the '-pedantic' options,
I get the following message:
pool.c: In function `manage_stop_children':
pool.c:369: warning: ISO C89 forbids mixed declarations and code
If that's the problem, then the solution would be to put the trace()
call after all variable declarations.
BTW, I don't have a FreeBSD machine here, so I can't test it.
Ilja
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands___www.nfg.nl
[Dbmail-dev] [DBMail 0000086]: quota exceeded causes forwards to fail
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086
==
Reported By:jnorell
Assigned To:
==
Project:DBMail
Bug ID: 86
Category: PIPE delivery (dbmail-smtp)
Reproducibility:always
Severity: major
Priority: normal
Status: acknowledged
==
Date Submitted: 09-Sep-04 21:26 CEST
Last Modified: 14-Sep-04 16:37 CEST
==
Summary:quota exceeded causes forwards to fail
Description:
When an alias lookup resolves to multiple deliver_to's with at least one
local INBOX delivery and one or more external forwards, if the local
mailbox is over quota the external forwards are sent an empty message
rather than the real email.
==
--
aaron - 09-Sep-04 21:44 CEST
--
I think you're exactly right about moving the quota checks to follow the
forwards. Try that out and see if that patches it right up. The new
delivery chain in 2.0 should not be affected, but it would be prudent to
double check it against related bugs... like what happens if the *delivery
user* has a quota applied, for whatever odd reason, or with combinations
of within quota, above quota and non-quota accounts and forwards.
--
jnorell - 11-Sep-04 01:08 CEST
--
After surmounting the delivery-chain learning curve, a fix is quite simple,
and that's just it (move forwards to happen before quota checks). Patch
is attached, tested only in pgsql, but is working fine on our production
machines so far.
--
ilja - 14-Sep-04 14:14 CEST
--
I can't apply the patch. It bails out when trying to patch
pgsql/dbpgsql.c.
Also, the patch looks a bit big. Does it change more than only the
forwarding code?
Jesse, can you please make a patch that applies cleanly to dbmail 1.2 CVS
(not 1.2.10)
--
jnorell - 14-Sep-04 16:37 CEST
--
You sure you didn't miss a -p1 or something? It applies clean for me:
mail2:/usr/src/dbmail# ./grab_latest_cvs
Press [Enter] at 'CVS password:' prompt
Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot-dbmail
CVS password:
Got latest cvs code - in directory dbmail_1_2-20040914
mail2:/usr/src/dbmail# cd dbmail_1_2-20040914
mail2:/usr/src/dbmail/dbmail_1_2-20040914# patch -p1
../dbmail_1_2-20040910_nullforward.patch
patching file forward.c
patching file mysql/dbmysql.c
patching file pgsql/CVS/Entries
patching file pgsql/dbpgsql.c
patching file pipe.c
The only things that aren't strictly towards this fix are a bit of
cleanup for a couple things that aren't needed (eg. some extra
if (..) { .. }'s for conditions that will never be true because you're
already in an else { .. } for that same condition) and added a trace
to dbpgsql.c to complain if we were requested to forward a db message
and that message has no messageblks, removed a math bug in the % display
here:
trace (TRACE_DEBUG,pipe_forward(): Sending block
-size=%d total=%d (%d\%), usedmem, totalmem,
-(((usedmem/totalmem)*100)));
+size=%d total=%d, usedmem, totalmem);
And I removed this trace(), which I've always wish I never left in a
patch last year :)
trace (TRACE_DEBUG,db_send_message_lines(): Using %d size
buffer,WRITE_BUFFER_SIZE);
Bug History
Date Modified Username FieldChange
==
09-Sep-04 21:26jnorellNew Bug
09-Sep-04 21:26jnorellFile Added: problem.log
09-Sep-04 21:44aaron Bugnote Added: 233
11-Sep-04 01:08jnorellBugnote Added: 234
11-Sep-04 01:08jnorellFile Added: dbmail_1_2-20040910_nullforward.patch
14-Sep-04 14:14ilja Bugnote Added: 236
14-Sep-04 14:24ilja Status
[Dbmail-dev] [DBMail 0000086]: quota exceeded causes forwards to fail
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086
==
Reported By:jnorell
Assigned To:
==
Project:DBMail
Bug ID: 86
Category: PIPE delivery (dbmail-smtp)
Reproducibility:always
Severity: major
Priority: normal
Status: acknowledged
==
Date Submitted: 09-Sep-04 21:26 CEST
Last Modified: 14-Sep-04 16:45 CEST
==
Summary:quota exceeded causes forwards to fail
Description:
When an alias lookup resolves to multiple deliver_to's with at least one
local INBOX delivery and one or more external forwards, if the local
mailbox is over quota the external forwards are sent an empty message
rather than the real email.
==
--
aaron - 09-Sep-04 21:44 CEST
--
I think you're exactly right about moving the quota checks to follow the
forwards. Try that out and see if that patches it right up. The new
delivery chain in 2.0 should not be affected, but it would be prudent to
double check it against related bugs... like what happens if the *delivery
user* has a quota applied, for whatever odd reason, or with combinations
of within quota, above quota and non-quota accounts and forwards.
--
jnorell - 11-Sep-04 01:08 CEST
--
After surmounting the delivery-chain learning curve, a fix is quite simple,
and that's just it (move forwards to happen before quota checks). Patch
is attached, tested only in pgsql, but is working fine on our production
machines so far.
--
ilja - 14-Sep-04 14:14 CEST
--
I can't apply the patch. It bails out when trying to patch
pgsql/dbpgsql.c.
Also, the patch looks a bit big. Does it change more than only the
forwarding code?
Jesse, can you please make a patch that applies cleanly to dbmail 1.2 CVS
(not 1.2.10)
--
jnorell - 14-Sep-04 16:37 CEST
--
You sure you didn't miss a -p1 or something? It applies clean for me:
mail2:/usr/src/dbmail# ./grab_latest_cvs
Press [Enter] at 'CVS password:' prompt
Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot-dbmail
CVS password:
Got latest cvs code - in directory dbmail_1_2-20040914
mail2:/usr/src/dbmail# cd dbmail_1_2-20040914
mail2:/usr/src/dbmail/dbmail_1_2-20040914# patch -p1
../dbmail_1_2-20040910_nullforward.patch
patching file forward.c
patching file mysql/dbmysql.c
patching file pgsql/CVS/Entries
patching file pgsql/dbpgsql.c
patching file pipe.c
The only things that aren't strictly towards this fix are a bit of
cleanup for a couple things that aren't needed (eg. some extra
if (..) { .. }'s for conditions that will never be true because you're
already in an else { .. } for that same condition) and added a trace
to dbpgsql.c to complain if we were requested to forward a db message
and that message has no messageblks, removed a math bug in the % display
here:
trace (TRACE_DEBUG,pipe_forward(): Sending block
-size=%d total=%d (%d\%), usedmem, totalmem,
-(((usedmem/totalmem)*100)));
+size=%d total=%d, usedmem, totalmem);
And I removed this trace(), which I've always wish I never left in a
patch last year :)
trace (TRACE_DEBUG,db_send_message_lines(): Using %d size
buffer,WRITE_BUFFER_SIZE);
--
ilja - 14-Sep-04 16:45 CEST
--
OK, I must be doing something wrong then..
but why's this?:
patching file pgsql/CVS/Entries
Ilja
Bug History
Date Modified Username FieldChange
==
09-Sep-04 21:26jnorellNew Bug
09-Sep-04 21:26jnorellFile Added: problem.log
09-Sep-04 21:44aaron Bugnote Added: 233
11-Sep-04 01
Re: [Dbmail-dev] DbMail CVS on FreeBSD 4.8, 4.9, 4.10 error pool.c:In function `child_reg_connected'
Much better, Paul. That's one snag removed. gcc -DHAVE_CONFIG_H -I. -I. -I. -fomit-frame-pointer -g -O2 -I/usr/local/inc l ude/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wst ri ct-prototypes -c pop3d.c pop3d.c: In function `main': pop3d.c:113: syntax error before `' gmake[2]: *** [pop3d.o] Error 1 gmake[2]: Leaving directory `/usr/install/new/dbmail' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/install/new/dbmail' gmake: *** [all-recursive-am] Error 2 - Original Message - From: Paul J Stevens [EMAIL PROTECTED] To: DBMAIL Developers Mailinglist dbmail-dev@dbmail.org Sent: Tuesday, September 14, 2004 3:12 AM Subject: Re: [Dbmail-dev] DbMail CVS on FreeBSD 4.8, 4.9, 4.10 error pool.c:In function `child_reg_connected' Mike, I've fixed the variable declarations involved. Could you please test again? I don't have access to a freebsd machine, so I'm not all too certain I actually fixed this. [EMAIL PROTECTED] wrote: /usr/local/bin/bash ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.-fomit-frame-pointer -g -O2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wstrict-prototypes -c pool.c gcc -DHAVE_CONFIG_H -I. -I. -I. -fomit-frame-pointer -g -O2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wstrict-prototypes -Wp,-MD,.deps/pool.pp -c pool.c -fPIC -DPIC -o .libs/pool.o pool.c: In function `child_reg_connected': pool.c:265: syntax error before `int' pool.c:266: `key' undeclared (first use in this function) pool.c:266: (Each undeclared identifier is reported only once pool.c:266: for each function it appears in.) pool.c:262: warning: unused variable `pid' pool.c: In function `child_reg_disconnected': pool.c:278: syntax error before `int' pool.c:279: `key' undeclared (first use in this function) pool.c:275: warning: unused variable `pid' pool.c: In function `child_unregister': pool.c:298: syntax error before `int' pool.c:299: `key' undeclared (first use in this function) pool.c:295: warning: unused variable `pid' pool.c: In function `manage_stop_children': pool.c:361: syntax error before `int' pool.c:364: `stillSomeAlive' undeclared (first use in this function) pool.c:364: `cnt' undeclared (first use in this function) pool.c:368: `i' undeclared (first use in this function) pool.c:369: `chpid' undeclared (first use in this function) gmake[2]: *** [pool.lo] Error 1 gmake[2]: Leaving directory `/usr/install/new/dbmail' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/install/new/dbmail' gmake: *** [all-recursive-am] Error 2 ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] Aliases Expansion, is dbmail the correct place?
Hello list, I stumbled on the failure to deliver mail to external recipients, when the local user was over quota. Is dbmail the correct place to do the alias expansion? Shouldn't this be done better in the MTA? Postfix and Sendmail supports connection with some work to both postgreSQL and MySQL. Isn't it better that we document the installation process for both MTAs than trying to implement the functionality ourselves. I beleive that we will increase the scalability of the application if we move the alias expansion to Postfix or Sendmail. Magnus
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
Thomas Mueller wrote:
Hi Paul,
I don't get it. Why doesn't freebsd like this code?
code
void manage_stop_children()
{
/*
*
* cleanup all remaining forked processes
*
*/
trace(TRACE_MESSAGE, %s,%s: General stop requested. Killing
children.. ,
__FILE__,__func__);
int stillSomeAlive = 1;
It appears gcc on freebsd doesn't like 'int var=0' type declarations inside
functions. Or am I missing something else here.
That's not allowed in C, all declarations have to be first.
I'll keep that one in mind.
C++ allows
declarations everywhere. Nevertheless 'declarations first' is a good
idea for better readability ...
Not that I agree with the readability argument though... thinking about some
very long functions in imapcommands.c with some pretty obscure variables neatly
declared at the beginning, but unused until a few hundred lines below...
When I'm in refactoring mode, extracting to new functions, I move all
declarations to where they are first used, and then move the codeblock to a
seperate function. I guess doing so a lot lately on the imap code, I got into
this habit of keeping declarations neatly together with the code that uses them.
Anyway, hope this fixes it for the freebsd users.
--
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands___www.nfg.nl
Re: [Dbmail-dev] current cvs head doesn't compiles under freebsd 5.2.1
On Tue, 14 Sep 2004 16:52:08 +0200, Paul J Stevens [EMAIL PROTECTED] wrote: Thomas Mueller wrote: Hi Paul, I don't get it. Why doesn't freebsd like this code? It appears gcc on freebsd doesn't like 'int var=0' type declarations inside functions. Or am I missing something else here. That's not allowed in C, all declarations have to be first. I'll keep that one in mind. C++ allows declarations everywhere. Nevertheless 'declarations first' is a good idea for better readability ... Not that I agree with the readability argument though... thinking about some very long functions in imapcommands.c with some pretty obscure variables neatly declared at the beginning, but unused until a few hundred lines below... When I'm in refactoring mode, extracting to new functions, I move all declarations to where they are first used, and then move the codeblock to a seperate function. I guess doing so a lot lately on the imap code, I got into this habit of keeping declarations neatly together with the code that uses them. Anyway, hope this fixes it for the freebsd users. You're correct on the readability part. In very long functions, having all declarations in the beginning makes things unreadable. Making functions shorter is the way to fix this :). There are some very long and ugly functions in some parts of DBMail that need splitting up. Ilja
Re: [Dbmail-dev] Aliases Expansion, is dbmail the correct place?
On Tue, 14 Sep 2004 16:47:37 +0200, Magnus Sundberg [EMAIL PROTECTED] wrote: Hello list, I stumbled on the failure to deliver mail to external recipients, when the local user was over quota. Is dbmail the correct place to do the alias expansion? Shouldn't this be done better in the MTA? Postfix and Sendmail supports connection with some work to both postgreSQL and MySQL. Isn't it better that we document the installation process for both MTAs than trying to implement the functionality ourselves. I beleive that we will increase the scalability of the application if we move the alias expansion to Postfix or Sendmail. Is there is a way make the MTA doit the same way as DBMail does know. e.g: have an alias that forwards to an external address and to a local address. Hmm, I'm sure there's a way to do that.. Can you give an example of how to configure Postfix to do this? Ilja
[Dbmail-dev] [DBMail 0000086]: quota exceeded causes forwards to fail
A BUGNOTE has been added to this bug.
==
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=086
==
Reported By:jnorell
Assigned To:
==
Project:DBMail
Bug ID: 86
Category: PIPE delivery (dbmail-smtp)
Reproducibility:always
Severity: major
Priority: normal
Status: acknowledged
==
Date Submitted: 09-Sep-04 21:26 CEST
Last Modified: 14-Sep-04 17:12 CEST
==
Summary:quota exceeded causes forwards to fail
Description:
When an alias lookup resolves to multiple deliver_to's with at least one
local INBOX delivery and one or more external forwards, if the local
mailbox is over quota the external forwards are sent an empty message
rather than the real email.
==
--
aaron - 09-Sep-04 21:44 CEST
--
I think you're exactly right about moving the quota checks to follow the
forwards. Try that out and see if that patches it right up. The new
delivery chain in 2.0 should not be affected, but it would be prudent to
double check it against related bugs... like what happens if the *delivery
user* has a quota applied, for whatever odd reason, or with combinations
of within quota, above quota and non-quota accounts and forwards.
--
jnorell - 11-Sep-04 01:08 CEST
--
After surmounting the delivery-chain learning curve, a fix is quite simple,
and that's just it (move forwards to happen before quota checks). Patch
is attached, tested only in pgsql, but is working fine on our production
machines so far.
--
ilja - 14-Sep-04 14:14 CEST
--
I can't apply the patch. It bails out when trying to patch
pgsql/dbpgsql.c.
Also, the patch looks a bit big. Does it change more than only the
forwarding code?
Jesse, can you please make a patch that applies cleanly to dbmail 1.2 CVS
(not 1.2.10)
--
jnorell - 14-Sep-04 16:37 CEST
--
You sure you didn't miss a -p1 or something? It applies clean for me:
mail2:/usr/src/dbmail# ./grab_latest_cvs
Press [Enter] at 'CVS password:' prompt
Logging in to :pserver:[EMAIL PROTECTED]:2401/cvsroot-dbmail
CVS password:
Got latest cvs code - in directory dbmail_1_2-20040914
mail2:/usr/src/dbmail# cd dbmail_1_2-20040914
mail2:/usr/src/dbmail/dbmail_1_2-20040914# patch -p1
../dbmail_1_2-20040910_nullforward.patch
patching file forward.c
patching file mysql/dbmysql.c
patching file pgsql/CVS/Entries
patching file pgsql/dbpgsql.c
patching file pipe.c
The only things that aren't strictly towards this fix are a bit of
cleanup for a couple things that aren't needed (eg. some extra
if (..) { .. }'s for conditions that will never be true because you're
already in an else { .. } for that same condition) and added a trace
to dbpgsql.c to complain if we were requested to forward a db message
and that message has no messageblks, removed a math bug in the % display
here:
trace (TRACE_DEBUG,pipe_forward(): Sending block
-size=%d total=%d (%d\%), usedmem, totalmem,
-(((usedmem/totalmem)*100)));
+size=%d total=%d, usedmem, totalmem);
And I removed this trace(), which I've always wish I never left in a
patch last year :)
trace (TRACE_DEBUG,db_send_message_lines(): Using %d size
buffer,WRITE_BUFFER_SIZE);
--
ilja - 14-Sep-04 16:45 CEST
--
OK, I must be doing something wrong then..
but why's this?:
patching file pgsql/CVS/Entries
Ilja
--
jnorell - 14-Sep-04 17:05 CEST
--
I'd guess this is from a tag in dbpgsql.c, maybe? Perhaps I have more in
my local dir than I should (should not have CVS directory?) or maybe it's
harmless .. the change (which I didn't make manually) is:
--- dbmail_1_2-20040910
Re: [Dbmail-dev] ACLs: anyone user
fix is in dbmail_2_0_branch Iljja On Tue, 14 Sep 2004 17:31:47 +0200, Ilja Booij [EMAIL PROTECTED] wrote: On Tue, 14 Sep 2004 16:28:08 +0200, Ilja Booij [EMAIL PROTECTED] wrote: On Sat, 11 Sep 2004 15:05:42 +0200, Thomas Mueller [EMAIL PROTECTED] wrote: Hi, I have a problem with anyone ACLs: using mutt I can change to: imaps://server/#Users/myuser/INBOX/mailbox When I try to select the folder in Thunderbirds 'manage folder subscriptions' the user isn't even listed. So 'anyone' ACLs seems to work, but 'anyone' folders aren't listed if a client asks for the folder list, is that possible? It certainly is possible.. I've just checked it and found the same symptoms. I've almost fixed it though, now code will be in CVS in 30 minutes or so (both HEAD and dbmail_2_0_branch) The fix is now in HEAD. Ilja
Re: [Dbmail-dev] Aliases Expansion, is dbmail the correct place?
Ilja Booij wrote: On Tue, 14 Sep 2004 16:47:37 +0200, Magnus Sundberg [EMAIL PROTECTED] wrote: Hello list, I stumbled on the failure to deliver mail to external recipients, when the local user was over quota. Is dbmail the correct place to do the alias expansion? Shouldn't this be done better in the MTA? Postfix and Sendmail supports connection with some work to both postgreSQL and MySQL. Isn't it better that we document the installation process for both MTAs than trying to implement the functionality ourselves. I beleive that we will increase the scalability of the application if we move the alias expansion to Postfix or Sendmail. Is there is a way make the MTA doit the same way as DBMail does know. e.g: have an alias that forwards to an external address and to a local address. Hmm, I'm sure there's a way to do that.. Can you give an example of how to configure Postfix to do this? Ilja ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev From the postfix site, http://www.postfix.org/MYSQL_README.html In short the way to operate is, 1. Install the postfix-mysql package, or compile postfix with MySQL support. 2. edit main.cf and add alias_maps = mysql:/etc/postfix/mysql-aliases.cf 3. Edit the file above, I actually beleive it can read the dbmail alias table with the right commands. Postfix supports both MySQL and PostgreSQL Magnus
[Dbmail-dev] Dbmail-dev] DbMail CVS on FreeBSD 4.8, 4.9, 4.10 error pool.c:In function `child_reg_connected'
Paul J Stevens You break my heart. There's no '' on or near line pop3d.c:113 Hey Paul: It doesn't make any sense, does it? I didn't have a chance to open pop3d.c and impad.c before I fired off the last test you asked for but I do now see that it doesn't make sense. I switched back to GLIB2.2 from 2.4.6 and it built OK but badly broken in operation. I will play with the new dbmail.conf (MAX_ERRORS=500, MINSPARECHILDREN=4 MAXSPARECHILDREN=8) when I get a chance tonight. Must shut this dev machine down now and get on to some other aligators... Sep 14 09:22:45 sunny dbmail/pop3d[36714]: pool.c,manage_restart_children: child[43869] exited. Restarting... Sep 14 09:22:45 sunny dbmail/imap4d[36653]: pool.c,manage_restart_children: child [43868] exited. Restarting... Sep 14 09:22:45 sunny dbmail/pop3d[43976]: pool.c,child_register: register child[43976] Sep 14 09:22:45 sunny dbmail/imap4d[43977]: pool.c,child_register: register child [43977] Sep 14 09:22:45 sunny dbmail/pop3d[36714]: pool.c,manage_restart_children: child[43871] exited. Restarting... Sep 14 09:22:45 sunny dbmail/imap4d[36653]: pool.c,manage_restart_children: child [43870] exited. Restarting... Sep 14 09:22:45 sunny dbmail/pop3d[43978]: pool.c,child_register: register child[43978] .. infinite best... Mike M. J. [Mike] O'Brien wrote: Much better, Paul. That's one snag removed. gcc -DHAVE_CONFIG_H -I. -I. -I. -fomit-frame-pointer -g -O2 -I/usr/local/inc l ude/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wst ri ct-prototypes -c pop3d.c pop3d.c: In function `main': pop3d.c:113: syntax error before `' gmake[2]: *** [pop3d.o] Error 1 gmake[2]: Leaving directory `/usr/install/new/dbmail' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/install/new/dbmail' gmake: *** [all-recursive-am] Error 2 - Original Message - From: Paul J Stevens paul at nfg.nl To: DBMAIL Developers Mailinglist dbmail-dev at dbmail.org Sent: Tuesday, September 14, 2004 3:12 AM Subject: Re: [Dbmail-dev] DbMail CVS on FreeBSD 4.8, 4.9, 4.10 error pool.c:In function `child_reg_connected' Mike, I've fixed the variable declarations involved. Could you please test again? I don't have access to a freebsd machine, so I'm not all too certain I actually fixed this. mike at mobrien.com wrote: /usr/local/bin/bash ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.-fomit-frame-pointer -g -O2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wstrict-prototypes -c pool.c gcc -DHAVE_CONFIG_H -I. -I. -I. -fomit-frame-pointer -g -O2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -W -Wall -Wpointer-arith -Wstrict-prototypes -Wp,-MD,.deps/pool.pp -c pool.c -fPIC -DPIC -o .libs/pool.o pool.c: In function `child_reg_connected': pool.c:265: syntax error before `int' pool.c:266: `key' undeclared (first use in this function) pool.c:266: (Each undeclared identifier is reported only once pool.c:266: for each function it appears in.) pool.c:262: warning: unused variable `pid' pool.c: In function `child_reg_disconnected': pool.c:278: syntax error before `int' pool.c:279: `key' undeclared (first use in this function) pool.c:275: warning: unused variable `pid' pool.c: In function `child_unregister': pool.c:298: syntax error before `int' pool.c:299: `key' undeclared (first use in this function) pool.c:295: warning: unused variable `pid' pool.c: In function `manage_stop_children': pool.c:361: syntax error before `int' pool.c:364: `stillSomeAlive' undeclared (first use in this function) pool.c:364: `cnt' undeclared (first use in this function) pool.c:368: `i' undeclared (first use in this function) pool.c:369: `chpid' undeclared (first use in this function) gmake[2]: *** [pool.lo] Error 1 gmake[2]: Leaving directory `/usr/install/new/dbmail' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/install/new/dbmail' gmake: *** [all-recursive-am] Error 2 ___ Dbmail-dev mailing list Dbmail-dev at dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl ___ Dbmail-dev mailing list Dbmail-dev at dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev ___ Dbmail-dev mailing list Dbmail-dev at dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The
Re: [Dbmail-dev] sort patch now in CVS
Paul, Glad it will work in the current CVS head, thanks for putting it in there... As you said and I had planed it is just a stop gap till we have header caching. But the btree works well it needs some work for other clients than sqmail as other clients use diffrent sort parameters and I didn't finish all the options to the SORT command per the RFC. Thanks, Leif Hi all, Following up on the performance thread I decided to checkout Leif's patch. It works great. I had to merge his code manually mostly due to Leif's indent and braces styles and the table changes since rc3, but that was no big deal. I've committed the patch to cvs-head. Please let me know how it works for you. If this hold up ok, I'll include this patch in the 2.0.0 debian packages as well. Thank you Leif. The sqmail crowd will love this. -- Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands___www.nfg.nl ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
RE: [Dbmail-dev] Aliases Expansion, is dbmail the correct place?
Oops,
a little typo in
dbmail_remote_rcpts.sql
select_field should be set to deliver_to
:)
--
Wolfram
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wolfram
A. Kraushaar
Sent: Dienstag, 14. September 2004 20:35
To: 'DBMAIL Developers Mailinglist'
Subject: RE: [Dbmail-dev] Aliases Expansion, is dbmail the
correct place?
Hi,
using postfix 2.1.4 w/dict_mysql I tried that one
(looks like it works):
INSERT INTO dbmail_aliases (alias, deliver_to) VALUES
('[EMAIL PROTECTED]','10'); (10 is a valid user_idnr from the
dbmail_users table)
INSERT INTO dbmail_aliases (alias, deliver_to) VALUES
('[EMAIL PROTECTED]','[EMAIL PROTECTED]');
In Postfix main.cf:
local_recipient_maps =
proxy:mysql:/usr/local/etc/postfix/dbmail_local_rcpts.sql
virtual_alias_maps =
proxy:mysql:/usr/local/etc/postfix/dbmail_remote_rcpts.sql
In dbmail_local_rcpts.sql:
user = dbuser
password = dbpass
dbname = dbname
table = dbmail_aliases LEFT JOIN dbmail_users ON
dbmail_aliases.deliver_to =
dbmail_users.user_idnr
select_field = alias
where_field = alias
additional_conditions = AND dbmail_users.user_idnr IS NOT NULL
hosts = inet:dbhostname:3306
In dbmail_remote_rcpts.sql:
user = dbuser
password = dbpass
dbname = dbname
table = dbmail_aliases LEFT JOIN dbmail_users ON
dbmail_aliases.deliver_to =
dbmail_users.user_idnr
select_field = alias
where_field = alias
additional_conditions = AND dbmail_users.user_idnr IS NULL
hosts = inet:dbhostname:3306
--
Wolfram
Is there is a way make the MTA doit the same way as DBMail
does know.
e.g:
have an alias that forwards to an external address and to a
local address.
Hmm, I'm sure there's a way to do that.. Can you give an example of
how to configure Postfix to do this?
Ilja
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] Aliases Expansion, is dbmail the correct place?
OK, this looks really good. I'll have a try at it myself.
Does it also work if there are several different deliver_to's for an alias?
Ilja
On Tue, 14 Sep 2004 20:57:02 +0200, Wolfram A. Kraushaar
[EMAIL PROTECTED] wrote:
Oops,
a little typo in
dbmail_remote_rcpts.sql
select_field should be set to deliver_to
:)
--
Wolfram
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wolfram
A. Kraushaar
Sent: Dienstag, 14. September 2004 20:35
To: 'DBMAIL Developers Mailinglist'
Subject: RE: [Dbmail-dev] Aliases Expansion, is dbmail the
correct place?
Hi,
using postfix 2.1.4 w/dict_mysql I tried that one
(looks like it works):
INSERT INTO dbmail_aliases (alias, deliver_to) VALUES
('[EMAIL PROTECTED]','10'); (10 is a valid user_idnr from the
dbmail_users table)
INSERT INTO dbmail_aliases (alias, deliver_to) VALUES
('[EMAIL PROTECTED]','[EMAIL PROTECTED]');
In Postfix main.cf:
local_recipient_maps =
proxy:mysql:/usr/local/etc/postfix/dbmail_local_rcpts.sql
virtual_alias_maps =
proxy:mysql:/usr/local/etc/postfix/dbmail_remote_rcpts.sql
In dbmail_local_rcpts.sql:
user = dbuser
password = dbpass
dbname = dbname
table = dbmail_aliases LEFT JOIN dbmail_users ON
dbmail_aliases.deliver_to =
dbmail_users.user_idnr
select_field = alias
where_field = alias
additional_conditions = AND dbmail_users.user_idnr IS NOT NULL
hosts = inet:dbhostname:3306
In dbmail_remote_rcpts.sql:
user = dbuser
password = dbpass
dbname = dbname
table = dbmail_aliases LEFT JOIN dbmail_users ON
dbmail_aliases.deliver_to =
dbmail_users.user_idnr
select_field = alias
where_field = alias
additional_conditions = AND dbmail_users.user_idnr IS NULL
hosts = inet:dbhostname:3306
--
Wolfram
Is there is a way make the MTA doit the same way as DBMail
does know.
e.g:
have an alias that forwards to an external address and to a
local address.
Hmm, I'm sure there's a way to do that.. Can you give an example of
how to configure Postfix to do this?
Ilja
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
RE: [Dbmail-dev] Aliases Expansion, is dbmail the correct place?
Yes,
works with multiple forwarders on my testbox.
Does really good mean it obsoletes forward.c ? :o)
--
Wolfram
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ilja Booij
Sent: Dienstag, 14. September 2004 21:43
To: DBMAIL Developers Mailinglist
Subject: Re: [Dbmail-dev] Aliases Expansion, is dbmail the
correct place?
OK, this looks really good. I'll have a try at it myself.
Does it also work if there are several different deliver_to's
for an alias?
Ilja
On Tue, 14 Sep 2004 20:57:02 +0200, Wolfram A. Kraushaar
[EMAIL PROTECTED] wrote:
Oops,
a little typo in
dbmail_remote_rcpts.sql
select_field should be set to deliver_to
:)
--
Wolfram
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wolfram
A. Kraushaar
Sent: Dienstag, 14. September 2004 20:35
To: 'DBMAIL Developers Mailinglist'
Subject: RE: [Dbmail-dev] Aliases Expansion, is dbmail the
correct place?
Hi,
using postfix 2.1.4 w/dict_mysql I tried that one
(looks like it works):
INSERT INTO dbmail_aliases (alias, deliver_to) VALUES
('[EMAIL PROTECTED]','10'); (10 is a valid
user_idnr from the
dbmail_users table)
INSERT INTO dbmail_aliases (alias, deliver_to) VALUES
('[EMAIL PROTECTED]','[EMAIL PROTECTED]');
In Postfix main.cf:
local_recipient_maps =
proxy:mysql:/usr/local/etc/postfix/dbmail_local_rcpts.sql
virtual_alias_maps =
proxy:mysql:/usr/local/etc/postfix/dbmail_remote_rcpts.sql
In dbmail_local_rcpts.sql:
user = dbuser
password = dbpass
dbname = dbname
table = dbmail_aliases LEFT JOIN dbmail_users ON
dbmail_aliases.deliver_to =
dbmail_users.user_idnr
select_field = alias
where_field = alias
additional_conditions = AND dbmail_users.user_idnr IS NOT NULL
hosts = inet:dbhostname:3306
In dbmail_remote_rcpts.sql:
user = dbuser
password = dbpass
dbname = dbname
table = dbmail_aliases LEFT JOIN dbmail_users ON
dbmail_aliases.deliver_to =
dbmail_users.user_idnr
select_field = alias
where_field = alias
additional_conditions = AND dbmail_users.user_idnr IS NULL
hosts = inet:dbhostname:3306
--
Wolfram
Is there is a way make the MTA doit the same way as DBMail
does know.
e.g:
have an alias that forwards to an external address and to a
local address.
Hmm, I'm sure there's a way to do that.. Can you give
an example of
how to configure Postfix to do this?
Ilja
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
___
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] Patch for dynmaic table prefixes... please consider ASAP
Hi All, Paul or whomever is the one to review and add patches these days, I have made a patch for current CVS head (2.1) that allows for dynamic table prefixes as I am tired of patching the source each time I want to use the latest CVS on my test platforms... :) Please consider and apply to the codebase for 2.1 asap. This requires the addition of table_prefix to the dbmail.conf Thanks, Leif Jackson dbmail-2.1cvs091404-dynamicprefix.diff Description: Binary data
Re: [Dbmail-dev] Patch for dynmaic table prefixes... please consider ASAP
On Tue, 14 Sep 2004 15:59:51 -0400 (EDT), Leif Jackson [EMAIL PROTECTED] wrote: Hi All, Paul or whomever is the one to review and add patches these days, I have made a patch for current CVS head (2.1) that allows for dynamic table prefixes as I am tired of patching the source each time I want to use the latest CVS on my test platforms... :) Please consider and apply to the codebase for 2.1 asap. This requires the addition of table_prefix to the dbmail.conf I'll have a look at this tomorrow (it's 10:15PM here now.. Why am I reading my e-mail?) I take it that this patch has been working for you for some time already? Ilja
Re: [Dbmail-dev] Patch for dynmaic table prefixes... please consider ASAP
On Tue, 14 Sep 2004 15:59:51 -0400 (EDT), Leif Jackson [EMAIL PROTECTED] wrote: Hi All, Paul or whomever is the one to review and add patches these days, I have made a patch for current CVS head (2.1) that allows for dynamic table prefixes as I am tired of patching the source each time I want to use the latest CVS on my test platforms... :) Please consider and apply to the codebase for 2.1 asap. This requires the addition of table_prefix to the dbmail.conf I'll have a look at this tomorrow (it's 10:15PM here now.. Why am I reading my e-mail?) I take it that this patch has been working for you for some time already? nope just wrote it 15 min before sending the patch but it has been tested and it doesn't add anything but one option to the db_params struct. -leif Ilja ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
