Re: [exim/exim] [Bug]: smtp transport outbuffer[4096] too small for XOAUTH2 AUTH commands, causes fatal "overlong write_command" (Issue #3208)

Thank you for looking at this.

Authenticator choice

We are not using authresults for the XOAUTH2 payload. Our client authenticator is the plaintext driver with public_name = XOAUTH2, and client_send / client_condition are expanded (here via Perl helpers) to produce the raw SASL XOAUTH2 string expected after AUTH XOAUTH2. That pattern is a common way to implement SASL mechanisms for which Exim does not ship a dedicated client driver, as described in the manual for the plaintext authenticator:
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_plaintext_authenticator.html

So the failure is not from misusing a header-related expansion; it is from the length of a single outgoing SMTP line once Exim has built the AUTH command (including continuation lines after 334), which still goes through smtp_write_command() and the fixed client output buffer.

Why this hits real deployments

Microsoft-issued access tokens (Azure AD / Office 365) are often large JWTs. After the usual SASL XOAUTH2 encoding, the base64 material on one AUTH line (or one continuation response) can exceed the current 4096-byte limit in the outgoing SMTP path (smtp_context’s outbuffer / DELIVER_BUFFER_SIZE), which triggers log_write_die("overlong write_command in outgoing SMTP") in smtp_write_command().

Increasing only the incoming SMTP command buffer does not fix this: SASL continuation responses are still emitted via the same outgoing write path and the same size check.

Reproducer (no reliance on exotic expansion syntax)

Any configuration where the expanded client_send yields an XOAUTH2 SASL string whose single SMTP transmission (initial AUTH … line or a single continuation line after 334) is longer than the outgoing buffer reproduces the issue. In practice: configure client_send to supply a realistically long token (e.g. a long Azure-style JWT in the XOAUTH2 user field), then attempt submission to a server that negotiates XOAUTH2 — the client aborts with the message above before the server can respond. A small standalone script that builds the RFC 7628-style string and feeds the same value into client_send (e.g. via ${perl{…}}) is enough to demonstrate it without depending on a particular expansion operator.

Request

We respectfully suggest treating this as a transport/client buffer sizing limitation for long single-line SMTP commands (notably OAuth2-related AUTH), rather than as invalid use of the plaintext authenticator. A modest increase of the outgoing command buffer (or another safe way to stream/chunk very long AUTH lines within protocol rules) would align better with token sizes seen in the wild and with the larger buffer already used for incoming SMTP commands in smtp_in.c.

If anything in the above still does not match how you intend client XOAUTH2 to be configured, we are happy to adjust the example to match documented practice.

---
View it on Exim Forgejo ( https://code.exim.org/exim/exim/issues/3208#issuecomment-239287 ) or reply to this email directly.

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
##   [email protected]
## Exim details at https://www.exim.org/
## Please use the Wiki with this list - https://code.exim.org/exim/wiki/wiki