Dovecot Core

The submission-login process implements the Dovecot submission protocol (typically on port 587). It acts as a proxy/client that manages SMTP connections to a backend.

Key behaviors:

• Capabilities: It supports standard SMTP capabilities including SIZE, ENHANCEDSTATUSCODES, AUTH, and XCLIENT. It also supports STARTTLS if TLS is enabled on the client connection.
• XCLIENT Support: It handles XCLIENT commands to extract proxy information such as source/destination IP, ports, and TTL. It specifically supports a FORWARD parameter which is decoded from Base64.
• Security: It enforces a limit on bad commands (CLIENT_MAX_BAD_COMMANDS = 10) before disconnecting the client. It also manages TLS initialization via STARTTLS.
• Backend Capabilities: The backend capabilities can be configured via submission_backend_capabilities. If not explicitly set, it defaults to 8BITMIME (and SMTPUTF8 if mail_utf8_extensions is enabled). If BINARYMIME is enabled, CHUNKING is automatically enabled.

The submission_proxy_state enum tracks the current stage of the Submission protocol proxy lifecycle. It defines the sequence of states a client transitions through when proxying submission connections, starting from the initial banner through EHLO, TLS negotiation, XCLIENT handling, and finally authentication.

Available states:

• SUBMISSION_PROXY_BANNER: Initial connection banner.
• SUBMISSION_PROXY_EHLO: Handling the EHLO command.
• SUBMISSION_PROXY_STARTTLS: Handling STARTTLS negotiation.
• SUBMISSION_PROXY_TLS_EHLO: Handling EHLO after TLS is established.
• SUBMISSION_PROXY_XCLIENT: Handling XCLIENT commands.
• SUBMISSION_PROXY_XCLIENT_EHLO: Handling EHLO after XCLIENT.
• SUBMISSION_PROXY_AUTHENTICATE: Handling the authentication phase.

enum submission_proxy_state {
	SUBMISSION_PROXY_BANNER = 0,
	SUBMISSION_PROXY_EHLO,
	SUBMISSION_PROXY_STARTTLS,
	SUBMISSION_PROXY_TLS_EHLO,
	SUBMISSION_PROXY_XCLIENT,
	SUBMISSION_PROXY_XCLIENT_EHLO,
	SUBMISSION_PROXY_AUTHENTICATE,

SUBMISSION_PROXY_STATE_COUNT
};

The config process in Dovecot is managed by the master_service. It follows a specific lifecycle to ensure configuration is parsed correctly before the master service considers the process healthy.

1. Initialization: The service is initialized via master_service_init with specific flags (e.g., MASTER_SERVICE_FLAG_DONT_SEND_STATS).
2. Security & Environment: Access is restricted using restrict_access_by_env and coredumps are managed via restrict_access_allow_coredumps.
3. Configuration Loading: Modules are loaded via config_parse_load_modules and settings are configured using settings_set_config_binary.
4. Service Readiness: Crucially, master_service_init_finish is called only after the configuration file has been successfully parsed. This prevents the master service from entering a crash loop by attempting to restart a process that is failing due to invalid configuration.
5. Execution: The process enters its main loop via master_service_run, accepting connections through a callback (e.g., client_connected) that handles connection creation via config_connection_create.
6. Cleanup: Upon exit, connections are destroyed, and modules/parsers are deinitialized in a specific order to prevent unmapping event categories before they are used.