OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: tcp_table query.

From: Bron Gondwana (brongfastmail.fm)
Date: Mon Jun 04 2007 - 18:33:47 CDT


On Mon, Jun 04, 2007 at 09:41:19AM -0800, Joshua J. Kugler wrote:
> On Saturday 12 May 2007 16:31, Wietse Venema wrote:
> > > >> Any news on when tcp_table lookups will be available?
> > > > No. Code that still needs incompatible changes will not go into
> > > > the stable release.
> > > Are you able to elaborate further? Is it something I could assist with,
> > > perhaps?
> > It implements a crappy protocol with a crappy user interface.
>
> May I respectfully disagree? For me, it implements a *simple* protocol with a
> *simple* interface. I was able to implement a server for it and concentrate
> on the logic in the server, not on trying to get the protocol implementation
> right. That was a major benefit for me. Personally, I wouldn't call the
> protocol crappy, but that's IMHO.

I would almost agree, but there's one really annoying "bug" - it
converts all keys to lowercase before they are passed through. Sadly,
some email systems are case significant out there, and so you can't
pass outbound email addresses to a tcp_table for canonicalisation
checks unless you return DUNNO to everything that's not for you. It
meant we needed to create about 5 different interfaces for our our
"postfixlookup" daemon.

Also, it's TCP only - it should support UNIX sockets simply as well,
I wound up writing a patch which was basically s/tcp/sock/, s/TCP/SOCK/
so we have a "sock" table type, but that's annoying and unclear.

Finally, I've written a patch that disconnects from the tcp daemon every
100 connections (not yet customisable) to allow potentially memory
leaky perl daemons to restart occasionally (some queries use a lot of
memory, and over time every single daemon gets to the size of the
biggest query because Perl doesn't release memory). The alternative is
what we've done for the policy daemon which is an epoll based
multiplexer that sits between postfix and the too heavy for
one-per-smtpd policy daemon.

But yeah, some sort of "look this up with a generic external service" is
really needed, and it's annoying that tcp_table has spent so long in the
"nearly there" state. I'm also willing to help with code or protocol
design options if Wietse is willing.

Bron.