Re: [vox-tech] smtp question - blocked ip
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] smtp question - blocked ip
On Mon, Jan 06, 2003 at 08:56:57AM -0800, Joel Baumert wrote:
> On Mon, Jan 06, 2003 at 08:21:59AM -0800, Ted Deppner wrote:
> > The only real problem an RBL could ever have is in it's human management,
> > listing/delisting processes specifically. That isn't a problem inherent
> > to RBLs... that'd be a problem for anything, anti-spam services or not.
> Pete's problem of being blocked because your ISP has been blocked is
> a biggie... Many people with access to broadband have limited if any
> choices about who their ISP is because of lack of competition, money,
> long term contracts, etc. To have your machine be "collateral" damage
> to an RBL for what could be an innocent reason is a problem.
Exactly my point regarding the human management.
Be sure not to miss the intentions thought... If pacbell was blocked
because of reasons most consider poor (as in this case), then it's
unfortunate to have collateral damage. If however, pacbell is a hotbed of
spam, having them blocked is excellent, and everyone would applaud such
The "usenet death penalty" 5 or more years ago served essentially the same
function for Usenet as RBLs do for SMTP. They were opt in, run by humans,
usually a well defined though obscure methodology for being considered an
abuser, etc. UDPs were exceptionally useful in getting usenet news
servers to behave properly.
An important point... "proper behavior" is defined by majority public
opinion. Many people "subscribed" to UDP and therefore it had power.
Same situation with PAN-AM's RBL. Majority public opinion in this case
said PAN-AM made a mistake... PAN-AM admitted as much shortly thereafter.
These blacklist services CANNOT have more power than the public gives
them. These services therefore serve to enforce majority public opinion.
There is therefore nothing intrinsically wrong with them... at least not
over time. Systems that perform well are "promoted" in public opinion,
those that aren't are demoted, thus lowering there effectivity and
usefulness, and power.
> One of the examples in the article is an ISP being blocked because it
> allows a SPAMer to sell their software is idiotic. The SPAMer isn't
> sending SPAM from the site so _WHY_ add it to the list?
If the ISP is deemed to be SPAM friendly, then it is appropriate to block
it in an attempt to bring its behavior into publically accepted norms.
Yes, assessing the involvement of collateral sites is problematic, but the
only real question is at what point this is appropriate. The concept is
Alegory: Why "attack" the employees of a retail store by boycotting that
store because of a product the store carries is produced by a company that
supports animal testing or overseas sweatshops? Those employees will lose
their jobs if the retail store goes under... At some point, public
opinion places blame collaterally. The only question is at what point.
> Your right the human factor is the problem with RBLs, and it is not an
> easy one to get around.
It is exceptionally easy to get around. There have always been
alternatives, black sheep, hermits, anarchists, other countries, etc, etc.
Get another ISP. Get another mail server. Setup a VPN to somewhere else.
Have a friend help you. Whatever. This should be the least worry for
anyone with a linux/open source background. There are literally hundreds
of alternative ways to get things done. The only thing in question is the
creativity to find them.
I had one of customer facing SMTP servers be used to transit spam (not an
open relay, but a relay none the less), and we were blocked by SpamCop.
SpamCop IMHO is a nearly useless service as an RBL (it's other forms *are*
useful if you want them, but as an RBL it's too aggressive for sitewide
I fixed the problem, shutdown our offending customer, deleted all the
spam, and changed our server's ip address. I didn't rail against
spamcop... they were doing what spamcop does, and obviously enough of the
public likes them as an RBL to give me enough problem that I needed to
adapt... not simply complain and rail. The adaptation took minutes, and
with the problem resolved, we didn't get blocked again.
> The second problem with RBLs is legality, from what I remember
> at least one RBL has been successfully sued for restraint of trade :-(.
There's not an ISP on the planet that is legally bound to deliver anyone's
email. It is a courtesy service, not a contractual obligation. If I
started dropping all mail with "lugod" in it, there's nothing illegal
about that. I may not be in business the next day because I've upset my
customers, but nothing illegal would have happened.
Now, regarding restraint of trade, that too is often overblown. Since I'm
not legally or contractually obiligated to transit any email at all, and
restraint of trade has to do with monopolies, antitrust, and money, there
can be no restraint of trade.
Consider if someone tried to sue UPS over "restraint of trade" because
they refuse to ship hand grenades. They're not legally or contractually
obligated to ship anything from anyone to anyone. They take business
where they want to. UPS could refuse to ship into Sacramento if they
wanted, and they could not be sued for "restraint of trade"... UPS can
make business decisions about how, when, where, and what they ship. If
they choose wisely, they'll be a successful business... if not, well...
As the services netizens utilize daily reach global ubiquity and we rely
on them heavily, we must not forget the realities of what these services
really are. SMTP is Simple Mail Transfer Protocol. It is not a
government regulated service. It is not the United States Postal Service.
And so forth.
> I guess the moral to the story is that people should not depend on
> entirly RBL's when making automated decisions on SPAM and just use it
> as a indication that something could be.
I personally agree with this... I always check the results of my personal
blocks, and actually flag everything, then let my mailing lists deliver,
and then send stuff to a holding pen. I don't like false positives.
I run very conservative RBLs at my employer, and more aggresive ones at
> I have been using spamassassin for about two months now and have been
> _very_ happy with the results. For my wife it has blocked >530 SPAM
> messages with only 3 incorrect blockings (fixed with a procmail rule).
> She still got about 50 messages a month, but that is _significanly_
> less than what we had before.
IMHO, systems that have false positives (due to false matches like
spamassasin uses) are utterly useless. RBLs, which penalize bad sites,
occasionally generating false positives, but which are known to come from
bad sites are an acceptable and thus far, necessary evil.
> I decreased some of the SPAM before with iptables rules blocking
> a list of RIPE and APIN networks, but stopped after getting the
> assassin working. When I get time I'll probably add some rules that
> give those networks enough points to get my SPAM from those networks
I've written one adaptive spam block system, which I believe has great
potential. Yahoo already does it too, so it can't be that bad. For a
large ISP, you track what IPs are generating high amounts of bounced
messages (due to bad addresses, users over quota, etc), and simply block
that IP (or class C if there's several single IPs), and you've knocked the
wind out of most spammers.
These sorts of "proactively reactive" methods are superior to anything
requiring human intervention, profiling (eg spamassassin), or static
lists, as far as I'm concerned. We get to "close the loop" on the bad
guy, automatically, instantaneously, and not deny a single valid
connection. (SpamCop is also proactively reactive, but it's tuned too low
to be useful to a large ISP, and it's human intensive to qualify what is
> I would be interested to read what you think is a good piece on
> the topic...
There's some of my thoughts... anyone else?
I don't really collect URLs on these items, and I don't know where people
really discuss this stuff. I've been on my own in this area for a while.
vox-tech mailing list