Hello, Running FC5 x86_64 with dovecot-1.0-0_8.beta3.rhfc5.at Using system user/passwds for 99.99% of users...have sql user/pass enabled to test virtual users from mysql.
How do I strip off the domain when users provide user@domain.com so that my userdb and passdb use just 'user'? (disregarding sql auth...I'm not concerned with that right now).
My dovecot.conf auth config:
passdb pam { args = dovecot }
passdb sql { args = /etc/dovecot-sql.conf }
userdb passwd { }
userdb sql { args = /etc/dovecot-sql.conf }
Can I just pass userdb the 'user' using an args= statement? %d? ...and then also to the passdb?
Thanks, Curt
Netlink Tech wrote:
Hello, Running FC5 x86_64 with dovecot-1.0-0_8.beta3.rhfc5.at Using system user/passwds for 99.99% of users...have sql user/pass enabled to test virtual users from mysql.
How do I strip off the domain when users provide user@domain.com so that my userdb and passdb use just 'user'? (disregarding sql auth...I'm not concerned with that right now).
My dovecot.conf auth config:
passdb pam { args = dovecot }
passdb sql { args = /etc/dovecot-sql.conf }
userdb passwd { }
userdb sql { args = /etc/dovecot-sql.conf }
Can I just pass userdb the 'user' using an args= statement? %d? ....and then also to the passdb?
Thanks, Curt This was answered on the list quite recently, you might want to search the archives.
On Wed, 2006-04-12 at 01:21 +1000, Peter Fern wrote:
Netlink Tech wrote:
Hello, Running FC5 x86_64 with dovecot-1.0-0_8.beta3.rhfc5.at Using system user/passwds for 99.99% of users...have sql user/pass enabled to test virtual users from mysql.
How do I strip off the domain when users provide user@domain.com so that my userdb and passdb use just 'user'? (disregarding sql auth...I'm not concerned with that right now).
My dovecot.conf auth config:
passdb pam { args = dovecot }
passdb sql { args = /etc/dovecot-sql.conf }
userdb passwd { }
userdb sql { args = /etc/dovecot-sql.conf }
Can I just pass userdb the 'user' using an args= statement? %d? ....and then also to the passdb?
Thanks, Curt This was answered on the list quite recently, you might want to search the archives. Could you be more specific as to what thread it was resolved in? I have seen threads over the past year asking how to do domain stripping with dovecot, none of them seem to be a solution that works with the main dovecot source tree, unless you are using SQL authentication and handle it in the query.
Regards Michael Baird
On Tue, 2006-04-11 at 09:36 -0500, Netlink Tech wrote:
Hello, Running FC5 x86_64 with dovecot-1.0-0_8.beta3.rhfc5.at Using system user/passwds for 99.99% of users...have sql user/pass enabled to test virtual users from mysql.
How do I strip off the domain when users provide user@domain.com so that my userdb and passdb use just 'user'? (disregarding sql auth...I'm not concerned with that right now).
In general I don't see this as very useful feature. Why are your users logging in with @domain? Or why not change your passdbs/userdbs to just contain the domain, and set auth_default_realm so everyone always logs in with domains?
My dovecot.conf auth config:
passdb pam { args = dovecot }
Here you could use some PAM plugin to strip it. I've no idea if such exists though.
passdb sql { args = /etc/dovecot-sql.conf }
Here you can modify your SQL command to use %n instead of %u.
userdb passwd { }
If the PAM plugin which strips the domain from username does it properly, it should have returned the new username to Dovecot and this should work..
userdb sql { args = /etc/dovecot-sql.conf }
And here again you can use %n.
On Wed, 2006-04-12 at 16:05 +0300, Timo Sirainen wrote:
On Tue, 2006-04-11 at 09:36 -0500, Netlink Tech wrote:
Hello, Running FC5 x86_64 with dovecot-1.0-0_8.beta3.rhfc5.at Using system user/passwds for 99.99% of users...have sql user/pass enabled to test virtual users from mysql.
How do I strip off the domain when users provide user@domain.com so that my userdb and passdb use just 'user'? (disregarding sql auth...I'm not concerned with that right now).
In general I don't see this as very useful feature. Why are your users logging in with @domain? Or why not change your passdbs/userdbs to just contain the domain, and set auth_default_realm so everyone always logs in with domains?
Because, my users don't follow directions well, and it saves tons of tech support calls if we just strip the domain. They might have migrated from another ISP where domain is necessary, and just think this is the way to configure it.
Switching my entire userbase and billing/provisioning system to create names with domains appended isn't a viable option for me at this time. My current pop3 solutions strips domain names,I thought this was essentially a standard feature for pop3/imap servers. I've seen many people ask about this on the mailing list for quite some time. I don't know why there is so much resistance to supporting functionality that is mostly a standard feature with other pop3/imap servers, and which also makes it *much* easier to migrate to dovecot from other solutions which support the domain stripping. It is far easier for me to change a setting on the server side, then it is to get 100's of users (probably mad after the changeover) to change their settings (although in a perfect world this is the best solution).
Regards Michael Baird
On Wed, 2006-04-12 at 09:48 -0400, Michael Baird wrote:
I don't know why there is so much resistance to supporting functionality that is mostly a standard feature with other pop3/imap servers, and which also makes it *much* easier to migrate to dovecot from other solutions which support the domain stripping.
I don't remember having seen all that much requests for this feature. Perhaps lately several people have asked for it, but for the last 3 years there haven't been all that many people.
If I added a new setting for every single feature people asked, dovecot-example.conf would be much larger than it currently is. And it already is too large I think.
So instead of adding lots of special case settings, I prefer to add few settings that can be useful for other cases as well. With that in mind, how about a setting something like this:
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username or
%n would drop away the domain if it was given. This translation is
done after auth_username_translation changes.
#auth_username_format =
On Wed, 2006-04-12 at 17:17 +0300, Timo Sirainen wrote:
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username or
%n would drop away the domain if it was given. This translation is
done after auth_username_translation changes.
#auth_username_format =
Wouldn't it be better to do it the other way around, and have it default to auth_username_format = %u@%n or something? OTOH, that need special handling of a trailing @ character (if %n is empty) or a new %X variable that is "@%n" or ""...
johannes
On Wed, 2006-04-12 at 16:24 +0200, Johannes Berg wrote:
On Wed, 2006-04-12 at 17:17 +0300, Timo Sirainen wrote:
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username or
%n would drop away the domain if it was given. This translation is
done after auth_username_translation changes.
#auth_username_format =
Wouldn't it be better to do it the other way around, and have it default to auth_username_format = %u@%n or something? OTOH, that need special handling of a trailing @ character (if %n is empty) or a new %X variable that is "@%n" or ""...
I think I'm doing it the way you want, but you just misunderstood the explanation. %u means username with domain, %n means the username without domain and %d is only the domain. I updated the comment to contain one more example:
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username, %n would
drop away the domain if it was given, or "%n-AT-%d" would change the '@' into
"-AT-". This translation is done after auth_username_translation changes.
#auth_username_format =
The default could be set as %u in there, but I didn't add it because then it would uselessly do a bit more work. The empty default just means that it doesn't do any changes.
On Wed, 2006-04-12 at 17:36 +0300, Timo Sirainen wrote:
I think I'm doing it the way you want, but you just misunderstood the explanation. %u means username with domain, %n means the username without domain and %d is only the domain. I updated the comment to contain one more example:
Yeah, sorry about that. I did indeed misunderstand that based on the fact that I can never remember if I want %d or %n :)
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username, %n would
drop away the domain if it was given, or "%n-AT-%d" would change the '@' into
"-AT-". This translation is done after auth_username_translation changes.
#auth_username_format =
Great, that clears things up, thanks :) Except that in the latter case, a username _without_ domain like 'johannes' is changed into 'johannes-AT-', no?
johannes
On Wed, 2006-04-12 at 17:06 +0200, Johannes Berg wrote:
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username, %n would
drop away the domain if it was given, or "%n-AT-%d" would change the '@' into
"-AT-". This translation is done after auth_username_translation changes.
#auth_username_format =
Great, that clears things up, thanks :) Except that in the latter case, a username _without_ domain like 'johannes' is changed into 'johannes-AT-', no?
Yea, but in that case you probably won't have usernames without domains. And auth_default_realm could help there also to get the domain in there. And if you _really_ want to have both "user-AT-domain" usernames and plain "user" usernames, then you can always patch the sources :)
On Wed, 2006-04-12 at 18:22 +0300, Timo Sirainen wrote:
Yea, but in that case you probably won't have usernames without domains. And auth_default_realm could help there also to get the domain in there. And if you _really_ want to have both "user-AT-domain" usernames and plain "user" usernames, then you can always patch the sources :)
Yes, I wouldn't worry about it either :)
johannes
On Wed, 12 Apr 2006, Timo Sirainen wrote:
On Wed, 2006-04-12 at 09:48 -0400, Michael Baird wrote:
I don't know why there is so much resistance to supporting functionality that is mostly a standard feature with other pop3/imap servers, and which also makes it *much* easier to migrate to dovecot from other solutions which support the domain stripping.
I don't remember having seen all that much requests for this feature. Perhaps lately several people have asked for it, but for the last 3 years there haven't been all that many people.
If I added a new setting for every single feature people asked, dovecot-example.conf would be much larger than it currently is. And it already is too large I think.
So instead of adding lots of special case settings, I prefer to add few settings that can be useful for other cases as well. With that in mind, how about a setting something like this:
Username formatting before it's looked up from databases. You can use
the standard variables here, eg. %Lu would lowercase the username or
%n would drop away the domain if it was given. This translation is
done after auth_username_translation changes.
#auth_username_format =
That would work great for me! I would still have to work on PAM for SASL/SMTP_AUTH...but that is not a dovecot issue.
On Wed, 12 Apr 2006 17:17:37 +0300 Timo Sirainen <tss@iki.fi> wrote:
: On Wed, 2006-04-12 at 09:48 -0400, Michael Baird wrote: : > I don't : > know why there is so much resistance to supporting functionality that is : > mostly a standard feature with other pop3/imap servers, and which also : > makes it *much* easier to migrate to dovecot from other solutions which : > support the domain stripping. : : I don't remember having seen all that much requests for this feature. : Perhaps lately several people have asked for it, but for the last 3 : years there haven't been all that many people.
I only use this feature during the first 2 weeks or so of migrating from some other pop3/imap server to dovecot. After that, I can make everyone fix their logins. Very useful when the CEO is traveling while I'm changing the mail server.
-- Don't say "yes" until I finish talking. -- Darryl F. Zanuck
On Wed, 12 Apr 2006, Timo Sirainen wrote:
On Tue, 2006-04-11 at 09:36 -0500, Netlink Tech wrote:
Hello, Running FC5 x86_64 with dovecot-1.0-0_8.beta3.rhfc5.at Using system user/passwds for 99.99% of users...have sql user/pass enabled to test virtual users from mysql.
How do I strip off the domain when users provide user@domain.com so that my userdb and passdb use just 'user'? (disregarding sql auth...I'm not concerned with that right now).
In general I don't see this as very useful feature. Why are your users logging in with @domain? Or why not change your passdbs/userdbs to just contain the domain, and set auth_default_realm so everyone always logs in with domains?
To echo Michael Baird... Current setup has hundreds of people using just username. In the case of other ISP/userbase buyouts, etc., keeping their current config saves headaches. And then like Michael said, some users have trouble differentiating what their username is versus their email addres (username@domain.com). The less tech support calls I get, the happier I am! :)
My dovecot.conf auth config:
passdb pam { args = dovecot }
Here you could use some PAM plugin to strip it. I've no idea if such exists though.
From archive, Grant seemed to have PAM module that does this (March 30, 2006 thread that Michael started 'Strip Realms') Since I haven't attempted to write anything for PAM yet, I have asked Grant if he would share his module...maybe he will share with the list? I also would be modifying the PAM module to try to get it to work with SASL/SMTP_AUTH.
passdb sql { args = /etc/dovecot-sql.conf }
Here you can modify your SQL command to use %n instead of %u. Understood, the sql part was not a problem.
userdb passwd { }
If the PAM plugin which strips the domain from username does it properly, it should have returned the new username to Dovecot and this should work..
userdb sql { args = /etc/dovecot-sql.conf }
And here again you can use %n.
Thanks Timo (and everyone else that has contributed to dovecot)
participants (6)
-
Johannes Berg
-
Michael Baird
-
Netlink Tech
-
Peter Fern
-
Peter Hessler
-
Timo Sirainen