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

postscreen questions

Expand Messages
  • Andy Dills
    I ve been investigating postscreen, as we ve been address probed/bombed for years, as we have a few domains that are very old (well, early 90s) that had a lot
    Message 1 of 23 , May 27, 2010
    • 0 Attachment
      I've been investigating postscreen, as we've been address probed/bombed
      for years, as we have a few domains that are very old (well, early 90s)
      that had a lot of users back in the dialup days. Our approach was to just
      throw hardware at the problem, and we've had a whole cluster of servers
      just sending out 550s all day long for years now.

      We don't do any RBL checks at the postfix level; we have amavisd-new
      handle all of that via spamassassin. I'm hesitant to allow a single
      blacklist to determine the fate of mail acceptance, especially when we
      have a very low false negative rate with amavisd/SA. Essentially, we'd
      rather throw hardware at the problem than potentially reject legit mail.

      My primary question is, would we see significant improvement by using
      postscreen if we don't use RBLs?

      Also, would postscreen_cache_map work with a mysql backend?

      Thanks,
      Andy

      ---
      Andy Dills
      Xecunet, Inc.
      www.xecu.net
      301-682-9972
      ---
    • Robert Schetterer
      ... same here, old short domains, openrelays in early times but checked to handle it with one machine, but of course yours might be more spammy at all ... why
      Message 2 of 23 , May 27, 2010
      • 0 Attachment
        Am 27.05.2010 15:34, schrieb Andy Dills:
        >
        > I've been investigating postscreen, as we've been address probed/bombed
        > for years, as we have a few domains that are very old (well, early 90s)
        > that had a lot of users back in the dialup days. Our approach was to just
        > throw hardware at the problem, and we've had a whole cluster of servers
        > just sending out 550s all day long for years now.

        same here, old short domains, openrelays in early times
        but checked to handle it with one machine, but of course yours might be
        more spammy at all
        >
        > We don't do any RBL checks at the postfix level;

        why do you not use selective rbl checks, only for dynip etc, as well as
        greylisting, there are a lot good cheap tricks with restictions that
        should help

        and/or perhaps use recent with iptables and/or fail2ban

        we have amavisd-new
        > handle all of that via spamassassin. I'm hesitant to allow a single
        > blacklist to determine the fate of mail acceptance, especially when we
        > have a very low false negative rate with amavisd/SA. Essentially, we'd
        > rather throw hardware at the problem than potentially reject legit mail.

        amavis should not gamble a lot with spam/virus until if you have good
        checks before it
        i have one support ticket a week i.e.
        by 3000 Mailboxes, mostly problems of the sender, extrem rare rbl
        related, nothing that cant be handeled easy

        >
        > My primary question is, would we see significant improvement by using
        > postscreen if we don't use RBLs?

        as far i know postscreen should help anyway
        but you should measure aud investigate your logs if a cheap/short 550
        is more usefull sometimes

        >
        > Also, would postscreen_cache_map work with a mysql backend?

        dont think so, but gurus should know exactly

        >
        > Thanks,
        > Andy
        >
        > ---
        > Andy Dills
        > Xecunet, Inc.
        > www.xecu.net
        > 301-682-9972
        > ---

        after all dont expect spammers/bots will give up only
        cause you have new antispam features integrated
        you may clean up your logs and/or need less resources
        but at my spam domains , spam traffic was never
        related to what antispam feature i ever integrated
        it was always in waves

        --
        Best Regards

        MfG Robert Schetterer

        Germany/Munich/Bavaria
      • Wietse Venema
        ... In my experience, the pregreet check kills off 50% of the zombies. Of course malware will improve and I expect to add deeper protocol checks (command
        Message 3 of 23 , May 27, 2010
        • 0 Attachment
          Andy Dills:
          >
          > I've been investigating postscreen, as we've been address probed/bombed
          > for years, as we have a few domains that are very old (well, early 90s)
          > that had a lot of users back in the dialup days. Our approach was to just
          > throw hardware at the problem, and we've had a whole cluster of servers
          > just sending out 550s all day long for years now.
          >
          > We don't do any RBL checks at the postfix level; we have amavisd-new
          > handle all of that via spamassassin. I'm hesitant to allow a single
          > blacklist to determine the fate of mail acceptance, especially when we
          > have a very low false negative rate with amavisd/SA. Essentially, we'd
          > rather throw hardware at the problem than potentially reject legit mail.
          >
          > My primary question is, would we see significant improvement by using
          > postscreen if we don't use RBLs?

          In my experience, the "pregreet" check kills off 50% of the zombies.
          Of course malware will "improve" and I expect to add deeper protocol
          checks (command pipelining, greylist) in anticipation.

          > Also, would postscreen_cache_map work with a mysql backend?

          postscreen needs very low latency (I put in explicit tests for
          this). Also, postscreen requires read, write, iterate support
          which is implemented only for file-based databases.

          If table access requires 10ms, then postscreen can handle only 100
          connection requests per second. You would be better off not using
          postscreen and instead turning up the number of smtpd processes.

          Wietse
        • Nataraj
          ... Using things like amavisd and spamassasin besides being very costly in terms of performance, is far more vulnerable to security exploits than rejecting as
          Message 4 of 23 , May 27, 2010
          • 0 Attachment
            Andy Dills wrote:
            > I've been investigating postscreen, as we've been address probed/bombed
            > for years, as we have a few domains that are very old (well, early 90s)
            > that had a lot of users back in the dialup days. Our approach was to just
            > throw hardware at the problem, and we've had a whole cluster of servers
            > just sending out 550s all day long for years now.
            >
            > We don't do any RBL checks at the postfix level; we have amavisd-new
            > handle all of that via spamassassin. I'm hesitant to allow a single
            > blacklist to determine the fate of mail acceptance, especially when we
            > have a very low false negative rate with amavisd/SA. Essentially, we'd
            > rather throw hardware at the problem than potentially reject legit mail.
            >
            > My primary question is, would we see significant improvement by using
            > postscreen if we don't use RBLs?
            >
            > Also, would postscreen_cache_map work with a mysql backend?
            >
            > Thanks,
            > Andy
            >
            > ---
            > Andy Dills
            > Xecunet, Inc.
            > www.xecu.net
            > 301-682-9972
            > ---
            >
            Using things like amavisd and spamassasin besides being very costly in
            terms of performance, is far more vulnerable to security exploits than
            rejecting as many connections as possible at an earlier time. I have
            used the various checks for valid domain names, helo names, etc, in
            conjunction with the RBL's to minimize scanning with spamassasin. I
            use restriction classes to define more and less conservative policys for
            different domains and even specific users when necessary.

            smtpd_restriction_classes = restrictive, permissive

            restrictive =
            reject_rbl_client zen.spamhaus.org
            reject_rbl_client dul.dnsbl.sorbs.net
            reject_rbl_client bl.spamcop.net

            permissive =
            reject_rbl_client pbl.spamhaus.org
            reject_rbl_client dul.dnsbl.sorbs.net


            check_recipient_access hash:/etc/postfix/smtpd_recipient_access

            smtpd_recipient_access contains:
            mydomain.com restrictive
            # I get the abuse mail and don't want to see alot of spam
            abuse@... restrictive
            otherdomain.org permissive
            127.0.0.1 OK


            The permissive class is very conservative and should cause practically
            no false positives. Even my restrictive class includes rbls known to
            have extremely low false positive rates. Spamhaus is known to be one of
            the most accurate rbl's with an excellent hit rate and low false
            positives. If you have a large site, check their web pages, since they
            do charge for high volume query rates and will block your access if you
            exceed the free limit.

            Nataraj
          • LuKreme
            ... That s just … silly ... Really? How much legit mail hits zen s rbl (hint, the number rhymes with hero ). -- You don t think you ve had enough, do you?
            Message 5 of 23 , May 27, 2010
            • 0 Attachment
              On 27-May-2010, at 07:34, Andy Dills wrote:
              >
              > I've been investigating postscreen, as we've been address probed/bombed
              > for years, as we have a few domains that are very old (well, early 90s)
              > that had a lot of users back in the dialup days. Our approach was to just
              > throw hardware at the problem, and we've had a whole cluster of servers
              > just sending out 550s all day long for years now.
              >
              > We don't do any RBL checks at the postfix level;

              That's just … silly

              > we have amavisd-new
              > handle all of that via spamassassin. I'm hesitant to allow a single
              > blacklist to determine the fate of mail acceptance, especially when we
              > have a very low false negative rate with amavisd/SA. Essentially, we'd
              > rather throw hardware at the problem than potentially reject legit mail.

              Really? How much legit mail hits zen's rbl (hint, the number rhymes with "hero").


              --
              'You don't think you've had enough, do you?' he said. I KNOW WHEN I'VE
              HAD ENOUGH. 'Everyone says that, though. I KNOW WHEN EVERYONE'S HAD
              ENOUGH. --Moving Pictures
            • Andy Dills
              ... That seems worth investigating, thank you. I appreciate how you re evolving postfix to address this (and the improvements to handle content filtering
              Message 6 of 23 , May 28, 2010
              • 0 Attachment
                On Thu, 27 May 2010, Wietse Venema wrote:

                > Andy Dills:
                > >
                > > I've been investigating postscreen, as we've been address probed/bombed
                > > for years, as we have a few domains that are very old (well, early 90s)
                > > that had a lot of users back in the dialup days. Our approach was to just
                > > throw hardware at the problem, and we've had a whole cluster of servers
                > > just sending out 550s all day long for years now.
                > >
                > > We don't do any RBL checks at the postfix level; we have amavisd-new
                > > handle all of that via spamassassin. I'm hesitant to allow a single
                > > blacklist to determine the fate of mail acceptance, especially when we
                > > have a very low false negative rate with amavisd/SA. Essentially, we'd
                > > rather throw hardware at the problem than potentially reject legit mail.
                > >
                > > My primary question is, would we see significant improvement by using
                > > postscreen if we don't use RBLs?
                >
                > In my experience, the "pregreet" check kills off 50% of the zombies.
                > Of course malware will "improve" and I expect to add deeper protocol
                > checks (command pipelining, greylist) in anticipation.

                That seems worth investigating, thank you. I appreciate how you're
                evolving postfix to address this (and the improvements to handle content
                filtering pre-queue, we will be moving to that once amavisd-new is more
                mature with regards to that).

                > > Also, would postscreen_cache_map work with a mysql backend?
                >
                > postscreen needs very low latency (I put in explicit tests for
                > this). Also, postscreen requires read, write, iterate support
                > which is implemented only for file-based databases.
                >
                > If table access requires 10ms, then postscreen can handle only 100
                > connection requests per second. You would be better off not using
                > postscreen and instead turning up the number of smtpd processes.

                That makes sense. I was just looking for a way to provide some "shared
                knowledge" among the servers in the cluster.

                Thanks,
                Andy

                ---
                Andy Dills
                Xecunet, Inc.
                www.xecu.net
                301-682-9972
                ---
              • lst_hoe02@kwsoft.de
                ... Hm. The infamous dispute with the austrian NIC comes to mind... We have throw out all spamhaus.org related blacklists since then. Regards Andreas
                Message 7 of 23 , May 28, 2010
                • 0 Attachment
                  Zitat von LuKreme <kremels@...>:

                  > On 27-May-2010, at 07:34, Andy Dills wrote:
                  >>
                  >> I've been investigating postscreen, as we've been address probed/bombed
                  >> for years, as we have a few domains that are very old (well, early 90s)
                  >> that had a lot of users back in the dialup days. Our approach was to just
                  >> throw hardware at the problem, and we've had a whole cluster of servers
                  >> just sending out 550s all day long for years now.
                  >>
                  >> We don't do any RBL checks at the postfix level;
                  >
                  > That's just … silly
                  >
                  >> we have amavisd-new
                  >> handle all of that via spamassassin. I'm hesitant to allow a single
                  >> blacklist to determine the fate of mail acceptance, especially when we
                  >> have a very low false negative rate with amavisd/SA. Essentially, we'd
                  >> rather throw hardware at the problem than potentially reject legit mail.
                  >
                  > Really? How much legit mail hits zen's rbl (hint, the number rhymes
                  > with "hero").

                  Hm. The infamous dispute with the austrian NIC comes to mind...
                  We have throw out all spamhaus.org related blacklists since then.

                  Regards

                  Andreas
                • Roderick A. Anderson
                  ... Run a cron job that checks for changes in the RDBMS and then rebuilds the postscreen_cache_map files if needed. ||/ Rod --
                  Message 8 of 23 , May 28, 2010
                  • 0 Attachment
                    Andy Dills wrote:
                    > On Thu, 27 May 2010, Wietse Venema wrote:
                    >
                    >> Andy Dills:
                    >>> I've been investigating postscreen, as we've been address probed/bombed
                    >>> for years, as we have a few domains that are very old (well, early 90s)
                    >>> that had a lot of users back in the dialup days. Our approach was to just
                    >>> throw hardware at the problem, and we've had a whole cluster of servers
                    >>> just sending out 550s all day long for years now.
                    >>>
                    >>> We don't do any RBL checks at the postfix level; we have amavisd-new
                    >>> handle all of that via spamassassin. I'm hesitant to allow a single
                    >>> blacklist to determine the fate of mail acceptance, especially when we
                    >>> have a very low false negative rate with amavisd/SA. Essentially, we'd
                    >>> rather throw hardware at the problem than potentially reject legit mail.
                    >>>
                    >>> My primary question is, would we see significant improvement by using
                    >>> postscreen if we don't use RBLs?
                    >> In my experience, the "pregreet" check kills off 50% of the zombies.
                    >> Of course malware will "improve" and I expect to add deeper protocol
                    >> checks (command pipelining, greylist) in anticipation.
                    >
                    > That seems worth investigating, thank you. I appreciate how you're
                    > evolving postfix to address this (and the improvements to handle content
                    > filtering pre-queue, we will be moving to that once amavisd-new is more
                    > mature with regards to that).
                    >
                    >>> Also, would postscreen_cache_map work with a mysql backend?
                    >> postscreen needs very low latency (I put in explicit tests for
                    >> this). Also, postscreen requires read, write, iterate support
                    >> which is implemented only for file-based databases.
                    >>
                    >> If table access requires 10ms, then postscreen can handle only 100
                    >> connection requests per second. You would be better off not using
                    >> postscreen and instead turning up the number of smtpd processes.
                    >
                    > That makes sense. I was just looking for a way to provide some "shared
                    > knowledge" among the servers in the cluster.

                    Run a cron job that checks for changes in the RDBMS and then rebuilds
                    the postscreen_cache_map "files" if needed.


                    \\||/
                    Rod
                    --
                    >
                    > Thanks,
                    > Andy
                    >
                    > ---
                    > Andy Dills
                    > Xecunet, Inc.
                    > www.xecu.net
                    > 301-682-9972
                    > ---
                  • Wietse Venema
                    ... That implies shared access to the postscreen_cache_map _file_, and is not supported. Wietse
                    Message 9 of 23 , May 28, 2010
                    • 0 Attachment
                      Roderick A. Anderson:
                      > >>> Also, would postscreen_cache_map work with a mysql backend?
                      > >> postscreen needs very low latency (I put in explicit tests for
                      > >> this). Also, postscreen requires read, write, iterate support
                      > >> which is implemented only for file-based databases.
                      > >>
                      > >> If table access requires 10ms, then postscreen can handle only 100
                      > >> connection requests per second. You would be better off not using
                      > >> postscreen and instead turning up the number of smtpd processes.
                      > >
                      > > That makes sense. I was just looking for a way to provide some "shared
                      > > knowledge" among the servers in the cluster.
                      >
                      > Run a cron job that checks for changes in the RDBMS and then rebuilds
                      > the postscreen_cache_map "files" if needed.

                      That implies shared access to the postscreen_cache_map _file_,
                      and is not supported.

                      Wietse
                    • Robert Schetterer
                      ... whatever if you do selective rbl checks, you will nearly never get into trouble, after all there is a lot checks which you can do before rbls so not much
                      Message 10 of 23 , May 28, 2010
                      • 0 Attachment
                        Am 28.05.2010 14:13, schrieb lst_hoe02@...:
                        > Zitat von LuKreme <kremels@...>:
                        >
                        >> On 27-May-2010, at 07:34, Andy Dills wrote:
                        >>>
                        >>> I've been investigating postscreen, as we've been address probed/bombed
                        >>> for years, as we have a few domains that are very old (well, early 90s)
                        >>> that had a lot of users back in the dialup days. Our approach was to
                        >>> just
                        >>> throw hardware at the problem, and we've had a whole cluster of servers
                        >>> just sending out 550s all day long for years now.
                        >>>
                        >>> We don't do any RBL checks at the postfix level;
                        >>
                        >> That's just … silly
                        >>
                        >>> we have amavisd-new
                        >>> handle all of that via spamassassin. I'm hesitant to allow a single
                        >>> blacklist to determine the fate of mail acceptance, especially when we
                        >>> have a very low false negative rate with amavisd/SA. Essentially, we'd
                        >>> rather throw hardware at the problem than potentially reject legit mail.
                        >>
                        >> Really? How much legit mail hits zen's rbl (hint, the number rhymes
                        >> with "hero").
                        >
                        > Hm. The infamous dispute with the austrian NIC comes to mind...
                        > We have throw out all spamhaus.org related blacklists since then.
                        >
                        > Regards

                        whatever if you do selective rbl checks, you will nearly never get into
                        trouble, after all there is a lot checks which you can do before rbls
                        so not much leaves to spamhouse, not using them in any way is not really
                        clever, if you like a rbl advanced configurable modus try policy-weight
                        which you can also use selective and/or with whitelisting etc

                        by the way its up to what your using, but i would miss rbls
                        in my antispam chain

                        >
                        > Andreas
                        >
                        >
                        >


                        --
                        Best Regards

                        MfG Robert Schetterer

                        Germany/Munich/Bavaria
                      • Roderick A. Anderson
                        ... My bad. I was thinking how I keep the relay and transport maps up to date on MX servers. The data is in a MSSQL table and each spool rebuilds it s
                        Message 11 of 23 , May 28, 2010
                        • 0 Attachment
                          Wietse Venema wrote:
                          > Roderick A. Anderson:
                          >>>>> Also, would postscreen_cache_map work with a mysql backend?
                          >>>> postscreen needs very low latency (I put in explicit tests for
                          >>>> this). Also, postscreen requires read, write, iterate support
                          >>>> which is implemented only for file-based databases.
                          >>>>
                          >>>> If table access requires 10ms, then postscreen can handle only 100
                          >>>> connection requests per second. You would be better off not using
                          >>>> postscreen and instead turning up the number of smtpd processes.
                          >>> That makes sense. I was just looking for a way to provide some "shared
                          >>> knowledge" among the servers in the cluster.
                          >> Run a cron job that checks for changes in the RDBMS and then rebuilds
                          >> the postscreen_cache_map "files" if needed.
                          >
                          > That implies shared access to the postscreen_cache_map _file_,
                          > and is not supported.

                          My bad. I was thinking how I keep the relay and transport maps up to
                          date on MX servers. The data is in a MSSQL table and each spool
                          rebuilds it's (hashed) maps when told to.


                          \\||/
                          Rod
                          --
                        • lst_hoe02@kwsoft.de
                          ... My only intention was to point out that the FP rate is sometimes a point of view . We also use RBLs but not Spamhaus any more and for sure everyone should
                          Message 12 of 23 , May 28, 2010
                          • 0 Attachment
                            Zitat von Robert Schetterer <robert@...>:

                            > Am 28.05.2010 14:13, schrieb lst_hoe02@...:
                            >> Zitat von LuKreme <kremels@...>:
                            >>
                            >>> On 27-May-2010, at 07:34, Andy Dills wrote:
                            >>>>
                            >>>> I've been investigating postscreen, as we've been address probed/bombed
                            >>>> for years, as we have a few domains that are very old (well, early 90s)
                            >>>> that had a lot of users back in the dialup days. Our approach was to
                            >>>> just
                            >>>> throw hardware at the problem, and we've had a whole cluster of servers
                            >>>> just sending out 550s all day long for years now.
                            >>>>
                            >>>> We don't do any RBL checks at the postfix level;
                            >>>
                            >>> That's just … silly
                            >>>
                            >>>> we have amavisd-new
                            >>>> handle all of that via spamassassin. I'm hesitant to allow a single
                            >>>> blacklist to determine the fate of mail acceptance, especially when we
                            >>>> have a very low false negative rate with amavisd/SA. Essentially, we'd
                            >>>> rather throw hardware at the problem than potentially reject legit mail.
                            >>>
                            >>> Really? How much legit mail hits zen's rbl (hint, the number rhymes
                            >>> with "hero").
                            >>
                            >> Hm. The infamous dispute with the austrian NIC comes to mind...
                            >> We have throw out all spamhaus.org related blacklists since then.
                            >>
                            >> Regards
                            >
                            > whatever if you do selective rbl checks, you will nearly never get into
                            > trouble, after all there is a lot checks which you can do before rbls
                            > so not much leaves to spamhouse, not using them in any way is not really
                            > clever, if you like a rbl advanced configurable modus try policy-weight
                            > which you can also use selective and/or with whitelisting etc
                            >
                            > by the way its up to what your using, but i would miss rbls
                            > in my antispam chain

                            My only intention was to point out that the FP rate is sometimes a
                            "point of view". We also use RBLs but not Spamhaus any more and for
                            sure everyone should carefully choose before using one and monitor the
                            results.

                            Regards

                            Andreas
                          • 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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.