[Exim] Two issues relating to spam

This evening, I've been dealing with spam on one of my employer's
smarthosts. And lots of it. I'll spare you the rants about DSL
customers running MS Exchange IMS, or webhosting customers with
vulnerable formmail.pl scripts. But yes, we do act when we find these.
Recently though, the spam volumes have increased by a staggering amount.


Two things are bothering me. One of them is a feature request (unless
I'm missing something), the other perhaps a bug. We're not planning on
migrating to Exim 4 just yet. If neither of these warrants a 3.x fix,
then we'll have to consider moving the migration forwards. :^(

These two things occured with Exim 3.35, built on FreeBSD 4.5.


Problem 1 -- A record pointing to 0.0.0.0
-------------------------------------------

$ host -t a goldrush.net
goldrush.net has address 0.0.0.0

This seems to cause Exim to deliver the mail to itself, until it reaches
30 hops; duplicated on Exim 3.35, FreeBSD 4.0. Some manual cleaning has
helped. I'm not able to find a way to say "if IP address resulting from
lookups is X, then skip", but I'm probably missing something obvious.
I'm perhaps understandably reluctant to blackhole anything concerning
that address, even as a /32. :^)

Are there any major gotchas with having the smtp transport refuse to
open a connection to 0.0.0.0?


Problem 2 -- hosts which deliberately don't issue banner
---------------------------------------------------------

209.151.233.24, which ultimately reverses to the lovely little hostname
"fix.your.open.relay.or.die.net", has something listening on port 25
which never issues an SMTP banner.

The Exim delivery process never times out on this. AFAICS, after the
connection is opened (proceeds normally), the command_timeout should
apply to waiting for the banner. Documented default is 5 mins. I'm
seeing processes which are still waiting for much longer. The only one
which I haven't yet killed has been waiting 24 mins (age of -J file).

Ironically, this leads to my attempts to clean the queue of spam not
doing as well as they might, since some messages remain locked on the
queue; I have to dig out the relevant Exim process (remembering
"exiwhat" is so much better than find/lsof :^) ) and kill it manually,
before being able to remove the spam.

In perusing the code, I'm unable to see anything wrong with the select()
timeout used. Another exiwhat just showed that a connection to
[209.151.233.19] "spam.must.die.net", which appears to blackhole
traffic, does time out correctly. So the alarm()-handler works.

What would happen if a remote server gave a "220-" line every four
minutes? [209.151.233.24] is currently not reachable, or I'd check
there. ;^)

--
The code was willing,
It considered your request,
But the chips were weak.