According to Alan J. Flavell,
>
> 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.
Well, there are huge numbers of them but only a very few
that are deliverable. So you are right that they aren't
doing me much harm. I was thinking doing a tarpit-like
thing might do a service to others (tying up microsoft virus
zombie machines from moving on to the next victim) and reduce
incoming bandwidth consumption.
> 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.
Oh, that one *is* a problem. I have a static ip myself, but
it's dhcp-configured by my cable company, quite likely in
the middle of a dynamic block. People who follow advice
like like yours are blocking legit people like me. Like
freakin Verizon does.
> > 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.
Good point.
> 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.
Well, if I can get the bit where I add IP addresses to the
smtp_penalty_box triggered from exim rather than from the
log, I could/would log that point.
> 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.
Yes I need to be careful about that.
> 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.
Actually this one is getting to the point where it's causing
problems- sometimes I have so many connections open that
exim4 is rejecting connections.
> > 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
Ah, thank you! Precisely the best and most useful answer I
could have expected. I don't know why I wasn't reading the
spec document. I guess it's name scared me away but it is very
accessible indeed.
> 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.
My domain has only my own policies... it's just for family
and friends. I don't think I'll use the plaintext scheme
for fear of growing it too big- the ipt_recent method has a
built-in limiting mechanism.
Thanks again Alan. You've been a great help.
Tony
