A BUGNOTE has been added to this bug.
======================================================================
http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000189
======================================================================
Reported By: OutboundIndex
Assigned To:
======================================================================
Project: DBMail
Bug ID: 189
Category: Database layer
Reproducibility: always
Severity: crash
Priority: normal
Status: new
======================================================================
Date Submitted: 02-Apr-05 02:59 CEST
Last Modified: 03-Apr-05 04:04 CEST
======================================================================
Summary: if alias == deliver_to, dbmail-smtp hogs mem until
killed by oom or queue gives up
Description:
We had several thousand aliases correctly in the format:
alias: [EMAIL PROTECTED]
deliver_to: 701
However, after these severe overloads kept occurring on each queue run if
certain recips were in the run, I found 9 users who had aliases like
this:
alias: [EMAIL PROTECTED]
deliver_to: [EMAIL PROTECTED]
There is an actual user named [EMAIL PROTECTED]
The machine would become unusuable during the queue run attempts. Could do
nothing but wait for oom to kill something or the queue to give up. I
watched "top" during this and could usually see 5 or 6 dbmail-smtp's at
the top of the list for mem usage, each creeping up until it was taking
10% to 30% of mem.
A paste from the log after turning trace level up to 5 is in the
"additional information."
I don't know if this type of alias is specifically disallowed. It was my
understanding from the docs that either the user_idnr OR the user name was
acceptable for a deliver_to.
I suggest even if this is or becomes a forbidden format, that a slight
change in the code could prevent this type of looping.
======================================================================
----------------------------------------------------------------------
aaron - 02-Apr-05 08:58 CEST
----------------------------------------------------------------------
Firstly, this is an incorrect usage. It only makes sense that an address
which delivers to itself will result in a loop.
That said, we should detect this and produce an error.
Two plausible solutions: in auth_check_user_ext, retrieve the actual
result and compare it with the given argument. Alternatively, before
adding the argument to the forwarding list, check the previous element of
the forwarding list to see if it's identical.
Thoughts? Alternatives?
----------------------------------------------------------------------
aaron - 03-Apr-05 04:04 CEST
----------------------------------------------------------------------
Here's the first plan in code. I have a sneaky feeling that this will
prevent the first alias from ever getting onto the list, though.
--- dbmail/auth/authsql.c-- 2005-04-02 18:09:22.701539640 -0800
+++ dbmail/auth/authsql.c 2005-04-02 18:11:50.066136816 -0800
@@ -444,6 +444,11 @@
trace(TRACE_DEBUG, "%s,%s: checking user %s to
%s",
__FILE__, __func__, username,
query_result);
+
+ /* Don't begin an infinite loop. */
+ if (strcmp(username, query_result) == 0)
+ continue;
+
occurences +=
auth_check_user_ext(query_result, userids,
fwds, 1);
Bug History
Date Modified Username Field Change
======================================================================
02-Apr-05 02:59OutboundIndex New Bug
02-Apr-05 08:58aaron Bugnote Added: 0000648
03-Apr-05 04:04aaron Bugnote Added: 0000649
======================================================================
