On Sun, 27 Nov 2005, Tony Godshall wrote:
[...]
> Symptom: tons of "Unroutable address" logs like this in
> my /var/log/exim4/mainlog...
>
> 2005-11-22 12:34:53 H=adsl-63-195-120-242.dsl.snfc21.pacbell.net
> (thesitefights.com) [63.195.120.242]
> F=<connie.cisneros_qx@???> rejected RCPT
> <middleton@???>: Unrouteable address
Those are normally doing you little harm. At least they're logged in
the same place as other exim issues, which can be helpful for admin
purposes. Count yourself lucky that the above ones were so easy to
reject: many will turn out to be counterfeited but genuine addresses,
which are not so easy to avoid on /that/ basis.
I'd recommend blocking patterns of dynamic/generic IP addresses at
RCPT time, such as this adsl-63-195-120-242.dsl.snfc21.pacbell.net
(wildcards or regexes can be useful, also there are dnsRBLs that you
can use). Then you won't need to get as far as verifying their
envelope sender domain.
> iptables rule:
TBH, I really think this is overdoing it as a defence mechanism.
In fact, I feel I have to say that you're leaping prematurely into the
implementation details before discussing the strategy. I'd rather
have the strategy discussion first.
iptables rules *would* be useful in a genuine denial-of-service
situation, but that isn't what you're discussing, as far as I can
tell. And nowadays, real denial-of-service attacks seem to come
distributed, so a single block isn't going to be a lot of use.
Sure, you can keep your exim logs tidy, but then you no longer know
what is going on. Unless you log the rejections in the iptables log,
and remember to look there.
I'd suggest looking at exim's own rate-limiting options and ACLs for
the more everyday hassles, and reserve the more powerful blocks, such
as exim's host_reject_connection (or ACL) and iptables blocking, for
extreme cases - that have been verified manually.
Rejections done any earlier than the RCPT phase take away the option
for some otherwise-bona-fide correspondent to get a mail through to
your postmaster address if you accidentally block them.
Though I must admit I have mixed feelings about accepting postmaster
mails from IPs which have already spammed our postmaster address in
the past. If I had my way, I'd block those into oblivion, but our
local policy says otherwise.
> I also have been noticing that some IP addresses come in
> with multiple connections with randomized HELO identities.
Indeed, and this is something that seems well worth using as the basis
of some kind of anti-abuse measure. But, again, I think putting into
iptables is stronger medicine than the situation requires.
> My real question is: how can I trigger the commandline
> checks above from within exim?
You have the option to ${run ... , or to use embedded Perl (if your
exim was built with it).
See "String expansions", "Expansion items" in the spec.
http://exim.org/exim-html-4.50/doc/html/spec_11.html#SECT11.5
But the only ways in which we have used that in the past (in fact
we're not using it now, though not for any reasons of its technical
ineffectivness), involved appending the offending IP to a plain file,
which exim was using for one of its tests. This works well: Perl was
able to open the file for append, and write the IP at the end, without
needing file locking and risking deadlocks, and exim would pick up the
updated file contents promptly. Our script also stamped date/time and
other details into a comment in the plain file, so it was
self-documenting. For what I mean by a "plain file", see 10.3 File
names in lists
http://exim.org/exim-html-4.50/doc/html/spec_10.html#SECT10.3
Of course, your policies may be different. I'm only showing some
thoughts from our situation.
good luck.
