Subject: [Asrg] Re: Asrg Digest, Vol 32, Issue 3

From: <[email-masked]>
Date: Sat, 03 Mar 2007 12:26:50 -0600

On Sat, 03 Mar 2007 12:00:22 -0500
> Date: Sat, 03 Mar 2007 11:14:56 -0500
>From: "Chris Lewis" <[email-masked]>
> Subject: Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0
> Cc: [email-masked]
> 
> [email-masked] wrote:
>> On Fri, 02 Mar 2007 23:19:03 -0500
>>  Stephanie Erin Daugherty <[email-masked]> wrote:
>>> Ok... I'm putting on my Nomex suit for this reply.
> 
>>> Routeable addresses are not inherently less secure. NAT 
>>>is not the
>>> only way, or even a good way to secure hosts. 
>> 
>> Securing the hosts is not the issue here.  Nor, in fact, 
>>securing
>> clients!  The fact is however that typical user desktop 
>>machines are
>> SAFER if just anyone anywhere on the Internet can't 
>>reach out and poke
>> them directly.
> 
> "Safer", but these days, NOT that much safer.  Most 
>spambots these days
> DO NOT require inbound connections from the Internet to 
>function, and
> therefore a NAT doesn't help, in fact becomes the 
>explicit hindrance you
> reported.

The problem is that most small businesses, when they 
arrange for an Internet connection, get a connection just 
like the one my client company got.  Their telephone 
company installs a NAT router, hooks it up somewhere in 
cooperation with their telephone service, and they're 
online.  When I first had a home ISDN connection, I had a 
fixed and routable IP address, but those days are gone 
(and were even gone back when I still had ISDN).  Nowadays 
most providers are loathe to assign fixed IP addresses.

The other problem is that most small businesses don't know 
anything about networking at that level, and they only see 
their NAT router as "that box on the wall" and usually 
don't even have any tools to administer it.  Usually that 
administration (which is little or none, generally) comes 
from their phone company.

Most such small companies don't have either IT or 
telecomm/networking people on-staff.  In my case, the 
company arranges their Internet connectivity through 
another company, and as their computer support consultant 
I haven't in the past directly talked with their Internet 
connectivity people.  It appears that I will have to 
become more involved there, and to set up their router 
more in awareness of the system's needs.

>> That's fine for companies like General Motors or Ebay or 
>>Amazon.  What
>> you're suggesting is arguably inappropriate for a 
>>15-person company with
>> NO inhouse IT staff at all (say, a doctor's office). 
>> We're talking
>> about a company here that uses ONE single Novell server 
>>running the
>> whole company.
> 
> Securing the NAT so that _only_ that one single Novell 
>server can reach
> the Internet on port 25 would have most likely 
>completely eliminated the
> problem you were seeing.

IF they used that Novell server for mail, yes.  But that's 
not the case.  The company president prefers normal 
Outlook and the separate-ISP POP3 mail solution they were 
using long ago (and I have tried to argue them away from 
that).

>> Ironically, the solution we (at least initially) had to 
>>go to involved
>> us moving AWAY from our inhouse outgoing MTAs, and 
>>having to ENABLE the
>> applications at individual user desktops to route their 
>>e-mails directly
>> to out-of-house servers.  This is neither safer, but 
>>also is MUCH slower
>> as viewed by the users than allowing their inhouse mail 
>>servers to
>> buffer such operations.
> 
> That also works to get your "critical" email out, but 
>won't prevent the
> NAT from abusing the Internet if you haven't also 
>secured the NAT
> against outbound port 25 connections.

Agreed on both counts.  A better solution would probably 
be to put better outgoing by-application firewall 
protection on each of their client PCs.

>> 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.

>>  (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.

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.

[snip]

>> 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.

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.

> You need to live with it.  Hence, the BCP effort to make 
>it at least
> minimally consistent/predictable.

I believe that the BCP effort needs to look less like an 
endorsement of the principle, and more like an effort to 
at least additionally sensitize folks to the problems with 
the approach.

> Ranting and railing against a technology that so much of 
>the industry
> has decided to embrace is pointless.

I think they are grasping at straws in an attempt to solve 
a serious and growing problem, using the only tools they 
are aware of.  If the only tool you have is a hammer, you 
try to make every problem look like a nail.

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.

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!).

Gordon Peterson
http://personal.terabites.com
1977-2007  Thirty year anniversary of local area 
networking

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 03 Mar 2007 14:29:30 -0500

>>> 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.

>>> 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

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
>> 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

> 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.