On Fri, Oct 01, 2021 at 12:47:29PM -0400, Viktor Dukhovni wrote:
> > -- basics --
> > Postfix: 3.5.6
>
> Since you're using Postfix 3.5, which by default supports long SASL
> messages after the initial response, your client is in violation of the
> SMTP SASL specification, and needs to have a bug filed against its SASL
> GSSAPI implementation. If that client is also Postfix, file that bug
> on this list. If not, reach out on the relevant forum, or bug tracking
> system.
Note that I rather expect the broken client is not Postfix 3.4 or later,
since the Postfix SMTP client code since then reads in part:
https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_sasl_glue.c#L366-L388
/*-
* Send the AUTH command and the optional initial client response.
*
* https://tools.ietf.org/html/rfc4954#page-4
* Note that the AUTH command is still subject to the line length
* limitations defined in [SMTP]. If use of the initial response argument
* would cause the AUTH command to exceed this length, the client MUST NOT
* use the initial response parameter...
*
* https://tools.ietf.org/html/rfc5321#section-4.5.3.1.4
* The maximum total length of a command line including the command word
* and the <CRLF> is 512 octets.
*
* Defer the initial response if the resulting command exceeds the limit.
*/
if (LEN(session->sasl_reply) > 0
&& strlen(mechanism) + LEN(session->sasl_reply) + 8 <= 512) {
smtp_chat_cmd(session, "AUTH %s %s", mechanism,
STR(session->sasl_reply));
VSTRING_RESET(session->sasl_reply); /* no deferred initial reply */
} else {
smtp_chat_cmd(session, "AUTH %s", mechanism);
}
> You can accommodate broken clients by raising line_length_limit even
> on Postfix >= 3.4 systems where this should not otherwise be necessary
> in most cases.
So this is your short-term solution, as well as filing bugs against the
actual broken clients.
--
Viktor.
