Postscreen Feature Request

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Postscreen Feature Request

allenc
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.

I SUGGEST, therefore, that an additional "TAR-PIT" option be added to
the list of available postscreen_mumble_action's.   I envisage this as
being the same as "ENFORCE", but with an added delay.

It would be very nice if the tar-pit action could be invoked from within
the Postscreen access control lists, but I appreciate that this could
disrupt stable and well-tested code.

I would be interested to hear what others make of this idea.

Allen C
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen Feature Request

Wietse Venema
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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen Feature Request

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.

--
        Viktor
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen Feature Request

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen Feature Request

allenc


On 02/09/17 22:03, Wietse Venema wrote:
>
> Surprise: I already solved that problem: postscreen would hand off
> the _decrypted_ session to the tarpitting daemon :-)
>

How would you optionally hand off to the tarpit daemon, instead of to
postfix?

Allen C
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen Feature Request

Wietse Venema
On 02/09/17 22:03, Wietse Venema wrote:
> Surprise: I already solved that problem: postscreen would hand off
> the _decrypted_ session to the tarpitting daemon :-)

Allen Coates:
> How would you optionally hand off to the tarpit daemon, instead of to
> postfix?

That requires new code for a config parameter that specifies the
pathname of the tarpit service's UNIX-domain socket, and new code
for making the Postfix library call to send the SMTP session's file
descriptor to that socket.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen Feature Request

allenc


On 03/09/17 00:43, Wietse Venema wrote:

> On 02/09/17 22:03, Wietse Venema wrote:
>> Surprise: I already solved that problem: postscreen would hand off
>> the _decrypted_ session to the tarpitting daemon :-)
>
> Allen Coates:
>> How would you optionally hand off to the tarpit daemon, instead of to
>> postfix?
>
> That requires new code for a config parameter that specifies the
> pathname of the tarpit service's UNIX-domain socket, and new code
> for making the Postfix library call to send the SMTP session's file
> descriptor to that socket.
>
> Wietse
>
Thanks for that.  My spam defences are pretty well sorted - only eight
since march - and I am itching to take the fight to them.

Thanks for your time.

Allen