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

Re: Snapshot 20130517

Expand Messages
  • /dev/rob0
    Still watching logs, this one just passed by. Probably unrelated to the changes in 20130517, but I was curious about it: May 19 13:24:20 harrier
    Message 1 of 25 , May 19, 2013
    • 0 Attachment
      Still watching logs, this one just passed by. Probably unrelated to
      the changes in 20130517, but I was curious about it:

      May 19 13:24:20 harrier postfix/postscreen[3533]: CONNECT from [188.42.15.19]:48706 to [207.223.116.211]:25
      May 19 13:24:26 harrier postfix/postscreen[3533]: NOQUEUE: reject: RCPT from [188.42.15.19]:48706: 450 4.3.2 Service currently unavailable; from=<bounce@...>, to=<munged@...>, proto=ESMTP, helo=<mail18.consumer-news123.com>
      May 19 13:24:26 harrier postfix/postscreen[3533]: PASS NEW [188.42.15.19]:48706
      May 19 13:24:26 harrier postfix/postscreen[3533]: DISCONNECT [188.42.15.19]:48706

      All is well and good for a non-whitelisted host, but apparently it
      was too quick in coming back to the secondary MX IP address ...

      May 19 13:24:26 harrier postfix/postscreen[3533]: CONNECT from [188.42.15.9]:33610 to [207.223.116.214]:25
      May 19 13:24:26 harrier postfix/postscreen[3533]: WHITELIST VETO [188.42.15.9]:33610

      ... all in the same second, but according to syslog, sequentially
      after having earned whitelist status.

      May 19 13:24:32 harrier postfix/postscreen[3533]: NOQUEUE: reject: RCPT from [188.42.15.9]:33610: 450 4.3.2 Service currently unavailable; from=<bounce@...>, to=<munged@...>, proto=ESMTP, helo=<mail8.consumer-news123.com>
      May 19 13:24:32 harrier postfix/postscreen[3533]: DISCONNECT [188.42.15.9]:33610

      Another six seconds pass before this one is turned away, which
      suggests that the greet pause was repeated. Makes sense, because
      "WHITELIST VETO" means it was not seen before.
      --
      http://rob0.nodns4.us/ -- system administration and consulting
      Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
    • Wietse Venema
      ... postscreen does not find the client IP address in the permanent postscreen_access_list, does not find client the IP address in the temporary
      Message 2 of 25 , May 19, 2013
      • 0 Attachment
        /dev/rob0:
        > Still watching logs, this one just passed by. Probably unrelated to
        > the changes in 20130517, but I was curious about it:
        >
        > May 19 13:24:20 harrier postfix/postscreen[3533]: CONNECT from [188.42.15.19]:48706 to [207.223.116.211]:25
        > May 19 13:24:26 harrier postfix/postscreen[3533]: NOQUEUE: reject: RCPT from [188.42.15.19]:48706: 450 4.3.2 Service currently unavailable; from=<bounce@...>, to=<munged@...>, proto=ESMTP, helo=<mail18.consumer-news123.com>
        > May 19 13:24:26 harrier postfix/postscreen[3533]: PASS NEW [188.42.15.19]:48706
        > May 19 13:24:26 harrier postfix/postscreen[3533]: DISCONNECT [188.42.15.19]:48706

        postscreen does not find the client IP address in the permanent
        postscreen_access_list, does not find client the IP address in the
        temporary postscreen_cache_map, logs the "all tests passed" status,
        updates the temporary postscreen_cache_map with the expiration time
        for each test, and forgets the test results.

        > All is well and good for a non-whitelisted host, but apparently it
        > was too quick in coming back to the secondary MX IP address ...
        >
        > May 19 13:24:26 harrier postfix/postscreen[3533]: CONNECT from [188.42.15.9]:33610 to [207.223.116.214]:25
        > May 19 13:24:26 harrier postfix/postscreen[3533]: WHITELIST VETO [188.42.15.9]:33610
        >
        > ... all in the same second, but according to syslog, sequentially
        > after having earned whitelist status.

        postscreen logs "CONNECT from", does not find the client IP address
        in the permanent postscreen_access_list, and does not find the
        client IP address in the temporary postscreen_cache_map. Therefore
        this is handled as a non-whitelisted client that connects to the
        "wrong" IP address.

        Why wasn't the client IP address found in the temporary
        postscreen_cache_map? Maybe silent corruption of the cache database.

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