I stand 100% corrected. That is a much better way. I was errored in my testing.
Of course now I'm going to ask, what happens if you set up a circular alias (yes I know you should get what you deserve, but)? I've had a user do this to me before, it wasn't pleasant. [EMAIL PROTECTED] -> [EMAIL PROTECTED] [EMAIL PROTECTED] -> [EMAIL PROTECTED] I guess I'll give it a shot and find out. :) Thanks and sorry for the mis-information. -- David A. Niblett | email: [EMAIL PROTECTED] Network Administrator | Phone: (352) 334-3400 Gainesville Regional Utilities | Web: http://www.gru.net/ -----Original Message----- From: Paul J Stevens [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 15, 2005 3:16 AM To: DBMail mailinglist Subject: Re: [Dbmail] send mail to alias -> Real Account -> forward 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 _______________________________________________ Dbmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
