On 1 Aug 2016, at 15:53, Axb wrote:
On 01.08.2016 21:30, Vincent Fox wrote:
I keep seeing people say "well if you have postscreen, greylisting is
just dumb".
I think that's a bit too strong. Robust greylisting that accommodates
the reality of mail systems that share one spool across many outbound
machines is not "dumb" but it is substantially less useful if you have
any spambot protection before it. In the case of the original question,
the context was specific to Postfix, where postscreen is a highly
effective optional tool operating well ahead of any full greylisting
implementation and taking out most of the bots that greylisting would
with less risk and resource cost.
Well what is the equivalent for other MTA?
There is no complete equivalent for any other MTA that I am aware of.
Postscreen has a unique (as far as I know) greeting delay implementation
(see below) as well as scored DNSBL checking, which makes it more
feasible to use some hair-trigger DNSBLs safely than it is if you use
them as hard tests (by requiring multiple hits on iffy lists.) There are
also optional after-greeting behavioral checks which amount to
simplistic zero-minimum-time greylisting because a "passing" client gets
a 4xx from postscreen itself at RCPT, after which it must retry within
the cache lifetime (30d by default) to get normal handling. Most sites
don't enable the after-greeting tests because it has that greylist-like
effect without the protections of a good greylist implementation.
google for "Greet pause" and "Early talker"
afaik there's implementations for Sendmail
Which had GreetPause well before postscreen or even the weaker
pre-postscreen 'sleep' trick that predated postscreen.
and Haraka. There may be something similar for EXIM , QMAIL may have
some obscure patch..
CGP also implements a greeting delay.
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.
