A BUGNOTE has been added to this bug.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000086
======================================================================
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:05 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/pgsql/CVS/Entries 2004-09-10
16:32:50.000000000 -0600
+++ dbmail_1_2-20040909.fix/pgsql/CVS/Entries 2004-09-09
12:27:00.000000000 -0600
@@ -2,6 +2,6 @@
/Makefile.in/1.5.2.1/Thu Apr 29 07:44:20 2004//Tdbmail_1_2_branch
/dbauthpgsql.c/1.47.2.3/Fri Jun 4 09:04:06 2004//Tdbmail_1_2_branch
/dbmsgbufpgsql.c/1.17/Mon Mar 17 16:04:09 2003//Tdbmail_1_2_branch
-/dbpgsql.c/1.105.2.3/Fri Sep 10 08:53:38 2004//Tdbmail_1_2_branch
+/dbpgsql.c/1.105.2.2/Tue Mar 23 09:04:38 2004//Tdbmail_1_2_branch
/dbsearchpgsql.c/1.13/Fri Oct 24 09:21:31 2003//Tdbmail_1_2_branch
Maybe just cut that to be safe.
Bug History
Date Modified Username Field Change
======================================================================
09-Sep-04 21:26jnorell New Bug
09-Sep-04 21:26jnorell File Added: problem.log
09-Sep-04 21:44aaron Bugnote Added: 0000233
11-Sep-04 01:08jnorell Bugnote Added: 0000234
11-Sep-04 01:08jnorell File Added: dbmail_1_2-20040910_nullforward.patch
14-Sep-04 14:14ilja Bugnote Added: 0000236
14-Sep-04 14:24ilja Status new => acknowledged
14-Sep-04 16:37jnorell Bugnote Added: 0000238
14-Sep-04 16:45ilja Bugnote Added: 0000239
14-Sep-04 17:05jnorell Bugnote Added: 0000240
======================================================================
