Hello, Definitely looks like a bug. Could you take your last post and file a bug report on the website? I'd imagine it'd get taken care of pretty quick, as that's not the intended behavior (nor what I see using 1.2.x).
---- Original Message ---- From: April Lorenzen <[email protected]> To: DBMail mailinglist <[email protected]> Subject: [Dbmail] alias bug: if user exists, auth_check_user is skipped Sent: Thu, 13 Jan 2005 14:12:04 -0500 > version 2.03 debian jan 12th 2005 pkg as well as 2.02 debian pkg > postgresql version did the same for me: > > Ok I have pin-pointed the issue to the extent trace=5 will show > > I DELETED the alias [EMAIL PROTECTED] deliver to user 460 - [EMAIL PROTECTED] > But dbmail still delivers to that user - because dbmail seems to > initially look to see if a user exists instead of initially looking at > aliases. > > I go to gmail and send an email addressed to [EMAIL PROTECTED] > If userid [EMAIL PROTECTED] exists, dbmail never tries to look for aliases > at all. (Yes, our userid's are actual full email addresses since we host > many domains.) > > Jan 13 13:33:01 crunch-a dbmail/smtp[8365]: dbpgsql.c,db_query: > executing query [SELECT user_idnr FROM dbmail_users WHERE > userid='[EMAIL PROTECTED]'] > > (found one so why bother looking for aliases? - it isn't bothering) > > Jan 13 13:33:01 crunch-a dbmail/smtp[8365]: dsn.c, dsnuser_resolve: > added user [EMAIL PROTECTED] id [460] to delivery list > Jan 13 13:33:01 crunch-a dbmail/smtp[8365]: dbpgsql.c,db_query: > executing query [INSERT INTO dbmail_messageblks (is_header, messageblk, > blocks ETC the message is delivered just to that one user and that's it. > > > Then I rename the userid [EMAIL PROTECTED] in dbmail_users just to eliminate > it, make it impossible for dbmail to find it. I send again from gmail to > [EMAIL PROTECTED] This time dbmail apparently says "ok there's no user by > that name so let me look up aliases for that name" - and finally after > days of frustration - it delivers to the aliases as one would expect: > > Jan 13 13:39:03 crunch-a dbmail/smtp[9205]: dbpgsql.c,db_query: > executing query [SELECT user_idnr FROM dbmail_users WHERE > userid='[EMAIL PROTECTED]'] > > (no result found, so it then checks for aliases) > > Jan 13 13:39:03 crunch-a dbmail/smtp[9205]: > authsql.c,auth_check_user_ext: checking user [EMAIL PROTECTED] in alias table > Jan 13 13:39:03 crunch-a dbmail/smtp[9205]: dbpgsql.c,db_query: > executing query [SELECT deliver_to FROM dbmail_aliases WHERE > lower(alias) = lower('[EMAIL PROTECTED]')] > Jan 13 13:39:03 crunch-a dbmail/smtp[9205]: > authsql.c,auth_check_user_ext: checking user [EMAIL PROTECTED] to [EMAIL > PROTECTED] > Jan 13 13:39:03 crunch-a dbmail/smtp[9205]: > authsql.c,auth_check_user_ext: checking user [EMAIL PROTECTED] to [EMAIL > PROTECTED] > Jan 13 13:39:03 crunch-a dbmail/smtp[9205]: dsn.c, dsnuser_resolve: user > [EMAIL PROTECTED] found total of [2] aliases > > It appears to me that we have gone from the old situation as I > understood it: > > "you must create an alias for every user even if the alias and the user > are named the same" > > to > > "you'll never get mail at the deliver-to for any alias which is named > the same as a userid in dbmail_users" > > The latter will cause my customers some dramatic problems - I don't even > see any work around I can do right now for them, if they need to receive > mail for a user account which is the addressee AND share that mail also > with a few others. > > It does of course make a lot of sense not to force us to carry an alias > named the same for every userid when the userid is already an email > address.... > > - April > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > -- End Original Message -- -- Jesse Norell jesse @ kci.net
