The below fix works fine if alias == deliver_to, but if not for: alias deliver_to ----- ---------- alias1 alias2 alias2 alias1
I was thinking that in 1.2 code, a list was kept of all deliver_to addrs that had been traversed during delivery and any loops detected. Did that get removed at some point, or is my memory faulty? ---- Original Message ---- From: <dbmail-dev@dbmail.org> To: dbmail-dev@dbmail.org Subject: [Dbmail-dev] [DBMail 0000189]: if alias == deliver_to, dbmail-smtp hogs mem until killed by oom or queue gives up Sent: Thu, 21 Apr 2005 09:19:21 +0200 (CEST) > > 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: 21-Apr-05 09:19 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); > > ---------------------------------------------------------------------- > paul - 03-Apr-05 09:42 CEST > ---------------------------------------------------------------------- > Just an other idea: > > Index: auth/authsql.c > =================================================================== > --- auth/authsql.c (revision 1726) > +++ auth/authsql.c (working copy) > @@ -392,7 +392,9 @@ > } > snprintf(__auth_query_data, AUTH_QUERY_SIZE, > "SELECT deliver_to FROM dbmail_aliases " > - "WHERE lower(alias) = lower('%s')", escaped_username); > + "WHERE lower(alias) = lower('%s') " > + "AND lower(alias) <> lower(deliver_to)" > + escaped_username); > free(escaped_username); > > trace(TRACE_DEBUG, "%s,%s: checks [%d]", __FILE__, __func__, > > ---------------------------------------------------------------------- > aaron - 21-Apr-05 09:19 CEST > ---------------------------------------------------------------------- > Paul, you put your idea into code? Can we close this bug? > > 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 > 03-Apr-05 04:05aaron File Added: dbmail-aliasloop-idea1.diff > > 03-Apr-05 04:10aaron File Added: dbmail-aliasloop-idea2.diff > > 03-Apr-05 09:42paul Bugnote Added: 0000650 > 21-Apr-05 09:19aaron Bugnote Added: 0000661 > ====================================================================== > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- End Original Message -- -- Jesse Norell jesse @ kci.net
