Loading ...
Sorry, an error occurred while loading the content.
 

Re: Feature request: new parameter no_result_format for ldap and sql maps

Expand Messages
  • Michael Storz
    ... The installed base really does not matter. E.g. none of the about 10.000 nodes on our supercoputer each with a Postfix installation will ever benefit from
    Message 1 of 13 , Sep 27, 2012
      Am 2012-09-24 19:06, schrieb Wietse Venema:
      > Michael Storz:
      >> seems I was
      >> not able to show the underlying problem, let me rephrase my problem:
      >>
      >> How can I configure arbitrarily complex if-then-else
      >> constructs
      >> for every possible table type?
      >
      > You will have to outsource that logic with tcp_table lookups.
      >
      > Considering that if-then-else table search is useful for maybe
      > 0.0001% of the installed base, I don't think it makes no sense to
      > spend significant of development resources on it now, and to spend
      > maintenance resources on it for eternity. There is a lot that needs
      > to be done and that benefits most of the installed base.
      >
      > Yes, I suppose that it's possible to emulate conditional processing
      > with magical query keys and magical lookup results. No, I don't
      > think that restriction_classes is an example that deserves expansion.
      >
      > References:
      > http://www.postfix.org/tcp_table.5.html
      >
      > Wietse

      The installed base really does not matter. E.g. none of the about
      10.000 nodes
      on our supercoputer each with a Postfix installation will ever benefit
      from the
      work you did the last years because there is only a null mailer
      installed and
      thats similar for nearly all installations of Postfix.

      New features are only of interest for the mail server of a whole site.
      Building
      there own reject-restriction is of interest for more sites than you
      think. Just
      two examples from the archives:

      In http://archives.neohapsis.com/archives/postfix/2010-02/0333.html
      the user wanted to have the following reject-restriction

      if (is_from_mynetwork AND is_sasl_authenticated) {
      DUNNO
      } else {
      REJECT
      }

      which is aequivalent to

      if (is_from_mynetwork) {
      DUNNO
      } else {
      REJECT
      }
      if (is_sasl_authenticated) {
      DUNNO
      } else {
      REJECT
      }

      Noel Jones solution uses the approach I suggested to implement the two
      if-then-else constructs:

      2 restriction classes with a jump-to-the-end-of-restriction-class
      action.

      In http://archives.neohapsis.com/archives/postfix/2010-12/0981.html
      Vi[ck]tor Duchovni made a very nice transformation of the requirement

      if (allowed-clients || (allowed-senders AND allowed-recipients)) {
      DUNNO
      } else {
      DISCARD
      }

      to

      if (allowed-senders) {
      DUNNO
      } else {
      if (allowed-clients) {
      DUNNO
      } else {
      DISCARD
      }
      }
      if (allowed-recipients) {
      DUNNO
      } else {
      if (allowed-clients) {
      DUNNO
      } else {
      DISCARD
      }
      }

      and implemented the inner if-then-else construct with a cidr-table
      using the
      default value for the else and again -- like Noel -- implementing the
      outer
      if-then-else with restriction classes and jump action.

      However, since they could not use a user-defined restriction class
      because of
      the missing jump action for this kind of class they had to use system
      defined
      restriction classes and OK as the jump action. This has the drawback
      that only
      this reject-restriction can be implemented and no other restriction
      because
      that would be over-jumped by OK whereas this would not be a problem
      with my
      expansion.

      Therefore I think my approach fits very well in the architecture of
      Postfix and
      the actual usage.

      The main advantage and usage case of this expansion would not be the
      user
      defined reject-restrictions but the possibility to have a whitelist for
      every
      single system-defined reject-restriction without jumping over the rest
      of the
      restrictions. his is a wish many admins have.

      How often you can read

      put the check_mumble_restriction AFTER
      reject_unauth_destination,
      otherwise you could become an open relay.

      on the list? The reason is the jump characteristic of OK. If people
      have a
      configuration

      smtpd_client_restrictions =
      check_client_access whitelist
      reject_mumble_client_restriction
      smtpd_helo_restrictions =
      check_helo_access whitelist
      reject_mumble_helo_restriction
      smtpd_sender_restrictions =
      check_sender_access whitelist
      reject_mumble_sender_restriction
      smtpd_recipient_restrictions =
      reject_unauth_destination

      everything works fine. But if they move all the restrictions to
      smtpd_recipient_restrictions then suddenly they become an open relay
      because
      the semantic has CHANGED:

      smtpd_recipient_restrictions =
      check_client_access whitelist
      reject_mumble_client_restriction
      check_helo_access whitelist
      reject_mumble_helo_restriction
      check_sender_access whitelist
      reject_mumble_sender_restriction
      reject_unauth_destination

      This would not be the case with my proposed expansion. They could move
      their
      restrictions around like they want without a semantic change.

      Now I have to discuss with my team what will cost us more: living with
      our
      workarounds of this deficiency of Postfix, writing our own policy
      daemon
      (could be expensive to implement because of all the ldap queries) or
      patching
      Postfix ourself. As far as I can see from the internals of
      smtpd_check.c the
      LAST action should be very easy to implement.

      Thanks for the discussion and your time. I have learned a lot about how
      Postfix
      implements its checks while preparing my posts.

      Michael
    Your message has been successfully submitted and would be delivered to recipients shortly.