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

Problem understanding check_client_access and tcp_table

Expand Messages
  • uffe
    Hello, Subject: Problem understanding check_client_access and tcp_table I have a problem understanding how to properly use check_client_access with an external
    Message 1 of 6 , Jun 10, 2014
      Hello,

      Subject: Problem understanding check_client_access and tcp_table

      I have a problem understanding how to properly use check_client_access with
      an external tcp_table (daemon)

      in my main.cf i have put the following:

      smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:11111

      The lookup process itself works - but I was under the impression that my
      tcp_table "daemon" would receive a "get " lookup requests with the source ip
      address as argument...

      What I am receiving is lots of lookup "get" requests with argument "unknown"
      and nothing else.

      My guess is that the "unknown" string represents unresolvable reverse
      lookups - because I'm testing with loopback 127.0.0.x addresses

      But what I was expecting was to receive lookup "get" requests with the raw
      source ip address as argument - as "unknown" is not of much use for spam
      analysis.

      Did I misunderstand the check_client_access ?

      How do I get the raw source ip address to my tcp_table lookup "daemon" ?

      I'm using Postfix 2.11.1 on FreeBSD 10

      Thanks in advance

      Kind regards Uffe







      --
      View this message in context: http://postfix.1071664.n5.nabble.com/Problem-understanding-check-client-access-and-tcp-table-tp68481.html
      Sent from the Postfix Users mailing list archive at Nabble.com.
    • Noel Jones
      ... check_client_access will test the hostname first, then if not found, the IP address. This behavior is independent of table lookup type. So your tcp table
      Message 2 of 6 , Jun 10, 2014
        On 6/10/2014 2:59 PM, uffe wrote:
        > Hello,
        >
        > Subject: Problem understanding check_client_access and tcp_table
        >
        > I have a problem understanding how to properly use check_client_access with
        > an external tcp_table (daemon)
        >
        > in my main.cf i have put the following:
        >
        > smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:11111
        >
        > The lookup process itself works - but I was under the impression that my
        > tcp_table "daemon" would receive a "get " lookup requests with the source ip
        > address as argument...
        >
        > What I am receiving is lots of lookup "get" requests with argument "unknown"
        > and nothing else.
        >
        > My guess is that the "unknown" string represents unresolvable reverse
        > lookups - because I'm testing with loopback 127.0.0.x addresses
        >
        > But what I was expecting was to receive lookup "get" requests with the raw
        > source ip address as argument - as "unknown" is not of much use for spam
        > analysis.
        >
        > Did I misunderstand the check_client_access ?
        >
        > How do I get the raw source ip address to my tcp_table lookup "daemon" ?
        >
        > I'm using Postfix 2.11.1 on FreeBSD 10
        >
        > Thanks in advance
        >
        > Kind regards Uffe


        check_client_access will test the hostname first, then if not found,
        the IP address. This behavior is independent of table lookup type.

        So your tcp table will need to respond to all hostname queries with
        500 Not Found
        followed by a newline. This will allow the IP query to happen.



        -- Noel Jones
      • Wietse Venema
        ... There will be no get client-address query when the get client-name answer is reject , defer , permit , ok , or something else that terminates the
        Message 3 of 6 , Jun 10, 2014
          uffe:
          > smtpd_client_restrictions = check_client_access tcp:[127.0.0.1]:11111
          >
          > But what I was expecting was to receive lookup "get" requests with the raw
          > source ip address as argument - as "unknown" is not of much use for spam
          > analysis.

          There will be no "get client-address" query when the "get client-name"
          answer is "reject", "defer", "permit", "ok", or something else that
          terminates the search.

          Wietse
        • uffe
          Thanks for your swift answers I ll try the recommendations immediately. English is not my native language - but it did not occour to me from reading that
          Message 4 of 6 , Jun 10, 2014
            Thanks for your swift answers

            I'll try the recommendations immediately.

            English is not my native language - but it did not occour to me from reading
            that documentation for tcp_table lookups that returning 500 would be
            aproprialte - I would have believed that is would have stopped the while
            delivery "transaction". Rereading the docs as we speak makes it more clear -
            thx




            --
            View this message in context: http://postfix.1071664.n5.nabble.com/Problem-understanding-check-client-access-and-tcp-table-tp68481p68487.html
            Sent from the Postfix Users mailing list archive at Nabble.com.
          • uffe
            Now I got it working - thanks Are tcp_table lookup deamon instances supposed to exit themselves - for every lookup - or can postfix reuse them persistent
            Message 5 of 6 , Jun 10, 2014
              Now I got it working - thanks

              Are tcp_table lookup "deamon" instances supposed to exit themselves - for
              every lookup - or can postfix reuse them "persistent"

              I'm having a hard time understanding the comment in the bugs section: The
              client does not hang up when the connection is idle for a long time
              (http://www.postfix.org/tcp_table.5.html)

              My tcp_table lookup "deamon" is currently running under daemontools (max
              concurrent 10 instances) and postfix seems to keep them hanging around - but
              sometimes it seems that the system gets stuck
              I'm going through my own code - but havent found anything yet - hence my
              question

              /Uffe




              --
              View this message in context: http://postfix.1071664.n5.nabble.com/Problem-understanding-check-client-access-and-tcp-table-tp68481p68490.html
              Sent from the Postfix Users mailing list archive at Nabble.com.
            • Noel Jones
              ... The tcp daemon should probably exit when the postfix client disconnects. This will happen periodically as postfix retires and recreates new smtpd
              Message 6 of 6 , Jun 10, 2014
                On 6/10/2014 6:32 PM, uffe wrote:
                >
                > Now I got it working - thanks
                >
                > Are tcp_table lookup "deamon" instances supposed to exit themselves - for
                > every lookup - or can postfix reuse them "persistent"
                >
                > I'm having a hard time understanding the comment in the bugs section: The
                > client does not hang up when the connection is idle for a long time
                > (http://www.postfix.org/tcp_table.5.html)
                >
                > My tcp_table lookup "deamon" is currently running under daemontools (max
                > concurrent 10 instances) and postfix seems to keep them hanging around - but
                > sometimes it seems that the system gets stuck
                > I'm going through my own code - but havent found anything yet - hence my
                > question
                >
                > /Uffe

                The tcp daemon should probably exit when the postfix client
                disconnects. This will happen periodically as postfix retires and
                recreates new smtpd processes.

                The max connections will need to be at least $default_process_limit
                (default 100). Each smtpd process will create its own connection to
                your table. I suppose you could use proxy:tcp: to limit the number
                of connections.


                -- Noel Jones
              Your message has been successfully submitted and would be delivered to recipients shortly.