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

Re: postscreen request: pcre support

Expand Messages
  • Len Conrad
    ... postfwd policy service can weight and score. Len
    Message 1 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 2 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 3 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 4 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 5 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.