Patch to force realm specifications from IMAPD

[Igor Brezac]

On Mon, 29 Sep 2003, Diego Rivera wrote:

> Hello all
>
> I ran into a brick wall today because I needed Cyrus-IMAPD to
> authenticate against specific realms, but it would always use the empty
> (default) one regardless of what I told it.
>
> So I came up with this quick patch which adds two config options:
>
> sasl_forced_realm: realm.com (default is null)
>

The cvs version of saslauthd has ldap_default_realm.

>     This option causes IMAPD/POP3D/LMTPD* to use the supplied realm spec
> in the sasl_server_new() calls (and thus, authenticate the provided user
> against that realm).  This works well with PLAIN, others may as well.
> I'm well aware that this may break other auth mechanisms, but it fixed
> my problem and others might find it useful.
>
>
> sasl_email_logins: yes|no (default is no)
>
>     This causes the realm spec to be set to "", which in turn should
> allow for "email-style" logins specifying a realm.  Naturally, if
> sasl_forced_realm is active this option has no effect.  Again - use with
> care.
>
> More detail on the problem this solved for me:
>
> My problem was that I wanted multiple IMAP instances (using different
> partitions, configurations, ip:port combos, etc) to authenticate against
> particular realms via saslauthd (using LDAP as its backend).
>
> Using fastbind with saslauthd I could then authenticate the user via
> LDAP binds, and find the user's dn via a filter such as
> "uid=%u,ou=%r,o=LDAP".  That way, I can keep separate user spaces,
> separate mailboxes, but run them all on the same box.

Why don't you hard code the realm here "uid=%U,ou=myrealm,o=LDAP"?  You
run a separate imapd/pop3d/saslauthd/slapd instance for each domain...

> Please look it over and comment.
>
> * LMTPD: I realize that preauth could be an issue with LMTPD, so the
> patch does go through the motions to NOT alter behavior if preauth is in
> effect.
>
> Also, since I didn't know (actually, didn't check :) ) if
> imapd/pop3d/lmtpd/etc automagically reload configuration changes the
> configuration values are always read from the config file.  If this is
> not the case, then they could be cached and used indefinitely.
>
> Anyway - here it is.  Please review it and tell me how bad it is :)
>
> Best
>

-- 
Igor