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 :) ). -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
