On 2 Aug 2016, at 14:00, John Hardin wrote:
On Tue, 2 Aug 2016, Bill Cole wrote:
What's special about the postscreen delay is:
1. It delays only the last line of a multi-line greeting, so it
catches MANY more bots than a simple delay.
2. It caches PASS results so even the very short (6s by default)
delay that it imposes only hits the first encounter with a client
that connects frequently. This is critically important in high-volume
situations where the difference between mean session lengths of 0.5s
and 6s is the difference between 2 and 12 MX boxes in a cluster.
Combined, this is why Sendmail and other MTA greeting delays are less
spectacularly effective than they used to be and less effective than
postscreen. The resource cost of prolonging every session to 6s is
untenable for busy machines, so bots that have adapted can get
through. Back in the early days of Sendmail's GreetPause a value of
3s would catch most bots but over the years some bots have adapted by
doing their own hard delays and others have learned to wait for
anything from the server. Few (if any) have adapted by actually
parsing the greeting and making sure that they've seen the end of a
multi-line greeting before talking.
That all sounds great.
Is there any way to use postscreen as a frontend filter for a sendmail
MTA?
Not currently.
Architecturally, Postfix and Sendmail are so different that it isn't
immediately obvious how one would hook postscreen to a sendmail process.
A postscreen process accepts connections over the net and hands off the
file descriptor for a "passing" connection to a smtpd process via a unix
domain socket, after which it is not involved in that session. It's not
a proxy or a pass-through filter, it's a connection handler.
