Hi John Jack Doe: Am 17.12.18 17:01 schrieb(en) JohnJackDoe tele2 de:
My /old/ machine is running Xubuntu 16.04 LTS. According to your instructions some time ago I build Balsa from GIT succesfully as follows:
[snip]
./configure --with-gpgme --with-gpg-app=/usr/bin/gpg2 --with-html-widget=webkit2 --with-spell-checker=gtkspell --with-rubrica=yes --with-libnotify --with-canberra --enable-smime --with-gtksourceview -- without-gnome --with-gcr=yes --with-compface
I see… this means that you *don't* have gss = Kerberos authentication enabled on this (old) box. The difference to the version from the Buster repo (on the new machine) is that it /has/ Kerberos authentication enabled. As the server offers '250-AUTH GSSAPI NTLM LOGIN', Kerberos authentication is tried first, and as it fails, you're lost. This is a bug I introduced a long time ago, actually. I created a patch 2½ hours ago, which /should/ fix this issue (see the message with subject “[Patch] SMTP, POP: fall back to auth w/ password if GSS failed”). So you have the following options: (1) get the latest git code, and build it with the options above, which disabled gss *or* (2) get the latest git code, and manually apply my patch from the message above *or* (3) wait until someone (Peter?) reviewed the patch and pushed it to git. With options (2) or (3), you may or may not enable gss, and authentication should always work for you. Or you wait for the Debian maintainer to build a new package after (3); no idea how fast they are.
I don't want to sound cheeky but the /old/ GIT version was running perfectly. So I assume that the code was and still is OK.
See above, the difference is that the code on the old box doesn't try to use Kerberos, whilst the pre-built one on the new does (and fails).
My /new/ machine is running Debian Stretch. I installed the package 2.5.6-1 from the Buster reposotory. I have no idea what compiler optins were used by the maintainer.
The error regarding the GSS security context indicates that they enabled GSS authentication.
I use Balsa, beside POP which is working, with an IMAP account at a Microsoft server. To the IMAP account I authenticate with username and password over SSL. To the SMTP account I authenticate with username only over TLS.
IMAP uses a different implementation, which already tries *all* possible auth methods, starting with GSS (which will fail), and then any other method advertised by the server. The (now fixed) approach for SMTP and POP is more efficient. Thanks a lot for pointing me to this bug, btw! Hope this helps, Albrecht.
Attachment:
pgpfSHbguXbBR.pgp
Description: PGP signature