Thank you all for your advices.
However, I am stubborn and I want to do it with userdb file.
I managed to solve it today... like this:
local_parts =
${lookup{$local_part@$domain}lsearch{/etc/courier/userdb}{$local_part}{}}
This was added in the local_user router.
It works.
Regards,
Marco
W B Hacker wrote:
> 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
>
>
>
>
--
Marco Meinardi <m.meinardi@???>
ReteItaly S.r.l.
www.reteitaly.com
_____________________________________________
C.so Svizzera, 185 - 10149 Torino - Italy
Tel. +39 011 7767694 - Mobile +39 335 7878604
Fax +39 011 746179
_____________________________________________
