Re: Reverse dns checking for local machine

Top Page
Delete this message
Reply to this message
Author: Greg A. Woods
Date:  
To: John Henders
CC: Philip Hazel, Sean Witham, exim-users
Subject: Re: Reverse dns checking for local machine
[ On Fri, August 22, 1997 at 11:52:47 (-0700), John Henders wrote: ]
> Subject: Re: Reverse dns checking for local machine
>
> Also, the big problem I'm seeing on a daily basis is the use of dial up
> pops from large providers for spamming. It is very difficult to identify
> the entire address range of, for instance, ms.uu.net pops or psi.net
> pops so any other tricks that can stop the spam from these is really
> helpful. These providers have so many pops, spread over most but not all
> of entire class b networks, and they certainly don't seem willing to
> tell us what address space they are in. It would be really useful to be
> able to ban anything that reverse resolved to, say, *.ms.uu.net. Right
> now I try a scattershot approach at reverse lookups by hand to try to
> find the appropriate address and netmask needed to get chunks of their
> address space.


Yes this is an enormous and growing problem.

I've started a campaign to have all dial-up providers lock their
customers into only the provider's mail gateway by way of filtering all
port-25 connects from the dial-up ports (in conjunction of course with
IP anti-spoof filters).

Some providors are vehemently opposed to my campaign. Others want to do
it but cannot for one administrative reason or another (one large
5-letter ISP can't because they cannot fathom the effort it would take
to correctly implement such filters in all the zillions of machines they
use to build their many dial-up networks.

Some are worried that the filtering will impact throughput, but of
course if they were already filtering against IP spoofing this would
only be one more rule and for an intelligent filter system it would only
trigger on TCP connection attempts.

Some are considering it, but as yet I don't think anyone I've spoken to
has actually implemented it.

Every time I receive a spam that's the result of a dial-up abuser,
esp. when the said abuser illegally uses third-party relay in a foolish
attempt to hide his tracks, I kindly insist that the aubser's providor
implement such filters ASAP in hopes of avoiding the inevitable
anti-abuse abuse that will flood their postmaster and contact
addresses.

The worst offenders perform such abuses from one-time throw-away
accounts, and when you can get such accounts for as little as a $5USA
charge, probably on a stolen credit card as some ISPs have told me.

Almost all corporate networks I've worked on, and esp. those that are
protected by a firewall, do this to their users, though for different
reasons.

However for the time being most PC mail clients and most spammer
shareware fails to use the correct hostname with HELO/EHLO
announcements and thus verifying that the HELO parameter matches the
source address often stops them dead in their tracks. Even some
professional spammers get caught by this trick. It is of course only a
trick as anyone with half a brain could easily write a mailer that
always announced itself with the correct doamin literal IP number for
the source address of the outgoing socket connection. In the mean time
the HELO/EHLO verification I've implemented in the most recent beta
versions of Smail does the job and I think Exim would well benefit from
this capability.

> All this is, of course, just a holding action. The amount of damage
> someone can do to a mail server with just a 28k modem is depressing.


I recently corresponded with an academic site in Brazil which had only
just increased their bandwidth when they were struck by a dial-up
spammer who dumped over 4000 RCPT TOs on them for each of many large
messages and eventually totally crashed their mail machine (after having
annoyed several tens of thousands of users resulting in a second crash
from the anti-abuse abuse that flowed in after they'd deleted the queue
and re-booted).

-- 
                            Greg A. Woods


+1 416 443-1734      VE3TCP      <gwoods@???>      <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>