Hi Noah,
On Wed, Jul 22, 2026 at 02:50:06PM -0400, Noah Meyerhans wrote:
> Control: tags -1 + moreinfo
>
> On Mon, Jul 20, 2026 at 02:45:14PM -0400, Noah Meyerhans wrote:
> > > After installing version 1:2.4.1+dfsg1-6+deb13u6 on my server,
> > > authentication starts failing like so:
> > >
> > > wouter@pc220518:~$ mbsync -a
> > > IMAP command 'AUTHENTICATE GSSAPI YIIC+AYJKoZ[...BASE64 data
> > > censored...]/z04t1yLI4jO7FJia0=' returned an error:
> > > [AUTHENTICATIONFAILED] Authentication failed.
> >
> > Interesting. When I run gsasl's autopkgtest suite, which includes a
> > gssapi authentication test, against trixie's 1:2.4.1+dfsg1-6+deb13u6
> > packages, it is able to authenticate successfully.
> >
> > > The changelog of that version mentions:
> > >
> > > * [366ef61] CVE-2026-33603: login-common: Only accept base64 in sasl
> > >
> > > Which seems like it might be overly strict?
> >
> > The patch was cherry-picked from upstream and is in sid/forky as well as
> > the current upstream releases. Which is not to say that it can't have
> > introduced a regression, of course...
> >
> > > At any rate, downgrading to 1:2.4.1+dfsg1-6+deb13u5 resolves the issue.
> >
> > I'll continue investigating. I have not tested your configuration, nor
> > have I tested mbsync, so there's more to look at.
>
> I have written an autopkgtest for dovecot to exercise GSSAPI
> authentication. It tests two clients: gsasl and python (imaplib +
> python3-gssapi). Both of these can successfully authenticate against
> the current 1:2.4.1+dfsg1-6+deb13u6 packages in trixie-security as well
> as the packages in sid/forky. You can see a successful execution of
> this test at https://salsa.debian.org/noahm/dovecot/-/jobs/9998007
>
> But I haven't yet gotten mbsync to successfully authenticate against any
> version, including older (pre deb13u6) versions of dovecot:
>
> # dpkg -s dovecot-gssapi | grep Vers
> Version: 1:2.4.1+dfsg1-6+deb13u3
>
> # HOME=/srv/dovecot-dep8/dep8/ mbsync -c mbsyncrc --list-stores
> ===== local:
> INBOX
> IMAP command 'AUTHENTICATE GSSAPI
> YIIC7wYJKoZIhvcSAQICAQBuggLeMIIC2qADAgEFoQMCAQ6iBwMFACAAAACjggH1YYIB8TCCAe2gAwIBBaELGwlLUkI1LlRFU1SiKTAnoAMCAQOhIDAeGwRpbWFwGxZhdXRvcGtndGVzdC1seGMtcmhheW9wo4IBrDCCAaigAwIBEqEDAgECooIBmgSCAZbGlGHcsJJgsaVR9ohZW/JYrm+12FKi9RMXWBRfHymhwLtmBm5skUFeHtAcjVoqkomCn2lphsjKqtja5LxXH5AN0VNOewY5EwuCk0uL1QHx7T5mfHe5vGDCoyYCVVxOjdFgBfaOw1P0+6GfSyA5fDxXG65SE/Tx46A0EPVFc+cTZpHoGMaA8fKuxOVlw89/pJ2OsRk2SdQpzf5Bl7zpmz/bgKtQfAYsJYUtaqLsSfnt/hGsEUcVyPkm+Bh/KSz1g7fWpsluhkBi59luR9QF99/iyIFK8iEzzhpMj9CA1ZqOVcvHhMbVoIY6k65z8ShtpS+tCuMz/OyA+hLXZB3v7nFXXk7bXaR9fqbTEEFYFuYz2w9GnyiAEpg+X7OkQsyz48Ipd4kZN2wKYBzs3haH3ZI2eWB1D96CsZ2h4AC8b+BuD9VFKCL6hM6DCXDYahyjRBXyKR7IN0hc5QvEoj3EbSrFbLx65pdCDkiTkfbcBijDl8TIkAsymJUGhkeWqZN+UO825j4VG/hUSqbYpL9re9WjgvQaW9SopIHLMIHIoAMCARKigcAEgb0fld5tNVV1sRLgyaTaTV9ADXRoxXAPOysQxNg1KTqKZjjiFPINuc61OqVW0pTEx+Ntzuh2qTTtSaLFu5gDcUDa4UGKUmKKIN8BPOLOJZ7F6Hq5C/Pws362YYRigWIZfrytPNwTXGoFf6lOt6uCbQeMz8hfeP/UN8GAGGbW+SiEpxj5UTLUC7OhP43uEPrnNCBudXPgvdI2dFVGoeWlY+D9YwSS+YNgw5oSQ6NxNcHkjtiAS5e+MrnAcw6u8Do='
> returned an error: [AUTHENTICATIONFAILED] Authentication failed.
>
> It's entirely possible that this particular issue is user error on my
> part, though, as I don't have experience with using or configuring
> mbsync. However, the fact that gsasl and python clients both work
> suggests that it's not a general gssapi problem with dovecot.
odd; I can definitely reproduce the problem with an upgrade of dovecot,
and that is fixed by downgrading.
> The mbsync config I've used in testing follows. It attempts to
> authenticate against the same account as is used in the successful
> python and gsasl tests.
>
> Expunge None
> Create Both
>
> MaildirStore local
> Path ~/Mail.mbsync/
> Trash Trash
>
> IMAPStore testimap
> Host autopkgtest-lxc-rhayop
> TLSType None
> AuthMechs GSSAPI
> User nobody
>
> Channel testchannel
> Far :testimap:
> Near :local:
> Expunge Both
> MaxMessages 150
> MaxSize 200k
>
> If you could share more about your mbsync configuration and invocation,
> maybe that will help.
My mbsync configuration looks like this:
---
Expunge Far
Create Both
MaildirStore local
Path /home/wouter/Maildir/
Inbox /home/wouter/Maildir/.
Trash Trash
SubFolders Verbatim
IMAPStore grep
Host imap.grep.be
User wouter
TLSType STARTTLS
CertificateFile /home/wouter/.config/mbsync/imap.grep.be.pem
Channel grep
Far :grep:
Near :local:
Sync All
Pattern * !spam spam.gemist spam.fout !spam.gemist.processed
!spam.fout.processed !archive
---
It's largely the same, except that I don't force an auth mechanism but
do force TLS.
I did notice something that might be related:
krb5kdc[246753]: TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18),
aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20),
aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16),
DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25),
camellia256-cts-cmac(26)}) 102.39.133.155: ISSUE: authtime 1785240482, etypes
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)}, [email protected] for imap/[email protected]
...which seems to indicate that some of my keytypes are deprecated and I
should migrate away from them (this is a 20+ year old krb5 realm, so
some cruft like that is expected, I suppose). Maybe the new dovecot is
somewhat more strict about things like that? If so it could be that.
--
"I never had a C in history!"
"Yeah, but there was so much less of it when you were my age!"
-- Joe Brockmeier recounting a conversation with his father, cfgmgmtcamp 2026,
Ghent
