On Fri, Sep 19, 2025 at 06:59:53PM +0200, Frank Reker wrote:
However - gues who does not do that - yes M$. The M$ exchange server does put an arbitrary string to the 334, e.g: 334 GSSAPI supported Of course this violates the RFC. But was there ever a standard that was not broken by MS? I can't remember. However passing this string to gsasl, of course will fail.The best would be to ignore the first messag in case the client must start the handshake, or even better put the IR directly into the AUTH message, but unfortunatly gsasl doesn't support a way to find out, wether the mech is client first or server first. At least I havn't found any.
Thanks for the bug report and suggested patch.I've pushed a quick commit to branch `kevin/stable-gsasl-smtp-ir-hack`. I chose this way in order to use the existing mutt base64 code, to only employ the hack on the initial response, and to not pre-trim more whitespace before the base64 (since smtp_get_auth_response already skips over the one whitespace allowed).
I haven't had a chance to test it thoroughly, but if it works for the bug you are seeing and passes more testing, I'll include it in the next stable release. (Which is way overdue...)
Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
