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

Re: post screen - temp whitelist TTL

Expand Messages
  • Chad M Stewart
    ... Is the expired time configurable? I used to use OpenBSD s spamd (for greylisting). I recall its logic being that when IP was whitelisted, it remained on
    Message 1 of 14 , Aug 2 4:26 AM
    • 0 Attachment
      On Aug 2, 2012, at 6:07 AM, Wietse Venema wrote:

      > Chad M Stewart:
      >>
      >> I am not understanding something correctly. I'm using postscreen
      >> and noticed that a recently connected IP had was not marked as
      >> PASS OLD but rather PASS NEW. See log entires below
      >
      > PASS NEW means there was no cache entry. Postfix does not
      > keep expired entries for eternity.

      Is the expired time configurable?

      I used to use OpenBSD's spamd (for greylisting). I recall its logic being that when IP was whitelisted, it remained on the whitelist for X time since its last connection to the host (35 days was the default I believe). In other words a system that connects to my mail server a lot would remain on the whitelist essentially indefinitely. Systems that only connect to my mail server every 45 days would have to go through the whitelist process every time. I think 35 days was selected for those once a month systems that send out reminders.

      I'd like to achieve this same behavior with postscreen, but alas looks like not possible. :(


      Thank you,
      Chad
    • Stan Hoeppner
      ... Then clearly you don t understand why postscreen even exists, nor how it works. Postscreen is designed to stop bot spam. The other stuff bolted on such
      Message 2 of 14 , Aug 2 5:03 AM
      • 0 Attachment
        On 8/2/2012 6:26 AM, Chad M Stewart wrote:
        >
        > On Aug 2, 2012, at 6:07 AM, Wietse Venema wrote:
        >
        >> Chad M Stewart:
        >>>
        >>> I am not understanding something correctly. I'm using postscreen
        >>> and noticed that a recently connected IP had was not marked as
        >>> PASS OLD but rather PASS NEW. See log entires below
        >>
        >> PASS NEW means there was no cache entry. Postfix does not
        >> keep expired entries for eternity.
        >
        > Is the expired time configurable?
        >
        > I used to use OpenBSD's spamd (for greylisting). I recall its logic being that when IP was whitelisted, it remained on the whitelist for X time since its last connection to the host (35 days was the default I believe). In other words a system that connects to my mail server a lot would remain on the whitelist essentially indefinitely. Systems that only connect to my mail server every 45 days would have to go through the whitelist process every time. I think 35 days was selected for those once a month systems that send out reminders.
        >
        > I'd like to achieve this same behavior with postscreen, but alas looks like not possible. :(

        Then clearly you don't understand why postscreen even exists, nor how it
        works. Postscreen is designed to stop bot spam. The other stuff bolted
        on such as DNSBL support, whitelists and blacklists was due to feature
        creep and most of it was not necessary.

        Postscreen imposes little delay on non-bot smtp clients, whether they're
        already cached or not, unless you have deep protocol tests enabled. In
        that case an SMTP client may get 4xx'd once if not in the cache, forcing
        the client to retry. Even then the delay is typically less than with a
        greylisting daemon.

        So my question for you is, why is it _necessary_ to salt this expiration
        period to your individual taste? What would this actually gain you?

        Keep in mind that Wietse's original postscreen implementation had ZERO
        user configurable features. If was fully automatic, autonomous, hands
        free. The feature you're wanting to monkey with is part of that
        original design. It doesn't _need_ to be monkeyed with, and it'll gain
        you nothing.

        --
        Stan
      • Wietse Venema
        ... As is documented! postconf|grep _ttl Wietse
        Message 3 of 14 , Aug 2 5:41 AM
        • 0 Attachment
          Chad M Stewart:
          >
          > On Aug 2, 2012, at 6:07 AM, Wietse Venema wrote:
          >
          > > Chad M Stewart:
          > >>
          > >> I am not understanding something correctly. I'm using postscreen
          > >> and noticed that a recently connected IP had was not marked as
          > >> PASS OLD but rather PASS NEW. See log entires below
          > >
          > > PASS NEW means there was no cache entry. Postfix does not
          > > keep expired entries for eternity.
          >
          > Is the expired time configurable?

          As is documented!

          postconf|grep _ttl

          Wietse
        • Wietse Venema
          ... Actually, the parameter is postscreen_cache_retention_time and it defaults to seven days. Wietse
          Message 4 of 14 , Aug 2 5:43 AM
          • 0 Attachment
            Wietse Venema:
            > Chad M Stewart:
            > >
            > > On Aug 2, 2012, at 6:07 AM, Wietse Venema wrote:
            > >
            > > > Chad M Stewart:
            > > >>
            > > >> I am not understanding something correctly. I'm using postscreen
            > > >> and noticed that a recently connected IP had was not marked as
            > > >> PASS OLD but rather PASS NEW. See log entires below
            > > >
            > > > PASS NEW means there was no cache entry. Postfix does not
            > > > keep expired entries for eternity.
            > >
            > > Is the expired time configurable?
            >
            > As is documented!
            >
            > postconf|grep _ttl

            Actually, the parameter is postscreen_cache_retention_time
            and it defaults to seven days.

            Wietse
          • Chad M Stewart
            ... I did have deep protocol tests enabled. Combined with my not having found postscreen_cache_retention_time (or at least not remembered it). -Chad
            Message 5 of 14 , Aug 2 11:48 AM
            • 0 Attachment
              On Aug 2, 2012, at 7:03 AM, Stan Hoeppner wrote:

              > On 8/2/2012 6:26 AM, Chad M Stewart wrote:
              >>
              >> On Aug 2, 2012, at 6:07 AM, Wietse Venema wrote:
              >>
              >>> Chad M Stewart:
              >>>>
              >>>> I am not understanding something correctly. I'm using postscreen
              >>>> and noticed that a recently connected IP had was not marked as
              >>>> PASS OLD but rather PASS NEW. See log entires below
              >>>
              >>> PASS NEW means there was no cache entry. Postfix does not
              >>> keep expired entries for eternity.
              >>
              >> Is the expired time configurable?
              >>
              >> I used to use OpenBSD's spamd (for greylisting). I recall its logic being that when IP was whitelisted, it remained on the whitelist for X time since its last connection to the host (35 days was the default I believe). In other words a system that connects to my mail server a lot would remain on the whitelist essentially indefinitely. Systems that only connect to my mail server every 45 days would have to go through the whitelist process every time. I think 35 days was selected for those once a month systems that send out reminders.
              >>
              >> I'd like to achieve this same behavior with postscreen, but alas looks like not possible. :(
              >
              > Then clearly you don't understand why postscreen even exists, nor how it
              > works. Postscreen is designed to stop bot spam. The other stuff bolted
              > on such as DNSBL support, whitelists and blacklists was due to feature
              > creep and most of it was not necessary.
              >
              > Postscreen imposes little delay on non-bot smtp clients, whether they're
              > already cached or not, unless you have deep protocol tests enabled. In

              I did have deep protocol tests enabled. Combined with my not having found postscreen_cache_retention_time (or at least not remembered it).


              -Chad
            • /dev/rob0
              I m not addressing the subject of the post, but just picking over the configuration snippet. ... [snip] ... I m not sure why you did this. Some MTAs, notably
              Message 6 of 14 , Aug 4 8:08 AM
              • 0 Attachment
                I'm not addressing the subject of the post, but just picking over the
                configuration snippet.

                On Wed, Aug 01, 2012 at 09:48:45PM -0500, Chad M Stewart wrote:
                > [root@mta01 /usr/local/etc/postfix]# postconf -n|grep postscreen
                [snip]
                > postscreen_client_connection_count_limit = 10

                I'm not sure why you did this. Some MTAs, notably qmail, are likely
                to assault you with many simultaneous connections. This non-default
                setting might cause difficulty at times in receiving legitimate mail,
                albeit from impolite clients.

                > postscreen_dnsbl_sites = sbl.spamhaus.org*1, xbl.spamhaus.org*1,
                > pbl.spamhaus.org*1
                > postscreen_dnsbl_threshold = 1

                This makes no sense. You make three queries, risking going over the
                Spamhaus free limit, or your company's paid limit as the case may be,
                gaining nothing over doing a single Zen lookup.

                Consider a higher threshold and enough lower-scored DNSBLs to be able
                to reach it. I use postscreen_dnsbl_threshold=3, and score Zen 3. My
                configuration is essentially what I have posted here in the past.

                > postscreen_greet_banner = "Welcome to our mail server"

                This is non-compliant and a bad idea.
                --
                http://rob0.nodns4.us/ -- system administration and consulting
                Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
              • Chad M Stewart
                ... To limit impolite clients from sucking up my resources. Just because they want to use a fire hose doesn t mean I have to drink at that rate. If a sending
                Message 7 of 14 , Aug 4 2:41 PM
                • 0 Attachment
                  On Aug 4, 2012, at 10:08 AM, /dev/rob0 wrote:

                  > I'm not addressing the subject of the post, but just picking over the
                  > configuration snippet.
                  >
                  > On Wed, Aug 01, 2012 at 09:48:45PM -0500, Chad M Stewart wrote:
                  >> [root@mta01 /usr/local/etc/postfix]# postconf -n|grep postscreen
                  > [snip]
                  >> postscreen_client_connection_count_limit = 10
                  >
                  > I'm not sure why you did this. Some MTAs, notably qmail, are likely
                  > to assault you with many simultaneous connections. This non-default
                  > setting might cause difficulty at times in receiving legitimate mail,
                  > albeit from impolite clients.

                  To limit impolite clients from sucking up my resources. Just because they want to use a fire hose doesn't mean I have to drink at that rate. If a sending system needs more than 10 connections, then maybe they'd better fix their queue algorithm. Starting up and tearing down a connection consumes resources. More efficient to send more than a single message over a connection.


                  >
                  >> postscreen_dnsbl_sites = sbl.spamhaus.org*1, xbl.spamhaus.org*1,
                  >> pbl.spamhaus.org*1
                  >> postscreen_dnsbl_threshold = 1
                  >
                  > This makes no sense. You make three queries, risking going over the
                  > Spamhaus free limit, or your company's paid limit as the case may be,
                  > gaining nothing over doing a single Zen lookup.

                  I'm testing things out. I'll have to figure out how I can get at the response from spamhaus so that I can block/accept as I wish. I may have a need to not block IPs on the PBL list, so if I query zen, then I've got to check the response and act accordingly. I'm not sure how to do that within Postfix/postscreen yet.

                  >
                  > Consider a higher threshold and enough lower-scored DNSBLs to be able
                  > to reach it. I use postscreen_dnsbl_threshold=3, and score Zen 3. My
                  > configuration is essentially what I have posted here in the past.
                  >
                  >> postscreen_greet_banner = "Welcome to our mail server"
                  >
                  > This is non-compliant and a bad idea.

                  That is prepended to the banner, the banner becomes a multi-line response, with the last line being the fqdn of the host.


                  -Chad


                  > --
                  > http://rob0.nodns4.us/ -- system administration and consulting
                  > Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                  >
                  > !DSPAM:2,501d3af626311889815724!
                  >
                  >
                • Reindl Harald
                  ... this is a bad idea, this was a bad idea and this will ever be a bad idea
                  Message 8 of 14 , Aug 4 2:46 PM
                  • 0 Attachment
                    Am 04.08.2012 23:41, schrieb Chad M Stewart:

                    >>> postscreen_greet_banner = "Welcome to our mail server"
                    >>
                    >> This is non-compliant and a bad idea.
                    >
                    > That is prepended to the banner, the banner becomes a multi-line response, with the last line being the fqdn of the host.

                    this is a bad idea, this was a bad idea and this will ever be a bad idea
                  • Stan Hoeppner
                    ... This slows legit clients down no more than greylisting does as it simply returns a 4xx to each excess connection. If you think that s harsh I limit
                    Message 9 of 14 , Aug 5 5:48 AM
                    • 0 Attachment
                      On 8/4/2012 10:08 AM, /dev/rob0 wrote:

                      >> postscreen_client_connection_count_limit = 10
                      >
                      > I'm not sure why you did this. Some MTAs, notably qmail, are likely
                      > to assault you with many simultaneous connections. This non-default
                      > setting might cause difficulty at times in receiving legitimate mail,
                      > albeit from impolite clients.

                      This slows legit clients down no more than greylisting does as it simply
                      returns a 4xx to each excess connection.

                      If you think that's harsh I limit concurrent connections to 4, though
                      I'm doing so with smtpd as I don't use postscreen. It works very well.
                      I have a single list server for which it has caused recurring problems
                      (see my thread) due to a misconfiguration on their end, and the fact
                      they use sendmail. They are actively working on the problem.

                      --
                      Stan
                    • /dev/rob0
                      ... Hmm, not according to my postconf.5.html#postscreen_greet_banner documentation. Is yours different? Even if so, it s still a bad idea. --
                      Message 10 of 14 , Aug 5 8:49 PM
                      • 0 Attachment
                        On Sat, Aug 04, 2012 at 04:41:25PM -0500, Chad M Stewart wrote:
                        > On Aug 4, 2012, at 10:08 AM, /dev/rob0 wrote:
                        > > I'm not addressing the subject of the post, but just picking
                        > > over the configuration snippet.
                        > >
                        > > On Wed, Aug 01, 2012 at 09:48:45PM -0500, Chad M Stewart wrote:
                        > >> [root@mta01 /usr/local/etc/postfix]# postconf -n|grep postscreen
                        > > [snip]

                        > >> postscreen_greet_banner = "Welcome to our mail server"
                        > >
                        > > This is non-compliant and a bad idea.
                        >
                        > That is prepended to the banner, the banner becomes a multi-line
                        > response, with the last line being the fqdn of the host.

                        Hmm, not according to my postconf.5.html#postscreen_greet_banner
                        documentation. Is yours different? Even if so, it's still a bad
                        idea.
                        --
                        http://rob0.nodns4.us/ -- system administration and consulting
                        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                      • /dev/rob0
                        ... Fine, I was just asking. I will take your word for it. That s one of those default settings I have never touched. -- http://rob0.nodns4.us/ -- system
                        Message 11 of 14 , Aug 5 8:53 PM
                        • 0 Attachment
                          On Sun, Aug 05, 2012 at 07:48:56AM -0500, Stan Hoeppner wrote:
                          > On 8/4/2012 10:08 AM, /dev/rob0 wrote:
                          >
                          > >> postscreen_client_connection_count_limit = 10
                          > >
                          > > I'm not sure why you did this. Some MTAs, notably qmail, are
                          > > likely to assault you with many simultaneous connections. This
                          > > non-default setting might cause difficulty at times in receiving
                          > > legitimate mail, albeit from impolite clients.
                          >
                          > This slows legit clients down no more than greylisting does as it
                          > simply returns a 4xx to each excess connection.
                          >
                          > If you think that's harsh I limit concurrent connections to 4,
                          > though I'm doing so with smtpd as I don't use postscreen. It
                          > works very well.

                          Fine, I was just asking. I will take your word for it. That's one of
                          those default settings I have never touched.
                          --
                          http://rob0.nodns4.us/ -- system administration and consulting
                          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                        • Stan Hoeppner
                          ... The purpose of this is to 1. Keep a single host or a small group of hosts that are hitting you simultaneously from flooding your inbound queue and bogging
                          Message 12 of 14 , Aug 6 6:39 AM
                          • 0 Attachment
                            On 8/5/2012 10:53 PM, /dev/rob0 wrote:
                            > On Sun, Aug 05, 2012 at 07:48:56AM -0500, Stan Hoeppner wrote:
                            >> On 8/4/2012 10:08 AM, /dev/rob0 wrote:
                            >>
                            >>>> postscreen_client_connection_count_limit = 10
                            >>>
                            >>> I'm not sure why you did this. Some MTAs, notably qmail, are
                            >>> likely to assault you with many simultaneous connections. This
                            >>> non-default setting might cause difficulty at times in receiving
                            >>> legitimate mail, albeit from impolite clients.
                            >>
                            >> This slows legit clients down no more than greylisting does as it
                            >> simply returns a 4xx to each excess connection.
                            >>
                            >> If you think that's harsh I limit concurrent connections to 4,
                            >> though I'm doing so with smtpd as I don't use postscreen. It
                            >> works very well.
                            >
                            > Fine, I was just asking. I will take your word for it. That's one of
                            > those default settings I have never touched.

                            The purpose of this is to

                            1. Keep a single host or a small group of hosts that are hitting you
                            simultaneously from flooding your inbound queue and bogging down your
                            storage. When inbound writes soak up all the IOPS, your outbound queue
                            fills up and deliveries are delayed. Two users asked here about this
                            exact problem in the past few months and in both cases tweaking this
                            setting fixed their queue problems.

                            2. Prevent such hosts from tying up all of your smtpd processes,
                            causing other clients to wait. The postscreen limit is directly tied to
                            the smtpd limit of the same name--setting one sets the other--as
                            postscreen needs to be able to hand off legit connections to smtpd.
                            Imagine the potential train wreck of giving postscreen 100 concurrent
                            connections but smtpd only 5.

                            The concurrent connection limit chosen will be site/server specific.
                            Some MX Postfix boxen are designed to absorb a lot more mail per unit
                            time than others, and some sites have a much larger inflow than others.

                            My site is very small and thus the _need_ for parallel inbound
                            deliveries should never arise. So a very low concurrency setting works
                            well but for misbehaving clients, only one at the present time. For a
                            much larger site such as say, ASU, with a student population of 55K plus
                            faculty/staff, a low concurrency limit such as mine will likely cause
                            lots of problems with list servers and freemailers, as would using anvil
                            for this purpose period, as it lacks sufficient granularity. For such a
                            large org, they'd want to use something like postfwd to limit concurrent
                            connections from specific problem hosts or domains, and not molest the
                            concurrent connections from known good senders.

                            --
                            Stan
                          Your message has been successfully submitted and would be delivered to recipients shortly.