> >The only fix for this is a *major* redesign of spamd (or equivalently > >incorporating spamd's greylisting code into a spamfilter which *does* > >relay connections at the IP level to an MTA - which is actually what I'm > >working on at the moment)
> Why start from scratch ? There are enough seasoned, full featured MTA's > around that will allow you to incorparate greylisting. And you get all > the other stuff like STARTTLS, AUTH etc gratis. > > I'd either accept spamd's few limitiations or incorparate greylisting > into a MTA. > > Just my thoughts. There *are* several greylisting implementations using MTAs if that is what you want. The attractive feature of spamd+openbsd/pf is that it is MTA-agnostic. After it does its thing it simply routes your connection through to the real MTA at the IP level. Anyway, it's not starting from scratch for me - I have a mature pseudo-transparent SMTP filter that works well and has been in service for over a year - it's just that I have not publicised it much because in its current form it requires configuration, such as telling it what domains you accept mail for, which IPs are local, etc. I needed to learn about transparent bridging first and recode the I/O so that the filtering is not visible at the IP level. Which I now have, mostly. My filter uses spamassassin plus spamprobe plus uvscan plus clamav, with some automatic detection of spamtrap addresses thrown in. I haven't yet added greylisting to it, and indeed our deployment at the University where I work has an openbsd running spamd sitting in front of my filter sitting in front of the real MTA! By incorporating the logic from spamd into my code, I can remove one piece of hardware. And improve spamd while I'm at it, because with thi sarchitecture I can forward that second connection attempt to the MTA, and avoid having two delays rather than one. Graham
