Problem:
========
Because of a very slow provisioning driver for exchange - creating a
user needs several seconds - the data in our OpenLDAP and the
Exchange/Active Directory are often out of sync, especially when
creating accounts for new students at the beginning of a semester. To
let the new 'Welcome Message' wait instead of bouncing, we check if the
data in both directories is consistent via check_recipient_access and
two LDAP queries.
If the account is in OpenLDAP
- and in Exchange then the result of the check should be DUNNO to
evaluate the next restrictions.
- is not in Exchange then the result should be a temporary reject.
Unfortunately this seems not to be possible because the ldap query only
gives back an action if sonething is found and not if something is NOT
found.
I then tried to put the second LDAP-query into a restriction class:
rc_check_exchange_sans_forward =
# OK wenn Empfaenger im AD/Exchange korrekt
check_recipient_access
proxy:ldap:/lrz/common/postfix/check_exchange_user_sans_forward_ads.ldap
# DEFER aller anderen
check_recipient_access
pcre:/lrz/common/postfix/check_exchange_user_defer.pcre
check_exchange_user_defer.pcre
# Catchall
/./ 450 User not yet available in Exchange
It works, but then all further restrictions are not evaluated.Therfore
we use an extra Postfix instance just for this check which is a little
bit of an overkill.
Solution:
=========
If a new parameter no_result_format would exist, we could define the
ldap procedure with
result_format = DUNNO
no_result_format = 450 User not yet available in Exchange
which is very straightforward and understandable.
The semantics of no_result_format would be very similar to
result_format. With LDAP_SUCCESS and no results this new parameter would
be used as the result. Because there is no result value from the
LDAP-query the lower-case, upper-case and decimal digit expansions would
use the input key.
Does this make sense?
Thanks,
Michael Storz
