ietf
[Top] [All Lists]

Re: Why Spam is a problem

2002-08-16 11:38:57
Also note that many of the Tier-1 providers have a financial disincentive
to do anything, as they are merely paid to move traffic - and the more spam
the more traffic and thus the more income.  The last thing they want is
for a successful anti-spam campaign when there's already a bandwidth glut
in the core....
--

Yeap! A successful anit-span ban can easily translate into more bandwidth glut,
which can mean less networking equipments being purchased and installed, which
in turn can translate into more Engineers being out of work.

No,..let them transmit the span. Just bridge it at the end point. You need to
give the
end user the power to decide if what is coming in is span or not. One man's span
could be another persons  life-saver.  The first time I get mail from source A,
if
it is span to me, I click on a menu that says "block" from source A,..and that
should be it.

Cheers,
Alex.

Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

On Fri, 16 Aug 2002 12:56:21 EDT, Bill Cunningham said:

So the responsibility should be placed on lower tier ISPs, what about the
main backbone like MAES.

Note that there's a *lot* of private peering agreements in place, and traffic
exchange points like MAES don't see all the traffic.  In addition, it's
tough enough to just *route* traffic at OC-48 speeds, trying to do filtering
intelligent enough to determine spam/not at line speeds is quite formidable
(hint - at OC-48, you're going about 300 Mbytes/sec - this means with a 3K
e-mail, you have all of about 10 microseconds to make a decision before you
start causing delays).

I won't even start contemplating what happens at OC-192 trunks.

Also note that many of the Tier-1 providers have a financial disincentive
to do anything, as they are merely paid to move traffic - and the more spam
the more traffic and thus the more income.  The last thing they want is
for a successful anti-spam campaign when there's already a bandwidth glut
in the core....
--
                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature



<Prev in Thread] Current Thread [Next in Thread>