The following bug has been SUBMITTED.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000159
======================================================================
Reported By:                OutboundIndex
Assigned To:                
======================================================================
Project:                    DBMail
Bug ID:                     159
Category:                   general delivery
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             13-Jan-05 21:11 CET
Last Modified:              13-Jan-05 21:11 CET
======================================================================
Summary:                    alias bug: if user exists, auth_check_user is 
skipped
Description: 
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
======================================================================

Bug History
Date Modified  Username       Field                    Change              
======================================================================
13-Jan-05 21:11OutboundIndex  New Bug                                      
======================================================================

Reply via email to