Op 14-11-2023 om 17:44 schreef Kees van Vloten:

I did another test: I have just downgraded the dovecot packages to the version in Bullseye, i.e. 2.3.19 -> 2.3.13, without making any other change.

This solved the issue! Thunderbird (which was not even restarted) can now send mails again.

Unfortunately it is not such a good solution as I would rather have more recent packages :-)

@aki, do you still think the culprit is in the client?

I'd say the client is the culprit. From what I can tell it is sending: AUTH GSSAPI <Enormous initial response>

This is not allowed. The initial response can only be used when the AUTH command stays small enough to fit in a regular SMTP command line. If it is bigger the client should do the following:

client> AUTH GSSAPI

server> 334

client> <Enormous initial response>

etc..

Further explained in RFC 4954, Section 4:

       The optional initial response argument to the AUTH command is
       used to save a round-trip when using authentication mechanisms
       that support an initial client response.  If the initial
       response argument is omitted and the chosen mechanism requires
       an initial client response, the server MUST proceed as defined
       in Section 5.1 of [SASL  <https://datatracker.ietf.org/doc/html/rfc4954#ref-SASL>].  In SMTP, a server challenge that
       contains no data is defined as a 334 reply with no text part.
       Note that there is still a space following the reply code, so
       the complete response line is "334 ".

       Note that the AUTH command is still subject to the line length
       limitations defined in [SMTP  <https://datatracker.ietf.org/doc/html/rfc4954#ref-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 (and
       instead proceed as defined in Section 5.1 of [SASL  <https://datatracker.ietf.org/doc/html/rfc4954#ref-SASL>]).

Regards,

Stephan.

Op 14-11-2023 om 17:44 schreef Kees van Vloten:

 I did another test: I have just downgraded the dovecot packages to
 the version in Bullseye, i.e. 2.3.19 -> 2.3.13, without making any
 other change.

 This solved the issue! Thunderbird (which was not even restarted) can
 now send mails again.

 Unfortunately it is not such a good solution as I would rather have
 more recent packages :-)

 @aki, do you still think the culprit is in the client?

I'd say the client is the culprit. From what I can tell it is sending: AUTH GSSAPI <Enormous initial response> This is not allowed. The initial response can only be used when the AUTH command stays small enough to fit in a regular SMTP command line. If it is bigger the client should do the following:

client> AUTH GSSAPI server> 334 client> <Enormous initial response> etc..

Further explained in RFC 4954, Section 4: The optional initial response argument to the AUTH command is used to save a round-trip when using authentication mechanisms that support an initial client response. If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in Section 5.1 of [SASL]. In SMTP, a server challenge that contains no data is defined as a 334 reply with no text part. Note that there is still a space following the reply code, so the complete response line is "334 ".

      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 (and
      instead proceed as defined in Section 5.1 of [SASL]).

Regards, Stephan.