Automatically inferring %d on multi-domain virtual install ?

Mon Feb 22 07:56:40 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 21 Feb 2016, Leon Kyneur wrote:

> Date: Sun, 21 Feb 2016 10:51:21 +0000
> From: Leon Kyneur <leon at dexterous.org>
> To: Dovecot Mailing List <dovecot at dovecot.org>, Timo Sirainen <tss at iki.fi>
> Subject: Re: Automatically inferring %d on multi-domain virtual install ?
> 
> very intrigued by your solution Timo, have attempted something similar in
> the past to no avail.
>
> When I tried I was unable to retain the user at domain when setting the domain
> as extra field - protected is new to me and can't find documentation - but
> also doesn't work :(
>
> # cat passwd.domains
> 10.100.1.1:::::::domain:protected=foo.org
> 10.100.1.2:::::::domain:protected=bar.org
>
> # cat imap.passwd
> user at bar.org:{plain}password::::::
> user at foo.org:{plain}password::::::
>
> dovecot.conf:
>
> passdb {
>    args = username_format=%l /etc/dovecot/passwd.domains

What, if you use:

args = username_format=%l@%d /etc/dovecot/passwd.domains
and:

10.100.1.1@:::::::domain:protected=foo.org
in the file ....

>    default_fields = nopassword=y
>    driver = passwd-file
>    result_success = continue
> }
>
> passdb {
>    args = scheme=plain-md5 username_format=%u /etc/dovecot/imap.passwd
>    driver = passwd-file
> }
>
> 1. user without domain localip 10.100.1.1 - adds foo.org:
> # doveadm auth lookup -x lip=10.100.1.1 user
> passdb: user
>    user : user at foo.org
>
> 2. user without domain localip 10.100.1.2 - adds bar.org
> # doveadm auth lookup -x lip=10.100.1.2 user
> passdb: user
>    user : user at bar.org
>
> 3. user WITH domain bar.org on localip 10.100.1.1 - still adds foo.org???
> # doveadm auth lookup -x lip=10.100.1.1 user at bar.org
> passdb: user at bar.org
>    user : user at foo.org
>
> Is the protected suffix supposed protect domain and not change it here?
>
>
> On Sun, Feb 21, 2016 at 1:20 PM Timo Sirainen <tss at iki.fi> wrote:
>
>> How about:
>>
>> passdb {
>>   driver = passwd-file
>>   args = username_format=%l /etc/dovecot/passwd.domains
>>   result_success = continue
>> }
>>
>> passdb {
>>   .. the real passdb for authentication ..
>> }
>>
>> Where /etc/dovecot/passwd.domains contains:
>>
>> 10.0.0.100:::::domain=foo.org
>> 10.0.0.101:::::domain=bar.org
>>
>> So the first passdb lookup would set the domain based on IP and then
>> continue for the actual authentication. Or if you don't want it to override
>> an explicit user at domain authentication, this should also work:
>>
>> 10.0.0.100:::::domain:protected=foo.org
>> 10.0.0.101:::::domain:protected=bar.org
>>
>> Not tested, but should work I think. At least with new enough Dovecot
>> versions.
>>
>>> On 19 Feb 2016, at 23:10, Gabriel L. Somlo <gsomlo at gmail.com> wrote:
>>>
>>> On Fri, Feb 19, 2016 at 08:41:15AM +0100, Steffen Kaiser wrote:
>>>>> I'm trying to allow domain-less logins for a multi-domain virtual IMAP
>>>>> server, and wondering if I can automatically infer the domain (value of
>>>>> variable %d) from the local IP (%l) or the hostname used by the client
>>>>> when connecting to my server.
>>>>>
>>>>> Let's say I have two host names: mail.foo.org (10.0.0.100) and
>>>>> mail.bar.com (10.0.0.200), with forward and reverse DNS configured to
>>>>> resolve A and PTR records in either direction.
>>>>>
>>>>> Let's also say I have 10.0.0.100 and 10.0.0.200 set up as secondaries
>>>>> on my server's loopback interface, and routing is set up to bring
>> client
>>>>> traffic to me for both of those IP addresses.
>>>>
>>>> Hm, it should be possible like so:
>>>>
>>>> 1) keep the file you have now as 2nd passdb, in order to let your users
>>>> login like now from anywhere
>>>>
>>>>> user1 at foo.org:{PLAIN}user1foo
>>>>
>>>> 2) from this file create another passwd-file with ExtraField via script
>> /
>>>> cron jobs, that defines
>>>>
>>>> user1 at 10.0.0.100:{PLAIN}user1foo:::::user=user1 at foo.org
>>>>
>>>> see http://wiki2.dovecot.org/PasswordDatabase/ExtraFields
>>>>
>>>> Maybe allow_nets could limit the clients further.
>>>>
>>>> Then add another passdb section pointing to that file using
>>>> username_format=%n@%l
>>>>
>>>> http://wiki2.dovecot.org/AuthDatabase/PasswdFile
>>>>
>>>> That will map domain-less logins to full mail addresses, which in turn
>> sets
>>>> %d, too.
>>>
>>> That *almost* worked :)
>>>
>>> I now have
>>>
>>>  passdb {
>>>    driver = passwd-file
>>>    args = username_format=%n@%l /var/lib/topgen/etc/postfix/users
>>>  }
>>>
>>> pointing to a "users" file with entries such as
>>>
>>>   user1 at 10.0.0.100:{PLAIN}user1foo:::::user=user1 at foo.org
>>>
>>> The only trouble is, %d does not get set; I get new "user1" and
>>> "user2" folders created directly under /var/lib/vmail/, which
>>> indicates the %d portion is equal to the empty string.
>>>
>>> I also tried
>>>
>>>   user1 at 111.0.10.10:{PLAIN}tartans1:::::domain=foo.org
>>>
>>> which the PasswordDatabase wiki page says should override %d, but
>>> still no luck...
>>>
>>> Thanks for the pointer though, now that I read the relevant bits of
>>> documentation it feels like I'm really close, and this *should* work.
>>> I'm still either missing something, or tickling a bug (probably the
>>> former :)
>>>
>>> Thanks,
>>> --Gabriel
>>>
>>>>
>>>>>
>>>>> The relevant bits of my dovecot.conf are:
>>>>>
>>>>> ---%<------------------------------------------------------------------
>>>>> mail_location = maildir:/var/lib/vmail/%d/%n
>>>>> passdb {
>>>>> driver = passwd-file
>>>>> args = /var/lib/vmail/etc/postfix/userdb
>>>>> }
>>>>> userdb {
>>>>> driver = static
>>>>> args = uid=dovenull gid=dovenull home=/var/lib/vmail/%d/%n
>>>>> }
>>>>> ---%<------------------------------------------------------------------
>>>>>
>>>>> And my userdb passwd-file right now includes:
>>>>>
>>>>> ---%<------------------------------------------------------------------
>>>>> user1 at foo.org:{PLAIN}user1foo
>>>>> user2 at foo.org:{PLAIN}user2foo
>>>>> user1 at bar.com:{PLAIN}user1bar
>>>>> user2 at bar.com:{PLAIN}user2bar
>>>>> ---%<------------------------------------------------------------------
>>>>>
>>>>> Right now, user1 at foo.org must configure their imap client like so:
>>>>>
>>>>>     IMAP server: mail.foo.org
>>>>>     username: user1 at foo.org
>>>>>     password: user1foo
>>>>>
>>>>> I would like to require this (and other) users to only have to set:
>>>>>
>>>>>     IMAP server: mail.foo.org
>>>>>     username: user1
>>>>>     password: ...
>>>>>
>>>>> and have dovecot somehow infer the "@foo.org" domain based on the fact
>>>>> that the connection was made to 10.0.0.100, which is mail.foo.org, and
>>>>> therefore the domain can *only* be "@foo.org".
>>>>>
>>>>> I could start out by splitting my user database into two files:
>>>>>
>>>>> userdb.foo.org
>>>>> ---%<------------------------------------------------------------------
>>>>> user1:{PLAIN}user1foo
>>>>> user2:{PLAIN}user2foo
>>>>> ---%<------------------------------------------------------------------
>>>>>
>>>>> userdb.bar.com
>>>>> ---%<------------------------------------------------------------------
>>>>> user1:{PLAIN}user1bar
>>>>> user2:{PLAIN}user2bar
>>>>> ---%<------------------------------------------------------------------
>>>>>
>>>>> ... then modify dovecot.conf's passdb setup like so:
>>>>>
>>>>> ---%<------------------------------------------------------------------
>>>>> passdb {
>>>>> driver = passwd-file
>>>>> args = /var/lib/vmail/etc/postfix/userdb.%d
>>>>> }
>>>>> ---%<------------------------------------------------------------------
>>>>>
>>>>> ... but how would I insure that %d is set to the proper value based
>>>>> on e.g. a reverse lookup of %l, which, in foo.org's case would be
>>>>> 10.0.0.100, and resolve to mail.foo.org, and *somehow* that would
>>>>> match %d == "@foo.org" ?
>>>>>
>>>>> Is this even possible in the first place, or am I just being too fussy
>>>>> about the aesthetics of my users' imap client config files ? :) :)
>>>>>
>>>>> Thanks much,
>>>>> --Gabriel
>>>>>
>>>>
>>>> - -- Steffen Kaiser
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEVAwUBVsbHG3z1H7kL/d9rAQLzRggAoBVJDWXDakkqLD+Gye/9KjHvfcIFkf+5
>>>> u3W7ZlPSvyePaAM8u0TDnIPJ15aeyO6XZbTTqB9iKQXzluCusvhNOUl14nVO4CjW
>>>> gJASzpo1Kc9moWW7sWXTF/MCO+O4zVSBtJWdVmJch80hQT8LJxG3jU45FJAd1Jj3
>>>> j+Rso5vEtH3Qw8i1cePaRc6FpDQ+7wboUI53OVjSKJGXbsyK5MXJFhoyvOo8UnvU
>>>> KdbyFoGkYR4n3zaSrkwof6TrRqqgcGA2TUyeQIS8j+ArhDpi7ilOU6x904KK7LoE
>>>> Ff2CzskTaTwEyTW1DZgJzLPc38PzMv9PX7QNUhdPHLFnYrhrutOfww==
>>>> =CFD6
>>>> -----END PGP SIGNATURE-----
>>
>

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVsq/OHz1H7kL/d9rAQI0zAgAmJoE93zZ4qwc+xsJKuhGBIYIhyTZ7rmv
8i62HsBzznqxBf2r0OWd4QDmWuyPE+vD3jAsD4pZvrLvbSXbkTrLUxUJwDhxoRtT
Ox37JS4y4LawGbeIbwvPkKOn6IuktGqZPEfj0PObuCcdjHwS3oETgRP3FUYIrqEq
ujyK7l7VSq8idHqLYa+9SA2YunBeq+LVVskB8z50+ut764nQq/bcqT3gn7MXER5I
KIUUzWsFJXFpEkhadxfarLz1sI0dXapbS1SpMgOZMG2MCr54pbClviy+CuvVBP4Q
8LSN9mLl3DFqa0vLHVrRrmOJNjRN4UUdQ4XFewkgjLvEJTNGiv4XlA==
=Hbr4
-----END PGP SIGNATURE-----