Using LDAP for mail distribution

[Julio Sánchez Fernández <j_sanchez@stl.es>]

Besides a number of things I have been doing in the OpenLDAP core code,
I have also been rewriting mail500.  I simply did not like it since it
implemented a model that not I don't like.  For months I have used my
own hacked up version, but I needed to extend it and I decided to do
the right thing.

What I am doing is completely managed through a configuration file and
there is no predefined semantics for any attribute type.  Search bases
are expressed as LDAP URLs and the filter in each can be arbitrarily
complicated: no hardwired limits.  BTW, I am going to have to look for
all buffer overruns in this and all unchecked memory allocations, it
needs some work here badly.

Routine isgroup is generalized w.r.t. objectclasses, you define what
objectclasses are mailgroups.

The basic algorithm is supported by an attribute semantics table.  For
each attribute, we keep three data items.

The first data item is the multiplicity.  If it is single-valued, it
is an error to have more than one.  If it is multi-valued, each value
will be taken into account in turn.

The second data item is the resolution effect.  It can be 'none', implying
that a value does not represent a recipient, but rather data that should
be remembered for later use, 'add' that makes the entry considered resolved
but permits later values from this attribute or other attributes add new
resolutions and 'resolve' that makes the entry resolved without further
processing.

The third data item is the semantics 'kind' or class.  An attribute may
represent a local native mailbox, an RFC822 address, the DN of an entry
that should be fetched and processed, an LDAP URL pointing to something
else, an authorized sender, a sender address to put on mail group messages,
etc.  The idea is that the list of semantics can be extended later.

Attributes are considered in the order defined by the admin.  This means
that most attribute types that do not represent recipients should be
defined first and that an attribute type that fully resolves an entry
should probably be defined before other 'add'-type attributes if they
are supposed to prevent them to be processed, etc.

My goal is to be able to have the behaviour I want with some configuration
file, while not losing the current functionality with an appropriate
different configuration file.  The latter part I cannot test and I need
help here.

Any takers?

Julio