Viktor Dukhovni:
> On Sat, Sep 02, 2017 at 09:01:21AM -0400, Wietse Venema wrote:
> > Allen Coates:
> > > GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the
> > > decision to reject the message has already been made;
> > > It seems to me that this is an opportunity to tar-pit the (bad) remote
> > > host, diminishing spam throughput, and eroding the host's useful
> > > life-span.
> >
> > postscreen could hand off a connection to some other daemon.
> >
> > Keeping connections open *inside* postscreen is definitely not an
> > option. That would limit postcreen's scalability. With a tarpit-only
> > daemon, failure in that daemon would not affect other connections.
>
> This is of course only possible if TLS is not in use. Since OpensSSL
> TLS state is not serializable for migration across processes, tarpitting
> TLS would cause congestion in tlsproxy.
Surprise: I already solved that problem: postscreen would hand off
the _decrypted_ session to the tarpitting daemon :-)
With postscreen, the tlsproxy daemon maintains the per-session TLS
state. Of course, tarpitting lots of TLS connections would be
expensive, and it may cause some tlsproxy processes to fail. But
that would not affect sessions that are already whitelisted.
Wietse
