Re: [exim] exim4 and courier userdb

Página Inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
Para: exim users
Assunto: Re: [exim] exim4 and courier userdb
Marco Meinardi wrote:

> Hi all,
>
> I'm trying to set up exim4 with courier imap integration.
> I'm not going to use local users (I mean not those contained in
> /etc/passwd) but I want to use /etc/courier/userdb database file.
> Of course my mail server will be multi-domain.
>
> For example in /etc/courier/userdb I have the entry:
> name.surname    imappw=asdfhskdjgfkfgghfg-etc-etc...

>
> And in my local_user router I have the entry:
> local_parts = lsearch;/etc/courier/userdb
>
> This works fine, it gets matched and delivered.
> Unfortunately, my imap user should contain also the domain, otherwise 
> the same username can't be used for more than one domain.
> So if I change my userdb file as follows:
> name.surname@domain    imappw=asdfhskdjgfkfgghfg-etc-etc...

>
> The lsearch fails.
> If I modify the lsearch like this:
> local_parts = partial(@)lsearch;/etc/courier/userdb
>
> Then I see that it tries to match name.surname or @name.surname, but it
> never tries name.surname@!
>
> So is there any way I can solve this? I need to make a partial check
> adding a wildcard AFTER the @ and not before!
> I know there are wildlsearch and nwildlsearch, but I didn't understand
> how to make use of the wildcards.
>
> Anybody can help me?
> Thanks a lot in advance!!
>


We did run a similar exim+courier-imap/pop test-bed for a time
several years ago.

After experimenting with various auth methods, we found it
easiest (not necessarily most efficient or robust) to use
PostgreSQL to provide UID:GID and storage location settings to
both Exim and Courier (and other combinations under test).

IIRC, your experience mirrors ours in that what we 'needed most'
was the ability to select <realfieldname> *as* <variable name
courier wanted> and in the sequence/order/position expected,
*and* modify the string as part of the process (insert or skip
'@' and split or concatenate fields, for example).

Courier can be a bit bloody-minded about all that.

At the end of the day, we moved to Exim+Dovecot-imap/pop for
production, as Dovecot needed only two lines of SQL, one for
auth, the other for storage, bore a closer 'resemblance' to the
acess method and format Exim needed, (almost cut 'n paste) hence
was *way* simpler to install and admin as a 'team'.

Anything one can do with SQL can also be done with any other
data store, but you will probably have to do more string
manipulation, qualification, etc. - more importantly - use more
different method/styles/types - 'languages', even, for that
manipulation, and in more places than one.

Dovecot was dirt-simple, Courier more 'challenging'.

HTH,

Bill