Am 2012-09-14 17:24, schrieb Wietse Venema:
Michael Storz:
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.
Except that this returns false rejects with for example address
extensions. Postfix looks up user+extension@domain before looking
up user@domain.
Wietse
Hi Wietse,
thanks for reminding me about the iterative nature of access map lookup
commands.
Since it makes no sense to specify a default for a single table lookup
a solution
could be to implement an implicit default to the access map lookup
commands. Similar
to a transport lookup, which uses '*' at the end to lookup a default,
one could modify
the algorithm for an access map lookup to use a default key at the end
of the lookup.
Instead of '*' the key could depend on the name of the query table or
the config file,
for example
default_access_map_mail_address_lookup_key = default_mail_%n
default_access_map_domain_lookup_key = default_dom_%n
default_access_map_network_address_lookup_key = default_ip_%n
where %n is replaced by the name of the table or config file. However
this solution
has some drawbacks like having two defaults for mail address lookups or
having to
define an explicit action return value for every object with ldap or
sql.
Instead of defining an implicit default one could implement the
possibility to define
an explicit default for a lookup command with the help of a user
defined restriction
class and the new action
LAST [label]
where label would be the name of a restriction class. The semantic of
LAST would be
similar to OK. If encountered, LAST would jump over all remaining
restrictions to the
end of the actual restriction class (no label given) or to the end of
the named
restriction class (with label given). When leaving the restriction LAST
would be
changed to DUNNO.
This would allow to augment every reject-restriction with one or more
whitelists based
on every available table type and it allows to define your own
reject-restriction commands:
Example revisited:
/etc/postfix/main.cf:
smtpd_restriction_classes =
rc_check_exchange_sans_forward
reject_inconsistent_recipient_data
rc_check_exchange_sans_forward =
# OK/LAST wenn Empfaenger im AD/Exchange korrekt
check_recipient_access
proxy:ldap:/etc/postfix/check_exchange_user_sans_forward.ldap
# REJECT aller anderen
REJECT
reject_inconsistent_recipient_data =
check_recipient_access
proxy:ldap:/etc/postfix/check_openldap_user_sans_forward.ldap
check_recipient_access
proxy:ldap:/etc/postfix/check_openldap_user_with_forward.ldap
...
smtpd_recipient_restrictions =
...
reject_inconsistent_recipient_data
...
/etc/postfix/check_openldap_user_sans_forward.ldap
...
query_filter =
(&(mwnEmail=%s)(mwnMailStatus=mailbox,active)(mwnMailMessageStore=exchange)(!(mwnMailWeiterleitung=*)))
result_attribute = mwnMailMessageStore
result_format = rc_check_exchange_sans_forward
/etc/postfix/check_exchange_user_sans_forward.ldap
...
query_filter =
(&(proxyAddresses=smtp:%s)(|(&(objectClass=user)(homeMDB=*)(homeMTA=*)(!(altRecipient=*))(!(deliverAndRedirect=TRUE)))(&(objectClass=group)(member=*))))
result_attribute = cn
result_format = LAST reject_inconsistent_recipient_data
...
Would implementing the LAST action make sense or did I overlook
something?
Michael
