On Thu, 27 Jan 2005, Zenon Panoussis wrote:
Sam Varshavchik wrote:
I just remembered that there's an LDAP_DEREF setting in authldaprc that
blabbers something about aliases. This is something completely different.
I plead guilty, I hadn't checked it. But it's not that. It was set
'never' before the upgrade and it was still 'never' after. Changing
it to all other possible values doesn't help. With
objectClass: top
objectClass: CourierMailAlias
objectClass: account
mail: dumm...@provocation.net
maildrop: dumm...@provocation.net
uid: dummy30
objectClass: top
objectClass: CourierMailAlias
objectClass: account
mail: dumm...@provocation.net
maildrop: ora...@provocation.net
uid: dummy29
objectClass: top
objectClass: CourierMailAccount
objectClass: account
uid: oracle
mail: ora...@provocation.net
uidNumber: 2018
gidNumber: 2018
homeDirectory: /somewhere
userPassword:: [lotsagarbage]
and 'LDAP_DEREF always', sending mail to dumm...@provocation.net
results in
authdaemond: authldaplib: refuse to authenticate dumm...@provocation.net:
uid=0, gid=0 (zero uid or gid not permitted)
courieresmtpd:
error,relay=2001:470:1f00:186:211:2fff:fed7:8bf8,from=<ora...@provocation.net>,to=<dumm...@provocation.net>:
450 Service temporarily unavailable.
I can only guess that on the second pass it looks for uidNumber and
gidNumber, assumes 0 when neither is found, and therefore runs against
the root issue. openldap is 2.0.27-17, mail to dumm...@provocation.net
is delivered correctly.
Didn't someone submit a LDAP patch to the list to have courier search for
additional aliases!?
Larry.