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

postscreen questions

Expand Messages
  • Deeztek Support
    I m trying out postscreen and I have a couple of questions. First off, here s my postscreen setup: postscreen_access_list = permit_mynetworks
    Message 1 of 23 , May 22, 2013
    • 0 Attachment
      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?
       
      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?

      Thanks in advance
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.