On Wed, 13 Mar 2002, Phil Pennock wrote:
> 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?
>
remote_smtp:
driver=smtp
..
ignore_target_hosts=0.0.0.0/32:127.0.0.0/8:10.0.0.0/8:192.168.0.0/16
..
> 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. ;^)
Perhaps a better question might be - why is your host trying to deliver
mail to these hosts? What domain's MX record points there? Maybe you
just want to reject all mail reciepients in that/those domain(s).
These might be spamtraps - if your users are trying to send mail to
them, then perhaps your users are trying to send spam?
>
> --
> The code was willing,
> It considered your request,
> But the chips were weak.
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
>
--
