Hello!

On 9/7/10, Wietse Venema <wie...@porcupine.org> wrote:

>> Next steps are a) support for different expiration times for
>> different tests, b) a dummy SMTP engine (similar to the smtp-sink
>> test program) to log the client/helo/sender/recipient for blocked
>> mail, and c) a simple form of greylisting if time permits.
>
> I have implemented the above except greylisting. After a major code
> rewrite, the code looks pretty solid, and the user interface looks
> usable. In fact, managing user interface complexity was almost half
> the work. The user interface changed less than the code underneath.
>
> Below is a the current manpage.  After the code has run for 24
> hours I'll roll it out as a non-production snapshot.
>
> The new content is in the "enforce" actions and in "tests after
> the 220 SMTP server greeting".
>
> ...
>
>        The  postscreen_pregreet_action        parameter specifies the action 
> that
> is
>        taken next:
>
>        ignore (default)
>             Ignore the failure of this test. Allow other tests to  complete.
>             Repeat this test the next time the client connects.
>
>        enforce
>             Allow  other tests to complete.  Log and reject all RCPT TO com-
>             mands with a 550 SMTP reply.  Repeat this test the next time the
>             client connects.
>
>        drop   Drop  the  connection immediately with a 521 SMTP
> reply.        Repeat
>             this test the next time the client connects.

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.

Comments?

Leandro

Reply via email to