ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0

2007-03-02 18:31:50
<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.

I'll admit they tend to work better for recipients than senders.

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.

Whose fault is that?  If you do something stupid, and the results are
bad for you, blaming others isn't going to accomplish much.

Businesses which count on reliable AND TIMELY e-mail 
transmissions simply cannot have their E-mail 
transmissions blocked "en masse" like this.

Note that the "cannot" is from their viewpoint, not mine.

If it is so critically important to them, perhaps they should have
taken better care to ensure that it works.

If I needed such email transmissions, I'd set up a separate server on
its own IP address and ensure that _only_ the business-general email
came from it.

Not being able to issue credits, deliver invoices, and 
send price updates (and in the oil and gas business, 
prices change daily) is a monumental burden on a company 
which is guilty of nothing more than being a victim,

It is guilty of emitting spam, by your own admission.  Whether it
should be considered "nothing more than [...] a victim" or "an
accident waiting to happen" is a judgment call.

Worse, from a Internet strategic standpoint, the dangers of this
kind of blunt-instrument blocking of E-mails for AN ENTIRE COMPANY
just because ANY ONE computer within their network is infected (and
it could even be an infected notebook computer carried in from home
and connecting to the office wireless LAN) will force more companies
to insist on MORE DANGEROUS separate, routable IP addresses for each
machine in their company.

First, there are many in-between stages (such as a mailer on its own
IP address while internal computers are NATted).  Second, how much
more dangerous can it be than the current method which already failed?

Ultimately, this "solution" just puts dramatically more (and very
unwanted) pressure on the limited IP address space, and INCREASES
the likelihood of getting the company's machines infected since now
their machines each have a real, routable IP address that can be
attacked by scanners and other exploits originating from outside the
company.

And if the company is sufficiently incompetent to permit such
infections, it will soon find its entire netblock listed, meaning that
the so-called "solution" doesn't even work.

 I can't overemphasize what a huge disruption this is to a company
(and again, one which DOES make a serious effort to be responsible!)

Obviously not serious enough.

 We are arguing the finer points about what is 
INHERENTLY a VERY flawed approach,

It works for me.  If you don't like it, don't use it.

AS A CONCEPT, where what we OUGHT to be doing instead is to figure
out better and more effective ways to efficiently and accurately
DIFFERENTIATE good mail from bad.

When you have a better one, I'll use that too.

As I have pointed out, such an approach would (in the example I
gave) efficiently perform such triage on the messages coming from
dear old Aunt Gertie's machine, allowing her legitimate mail to
continue to be delivered while effectively guaranteeing that the
spambot-generated garbage running on her same machine and transiting
the same server(s) would be T-canned and never seen by a human (and
therefore, hopefully, not be worth injecting into the Net in the
first place).

Spammers would still send, and now there would be much less incentive
for a company to disinfect its machines and keep them clean.

Seth

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg