@manfred That’s not quite the question…
As I read the code (if I’m reading it correctly on the combined backend) it checks all the Logon functions, and does so in the order they are declared. So once you get past “IMAP”, for example, we know the login is good (that is, the password was verified.) The combined backend only considers a sign-on good if all of the back ends return valid for the Logon function.
The reason this is important in the instant case is that in order to check a password you must run with privileges somewhere. Dovecot does, of course, and I could call IMAP’s authentication checking routine, which the implements whatever system policy underlies it (e.g. PAM, LDAP, etc.) Caldav/Carddav do this, but the Caldav/Carddav server have other reasons to do so (since they’re potentially called directly by user agents on a listening port, as is IMAP.)
But if I know the login is good then I don’t need to do that; that is, I can stash the login id passed as a local to the back end without verifying it and just return true, because someone else (at least one, and perhaps three!) already has. This means I don’t need to write a daemon that runs with privileges since I can safely assume that the username field is valid and has been authenticated; I can thus ignore the password passed entirely and use php’s Postgres library directly rather than defining an IPC protocol of some sort to talk to a note back end that runs with privileges and queries the system’s password store. Since there’s no “notes” extension to Davical that I’m aware of, and thus “Notes” would only be accessed through Exchange, there appears to be no shortcoming to doing it this way, nor any particular security implication either (since the db admin can always get to the calendar tables, for example, directly.)
Unless I’m parsing the code incorrectly this appears to be safe and, in addition, lighter-weight since it’s both one less daemon to run and one less pass through the authentication process.