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

Re: postscreen request: pcre support

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.