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

Re: postscreen questions

Expand Messages
  • Noel Jones
    ... No, not needed. But some folks like to leave them in anyway because 1) they re free if the DNS response is currently cached and 2) postscreen internally
    Message 1 of 23 , May 22, 2013
    • 0 Attachment
      On 5/22/2013 8:41 AM, Deeztek Support wrote:
      > I'm trying out postscreen and I have a couple of questions. First
      > off, here's my postscreen setup:
      >
      > postscreen_access_list = permit_mynetworks
      > postscreen_blacklist_action = enforce
      > postscreen_dnsbl_action = enforce
      > postscreen_greet_action = enforce
      > postscreen_dnsbl_sites = zen.spamhaus.org*3
      > b.barracudacentral.org*2
      > bl.spameatingmonkey.net*2
      > dnsbl.ahbl.org*2
      > bl.spamcop.net
      > dnsbl.sorbs.net
      > psbl.surriel.com
      > bl.mailspike.net
      > swl.spamhaus.org*-4
      > list.dnswl.org=127.[0..255].[0..255].0*-2
      > list.dnswl.org=127.[0..255].[0..255].1*-3
      > list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
      > postscreen_dnsbl_threshold = 3
      > postscreen_pipelining_enable = yes
      > postscreen_non_smtp_command_enable = yes
      > postscreen_bare_newline_action = enforce
      > postscreen_bare_newline_enable = yes
      >
      > so, the RBLs are getting utilized by postscreen before it even hits
      > the smtp service. So, am I right to assume that the
      > reject_rbl_client lines in my smtpd_recipient_restrictions are no
      > longer needed?

      No, not needed. But some folks like to leave them in anyway because
      1) they're "free" if the DNS response is currently cached and 2)
      postscreen internally caches "PASS" status, possibly after a bad
      client is newly listed in an rbl.


      >
      > Additionally, in my smtpd_recipient_restrictions I have a
      > check_client_access line that points to a list of rbl_override email
      > addresses so that I can receive e-mail from someone even if they are
      > sending e-mail from an IP that's listed on an RBL. I can't seem to
      > find any reference on how to accomplish this with postscreen. Is
      > that even possible or are we relying on the RBL scoring system for
      > postscreen?

      (I'm wondering why a check_client_access map points to a list of
      email addresses, but maybe you misspoke)

      There is no conditional whitelisting available in postscreen. Only
      use highly trusted (by *YOU*) RBLs in postscreen, or use scoring so
      that multiple listing are required for rejection.

      Secondly, remember postscreen is intended as a quick-and-simple
      zombie killer, its only purpose is to reduce the workload on the
      more complex filters further downstream.



      -- Noel Jones
    • Bill Cole
      ... And 3) there are more fine-tuned configurations available via the core Postfix settings to handle cases where you can tolerate false positive hits for
      Message 2 of 23 , May 22, 2013
      • 0 Attachment
        On 22 May 2013, at 11:02, Noel Jones wrote:

        > so, the RBLs are getting utilized by postscreen before it even hits
        >> the smtp service. So, am I right to assume that the
        >> reject_rbl_client lines in my smtpd_recipient_restrictions are no
        >> longer needed?
        >
        >
        > No, not needed. But some folks like to leave them in anyway because
        > 1) they're "free" if the DNS response is currently cached and 2)
        > postscreen internally caches "PASS" status, possibly after a bad
        > client is newly listed in an rbl.

        And 3) there are more fine-tuned configurations available via the core
        Postfix settings to handle cases where you can tolerate "false positive"
        hits for some addresses but not others. For example: my own system
        serving family and friends has a handful of older addresses whose
        history has left them with massive spam loads, but the overwhelming
        volume of its legitimate mail is aimed at other addresses using a couple
        of different "tagging" patterns that are aliases for those legacy
        addresses. Because the tagged addresses are shared in narrower ways,
        they rarely get spam of any sort and are easily burned when they do. I
        use DNSBLs that can be overaggressive which alone each fall short of my
        postscreen limit, but which also are in a reject_rbl_client rules AFTER
        a check_recipient_access rule which OK's the alias patterns. The result
        is that mail to tagged addresses has more lenient treatment with respect
        to those FP-prone DNSBLs and I don't have to work out the issue of how
        and whether to whitelist legit mail from problematic mixed sources in
        Postfix.
      • Stan Hoeppner
        On 5/22/2013 10:02 AM, Noel Jones wrote: ... This fact is not emphasized often enough. Many people forget the intended purpose of postscreen, or simply never
        Message 3 of 23 , May 22, 2013
        • 0 Attachment
          On 5/22/2013 10:02 AM, Noel Jones wrote:
          ...
          > Secondly, remember postscreen is intended as a quick-and-simple
          > zombie killer, its only purpose is to reduce the workload on the
          > more complex filters further downstream.

          This fact is not emphasized often enough.

          Many people forget the intended purpose of postscreen, or simply never
          read the opening of the docs, and falsely see it as a replacement for
          smtpd_foo_restricions, policy daemons, firewalls, etc. This is a direct
          result of the feature creep late in the development of postscreen.
          While the added features are beneficial to some, they are not a
          replacement for most of the existing antispam features of Postfix and
          popular addons.

          In fact, for low volume servers, using postscreen can be more trouble
          than it's worth according to many posts here, especially if 'after 220'
          tests are enabled without fully understanding the ramifications.

          I've personally never configured postscreen. Why?

          1. My servers are low volume
          2. I've never had problems with bots eating up smtpds
          3. I reject in smtpd w/3 dnsbls and 3 rhsbls and this has worked great

          I'll make an educated guess that many folks here have configured
          postscreen simply because it was/is "the new thing", without considering
          whether they -needed- it or not. Many have run into the same address
          based whitelisting problem mentioned here, and either ditched
          postscreen, or spent hours/days trying to tweak it just right.

          My advice is to avoid postscreen unless bots are eating up your smtpds.
          If they're not, and your current setup works well, you gain little, or
          nothing, by using postscreen, but for headaches integrating it.

          --
          Stan
        • Deeztek Support
          For me, implementing postscreen has made a significant difference with the spam. I had a problem with false positives before I started using postscreen and
          Message 4 of 23 , May 23, 2013
          • 0 Attachment

            For me, implementing postscreen has made a significant difference with the spam. I had a problem with false positives before I started using postscreen and that seemed to be using the sorbs rbl which in turn forced me to use the rbl_override. Sorbs seems to be very aggresive and not worth the effort. I have since removed it so hopefully this will eliminate the need for rbl_override.

             

            On another topic, I had an issue the other day where an outside sender was trying to send e-mail to an internal recipient and their e-mail was getting delayed due to a DNS issue on their end. The exact error was:

            (Host or domain name not found. Name service error for name=rotary.org type=MX: Host not found, try again)

             

            I'm assuming this was happenning due to the reject_unknown_sender_domain in my smtpd_recipient_restrictions. It eventually got fixed and the e-mail was able to get delivered however in the meantime what would be the best way to bypass that person's e-mail address so that e-mail will still get delivered even though their server is misconfigured? 

             

             

            Thanks in advance

             

             


            From: owner-postfix-users@... [owner-postfix-users@...] on behalf of Stan Hoeppner [stan@...]
            Sent: Wednesday, May 22, 2013 4:33 PM
            To: postfix-users@...
            Subject: Re: postscreen questions

            On 5/22/2013 10:02 AM, Noel Jones wrote:
            ...
            > Secondly, remember postscreen is intended as a quick-and-simple
            > zombie killer, its only purpose is to reduce the workload on the
            > more complex filters further downstream.

            This fact is not emphasized often enough.

            Many people forget the intended purpose of postscreen, or simply never
            read the opening of the docs, and falsely see it as a replacement for
            smtpd_foo_restricions, policy daemons, firewalls, etc.  This is a direct
            result of the feature creep late in the development of postscreen.
            While the added features are beneficial to some, they are not a
            replacement for most of the existing antispam features of Postfix and
            popular addons.

            In fact, for low volume servers, using postscreen can be more trouble
            than it's worth according to many posts here, especially if 'after 220'
            tests are enabled without fully understanding the ramifications.

            I've personally never configured postscreen.  Why?

            1.  My servers are low volume
            2.  I've never had problems with bots eating up smtpds
            3.  I reject in smtpd w/3 dnsbls and 3 rhsbls and this has worked great

            I'll make an educated guess that many folks here have configured
            postscreen simply because it was/is "the new thing", without considering
            whether they -needed- it or not.  Many have run into the same address
            based whitelisting problem mentioned here, and either ditched
            postscreen, or spent hours/days trying to tweak it just right.

            My advice is to avoid postscreen unless bots are eating up your smtpds.
             If they're not, and your current setup works well, you gain little, or
            nothing, by using postscreen, but for headaches integrating it.

            --
            Stan

          • Wietse Venema
            ... Manual whitelisting. /etc/postfix/main.cf: smtpd_recipient_restrictions = ... reject_unauth_destination check_sender_access hash:/etc/postfix/sender_access
            Message 5 of 23 , May 23, 2013
            • 0 Attachment
              Deeztek Support:
              > On another topic, I had an issue the other day where an outside
              > sender was trying to send e-mail to an internal recipient and their
              > e-mail was getting delayed due to a DNS issue on their end. The
              > exact error was:
              >
              > (Host or domain name not found. Name service error for name=rotary.org
              > type=MX: Host not found, try again)
              >
              > I'm assuming this was happenning due to the reject_unknown_sender_domain
              > in my smtpd_recipient_restrictions. It eventually got fixed and
              > the e-mail was able to get delivered however in the meantime what
              > would be the best way to bypass that person's e-mail address so
              > that e-mail will still get delivered even though their server is
              > misconfigured?

              Manual whitelisting.

              /etc/postfix/main.cf:
              smtpd_recipient_restrictions =
              ...
              reject_unauth_destination
              check_sender_access hash:/etc/postfix/sender_access
              reject_unknown_sender_domain

              /etc/postfix/sender_access:
              rotary.org OK

              Postfix currently does not remember the result of previous
              reject_unknown_sender_domain tests, so it cannot automatically
              permit a site to send mail based on previous results.

              Wietse
            • Deeztek Support
              ... So check_sender_access hash:/etc/postfix/sender_access should be removed from the smtpd_sender_restrictions and instead only have it in the
              Message 6 of 23 , May 23, 2013
              • 0 Attachment

                > Manual whitelisting.

                > /etc/postfix/main.cf:
                >    smtpd_recipient_restrictions =
                >        ...
                >        reject_unauth_destination
                >        check_sender_access hash:/etc/postfix/sender_access
                >        reject_unknown_sender_domain

                > /etc/postfix/sender_access:
                >    rotary.org OK

                 

                So check_sender_access hash:/etc/postfix/sender_access should be removed from the smtpd_sender_restrictions and instead only have it in the smtpd_recipient_restrictions?

                 

                Additionally, I noticed that you placed check_sender_access right above reject_unknown_sender_domain would it be better to also place above the following?:

                 

                    reject_invalid_hostname,
                    reject_non_fqdn_sender

                Thanks

                 


              • Wietse Venema
                ... Not having seen your configuration I showed one example. You can instead use smtpd_sender_restrictions check_sender_access hash:/etc/postfix/sender_access
                Message 7 of 23 , May 23, 2013
                • 0 Attachment
                  Deeztek Support:
                  > > Manual whitelisting.
                  >
                  > > /etc/postfix/main.cf:
                  > > smtpd_recipient_restrictions =
                  > > ...
                  > > reject_unauth_destination
                  > > check_sender_access hash:/etc/postfix/sender_access
                  > > reject_unknown_sender_domain
                  >
                  > > /etc/postfix/sender_access:
                  > > rotary.org OK
                  >
                  >
                  >
                  > So check_sender_access hash:/etc/postfix/sender_access should be
                  > removed from the smtpd_sender_restrictions and instead only have
                  > it in the smtpd_recipient_restrictions?

                  Not having seen your configuration I showed one example.

                  You can instead use

                  smtpd_sender_restrictions
                  check_sender_access hash:/etc/postfix/sender_access
                  reject_unknown_sender_domain

                  > Additionally, I noticed that you placed check_sender_access right
                  > above reject_unknown_sender_domain would it be better to also place
                  > above the following?:

                  Yes you could.

                  Wietse
                • LuKreme
                  ... I m one of those. I don t NEED it, but it has reduced the load on my hardware significantly because far less mail is hitting spamd. -- In the words of one
                  Message 8 of 23 , May 23, 2013
                  • 0 Attachment
                    On 22 May 2013, at 14:33 , Stan Hoeppner <stan@...> wrote:

                    > I'll make an educated guess that many folks here have configured
                    > postscreen simply because it was/is "the new thing", without considering
                    > whether they -needed- it or not. Many have run into the same address
                    > based whitelisting problem mentioned here, and either ditched
                    > postscreen, or spent hours/days trying to tweak it just right.

                    I'm one of those. I don't NEED it, but it has reduced the load on my hardware significantly because far less mail is hitting spamd.

                    --
                    In the words of one of the founding Igors: 'We belong dead? Ecthcuthe
                    me? Where doeth it thay "we"?'
                  • Stan Hoeppner
                    ... You may also want to look into automatic whitelisting. IIRC a daemon exists for this. You ll have to look around. Some time ago Viktor and I knocked out
                    Message 9 of 23 , May 23, 2013
                    • 0 Attachment
                      On 5/23/2013 10:23 AM, Wietse Venema wrote:
                      > Deeztek Support:
                      >> On another topic, I had an issue the other day where an outside
                      >> sender was trying to send e-mail to an internal recipient and their
                      >> e-mail was getting delayed due to a DNS issue on their end. The
                      >> exact error was:
                      >>
                      >> (Host or domain name not found. Name service error for name=rotary.org
                      >> type=MX: Host not found, try again)
                      >>
                      >> I'm assuming this was happenning due to the reject_unknown_sender_domain
                      >> in my smtpd_recipient_restrictions. It eventually got fixed and
                      >> the e-mail was able to get delivered however in the meantime what
                      >> would be the best way to bypass that person's e-mail address so
                      >> that e-mail will still get delivered even though their server is
                      >> misconfigured?
                      >
                      > Manual whitelisting.
                      >
                      > /etc/postfix/main.cf:
                      > smtpd_recipient_restrictions =
                      > ...
                      > reject_unauth_destination
                      > check_sender_access hash:/etc/postfix/sender_access
                      > reject_unknown_sender_domain
                      >
                      > /etc/postfix/sender_access:
                      > rotary.org OK
                      >
                      > Postfix currently does not remember the result of previous
                      > reject_unknown_sender_domain tests, so it cannot automatically
                      > permit a site to send mail based on previous results.
                      >
                      > Wietse


                      You may also want to look into automatic whitelisting. IIRC a daemon
                      exists for this. You'll have to look around.

                      Some time ago Viktor and I knocked out a basic shell script that does
                      this. It scans the mail log file for successful deliveries and adds the
                      recipient address to a whiltelist. Once your Postix has delivered to an
                      address it will always accept mail from that address, assuming you check
                      this table before other restrictions. The script with basic
                      instructions is here:

                      http://www.hardwarefreak.com/whtlst_gen.sh.txt

                      Depending on your mail flow and other factors, you may want to cron it
                      more frequently than suggested. I've been using this on Debian for a
                      couple of years now and it works great. This is designed for use on an
                      MX that also does all outbound delivery. It's easily adaptable for
                      split setups or farms. I described one way of doing so previously. It
                      should be in the list archives somewhere.

                      --
                      Stan
                    • Bill Cole
                      ... This specific error message is very commonly the result of a resolver being tricked by purely local IPv6 existence (i.e. auto-configured interfaces and
                      Message 10 of 23 , May 23, 2013
                      • 0 Attachment
                        On 23 May 2013, at 10:49, Deeztek Support wrote:

                        > On another topic, I had an issue the other day where an outside sender
                        > was trying to send e-mail to an internal recipient and their e-mail
                        > was getting
                        > delayed due to a DNS issue on their end. The exact error was:
                        >
                        > (Host or domain name not found. Name service error for name=rotary.org
                        > type=MX: Host not found, try again)


                        This specific error message is very commonly the result of a resolver
                        being tricked by purely local IPv6 existence (i.e. auto-configured
                        interfaces and link-local addresses) into trying to query other DNS
                        servers over IPv6. All 5 NS records for rotary.org point to names with
                        both A and AAAA (IPv6) records, which makes that a plausible root cause.
                      Your message has been successfully submitted and would be delivered to recipients shortly.