Eliminating the choice of credential types from the logic required by the modules simplifies the support code required by those modules. In fact, it should also simplify the code required by the invoking code, since the invoker will necessarily have different handling for reading and parsing different credential types from a client. Servers that only handle one type of credentials do not have to deal with this detail.
There is no one list of facts that must be reported by an authenticator. This list that is reported may be extended to include more optional facts.
Simplifying identifier names into a single byte greatly simplifies parsing code, without making the output code any more complex, and without significantly reducing the range of facts that can be expressed. It also helps to avoid enlarging the datagram size, which is important due to the strict limits on total size (see below).
What was accomplished by chaining with Courier's authentication modules can be better accomplished through other means. If multiple types of authentication for the same credentials can occur, run seperate services on seperate IPs that use different CVM modules. If multiple types of credentials are used, they will each invoke a seperate CVM module. This eliminates all of the coding and design headaches associated with chaining Courier IMAP authentication modules.
With the checkpassword interface, the authentication module drops root priviledges before executing the second stage program. This however greatly reduces or eliminates the feasability of executing the unpriviledged second stage program in a chroot environment for additional security.
Limiting the total input and output and output size to reasonable values eliminates one class of denial of service attacks by limiting the amount of memory required for buffers and parsing on both the part of the module and the invoker.
A single UDP frame is limited to 512 bytes without introducing serious transmission reliability problems. The UDP response also contains a single byte indicating success/failure that the executable-mode programs transmit out-of-band through the program's exit code.
Long-running server modules provide a method for transitioning permissions boundaries (such as requiring EUID 0 to read /etc/shadow) without having to resort to setuid execution, as well as opportunities for caching of credential information that may otherwise take significant amounts of time to fetch.
Through the standard UNIX permission model, system administrators can restrict access to UNIX domain servers. Administrators of clusters can use UDP modules to provide centralized authentication services.