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

Re: greetpause

Expand Messages
  • Wietse Venema
    ... Given enough of them, indeed. By the way, the above is an argument for breaking up features like reject_rbl_client up into smaller features. For example, a
    Message 1 of 27 , Mar 31, 2006
    • 0 Attachment
      mouss:
      > Wietse Venema wrote:
      > > mouss:
      > >> while I am in, is it recommended to use delay_reject=no and implement
      > >> greetpause in client stage or is this a bogus/bad measure?
      > >
      > > Doing this for every connection would qualify as bogus.
      > >
      > > This pause makes sessions last longer, and therefore makes the
      > > server use more SMTP server processes. This limits the volume
      > > of mail that a server can handle.
      > >
      >
      > I had in mind something like
      > check_client_access pcre:$dir/greetpause_clients
      >
      >
      > greetpause_clients would contain patterns for dyn-like clients patterns,
      > for example:
      > /\.adsl\./ greet_pause
      >
      > but I guess this would still be bad in case many of these connect to the
      > server.

      Given enough of them, indeed.

      By the way, the above is an argument for breaking up features like
      reject_rbl_client up into smaller features. For example, a "reject_if"
      portion and an "is_rbl_client" portion. The code that implements
      the "is_rbl_client" portion could then be used for other purposes,
      like pausing. This eliminates kludges like having to use access
      map lookups.

      "reject_rbl_client" would then become an alias for "reject_if
      is_rbl_client"; but this is not the only way the decomposition
      could be done.

      > > Instead, this could be done in a front end daemon that accepts
      > > connections from the network and that passes them to Postfix smtpd,
      > > with some delay in the case of strangers. This daemon could drop
      > > connections that receive data within some short time after connection
      > > acceptance.
      >
      > What is the recommended way to pass the client IP to postfix? XCLIENT?

      I wrote "pass the connection", not "copy data from one socket to
      another socket". In terms of the BSD socket API, this means sending
      the file descriptor with the accepted connection from the front-end
      process process to a Postfix SMTP server process.

      > > The 2.3 snapshots have unfinished code for a new connection type
      > > besides fifo, unix and inet. This would allow one process to censor
      > > all the incoming SMTP connections, without incurring the cost of
      > > one SMTP server process per connection.

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