I was starting to have nightmares about maintaining my own branch. :)
thanks for including this. I just 'checked it out' (co - ba dump bump..). It passes the "it compiles and retrieved my mail once test". :-p

just a thought, looking at my logs, maybe the login should be with the DN? This might be beneficial if one is actually searching (auth_bind = yes).

Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=<boing>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured

vs something like

Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured

Thanks again, great work on the imap (and pop) server.

Geff

Quoting Timo Sirainen tss@iki.fi:

On Mon, 2006-01-02 at 17:43 -0800, Geff wrote:

...

Let me know how you like this one.

This assumes one config parameter. The non-null of auth_bind_userdn overrides auth_bind = yes.

I'm using this patch now on cvs head.

Committed. I moved some of the common authbind code to a new function. See if I broke it :)

Quoting Timo Sirainen tss@iki.fi:

...

Jan 6 17:48:08 kusanagi dovecot: imap-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured

If you make LDAP's userdb query return the DN as "user", and also make sure that you're not using %u in default_mail_env, you could have that.

I'm not sure if I'd want to make a separate "log-user" variable to confuse things..

From a security perspective audit logs or access control mechanisms have what's called SRA or subject resource action. So in the simple case of a website that's as follows:

subject: user, also called user princple. resource: host + url + query string action: get (post, etc)

Or in the case of mail:

subject: user resource: mail file action: read / login / search / select.

However it seems that we have two subjects. We have one for the passdb and one of the userdb. On my setup the passdb's subject is theoretically the ldap dn and the userdb's subject is the /etc/passwd getpwnam type unix account. So we really have two subjects that need to be logged in general unless they match of course. Yeah that can be messy, but perhaps worse not to know about both principles in the event of a security incident.

Just food for thought.

Geff