Примечание: это вольный перевод, все ошибки на ваш страх и риск

Dovecot делится на несколько процессов, где каждый процесс делает только одну вещь. Это так потому что это делает код более понятным, а также это позволяет настроить различные привилегии для каждого процесса. Наиболее важные процессы это:
1. Мастер процесс (dovecot)
2. Лог процесс (log)
3. Конфиг процесс (config)
4. Аутентификационный процесс (auth)
5. Логин процессы (imap-login, pop3-login)
6. Майл процессы (imap, pop3, lmtp)

Этот процесс запускает дочерние процессы и держит их в работе. Если дочерний процесс погибает, другой запускается вместо него автоматически, если это необходимо. Мастер процесс запускается от root,  так что его функциональность стараются держать минимальной. Мастер процесс это единственный процесс, который открывает все  inet, unix socket и fifo листенеры (listener(ы)).

Каждый сервис имеет канал, через который отправляются обновления статуса мастер процессу, о том сколько клиентских соединений сервис еще сможет принять.

Логин процессы являются специальными: когда мастер процесс узнает что все логин процессы заполнены, он уведомляет их об этом. Логин процессы затем начинают закрывать старые соединения чтобы освободить пространство для других клиентских соединений. Это предотвращает DOS атаки на логин сервисы.

Большая часть логирования делается через лог процесс. Только мастер процесс и процессы которые запускаются отдельно (например dovecot-lda) обходят лог процесс.

Лог процесс имеет несколько преимуществ перед прямым логированием:
- лог процесс может замедлять сервис, который логирует очень быстро.
- весь stderr вывод логируемый процессами захватывается лог процессом, поэтому любые ошибки выводимые библиотеками не теряются. Эти ошибки также всегда имеют лог-префикс показывающий какой сервис вызвал ошибку.
- избегается дублирование лог строк об авариях.

Конфиг процесс считывает конфигурационные файлы и выдает конфигурацию в простом формате другим процессам через UNIX сокет.

Мастер процесс читает свою конфигурацию другим способом: он вначале выполняет doveconf, чтобы считать конфигурацию, чтобы потом выполнить ее своим бинарником.

Отдельные средства такие как: dovecot-lda и doveadm вначале считывают конфигурацию через UNIX сокет, но если им отказано, они запускают doveconf.

Процесс аутентификации обрабатывает все что относится к аутентификации: механизмы аутентификации SASL, поиск и верификация паролей и поиск пользовательской информации. Существует только один мастер процесс аутентификации, который принимает все входящие соединения. Также существуют рабочие процессы аутентификации

Это означает что мастер процессу аутентификации нужно быть очень эффективным в том что он делает и он не должен надолго блокироваться, иначе это приведет к зависанию всех аутентификаций.

Чтобы обработать потенциально долго-работающие операции существуют рабочие процессы аутентификации. Они часто используются для passdb и userdb поисков.

Рабочие процессы аутентификации могут также использоваться для верификации парольных хэшей, что может быть необходимо если используются сильные алгоритмы хэширования.

Логин процессы требуют задействовать IMAP, POP3, ManageSieve или Submission протоколы, перед тем как пользователь успешно залогинится.

Каждый протокол обрабатывается отдельным процессом (и бинарником). Эти процессы запускаются с минимально возможными привилегиями.

К сожалению модель безопасности UNIX по умолчанию все еще позволяет им делать больше чем они должны.

Тем не менее, логин процесс по умолчанию запускается по учетке пользователя которая не имеет специального доступа к чему-либо, и запускается внутри без_права_на_запись chroot где существует только пара UNIX сокетов.

Повредить внутри сервера будет трудно. Конечно возможно все еще создать соединения на другие сервисы которые обычно недоступны с внешних IP адресов.

Когда новое соединение приходит, один из логин процессов принимает его. После этого клиент обычно ничего больше не делает, кроме того как выполняет запрос списка возможностей сервера и затем подключения.

Аутентификация производится путем переговоров в аутентификационном процессе. Логин процесс не является доверенным процессом для процесса аутентификации, поэтому даже если атакующий будет иметь возможность выполнить произвольный код внутри логин процесса, то не будет возможности подключиться без валидного имени_пользователя и пароля.

После получения ответа об успешной аутентификации от процесса аутентификации, логин процесс подключается к майл процессу через UNIX сокет и отправляет файловый дескриптор.

Майл процесс проверяет, узнавая у процесса аутентификации, что аутентификация действительно была успешной.

По умолчанию каждый логин процесс обрабатывает только одно соединение и впоследствии самоуничтожается (но смотри SSL проксирование ниже). При таком способе атакующий не может увидеть другие людские соединения. Это может однако быть отключено, в этом случае модель безопасности значительно пострадает.

Логин процессы полностью обрабатывают SSL/TLS соединения. Они продолжают проксировать соединение к майл процессам в течении полного времени_жизни соединения. При таком способе, даже если будет найдена дыра в безопасности в SSL библиотеке, то аутентифицированный пользователь все еще не сможет выполнить код вне логин процесса.

Эти процессы производят актуальную после-подключения (после того как пользователь залогинился) обработку используя привилегии подключенного пользователя.

Существуют также другие различные широко используемые процессы:
anvil: следить за тем какие почтовые процессы каких обрабатывают пользователей
dict: прокси процесс для dict поисков
dns-client: асинхронные DNS поиски
imap-hibernate: простаивающие imap соединения могут быть перемещены в гибернационные процессы
indexer и indexer-worker: для полнотекстовой индексации
ipc: для подключения к логин процессам
stats: отслеживание статистики