On 2012-02-17 at 08:38 -0500, Phil Pennock wrote: > Adventurous folks already using Heimdal needed for testing git branch of
> Exim. Docs not yet updated.
>
> Per my mail of 2012-02-04, """Heimdal 1.4 put in some restrictions on
> honouring a value of $KRB5_KTNAME inherited from the environment, which
> means that at present there's no way to make Exim work with a
> non-default keytab file."""
>
> I've added a "heimdal_gssapi" authenticator, server-only. I've
> developed and tested against Heimdal 1.4 on FreeBSD.
(As already noted, I think, the docs were updated).
I've just tried again to use Apple Mail with GSSAPI, and once more it
works with IMAP but not initially with SMTP. So no change there.
However, because of the debug messages I wrote for Exim in the new
heimdal_gssapi Authenticator, I can now tell *why* it is failing. And I
was then able to get it working.
SMTP<< BQQG/wAAAAAAAAAACK+ONaHkLnpgIS85uofF9Usl2zdQIcbUE1HdxWGWQrfF90jr8QAaD0dBJo6z0aySKV5zpQ==
gssapi: final message too short; need flags, buf sizes and authzid SMTP>> 535 Incorrect authentication data
The somewhat under-specified GSSAPI/SASL mechanism (in old RFCs, fixed
in the drafts for the replacement) makes it a little hard to puzzle
through what's required after authentication, or that there is a step
afterwards. I remember my confusion when I first wrote a GSSAPI
client authenticator (in Perl in 2006) how awkward it was to get the
needed values.
I add an identifier to the auth, and select retry, and Apple Mail does
not send an Initial Response and does not send data when nudged. When I
run Connection Doctor, it sends AUTH GSSAPI and then QUIT, without
terminating SASL negotiation with the "*" break.
So I switch to just usercode, instead of usercode@REALM, and it works
but is then rejected by my server_condition, which is an easy fix.
So: with no usercode filled in, Apple Mail does not set an authzid for
the request; it's not clear to me if this is allowed by RFC 4752, but I
will change Exim to support it and just dup the authen id to authzid for
that case (and only commit that if it's clear that this is sufficient to
fix).
With a full realm-qualified usercode, Apple Mail fails to start
authentication and is buggy. With just a user, with an appropriate
"server_condition", it works.
(Of course, my test mail to a Gmail account had my phone beep for
successful delivery to Gmail before Mail played the successfully-sent
notification swishing sound .. at least they err on the side of caution
before reporting success :) ).
