On 2013-01-05 at 00:10 +0000, Andy Bennett wrote:
> I have not found any suggestions that the cyrus_sasl authenticator can
> work in client mode.
It can't, it's server-only. And even if it weren't, it's limited in
things like being able to specify alternative keytab files. Exim as a
client is going to be running as the Exim runtime user, so should not
have access to `/etc/krb5.keytab`. There's no way to direct Exim with
cyrus-sasl to use an alternative keytab in a reliable and portable way,
in large part because Exim is a setuid binary (so, eg, Heimdal will
ignore KRB5_KTNAME).
> + For exim acting as an SMTP client (i.e. when initiating an SMTP
> connection to the smarthost) to use the data in a keytab to provide a
> username and password to an authenticator.
> + For exim acting as an SMTP client to use a Kerberos service ticket
> (obtained with the credentials in the keytab) to authenticate to the
> relay via GSSAPI.
> This is the ideal scenario and in this instance the credentials would
> never be sent over the wire.
Neither at present. The correct fix is to expand the heimdal_gssapi
authenticator to handle client-side authentication. This would be the
simplest, with fewer layers of abstraction to manipulate, and is newer
code (introduced with Exim 4.80).
> Alternatively, can anyone recommend a nullmailer or equivalent that I
> can use on the client machines?
I'm not aware of a Kerberos-speaking one.
> The only vaguely relevant message I could find in the archive is this
> one which explains auth negotiations:
>
> https://lists.exim.org/lurker/message/20110409.005823.27da0235.en.html
That was me, and since then I've written the heimdal_gssapi
authenticator.
I welcome patches to add the client-side code for heimdal_gssapi; I'm
not going to have time to write the code myself, any time soon.
`src/auths/heimdal_gssapi.c` and fill out the body of
`auth_heimdal_gssapi_client()`, probably adding options to
`auth_heimdal_gssapi_options` (keep sorted alphabetically) and change
`auth_heimdal_gssapi_init()` so that if the client side is configured
acceptably, then `ablock->client` is set `TRUE`. You'll need to make
sure that both client and server can be independently enabled in the
..._init() function without bailing out too early.
-Phil