[Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP

DaLiV at apollo.lv DaLiV at apollo.lv
Wed Feb 9 12:02:32 EET 2011


Timo Sirainen wrote:
> On 9.2.2011, at 9.37, DaLiV at apollo.lv wrote:
>
>    
>> existing version 1 config file, that allow such configuration:
>> -------- /etc/dovecot.conf BEGIN ----------------
>> server mail.domain1.tld {
>>      
> I'm surprised that this server block really worked for you. I only remember having problems with it, and that's why its existence is well hidden.
it's worked flawlessy for many years : firstly redhat distros, later all 
fedora versions. But in latest fedora distro are included v2.x branch ...
>   In v2.0 the idea is anyway that you could do:
>
> local mail.domain1.tld {
>    ..
> }
> local mail.domain2.tld {
>    ..
> }
>
> But this unfortunately doesn't currently work for auth settings.
i've seen - auth from many databases possible - but all in one block, 
... as solution can create 2 variables that may be passed to auth process :
- 1 = local ip address , to which was connected client
- 2 = resolved ip address from 1
that variables must be possible to use in auth database "include file" 
definition similar to :
!include auth-ldap.conf.%IP
or
!include auth-ldap.conf.%IP_Resolved

_- another way _(possible that will be more easiest, and good enough for 
advanced configurations)  = single variable that may be set in block of 
exact ip listener configuration , as for provided before example may set 
variable "auth_db_suffix" = string("dc=domain1,dc=tld") for definition 
"local mail.domain1.tld" and that variable are inserted in auth block 
via variable inserting mechanism ...

>   I'll get around to doing it at some point.. There is actually probably one horribly ugly way to make this already work, but it's so bad I don't really even want to suggest it (involving creating duplicate service blocks for different IPs and chrooting their processes to different dirs)..
>    
that way (multiple instances of dovecot with full copy of all 
configuration files) i was doing, but not liked, so on each update of 
distro currently i'm recompiling and reinstalling 1.x version on all 
mine controlled servers (ppc+x86+x64) ...


More information about the dovecot mailing list