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

[Seth Breidbart]

<gep2 at terabites.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