Suppose that you are running a sendmail server which is the final delivery server and that the users of the mail system are not physical users on the server (ie. they do not exist in /etc/passwd). What choices do you have in order to accept valid local email?
- Use LDAP.
- Edit mbdb.c and add a map. You can add your custom map and the relevant hooks to support the external directory of your choice. Read the source on how to do that.
- Edit mbdb.c and wrap getpwnam(3). Similar to the above but it may seem easier in some cases, especially if the users are kept in /etc/passwd like file. The first time I saw such a trick was when I was reading TACACS+ code.
- Use MAILER(`local’) without the w flag, which means that /etc/passwd is not consulted prior to forking the mail delivery agent. This is accomplished by:
MODIFY_MAILER_FLAGS(`LOCAL’, `-w’)dnl
That way the local mailer and not sendmail decides whether the user exists or not. You have to write your own delivery agent.
Of the above choices I rely heavily on #3 (although I am not using flat files) and lately I used #4. LDAP is always my last choice. I am sure there are other choices though.
(part 2)
Managing organized complexity 
why is LDAP your last choice? I mean, in part 2 you mention the possibility of using a database to store emails, what’s wrong with using a database, like LDAP, to store usernames? Isn’t the flexibility worthwhile sometimes?
I would never call resorting to a hierarchical database as a flexible choice. I would call it a “riding the wave” choice, since in CS we observe a 20-year cycle of collective amnesia. Hierarchical databases are dead. Resurrecting them like gholas every now and then does not make them better.
I understand that network oriented people and most system administrators do not need to invest in database theory, but those who have been taught databases (for example by this guy) have no excuse.
Sure, LDAP is not a flexible database model but using any database with a standard and popular API provides, in general, flexibility due to reusability. If you have invested in database theory and want the extra flexibility that a relational db provides you could just use a relational database as the backend of an LDAP frontend server (OpenLDAP supports this). In any case I agree that the good LDAP support in Sendmail maybe a ‘riding the wave’ choice but it is also a fact. Why ignore it?
Two questions and an observation:
– Why do I need yet another software layer?
– Given the fact that my data is already modeled and accessible why do I need to design, implement and maintain yet another schema over it? For one data set I need a single schema, not two (and especially not of different styles) because synchronization issues will arise.
– Using a relational database as the storage manager for an LDAP server (which means having a relational schema that depicts the LDAP schema’s tree structure) is something totally different from having data, already modeled on a relational schema (read: an MIS already exists and works) and then wanting to make it accessible via LDAP.
So there, the fact that LDAP support in sendmail is of excellent quality is irrelevant. Because deploying LDAP means increasing complexity in an already complex environment where you already have the tools to perform the same tasks.