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

Re: Creating exceptions to greylisting

Expand Messages
  • Viktor Dukhovni
    ... This is not robust for two reasons, the first is a simple oversight, replace: /.*facebook .com$/ permit with / .facebook .com$/ permit since
    Message 1 of 13 , Feb 2, 2013
    • 0 Attachment
      On Sat, Feb 02, 2013 at 03:34:30PM -0600, Stan Hoeppner wrote:

      > check_client_access pcre:/etc/postfix/client_access
      > ...
      >
      > /etc/postfix/client_access:
      > /.*facebook\.com$/ permit

      This is not robust for two reasons, the first is a simple oversight,
      replace:

      /.*facebook\.com$/ permit

      with

      /\.facebook\.com$/ permit

      since "notfacebook.com" is not "facebook.com" and any SMTP client
      in the real facebook.com domain would be a proper sub-domain.

      The second issue is not easy to fix, transient DNS lookup errors
      (timeouts, ...) may result in a client hostname of "unknown" rather
      than <mumble>.facebook.com. In such cases the whitelist entry will
      not apply. Generally this is a problem as messages may be erroneously
      rejected due to a transient error. In this case, provided the whitelist
      entry is solely to avoid greylisting, this is OK, since greylisting
      is responds with temporary (4XX) error codes.

      --
      Viktor.
    • Stan Hoeppner
      ... It wasn t intended to be robust Viktor, but quite the opposite. ... I guess you missed what came directly after that... ... Sometimes, when a kid asks for
      Message 2 of 13 , Feb 2, 2013
      • 0 Attachment
        On 2/2/2013 3:50 PM, Viktor Dukhovni wrote:
        > On Sat, Feb 02, 2013 at 03:34:30PM -0600, Stan Hoeppner wrote:
        >
        >> check_client_access pcre:/etc/postfix/client_access
        >> ...
        >>
        >> /etc/postfix/client_access:
        >> /.*facebook\.com$/ permit
        >
        > This is not robust for two reasons, the first is a simple oversight,
        > replace:

        It wasn't intended to be robust Viktor, but quite the opposite.

        > /.*facebook\.com$/ permit
        >
        > with
        >
        > /\.facebook\.com$/ permit
        >
        > since "notfacebook.com" is not "facebook.com" and any SMTP client
        > in the real facebook.com domain would be a proper sub-domain.

        I guess you missed what came directly after that...

        On 2/2/2013 3:08 PM, Stan Hoeppner wrote:
        > You may want to be more specific. I made my example very generic as
        > your expression above seems to miss some of their outbound host rdns,
        > such as: outappmail004.snc4.facebook.com

        Sometimes, when a kid asks for an apple, it's better to give him a
        rotten one, so as to teach him to pick his own fresh apples from the
        tree. I.e. I gave him a rotten example of a regex hoping/assuming he'd
        do some legwork and create his own set of fully qualified expressions to
        meet his needs.

        --
        Stan
      • James Griffin
        ... Sure, I can understand that. ... No, Macports does not overwrite what Apple has installed and yes, it does use its own separate filesystem as Fink does;
        Message 3 of 13 , Feb 3, 2013
        • 0 Attachment
          --> Gerben Wierda <gerben.wierda@...> [2013-02-02 20:55:42 +0100]:

          > Just so there is no misunderstanding: I am unhappy running an
          > older version that is not updated with security fixes anymore and
          > I had planned to upgrade before now (but not immediately when 10.8
          > came out as 10.8.0 Server was not what you say trustworthy. I skipped
          > 10.7 server altogether because it is a disaster area. I plan
          > to upgrade asap to 10.8 server.

          Sure, I can understand that.

          > Does macports overwrite what Apple has provided or does it have
          > ts own separate tree (like fink used to have, which means you get
          > another job that is: keeping the second tree up to date)?

          No, Macports does not overwrite what Apple has installed and yes,
          it does use its own separate filesystem as Fink does; it's under
          /opt/local. However, they do specify that have programs installed
          in /usr/local (i.e. manually installed or otherwise) causes issues
          when using Macports. Totally OT, sorry about that.

          It does provide you a way of keeping installed programs up-to-date
          which is why I suggested it. You simply use launctl/Launchd to
          select which MTA you use; i.e. the Macports installed version or
          the Apple preinstalled version.
        Your message has been successfully submitted and would be delivered to recipients shortly.