The implementation for XOAuth2 does not seem to respect the following part of the RFC 4954:
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]).
If I understand it correctly, the maximum length of the token that can be sent the way it is now (with AUTH XOAUTH2 <token> command) is 512 bytes (SMTP line length limit) - 2 bytes (CRLF) - 13 bytes (length of the literal AUTH XOAUTH2) = 497. That applies to the base64-encoded version of the token.
For longer tokens, the multiline variant should be used instead, sending AUTH XOAUTH2, waiting for 334 response from the server and then submitting the whole OAuth2 (JWT) token on the next line.
The implementation for XOAuth2 does not seem to respect the following part of the RFC 4954:
If I understand it correctly, the maximum length of the token that can be sent the way it is now (with
AUTH XOAUTH2 <token>command) is 512 bytes (SMTP line length limit) - 2 bytes (CRLF) - 13 bytes (length of the literalAUTH XOAUTH2) = 497. That applies to the base64-encoded version of the token.For longer tokens, the multiline variant should be used instead, sending
AUTH XOAUTH2, waiting for 334 response from the server and then submitting the whole OAuth2 (JWT) token on the next line.The problematic code is here: https://github.com/pear/Net_SMTP/blob/bbd29e59eaba98fc08ded7d1a76599564490c1b5/Net/SMTP.php#L1010
I also created issue in the Roundcube project (https://github.com/roundcube/roundcubemail/issues/8623) to bring more awareness to the issue, as the implementation here was done by a Roundcube team member.
Also, if I did not understand the issue or the RFC right, I'll be happy for a correction. Otherwise I will start working on a PR.
Thank you!