-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
gep2(_at_)terabites(_dot_)com wrote:
On Sat, 03 Mar 2007 12:00:22 -0500
Date: Sat, 03 Mar 2007 11:14:56 -0500
From: "Chris Lewis" <clewis(_at_)nortel(_dot_)com>
Note that the blacklisting taking effect at E-fax, specifically (and
which suddenly prevented the company from sending out more than 500
faxes a day) happened at least three days after (TTBOMK) the infection
HAD been cleared up.
Three days _after_ you removed the listing? That seems unlikely.
No, three days after I removed the INFECTION. I'm just reporting what
actually happened. In any case, it appears that many users of RBLs only
update their lists every few days.
Removal of the infection has very little to do with the listing - how
does a DNSBL that detects infected email emission know when you removed
an infection? It only knows when it emits. It can't guess at a negative.
(Of course, who can be sure? The blacklisting
company doesn't tell us EXACTLY what they were blacklisting us for).
Did you ask? The CBL (main component of the XBL) is pretty good at
explaining what happened.
CBL explained that XBL was the cause.
That's wrong. I'm astonished that you got it that wrong.
The CBL would do no such thing. The XBL is a composite of two DNSBLs -
NJABLproxy and CBL. If you want an IP out of the XBL, you have to deal
with the CBL or NJABLproxy.
Given that the CBL is something like 95% of the XBL, the CBL is usually
the right place to go.
The CBL has self-removes, which you'd immediately see if you did a
lookup there. Once removed from the CBL, it disappears from the CBL and
XBL publication within about an hour.
I tried at XBL. Their (XBL) Web site makes it fairly clear that they
don't even read such questions, only just archive them for later
research or some such. They explain what sorts of things get a company
onto XBL, but aren't specific about specifically what got MY client
company onto there.
They also tell you to go to the CBL.
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.
Sorry, the industry has already decided that issue. The fact that so
much of your customer's email was blocked by administrators explicitly
making the choice to use IP-based filtering means that this genie CANNOT
be put back in the bottle.
I disagree.
The administrators of 100s of millions worth of end-users disagree with
you. The proof is in the effect of a XBL or PBL listing.
First of all, I think that we ought to include explicit warnings in any
document discussing BCPs that IP-based RBLs are inherently flawed, and
that our recommendations should be viewed as less an endorsement of that
approach than an attempt to minimize the expected collateral damage.
Second, thirty years ago "the industry had decided" that mainframes were
the way to do business processing, and to propose anything different
than that was laughable. Nobody at the time was proposing LANs of small
computers as a serious alternative, but once that was done (and once the
advantages of that approach became apparent) the industry shift was
inevitable. The same in this case... if we can give people something
that DOES solve the problems, or at least which does so better than the
previous approaches (which have NOT), then I believe that the older
approaches will fade.
Ah, but you forget, the movement from mainframes to LAN business models
had (a) an economic incentive and (b) took about 20 years.
So far, the economic incentive is to continue using DNSBLs, and are you
planning on waiting 20 years?
To get anywhere, you have to find something that works even remotely as
well as DNSBLs.
Lots of smart people have been working on this problem for a long time.
None of them have come up with more effective solutions. Neither have you.
I really think that a better solution is that which a previous post also
touched on... a cooperative "reputation" system between the sender and
recipient, where the recipient's end "knows" that they expect to receive
from who... with suitably protective defaults for initial mails from
previously unestablished senders.
In my case, each time I start doing e-mail I go and remove all the
messages recently added to my Inbox which have nondescript or
nonsensical subjects. I will keep many of those vague or unfamiliar
subjects if I recognize the name of the sender. This is an informal
(and manual) version of the principle I've proposed... a set of
standards for acceptance based on who the sender is, and my recognition
of them.
You really don't have a grasp of how bad the problem is, do you?
Have you had to cope with this in the sense of 1000 or more spams per day?
In fact, most evaluations I've seen to date show that properly chosen
DNSBLs have a higher accuracy rate than human beings do.
Another poster suggested that VC firms would be happy to pony up money
to finance a startup with a good solution to the spam problem... but the
problem with that is that such a solution really WANTS to be integrated
into an E-mail client program, and one which is widely used. People are
loathe to change E-mail client software. This is one of those places
where most startups don't really have a chance... companies either use
Exchange/Outlook or Lotus Notes or some such, and individuals use
Outlook Express, Thunderbird, or some other such client. Getting a good
solution built into Outlook and Outlook Express would be the way it
should be done. It's not a problem that can be solved by an expensive
enterprise-type solution, since so many of the problems occur with
unsophisticated home users, or at very small companies that run with
minimal IT expertise (and budget!).
Don't you think that M$, Thunderbird etc. haven't been trying to come up
with a better solution?
Even Microsoft uses DNSBLs, despite having in the past come out against
them. Because they work better than anything else they've come up with,
despite having thrown an awful lot of money at the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
iQCVAwUBRenMmp3FmCyJjHfhAQJUkAP+KVQBXmSXHD0UgtquxteY+Nv99dE4ysfV
lxhH02bahwH3XGTdKhFYRgIS64n5aCSvNhW57qdw3e7h+7hkPaAZUNB4b3oL3duD
G6WrH03UAF98wjAPhzAYreE7tM3BCeac3waOFBLlLMagKunbBwPKXg2D2r4Gw3jg
oA0g++QUT08=
=X/t2
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg