David, Would you be so kind to test the dbmail_2_0 branch in svn. I've added loop detection in auth_check_user_ext. Or rather, reinstated the loop detection there but unused.
Niblett, David A wrote: > Ok, I just confirmed that the below situation is really, > really bad. > > Technically I'm not sure this is a bug since it's doing > exactly what it's supposed to do, but it could cause some > serious grief. > > Seems like there should be some loop protection in the routine. > > -- > David A. Niblett | email: [EMAIL PROTECTED] > Network Administrator | Phone: (352) 334-3400 > Gainesville Regional Utilities | Web: http://www.gru.net/ > > > > -----Original Message----- > From: Niblett, David A [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 15, 2005 8:24 AM > To: 'DBMail mailinglist' > Subject: RE: [Dbmail] send mail to alias -> Real Account -> forward > > > 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
