Niblett, David A wrote: > In my tests what happens now is that your inbound Email, hits > dbmail, the alias look up says that it has to invoke SMTP to > send the message, so it's back to your SMTP server, which then > turns around and sends it back to DBMail with the new address, > which then, once again, invokes the SMTP to send the message to > the forward location.
David, this is not correct! dsnuser_resolve and auth_check_user_ext together will resolve the deliver_to field recursively. So if the deliver_to contains a numeric user_idnr the message will be delivered straight to the database; if deliver_to is an address, dbmail will lookup the deliver_to address to see if it's a valid alias for a user, and if so, deliver to that user. The external delivery route (smtp) is only selected if an address is *not* an alias for a known user. Any other behaviour would entail a bug. > If the user_idnr is used in the deliver_to then the message is > immediately stored in the database making it much more efficient. > > The only problem I have with the dbmail_aliases table is that > there is no DB reference to a user_idnr. I added a column (called > user_idnr) in dbmail_aliases, which is a foreign key reference > to dbmail_users(user_idnr), and support cascade on delete. There are good reasons for not supporting restraints on the aliases table, just like /etc/aliases is not restricted by the entries in /etc/passwd. Consider system pipes like entries for mailman, etc... Those are system aliases, and are not connected to any user. For the very same reason I've setup dbmail's ldap support to support both email attributes and forwarding attributes on user objects (DbmailUser), as well as support separate forwarding-only objects (DbmailForwardingAddress). -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
