[PATCH 4/5] submission-login: client-authenticate - Reply 421 4.7.0 on mail_max_useri...

Until now the connection limit was reported via the same 454 4.7.0 reply
that is used for generic temporary authentication failures. That makes
proxies (including Dovecot's own submission proxy) treat the rejection as
a transient auth error and retry, which is futile when the limit is hit
and only obscures the actual cause in the proxy log.

Reply with 421 4.7.0 instead. RFC 5321 Section 4.2.1 specifies 421 as
"service shutting down, closing transmission channel", which is the
right signal for "do not retry on this connection". The 421 + 4.7.0
combination is unique among the 421 replies emitted by submission and is
used by the submission proxy to recognize this specifically as a
connection-limit reply rather than a generic 421 internal/shutdown.

Gbp-Pq: Name 0004-submission-login-client-authenticate-Reply-421-4.7.0.patch

diff --git a/src/submission-login/client-authenticate.c b/src/submission-login/client-authenticate.c
index 6c5a0b81c620e28775d1ef20d28f52f3fbc8022e..93cd1d786d89f4fe4d08d21b98a930e00d4accde 100644 (file)
--- a/src/submission-login/client-authenticate.c
+++ b/src/submission-login/client-authenticate.c
@@ -151,6 +151,24 @@ void submission_client_auth_result(struct client *client,
                 */
                smtp_server_reply(cmd, 454, "4.7.0", "%s", text);
                break;
+       case CLIENT_AUTH_RESULT_LIMIT_REACHED:
+               /* The user has too many concurrent connections. Reply with
+                  421 4.7.0: 421 means "service shutting down, closing
+                  transmission channel" (RFC 5321 Section 4.2.1) and
+                  signals the client that retrying on this same connection
+                  is pointless. The proxy uses the 421 + 4.7.0 combination
+                  to recognize this specifically as a connection-limit
+                  response (rather than a generic 421 internal/shutdown
+                  reply) and avoid reconnecting.
+
+                  Use reply_immediate() rather than the queued
+                  smtp_server_reply() because the caller (sasl-server)
+                  immediately tears the connection down after this returns,
+                  which would abort a queued reply before it reaches the
+                  wire. */
+               smtp_server_connection_reply_immediate(subm_client->conn,
+                       421, "4.7.0 %s", text);
+               break;
        case CLIENT_AUTH_RESULT_ABORTED:
                /* RFC4954, Section 4: