SASL support in INN 2.5.0

[Julien ÉLIE]

Hi Russ,

>> Consider for instance the Debian package which has SASL support.  A
>> news client will see AUTHINFO SASL and try to authenticate with
>> AUTHINFO SASL PLAIN <base64-string>.
>
> Hm, shouldn't we be interrogating the SASL library for the supported
> mechanisms, and if PLAIN isn't supported, not including it?

Yes, it is what we do:

    /* Check for available SASL mechanisms.
     * Start the string with a space for the strstr() calls afterwards. */
    sasl_listmech(sasl_conn, NULL, " ", " ", "", &mechlist, NULL, NULL);


I assumed in my example that it was installed.



> Or does the SASL library always report that PLAIN is supported?

No, I don't think so:

% aptitude show libsasl2-modules
Paquet : libsasl2-modules
Dépend : libsasl2-2 (= 2.1.22.dfsg1-8+etch1), libc6 (>= 2.3.6-6), libssl0.9.8 (>= 0.9.8c-1)
Suggère: libsasl2-modules-otp, libsasl2-modules-ldap, libsasl2-modules-sql, libsasl2-modules-gssapi-mit
Description : Pluggable Authentication Modules for SASL
 This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, NTLM, CRAM-MD5, and DIGEST-MD5 (with DES support).


libsasl2-modules (which is a recommended package for inn2) should be installed.


The problem is that a user can have libsasl2-modules installed without wanting
it for his INN.  Imagine libsasl2-modules is installed because of Postfix
or slapd (OpenLDAP); it would be automatically used by INN.



>> That's why I had imagined to have an sasl_auth: parameter in
>> readers.conf auth blocks.  If set to true, then an AUTHINFO SASL
>> request will match this block if successful.
>>
>> AUTHINFO SASL would not be advertised if there is no "sasl_auth: true"
>> in readers.conf.
>
> This does make sense to me.

OK, I will do that.  It will solve the issue.

-- 
Julien ÉLIE

« Le chemin n'est pas difficile, c'est le difficile qui est le chemin. » (Kierkegaard)