Criminals, The Network, and You [Was: Something Else]

Tue Sep 18 13:06:37 UTC 2007

On Wed, Sep 12, 2007 at 03:43:22PM -0600, Jason J. W. Williams wrote:
> In my opinion, the first and fourth statements are not necessarily in
> conflict. A reputation system based purely on reverses is pretty broken.

Actually, it's amazingly reliable, when the patterns (literal string
matches and regular expressions) are carefully compiled and cross-checked.

One example of the thousands of patterns I block outright is *.fios.verizon.net.
I do this (a) because I'm seeing lots of spam from generically-named hosts
in that subdomain, e.g., within the last hour attempts have been noted from:

	relay=pool-71-164-205-139.dllstx.fios.verizon.net [71.164.205.139]
	relay=pool-71-170-104-162.dllstx.fios.verizon.net [71.170.104.162]
	relay=pool-71-170-70-195.dllstx.fios.verizon.net [71.170.70.195]
	relay=pool-71-172-239-30.nwrknj.fios.verizon.net [71.172.239.30]
	relay=pool-71-189-201-76.lsanca.fios.verizon.net [71.189.201.76]
	relay=pool-71-190-246-40.nycmny.fios.verizon.net [71.190.246.40]
	relay=pool-72-73-220-84.cmdnnj.fios.verizon.net [72.73.220.84]
	relay=pool-72-76-240-99.nwrknj.fios.verizon.net [72.76.240.99]
	relay=pool-72-84-85-199.nrflva.fios.verizon.net [72.84.85.199]
	relay=pool-72-89-97-187.bflony.fios.verizon.net [72.89.97.187]
	relay=static-71-183-52-18.nycmny.fios.verizon.net [71.183.52.18]

(b) because I've yet to receive a single report of a false positive from
this pattern after using it for a considerable period of time and (c) because
Verizon seems disinclined to do anything about the problem other than
have their paid professional spokesliars repeat the usual B.S., viz.:

	http://www.theregister.co.uk/2007/09/10/isps_ignore_strorm_worm_and_other_malware/
	ISPs turn blind eye to million-machine malware monster
	By Dan Goodin in San Francisco
	Published Monday 10th September 2007 06:02 GMT

	[...]
	Verizon turned down requests for an interview with a security
	engineer, but a spokeswoman said officials are aware of the
	rankings and are working to put new measures in place by the end
	of the year to curb the spam flowing out of its network. "We are
	concerned about it," the spokeswoman, Bobbi Hensen, said. "We
	don't like spam. We are aggressively working on that."
	[...]

Uh-huh.  This problem was reported to Verizon roughly FIVE YEARS ago,
and should have, of course, been competently addressed withing a matter
of days.  It hasn't been.  There is no sign that it will be.  It's therefore
been necessary for those of us enduring torrential quantities of
Verizon-originated abuse to take appropriate defensive actions.

Like rejecting all SMTP traffic from *.fios.verizon.net.

And Verizon is merely one of the offenders -- the article cited above lists
several others.  I just happened to single them out for use as an example
here because I found the contrast between their years-long history of utter
negligence and their officially-stated position to be particularly striking.
Comcast, Charter, SBCGlobal, Ameritech, Level3, SWBell, Nextgentel, Pacbell,
and Qwest, just to name a few off the cuff, are equally culpable.

Anyway: the use of generic rDNS patterns for outright rejection turns out
to be quite effective with a very low FP rate.

> Regarding the second, you're absolutely right. It's not your
> responsibility if a 3rd party doesn't have a rDNS entry (at all or
> non-generic), however the reality is you're going to have to deal with
> it anyway. If your customers allow you to tell the senders to buzz off
> and fix it, that's terrific.  However, you're in a more authoritarian
> (IT-wise) environment than most I would suspect. Also, you risk hurting
> your customers. As an example, it's not a suitable answer to our law
> firm customers who are critically-dependent on receiving e-mail from
> hopelessly broken senders.

Any firm that is critically dependent on email (beyond an intranet
environment) is being naive and foolish by relying on a known-unreliable
communications medium.  Connections fail.  DNS breaks.  Servers croak.
Disks fill.  Poor software is deployed.  And the entire Internet-wide
infrastructure for mail is under constant stress from spam, DoS attacks,
misconfiguration, and outright stupidity (e.g. SAV).

As to hopelessly-broken senders, we do not do them any favors by
accomodating their brokeness.  It is better in the long term for all
of us to educate them about the not just the de jure, but the de facto
minimum requirements for mail servers -- which in 2007 include not
only functional rDNS, but rDNS pointing to non-generic hostnames.

---Rsk