The porting of dovecot to netAuth consists of
(a) removing code,
(b) moving some code into the imap process and
(c) removing three of the four processes.
A dovecot process ported to
netAuth is not expected to perform the following functions:
message encryption using OpenSSL, GNU-TLS or the like;
performing the complex setuid() operation and
related code to ensure that the process does not have any
privileged left-overs (in the form of file descriptors) in the
Hence, code for these security sensitive operations need
not be implemented by the dovecot executable and can be removed.
Thus, summarizing the dovecot port to netAuth:
Thus, the dovecot port to netAuth runs as a single process type
(following the design for a concurrent server
implementation shown in Figure 4).
The master, auth and login processes are eliminated
after taking a small amount code from them.
- the auth process (and its code) is eliminated
completely as the user authentication is performed by
the OS as part of connection establishment.
- from the master process, only
the code to bind to the privileged port and
to configure a new mail process with the
appropriate set of environment variables is retained.
(Dovecot passes configuration information to the imap process
as environment variables)
- from the login process, only the initialization of a new connection
(1a and 1b in Figure 6) is retained.
- the core functionality of
accessing and maintaining mailboxes in the imap process is retained.
The resulting imap code
performs the following steps:
- initializes a socket to listen for new connections.
It performs a bind on the privileged port, a listen,
sets the accept mode to acceptByUser and
blocks on pre_accept
waiting for a connection from a user for which there is no imap process.
- when a connection from a new user arrives, the process
returns from pre_accept with the new user's information.
The process forks a child process to handle the user
and returns to waiting for a new user.
- the child process changes the user by executing
set_net_user with the user information from
the pre_accept call.
The child process runs as the new user.
This process can now accept the connections (for that user)
and process the MVA's requests.
The user is authenticated as part of the processing
in the network stack to accept a connection
Hence, pre_accept returns only for
Connection requests of users that fail to
successfully authentication are dropped
(with a RST sent back).