How to have postfix use saslauthd and pam?

[Bill Kearney]

> The pam_mysql stuff has repeatedly been reported to be leaking memory. I
can't
> confirm that, since I never used it.

I've likewise heard this mentioned, is it still an issue?  I'll check it's
mailing lists.

> I'd prefer to use sql directly like this:

What are the downsides of using it directly?  Anything?  Beyond that the
pam_sql module has some more robust logging, is there some sort of cached
connection downside?  This isn't going to be a highly loaded box so making
efficient use of SQL connections is unlikely to be a big deal.  But I could
imagine in some installations it'd be a concern.  I was sort of under the
impression that saslauthd acted in this capacity.  Is that not correct?

> Create a DB. You must not encrypt the passwords or it will never work -
the
> shared secret mechanisms need to retrieve the passwords unencrypted.

If you want to use shared secrets, that is.  Good point.  That gets into the
whole 'does the client program know how to use it properly' situation.  I'd
like to have SquirrelMail (or some other web interface) connecting in
addition to the usual suspects; Tbird, pine, Outlook & Outlook Express but
not much else.  But I suppose it'll be important to figure THAT out first
before I go populating the database without plaintext passwords, eh?

> Create a DB user, set appropriate permissions to access your DB and verify
> this user is able to connect to the DB and is able to retrieve data from
it.
>
> Then create the following config in /usr/lib/sasl2/smtpd.conf:
>
> pwcheck_method: auxprop
> mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
> auxprop_plugin: sql
> ... SQL options according to options.html from the Cyrus-SASL.2.x
> documentation...

Ah, the it's a matter of using the mech_list to tell the remote client what
are available?  So if I didn't want to use CRAM-MD5 and DIGEST-MD5 then I'd
leave them out of mech_list?

> Before using Postfix to test the setup, install cyrus-sasl-devel.* and use
> sasl2-sample-server and sasl2-sample-client to test the configuration from
> smtpd.conf. To test, create a symlink from /usr/lib/sasl2/smtpd.conf to
> /usr/lib/sasl2/sample.conf (this is where sasl2-sample-server will look
for
> config), start sasl2-sample-server, on another terminal window start
> sasl2-sample-client and then try to authenticate.

Ok, that helps explain how to use it.

> If that works, turn to main.cf and add the following config:
>
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_local_domain = FOOBAR
>
> where FOOBAR matches the value you've added as realm (or domainpart) to
the
> usernames that authenticate.

Right so if the username being looked up from the database is
joe at example.com, and the user connects with just "joe" and a password, then
the smtpd_sasl_local_domain would have to be 'example.com'.  Case sensitive?

How does this domain value affect virtual users?  If the default domain
isn't set, as in there's just a 'joe' user, along with other virutal users;
tom at otherdomain.com, harry at somewherelese.com, etc.  I realize they'd all be
connecting with their full e-mail address, but how would that affect using
the smtpd_sasl_local_domain value?  I don't want to start populating it one
way only to have it be a problem later.

> Then reload Postfix, telnet to the server on port 25 and see if it offers
AUTH
> after an EHLO. If that works, test with a mail client. If it doesn't, use
> "saslfinger -s" to provide helpful debug output on the list. For
saslfinger
> see my signature.

Thanks, I already have saslfinger loaded.  I'll try your advice first before
posting the output.

-Bill Kearney