Sander Holthaus - Orange XL writes:
Yes. I and a few others asked this question before. I bookmarked the address for the patch, http://home.earthlink.net/~x1pfister/courier/, but it doesn't seem to exist anymore.
Sam, couldn't something like this be implemented in Courier? Though it will cause some extra overhead, it shouldn't be too much and if people can define how recursive it is allowed to be (e.g. LDAP_RECURSION_DEPTH = 0 for disallowing recursion, 1 for allowing one recursive call, etc).
The problem is that resolving recursive aliases introduces a lot of additional complexities into the alias resolution process. As a persistent daemon process, courierldapaliasd is very long lived. Long-living daemons, like courierldapaliasd, should avoid using dynamic memory allocations as much as possible. courierldapaliasd uses none, except for whatever happens in the standard C library, and OpenLDAP, which I can't do anything about.
There are a number of technical reasons for that.
Plus, I have to question whether it is proper to have recursive LDAP aliases in the first place. That means that, for example, an alias that expands out to a hundred addresses will cause a hundred additional round-trip LDAP lookups. Every time. This does not sound like a right design to me.
It makes more sense to me to have all the recursive alias resolutions done once, and save the expanded alias list in the LDAP directory.
This is exactly how Courier's native mail aliases work. With native aliases, I don't look up every address every time. The makealiases script reads the alias file, expands all aliases recursively, and builds a GDBM/DB database where the aliases are already expanded. This eliminates a lot of waste from the code that receives new messages. Only a single lookup is required for an E-mail address.
An LDAP-based setup should be structured in the same way.
pgp1CzK4OUX3b.pgp
Description: PGP signature
