postfix-devel September 2010 archive
Main Archive Page > Month Archives  > postfix-devel archives
postfix-devel: Re: postscreen update: log helo/sender/recipient

Re: postscreen update: log helo/sender/recipient

From: Wietse Venema <wietse_at_nospam>
Date: Thu Sep 23 2010 - 21:23:34 GMT
To: Postfix developers <>

Leandro Santi:
> Hello!

Long time no talk!

> I don't have statistics to back up my reasoning, but I guess it
> might be interesting to implement a fourth action, i.e., forward
> suspicious SMTP connections to an alternative Postfix smtpd
> (perhaps proxy) service.
> The rationale is that we could use postscreen tests for
> doing compulsory greylisting on general purpose mail systems
> (lots of users, more than one single spam filtering policy):
> o well-behaved SMTP clients which do not trigger postscreen
> tests are forwarded to an smtpd that can do greylisting on a
> per-user basis, i.e., greylist some users but not all of them.
> o SMTP clients that trigger postscreen checks are forwarded
> to a different service with possibly more strict checks -
> compusolsory greylisting for instance.
> I guess I could find this feature useful, but as said, right now
> I have no evidence to quantify the amount of (for instance)
> legitimate pregreeters that can or cannot pass through
> greylisting.

Multiple service levels makes sense when postscreen is changed from
a zombie blocker into a scoring system. That seems counter to the
purpose of postscreen which is to reduce the MTA overload, instead
of dumping all the hard decisions on the MTA (and it takes only a
few more lines of code to make greylisting part of postscreen).

Currently, about half of all my DNSBL blocked clients is a pregreeter,
and some 90+% of all my pregreeters is in a major DNSBL such as In the unlikely case that a legitimate pregreeter
runs into postscreen (and is not whitelisted by the default
$mynetworks value), the postscreen logging will provide the necessary
evidence for trouble shooting.