[Date Prev][Date Next]
Re: Using LDAP for mail distribution
> I'd be happy to look at it. I'm involved in replacing mail500's use on
> the UMich campus. I don't expect that any sort of sendmail mailer will
> be acceptible here, as it's just terribly inefficient.
Now that you mention it, my original plan was to do this inside sendmail.
Not with multiple maps or something, since it would be terribly inefficient.
I was rather thinking of copying the UDB organization and build something
new able to support a rich semantic model. How to do this in a way
suffciently general to have a chance to be accepted in sendmail is what
I am exploring now. Not that UDB is not rather specific, but then, we
are not UCB ;-)
So instead of messing with sendmail with no clear direction, I decided to
hack mail500 instead, since it is something small and easier to understand.
But folding back the functionality into sendmail is an idea I have not
completely abandoned. I might do it if this experiment results in a
powerful basis for defining very different models and can be done cleanly.
Because the sendmail->mail500->sendmail process is undesirable and I am
not sure it behaves properly in the presence of transient errors.
> I am, however, interested in your config file concepts. What was the
> functionality that you were aiming for?
Everything supported now, plus the Stanford model, plus the mailRecipient
and mailGroup classes from Netscape. Plus anything else. The full monty.
See that first of all, there is a strong schism between models. For some,
"mail" is a final attribute, everything finally resolves to that. For
others, "mail" is a search criterion and the final recipient is derived
from data in the entries, such as the uid.
For that reason, I start by declaring attribute types as devoid of meaning
and the engine has no knowledge of attribute types except as defined in
the configuration file. The engine only understands semantic abstractions.
But initially, my goal is not to break anything and using mail500 to hold
mailing list definitions for 50-odd different domains. In my usage, the
recipient address (with its FQDN, another schism) is used to search the
directory. Entries that resolve to local mailboxes are resolved to the uid
attribute. Mail groups have members either as RFC822 addresses and as
DN-valued attributes. Some recipients, though defined in the directory,
have no local mailboxes and their mail is forwarded to some other address.
In the mail group area, there are also three different approaches in common
use. One is listing members in the group entry. Other is members adding
the groups in their own entries. The third is the dynamic group concept
that Netscape is (was?) trying to patent. BTW, I fail to see how something
that is a simple side effect of a combination of options in what I am doing
can be patented. To prevent infringing the patent, a check would have to
be put in place to forbid some options from being used together...
Tell me what you would like to have and I will try to include it.