Derrick 'dman' Hudson writes:

The standalone maildrop build does.

That's generally how the version of maildrop that's bundled with Courier works; namely because the mail delivery environment is a known item (and there are also a couple of other environment variables which are read for various purposes).

maildrop-standalone cannot really make these kinds of assumptions; it acts as a default, generic mail delivery agent (with getpwnam) and such. If getpwnam fails, the assumption is that the NIS server is down, or something of that sort.

maildrop-standalone does have some hooks for a virtual mail account database, of some sort. There's a primitive module available that reads an LDAP directory; there's also a module that reads a simple GDBM/DB based list of accounts.

A supplied script builds the GDBM/DB database from a plain file, with records arranged in a straightforward format. It is trivial to take whatever virtual mail account provisioning database is used by the mail server, dump it to some convenient format, and reformat it to the format that will be compiled into the GDBM/DB database list.

None of the above relieves the mail server from the responsibility of determining the validity of the recipient address, and to reject mail to nonexistent recipients. That's _STILL_ mail server's job, and nobody else's. The mail delivery agent's job is to deliver mail to a local mail account. Nothing more, nothing less. If the mail delivery agent cannot determine what the local mail account is, the logical conclusion is that it's due to a local system misconfiguration of some sort; hopefully a temporary one. Perhaps the GDBM/DB database hasn't yet been refreshed. It can take a while to refresh a GDBM/DB account database with thousands of records; it would be impractical to do so after every change to the account database in a large ASP environment. Therefore, a reasonable setup is to have regularly-scheduled GDBM/DB database refreshes. If mail arrives to a new account and the GDBM/DB account database wasn't refreshed yet, EX_TEMPFAIL will quietly defer the mail in the mail server's queue until the database is refreshed, and the mail server attempts to redeliver it later.

This should not even be an issue with the LDAP lookup hook. Presumable the LDAP hook will point to the real mail server account database, so everyone will always be in sync with each other.