Michael Storz:
> The consistency check requires that a user object is first (correctly) 
> defined in OpenLDAP. Only then the second check looks for the correct 
> definition in Active Directory. If it is not then we defer the email (we 
...
> If a new user is created the user object appears instantly in the 
> OpenLDAP directory. [...]
> Therefore if the user/address is not in the OpenLDAP directory I can 
> sa[f]ely reject such an address.

So it is an inconsistency between LDAP and Active Directory, such
that the user exists in LDAP but not yet in Active Directory.

It's almost like different organizations being responsible for
different parts of the infrastructure. Hm.

We can attack this in a number of ways.  

- You want to return "450 User not yet available" when the query
  returns NOTFOUND. This could be as simple as exploiting the linear
  search order of smtpd_mumble_restrictions:

    smtp_mumble_restrictions =
        ...
        # Query AD first.
        check_something_access ldap:the-AD-table
        # Not found in AD, return a generic error.
        check_something_access pcre:/etc/postfix/mumble_default

    /etc/postfix/mumble_default
        /./ 450 User not yet available

- Introduce special lookup keys for each table-driven feature
  (access, transport_maps, canonical, etc.). The "*" in transports
  is a particularly ugly example. If it would be done in a more
  general manner (see examples below), then I would not have to
  maintain special code that works only for one feature.

- Introduce new table syntax for multi-table features:

    local_recipient_maps = 
        ldap:the-AD-table
        notfound=tempfail:

  Where tempfail is a map that always fails all queries with a
  temporary error.

  This requires changing all code that queries multiple maps, so
  that it makes an extra call to pick up the "notfound" result.
  That's pretty straightforward, as long as we resist the temptation
  to extend "notfound" and make it into a programming language.

- Finer control over multi-table iteration.  If there were a way
  to make Postfix do all the queries on the first map before it
  queries the second map, and so on, then that could also solve the
  problem.

It seems that your problem is not with the multi-table features,
so the linear smtpd_mumble_restrictions search order should take
care of things.

        Wietse

Reply via email to