Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0
2007-03-03 01:03:20
On Fri, 2 Mar 2007 21:43:58 -0600
"Al Iverson" <aliversonchicagolists(_at_)gmail(_dot_)com> wrote:
On 3/2/07, gep2(_at_)terabites(_dot_)com <gep2(_at_)terabites(_dot_)com>
wrote:
As you know, in a recent thread I commented on what a
LOUSY solution IP-address-based blacklists are, in
general.
Part of the problem is that it is a VERY blunt
instrument,
especially for companies which operate a large network
from behind a NAT router.
Take blacklists out of the equation, and it doesn't
solve your problem.
The key problem is that an ENTIRE COMPANY can be put out
of business for DAYS by ONE IP address getting blocked,
and as the company gets more dependent on E-mail and gets
more computers, the statistical likelihood that some day
one of them will get infected gets higher and higher.
Much of spam identifying, filtering, and blocking is
based on the
sending reputation of an IP address.
Right. And IP addresses are a LOUSY way to base that, for
a whole variety of reasons.
It has moved far beyond being
blacklist specific, and that train has long left the
station.
IP address-based email reputation mechanisms did not
even necessarily
come about due to the rise of blacklists. An IP address
has always
been a readily measurable identifier allowing one to
denote the source
(or at least the previous hop) of a certain piece of
mail.
Yes, and I guess the reason why people try to use it IS
because it is so obvious... without ever asking (or more
to the point, ANSWERING) the issue of whether it is a GOOD
basis.
In part because, yes, it DOES only identify the previous
hop. In point of fact, it is difficult to go back behind
that previous hop; certainly you cannot be 100% sure WHO
the original sender really is, especially if Received:
headers have been forged.
A very
common identifier, and widely used to identify a mail
source in many
different situations, for years and years.
The fact that it has been used for a long time does NOT
make it automatically an intelligent choice to use for
spam control... as my own recent and very dramatic
experience demonstrates VIVIDLY.
I grant it's not always the most granular identifier.
Absolutely. It is SUCH a blunt instrument that I firmly
believe it is TECHNICALLY IRRESPONSIBLE for any
intelligent person to propose basing almost any kind of
spam control scheme upon it.
I just fail to
see blacklists as reason this sucks. Seems to me like
you're tilting
at the wrong windmills.
What I object to, and after this last week more
strenuously than ever, is this serious tendency of this
group to seemingly inevitably gravitate back to this
"death spiral" mode centering around idiotic and
ultimately counter-productive blacklisting (or other
"reputation") strategies based on IP addresses!
Again, this is counter-productive because it tends to
force companies AWAY from having their internal networks
protected by NAT routers and thus, not having their
internal machines protected by using
non-externally-accessible, non-routable IP addresses. It
also encourages, consequently, an unpleasant demand for
large numbers of new, routable IP addresses which would
otherwise not be needed.
Al Iverson
--
Al Iverson on Spam and Deliverabilty, see
http://www.aliverson.com
Gordon Peterson
http://personal.terabites.com
1977-2007 Thirty year anniversary of local area
networking
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, (continued)
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, Steve Atkins
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, Daniel Feenberg
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, der Mouse
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, Seth Breidbart
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, Al Iverson
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0,
gep2 <=
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, Stephanie Erin Daugherty
- Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0, gep2
|
|
|