all humans associated with Mycorp in any way are in ou=people,dc=mycorp,dc=com

no non-humans (eg machine accounts) will ever be put in ou=people

the custom OID registered through IANA for our organization is 12345. The private enterprise OID space begins at 9.9.9.9.9 and we have reserved our own OID tree to start LDAP at OID numeral 2, so the LDAP tree begins at 9.9.9.9.9.12345.2. Please see mycorp-oid-tree.txt for the subnumbers for our custom object classes and attribute types. Addendum: openldap/schema/mycorp.schema

all custom attributes for people not in traditional LDAP schema, used for in-house applications, etc, will be listed in the mycorpPerson objectClass, which each employee must have. The namespace for attributes of this type is denoted with the prefix "mycorp", and all attributes in this objectClass, have said prefix.

The mycorpStatus attribute describes the status of the person's current relationship with Mycorp:

• every ACTIVE Mycorp employee will have objectclass=mycorpPerson and attribute mycorpStatus=active
• every PAST Mycorp employee will have objectclass=mycorpPerson and attribute mycorpStatus=gone (in addition to the usual userPassword disablement)
• every PENDING TERMINATION will have objectclass=mycorpPerson and attribute mycorpStatus=disabled (in addition to the usual userPassword disablement, which disables LDAP authentication, and thus login when LDAP is the authentication backend)

This is a required attribute for objectClass mycorpPerson.

the mycorpType attribute depicts the type of relationship the person has with Mycorp, and has exactly one of the following values:

• contractor
• employee
• partner
• hourly
• investor
• customer

these values can in turn be used for access control, mail routing or delivery decisions, etc.

This is a required attribute for objectClass mycorpPerson.

no users will ever be removed from the DIT. They will merely have their attribute mycorpStatus=disabled or mycorpStatus=gone.

all persons will have the following objectClasses: person, organizationalPerson, inetOrgPerson, mycorpPerson, including all required attributes of those object types.

These are just arbitrary objectClass=groupOfUniqueNames, and are containers for other DNs. They have no other purpose but to be groups of objects from other organizationalUnits.

it is intended that the dn subtype "owner" attribute is the authoritative uniqueMember editor for any ou=groups groupOfUniqueNames, and that any such group have said subtype as an attribute

• XXX TODO can "owner" be a groupOfUniqueNames?

Groups can be used for access control, as well as for things like static mailing lists.

Mail routing is accomplished through an implementation of draft-lachman-laser from IETF. My reference draft was from May of 2002. However, my implementation differs in several important ways:

• There is no use of mailHost, which is largely useless in our environment, and in the presence of a robust interpretation of mailRoutingAddress. By this I refer to the second important difference:
• A multi-valued mailRoutingAddress, to allow for multiple recipients to be specified for a given mailLocalAddress. This allows us to have many:1, 1:many, and many:many address expansions, which I think is a more flexible mechanism. Previous to doing this, I had to use procmail recipes to implement mail CCs, and LDAP could only be used for mail forwardinging to a single recipient.

Because the deviation from the LASER draft schema definition for mailRoutingAddress, I have used a new objectClass prefixed with the Mycorp OID, called mycorpMailRecipient, and having multival attributes mycorpMailRoutingAddress and mycorpMailLocalAddress instead of the inetLocalMailRecipient with mailRoutingAddress and mailLocalAddress.

Any object in the mycorpMailRecipient class is an end-recipient for emails, at each of the addresses listed in the mycorpMailLocalAddress multi-value. The "mail" single-value attribute should correspond to the preferred (primary) mycorpMailLocalAddress for the object, and is mandatory for objectclass=person objects that are mycorpMailRecipients.

Any object not having the mycorpMailRecipient class, can never receive mail.

for each mycorpMailRecipient, at any mycorpMailLocalAddress, mail is routed to the mycorpMailRoutingAddress(es) via envelope rewriting, and resent. Note that after envelope rewriting, the result could be something that ends up being local, so this attribute could specify either a local or remote destination.

STATIC GROUPS: if mail to a mycorpMailLocalAddress corresponds to an inetLocalMailRecipient that is a groupOfUniqueNames, then each uniqueMember from the group is recursed by the address canonicalizer to other objects in the DIT (usually people). In this way a political group can be mail-enabled by simply setting the inetLocalMailRecipient on the object. This also allows groups already used for ACLs (for example, "those with write access to CVS") to have a corresponding mail group, without duplication of the group membership information in another area of the DIT or another database.

All mail routing occurs via realtime LDAP lookups. However, the MTA reserves the right to cache lookup data for a while (we're talking about LDAP here after all, not a bank transaction system) At the time of this writing I'm using least-change principle and doing no caching, but using the lookup cache options of the MTA is certainly something I will enable soon.