Automatically inferring %d on multi-domain virtual install ?

[Timo Sirainen]

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-----