The following issue has been REOPENED. ====================================================================== http://www.dbmail.org/mantis/view.php?id=860 ====================================================================== Reported By: Disconnect Assigned To: ====================================================================== Project: DBMail Issue ID: 860 Category: general delivery Reproducibility: have not tried Severity: minor Priority: normal Status: feedback target: ====================================================================== Date Submitted: 22-Sep-10 18:43 CEST Last Modified: 23-Sep-10 20:54 CEST ====================================================================== Summary: Domain wildcard (@foo.com) overrides user wildcard (user@) Description: Looking at issue 105, I should be able to have the following entries: joe -> joe@ jane -> @foo.com with "j...@foo.com" going to Jane, and "j...@foo.com" going to Joe. Instead, the more general @foo.com overrides the j...@.
Non-wildcard (j...@foo.com) overrides the wildcards, as expected. ====================================================================== ---------------------------------------------------------------------- (0003109) Disconnect (reporter) - 22-Sep-10 18:44 http://www.dbmail.org/mantis/view.php?id=860#c3109 ---------------------------------------------------------------------- Doesn't seem like it will let me edit, so updated description: Looking at issue 105, I should be able to have the following entries: joe -> joe@, j...@foo.com jane -> @foo.com "j...@foo.com" should go to Jane, and "j...@foo.com" should go to Joe. Instead, the more general @foo.com overrides the j...@. Non-wildcard (j...@foo.com) overrides all the wildcards, as expected. ---------------------------------------------------------------------- (0003110) paul (administrator) - 23-Sep-10 11:12 http://www.dbmail.org/mantis/view.php?id=860#c3110 ---------------------------------------------------------------------- I strongly disagree here. User wildcards are *not* more specific than domain wildcards. They are meant to be used as a relay of last-resort, and should be used sparingly. Assigning @example.com to a user, means that user should get all email for 'his' domain, no matter what mailbox part was specified. As a user I would be very unhappy to learn that some other user who (accidently) had a mailbox wildcard assigned to his account, started getting email that was destined for my domain! As a email hosting provider such a scenario would be cause for some serious PR headaches. What a nightmare. Finally, changing this kind of policy decision will create backward compatibility issues for current installations. Again nightmares ensue. Unless someone manages to convince me it is indeed necessary to do this, and do it gracefully, this is one change that's not going in. ---------------------------------------------------------------------- (0003111) Disconnect (reporter) - 23-Sep-10 15:37 http://www.dbmail.org/mantis/view.php?id=860#c3111 ---------------------------------------------------------------------- At the least, it should be configurable. It breaks with the established behavior of other MDAs - in postfix for example, the lookup is j...@foo.com, joe@, @foo.com -- http://postfix.eu.org/virtual.5.html Perhaps a new flag: u...@% overrides @domain overrides user@ That would maintain backwards compatibility while still allowing global user aliases and domain fallbacks. (Alternately, turn it around: @domain overrides @user overrides %...@domain, where the % indicates delivery of last resort..) ---------------------------------------------------------------------- (0003112) paul (administrator) - 23-Sep-10 18:35 http://www.dbmail.org/mantis/view.php?id=860#c3112 ---------------------------------------------------------------------- I still don't understand what use-case you are actually pursuing. Reading virtual(5): Virtual alias domains are not to be confused with the virtual mailbox domains that are implemented with the Postfix virtual(8) mail delivery agent. With virtual mailbox domains, each recipient address can have its own mailbox. where the table lookup described in virtual(8) much better describes the current convention in dbmail. ---------------------------------------------------------------------- (0003113) Disconnect (reporter) - 23-Sep-10 19:02 http://www.dbmail.org/mantis/view.php?id=860#c3113 ---------------------------------------------------------------------- virtual(8) is a different animal entirely, and I disagree about the application to dbmail - virtual(8) maps one address to many destinations and doesn't allow user wildcards at all. dbmail maps one destination to many addresses, as described in virtual(5) except for precedence. virtual(8) search order: - u...@domain.com - @domain.com virtual(5) search order; - u...@domain.com - user@ - @domain.com dbmail: - u...@domain.com - @domain.com - user@ (proposed) - %...@domain.com I'm trying to do a migration from postfix, where we have about 2 dozen domains handled by a dozen or so destinations. Each domain has a wildcard fallback and most of the users are wildcarded to all domains. (There are some overrides, where a u...@domain takes precedence over the user wildcard - eg sa...@domain1 might not be handled by the default sales@ destination) If it just can't be done I'll look for a new solution and get out of your hair, but it seems like a reasonable, common ordering. (Worst case is maintaining the virtual list in postfix, before it hands off to dbmail, but that is going to mean yet another configuration location for domains/users/etc. Ugh.) ---------------------------------------------------------------------- (0003114) paul (administrator) - 23-Sep-10 20:25 http://www.dbmail.org/mantis/view.php?id=860#c3114 ---------------------------------------------------------------------- Why not simply drop the wildcards and use explicit routing? A 'dozen or so destinations' simply doesn't warrant changing one of the most critical codepaths in dbmail's delivery chain. ---------------------------------------------------------------------- (0003115) Disconnect (reporter) - 23-Sep-10 20:35 http://www.dbmail.org/mantis/view.php?id=860#c3115 ---------------------------------------------------------------------- A dozen or so -mailboxes-. Hundreds (thousands, with the domain multiplier) of incoming addresses. (Many of them untracked, since it hasn't been necessary.) ---------------------------------------------------------------------- (0003116) paul (administrator) - 23-Sep-10 20:51 http://www.dbmail.org/mantis/view.php?id=860#c3116 ---------------------------------------------------------------------- please stop re-opening this report! ---------------------------------------------------------------------- (0003117) Disconnect (reporter) - 23-Sep-10 20:54 http://www.dbmail.org/mantis/view.php?id=860#c3117 ---------------------------------------------------------------------- maybe i'm missing it, but there is no other way to respond to your comments when it is closed. in any case, thats fine. go ahead and re-close it, i'll start evaluating other tools - this isn't worth the hassle at this point. Issue History Date Modified Username Field Change ====================================================================== 22-Sep-10 18:43 Disconnect New Issue 22-Sep-10 18:44 Disconnect Note Added: 0003109 23-Sep-10 11:12 paul Note Added: 0003110 23-Sep-10 11:14 paul Status new => closed 23-Sep-10 11:14 paul Resolution open => won't fix 23-Sep-10 11:14 paul Category Database layer => general delivery 23-Sep-10 15:37 Disconnect Note Added: 0003111 23-Sep-10 15:37 Disconnect Status closed => feedback 23-Sep-10 15:37 Disconnect Resolution won't fix => reopened 23-Sep-10 18:35 paul Note Added: 0003112 23-Sep-10 19:02 Disconnect Note Added: 0003113 23-Sep-10 20:25 paul Note Added: 0003114 23-Sep-10 20:25 paul Status feedback => closed 23-Sep-10 20:25 paul Resolution reopened => won't fix 23-Sep-10 20:35 Disconnect Note Added: 0003115 23-Sep-10 20:35 Disconnect Status closed => feedback 23-Sep-10 20:35 Disconnect Resolution won't fix => reopened 23-Sep-10 20:51 paul Note Added: 0003116 23-Sep-10 20:51 paul Status feedback => closed 23-Sep-10 20:51 paul Resolution reopened => won't fix 23-Sep-10 20:52 Disconnect Issue Monitored: Disconnect 23-Sep-10 20:54 Disconnect Note Added: 0003117 23-Sep-10 20:54 Disconnect Status closed => feedback 23-Sep-10 20:54 Disconnect Resolution won't fix => reopened ====================================================================== _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
