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

Re: postscreen request: pcre support

Expand Messages
  • Wietse Venema
    ... This functionality already exists in smtpd. There is no need to duplicate this in postscreen. Postscreen s purpose is to keep zombies away so that you can
    Message 1 of 10 , Dec 1, 2010
    • 0 Attachment
      Jeroen Koekkoek:
      > Hi,
      >
      > I would like to request pcre table support in postscreen for some fields
      > e.g. client_name, helo_name, etc.
      >
      > For example if client is not listed on any dnsbl, but the reverse
      > hostname matches /\.dsl\./, the client is greylisted.
      >
      > Or if client is listed on a single dnsbl and contains something like
      > dialup, the connection is dropped.

      This functionality already exists in smtpd. There is no need to duplicate
      this in postscreen.

      Postscreen's purpose is to keep zombies away so that you can keep
      using the existing smtpd features.

      It is not a scoring system that makes a decision at the end.
      Instead, postscreen makes the decision as early as possible.

      Wietse
    • Mark Scholten
      ... Is it possible to use postscreen and give points for things and when it is between 2 values it is greylisted and if it is below the lowest value it is
      Message 2 of 10 , Dec 1, 2010
      • 0 Attachment
        > -----Original Message-----
        > From: owner-postfix-users@... [mailto:owner-postfix-
        > users@...] On Behalf Of Wietse Venema
        > Sent: Wednesday, December 01, 2010 4:41 PM
        > To: Postfix users
        > Subject: Re: postscreen request: pcre support
        >
        > Jeroen Koekkoek:
        > > Hi,
        > >
        > > I would like to request pcre table support in postscreen for some
        > fields
        > > e.g. client_name, helo_name, etc.
        > >
        > > For example if client is not listed on any dnsbl, but the reverse
        > > hostname matches /\.dsl\./, the client is greylisted.
        > >
        > > Or if client is listed on a single dnsbl and contains something like
        > > dialup, the connection is dropped.
        >
        > This functionality already exists in smtpd. There is no need to
        > duplicate
        > this in postscreen.

        Is it possible to use postscreen and give points for things and when it is
        between 2 values it is greylisted and if it is below the lowest value it is
        accepted and if it is above the highest value it is rejected? In that case
        it would be useful to have an option to have pcre table to give certain
        points. If you are listed in dnsbl X and you've a hostname that match
        /\.dsl\./ -> greylist, if you are only listed in dnsbl X -> accept, if you
        are listed in dnsbl X, you've a hostname that match /\.dsl\./ and are listed
        in dnsbl Y -> reject.

        Would something like that be possible with postfix/postscreen without using
        a milter?

        Mark
      • jeroen@intuxicated.org
        On Wed, 1 Dec 2010 10:41:22 -0500 (EST), Wietse Venema ... Not entirely, because I can t combine scores in smtpd. I would need a policy service for that
        Message 3 of 10 , Dec 1, 2010
        • 0 Attachment
          On Wed, 1 Dec 2010 10:41:22 -0500 (EST), Wietse Venema
          <wietse@...> wrote:
          > Jeroen Koekkoek:
          >> Hi,
          >>
          >> I would like to request pcre table support in postscreen for some fields

          >> e.g. client_name, helo_name, etc.
          >>
          >> For example if client is not listed on any dnsbl, but the reverse
          >> hostname matches /\.dsl\./, the client is greylisted.
          >>
          >> Or if client is listed on a single dnsbl and contains something like
          >> dialup, the connection is dropped.
          >
          > This functionality already exists in smtpd. There is no need to duplicate
          > this in postscreen.
          >
          > Postscreen's purpose is to keep zombies away so that you can keep
          > using the existing smtpd features.
          >
          > It is not a scoring system that makes a decision at the end.
          > Instead, postscreen makes the decision as early as possible.
          >
          > Wietse

          Not entirely, because I can't combine scores in smtpd. I would need a
          policy service for that (correct me if i'm wrong). So if I wanted to do
          this check I would need an smtpd + policy service and the policy service
          would need to do the exact same lookups in order to get a combined score
          and make a descision based on that.

          I think it's a lot of overhead where one or two pcre checks would suffice.

          If I create a patch, could this feature make its way into postfix?

          Jeroen
        • Wietse Venema
          ... Again. if something can already be done with smtpd plus milter or policy plugin or content filter then I urge you to keep using that already existing
          Message 4 of 10 , Dec 1, 2010
          • 0 Attachment
            jeroen@...:
            >
            > On Wed, 1 Dec 2010 10:41:22 -0500 (EST), Wietse Venema
            > <wietse@...> wrote:
            > > Jeroen Koekkoek:
            > >> Hi,
            > >>
            > >> I would like to request pcre table support in postscreen for some fields
            >
            > >> e.g. client_name, helo_name, etc.
            > >>
            > >> For example if client is not listed on any dnsbl, but the reverse
            > >> hostname matches /\.dsl\./, the client is greylisted.
            > >>
            > >> Or if client is listed on a single dnsbl and contains something like
            > >> dialup, the connection is dropped.
            > >
            > > This functionality already exists in smtpd. There is no need to duplicate
            > > this in postscreen.
            > >
            > > Postscreen's purpose is to keep zombies away so that you can keep
            > > using the existing smtpd features.
            > >
            > > It is not a scoring system that makes a decision at the end.
            > > Instead, postscreen makes the decision as early as possible.
            > >
            > > Wietse
            >
            > Not entirely, because I can't combine scores in smtpd. I would need a
            > policy service for that (correct me if i'm wrong). So if I wanted to do
            > this check I would need an smtpd + policy service and the policy service
            > would need to do the exact same lookups in order to get a combined score
            > and make a descision based on that.

            Again. if something can already be done with smtpd plus milter or
            policy plugin or content filter then I urge you to keep using that
            already existing functionality.

            > I think it's a lot of overhead where one or two pcre checks would
            suffice. > > If I create a patch, could this feature make its way
            into postfix? > > Jeroen > >

            I don't take any code before I have seen a clear design of user
            interface (how to use) and semantics (what it does). That is,
            write the manpage and we can talk about how it would work. But I
            warn you, I will not take something that simply hard-codes PCRE
            lookups plus counter into postscreen.

            Wietse
          • Len Conrad
            ... postfwd policy service can weight and score. Len
            Message 5 of 10 , Dec 1, 2010
            • 0 Attachment
              >Not entirely, because I can't combine scores in smtpd.

              postfwd policy service can weight and score.

              Len
            • Tomoyuki Murakami
              ... and also said, ... To keeping away zombies from smtpd, and do the decision as early as possible, it is natural that the similar access control
              Message 6 of 10 , Dec 2, 2010
              • 0 Attachment
                Wietse:
                > Again. if something can already be done with smtpd plus milter or
                > policy plugin or content filter then I urge you to keep using that
                > already existing functionality.

                and also said,

                > Postscreen's purpose is to keep zombies away so that you can keep
                > using the existing smtpd features.
                >
                > It is not a scoring system that makes a decision at the end.
                > Instead, postscreen makes the decision as early as possible.

                To keeping away zombies from smtpd, and do the decision as early
                as possible, it is natural that the similar access control
                functionality as implemented in smtpd may be required, I think.
                because zombies can be fixed their behavior over time,
                and the difference between legitimates may be just their IPs
                accesing from and reverse DNS names. so that the RBLDNS
                scoreing works very effectively in my site now.

                If there are any additional features to the postscreen,
                at least, policy-delegation I/F is useful for that purpose.

                --
                Tomo.
              • Jeroen Koekkoek
                ... I ve read through the postscreen code and got a general understanding of how it works internally. But judging from the documentation: is postscreen
                Message 7 of 10 , Dec 15, 2010
                • 0 Attachment
                  On 12/01/2010 06:42 PM, Wietse Venema wrote:
                  > jeroen@...:
                  >>
                  >> On Wed, 1 Dec 2010 10:41:22 -0500 (EST), Wietse Venema
                  >> <wietse@...> wrote:
                  >>> Jeroen Koekkoek:
                  >>>> Hi,
                  >>>>
                  >>>> I would like to request pcre table support in postscreen for some fields
                  >>
                  >>>> e.g. client_name, helo_name, etc.
                  >>>>
                  >>>> For example if client is not listed on any dnsbl, but the reverse
                  >>>> hostname matches /\.dsl\./, the client is greylisted.
                  >>>>
                  >>>> Or if client is listed on a single dnsbl and contains something like
                  >>>> dialup, the connection is dropped.
                  >>>
                  >>> This functionality already exists in smtpd. There is no need to duplicate
                  >>> this in postscreen.
                  >>>
                  >>> Postscreen's purpose is to keep zombies away so that you can keep
                  >>> using the existing smtpd features.
                  >>>
                  >>> It is not a scoring system that makes a decision at the end.
                  >>> Instead, postscreen makes the decision as early as possible.
                  >>>
                  >>> Wietse
                  >>
                  >> Not entirely, because I can't combine scores in smtpd. I would need a
                  >> policy service for that (correct me if i'm wrong). So if I wanted to do
                  >> this check I would need an smtpd + policy service and the policy service
                  >> would need to do the exact same lookups in order to get a combined score
                  >> and make a descision based on that.
                  >
                  > Again. if something can already be done with smtpd plus milter or
                  > policy plugin or content filter then I urge you to keep using that
                  > already existing functionality.
                  >
                  >> I think it's a lot of overhead where one or two pcre checks would
                  > suffice.> > If I create a patch, could this feature make its way
                  > into postfix?> > Jeroen> >
                  >
                  > I don't take any code before I have seen a clear design of user
                  > interface (how to use) and semantics (what it does). That is,
                  > write the manpage and we can talk about how it would work. But I
                  > warn you, I will not take something that simply hard-codes PCRE
                  > lookups plus counter into postscreen.
                  >
                  > Wietse

                  I've read through the postscreen code and got a general understanding of
                  how it works internally. But judging from the documentation: is
                  postscreen intended to ever do more than allowing/disallowing client
                  connections? e.g. greylisting or specifying a follow-up service like
                  postgrey?

                  If it's not: It would be nice if the dnsbl results could be passed to
                  the follow-up smtpd process, so they in turn can be passed to a policy
                  daemon. It would save cpu cycles, etc and it would make implementing a
                  policy daemon that needs those results anyway a lot easier.

                  If it is: I'll write about how I think the configuration options, maps,
                  etc should look.

                  - Jeroen
                • Victor Duchovni
                  ... No, for most connections that are passed on the client was already whitelisted, so no tests were performed and there are no results to pass on. There is no
                  Message 8 of 10 , Dec 15, 2010
                  • 0 Attachment
                    On Thu, Dec 16, 2010 at 12:38:46AM +0100, Jeroen Koekkoek wrote:

                    > I've read through the postscreen code and got a general understanding of
                    > how it works internally. But judging from the documentation: is postscreen
                    > intended to ever do more than allowing/disallowing client connections? e.g.
                    > greylisting or specifying a follow-up service like postgrey?
                    >
                    > If it's not: It would be nice if the dnsbl results could be passed to the
                    > follow-up smtpd process, so they in turn can be passed to a policy daemon.
                    > It would save cpu cycles, etc and it would make implementing a policy
                    > daemon that needs those results anyway a lot easier.

                    No, for most connections that are passed on the client was already
                    whitelisted, so no tests were performed and there are no results to
                    pass on. There is no benefit in over-optimizing this code path, if
                    DNSbl lookups were performed, the data is cached in your DNS cache,
                    and another lookup will be quite cheap.

                    As for policy daemons, they may run before or after Postfix performs
                    any RBL lookups, and the complexity of trying to pass such data to
                    them is not worth the effort.

                    --
                    Viktor.
                  • Jeroen Koekkoek
                    ... You are right, forgot about postscreen s internal cache. Well, not before the connection is handed of to an smtpd right? But yes, you are right. Results
                    Message 9 of 10 , Dec 15, 2010
                    • 0 Attachment
                      On 12/16/2010 12:47 AM, Victor Duchovni wrote:
                      > On Thu, Dec 16, 2010 at 12:38:46AM +0100, Jeroen Koekkoek wrote:
                      >
                      >> I've read through the postscreen code and got a general understanding of
                      >> how it works internally. But judging from the documentation: is postscreen
                      >> intended to ever do more than allowing/disallowing client connections? e.g.
                      >> greylisting or specifying a follow-up service like postgrey?
                      >>
                      >> If it's not: It would be nice if the dnsbl results could be passed to the
                      >> follow-up smtpd process, so they in turn can be passed to a policy daemon.
                      >> It would save cpu cycles, etc and it would make implementing a policy
                      >> daemon that needs those results anyway a lot easier.
                      >
                      > No, for most connections that are passed on the client was already
                      > whitelisted, so no tests were performed and there are no results to
                      > pass on. There is no benefit in over-optimizing this code path, if
                      > DNSbl lookups were performed, the data is cached in your DNS cache,
                      > and another lookup will be quite cheap.
                      >
                      > As for policy daemons, they may run before or after Postfix performs
                      > any RBL lookups, and the complexity of trying to pass such data to
                      > them is not worth the effort.
                      >

                      You are right, forgot about postscreen's internal cache.

                      Well, not before the connection is handed of to an smtpd right? But yes,
                      you are right. Results should be read from a caching dns server to keep
                      things simple.

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