Stuart Henderson wrote:
--On 26 October 2005 08:21 -0500, James Harless wrote:
I do have variables that are known (the sender email address and the
recipient email address). The problem is tying them to the IP Address
of the MTA when it's seen @ spamd. It may be that there isn't a
solution without direct modification of spamd.
By design, spamd can't do this. It neither accepts mail itself, nor
proxies to the real backend server. It always sends a tempfail result
code, and if it's the second time it's seen client_ip|src|dest, it
adds to a table at the same time, so that on the third attempt the
real mailserver is hit instead.
I definitely won't be disabling spamd ;)
The type of functionality you're looking for needs something with
hooks directly into the mail server itself, there's no way with spamd
to avoid delaying a connection unless you /already/ know the IP
address. Maybe milter-greylist or postgrey already do what you're
looking for, or if not they'll likely be easier to adapt.
Not to venture off topic, but it's at this point that I would suggest
you look at qpsmtpd (http://smtpd.develooper.com) for your anti-spam
needs. It's an SMTP server written entirely in perl and is incredibly
extensible (easy to do so as well.) It's nice and speedy: apache.org
and perl.org receive all of their mail through it. It can tie into
Postfix and qmail, and there is an experimental SMTP proxy function as
well. I hope to getting around to creating an interface to sendmail as
well. Its connections can be managed by an internal polling server
(using epoll or kqueue under linux/bsd if available), a forkserver
model, tcpserver (with speedy-cgi/pperl/forkserver), or apache2 (via
mod_perl). It is my current perl love, and I would highly recommend at
least a peek at it.
For a quick summary by one of the main developers, see:
http://www.oreillynet.com/pub/a/sysadmin/2005/09/15/qpsmtpd.html
