Am 02.08.2016 um 20:00 schrieb John Hardin:
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?
no - postscreen is not a smtp proxyin fact the connection is handed over from postcreen to the smtpd process after a client has passed the tests
signature.asc
Description: OpenPGP digital signature
