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

Re: Creating exceptions to greylisting

Expand Messages
  • Stan Hoeppner
    ... That s awfully difficult to read. Try putting each on its own line as in the examples we ve given you. Also, put everything under
    Message 1 of 13 , Feb 2, 2013
      On 2/2/2013 1:55 PM, Gerben Wierda wrote:
      > 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.
      >
      > For now, I came up with:
      >
      > smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/whitelist_mtaclientdomains reject_rbl_client zen.spamhaus.org permit
      > smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_client_access hash:/etc/postfix/whitelist_mtaclientdomains check_policy_service unix:private/policy permit

      That's awfully difficult to read. Try putting each on its own line as
      in the examples we've given you. Also, put everything under

      smtpd_recipient_restrictions

      and eliminate smtpd_client_restrictions altogether. Now you no longer
      have to duplicate restrictions between them. More importantly, you have
      fine grained control over evaluation order. Thus, this would be much
      better:

      smtpd_recipient_restrictions =
      permit_mynetworks
      permit_sasl_authenticated
      reject_unauth_destination
      check_client_access pcre:/etc/postfix/client_access
      check_sender_access pcre:/etc/postfix/sender_access
      reject_rbl_client zen.spamhaus.org
      check_policy_service unix:private/policy
      ...

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

      /etc/postfix/sender_access
      /.*@apg\.nl$/ permit
      ...

      > Which makes sure some clients are permitted before they end up in either RBL or Policy. Just for you more experienced people: is this OK?

      When using separate client and recipient restrictions, as you have
      above, your rbl check against Zen can trigger before your whitelist
      checks, causing a rejection. Using the method I've detailed above
      avoids this situation. Because Postfix performs delayed rejection by
      default, you can put all of your restrictions under
      smtpd_recipient_restrictions and carefully control the order of
      restriction evaluations. I'd guess that every experienced OP on this
      list does it this way. It just doesn't make any sense to do otherwise.

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

      I have zero experience with MacOS. Sorry.

      --
      Stan
    • 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 2 of 13 , Feb 2, 2013
        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 3 of 13 , Feb 2, 2013
          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 4 of 13 , Feb 3, 2013
            --> 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.