The following bug has been CLOSED
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000159
======================================================================
Reported By: OutboundIndex
Assigned To: paul
======================================================================
Project: DBMail
Bug ID: 159
Category: general delivery
Reproducibility: always
Severity: major
Priority: normal
Status: closed
======================================================================
Date Submitted: 13-Jan-05 21:11 CET
Last Modified: 20-Mar-05 15:25 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
======================================================================
----------------------------------------------------------------------
aaron - 14-Jan-05 01:59 CET
----------------------------------------------------------------------
Oh my, I didn't consider that side of the situation. In DBMail 1.x, the
alias must always exist, even if the username is a full email address. A
number of people running such sites complained, and indeed it does seem
silly. So I made delivery check the users table first -- and not the
aliases table at all if it sees something.
The change that we'd need is to check the aliases table, too, and abide by
it if the delivery address is a forward.
I'll repost this on the mailing list, too -- but are there any semantics
that would be ruined if we changed from:
if (address is username)
put username on delivery list
else
if (address has aliases)
resolve aliases into deliveries and forwards
To:
if (address has aliases)
resolve aliases into deliveries and forwards
else
if (address is username)
put username on delivery list
----------------------------------------------------------------------
aaron - 16-Jan-05 21:06 CET
----------------------------------------------------------------------
This patch changes the behavior to:
if (address has aliases)
resolve aliases
else if (address is username)
deliver to username
else if (address matches domain catch-all)
deliver to domain-user
else
error and bounce
----------------------------------------------------------------------
aaron - 20-Jan-05 13:18 CET
----------------------------------------------------------------------
Patch goes into dbmail_2_0_branch. Needs to go into HEAD, too, huh?
----------------------------------------------------------------------
aaron - 10-Mar-05 03:03 CET
----------------------------------------------------------------------
Paul, could you work this into the trunk please?
----------------------------------------------------------------------
paul - 20-Mar-05 15:25 CET
----------------------------------------------------------------------
patch applied clean to trunk. I'm closing this bug now.
Bug History
Date Modified Username Field Change
======================================================================
13-Jan-05 21:11OutboundIndex New Bug
14-Jan-05 01:59aaron Bugnote Added: 0000533
16-Jan-05 21:06aaron File Added: dsn.patch
16-Jan-05 21:06aaron Bugnote Added: 0000538
20-Jan-05 13:18aaron Bugnote Added: 0000562
10-Mar-05 03:03aaron Bugnote Added: 0000598
20-Mar-05 15:25paul Bugnote Added: 0000624
20-Mar-05 15:25paul Assigned To => paul
20-Mar-05 15:25paul Resolution open => fixed
20-Mar-05 15:25paul Status new => resolved
20-Mar-05 15:25paul Status resolved => closed
======================================================================
