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

From: <[email-masked]>
Date: Fri, 02 Mar 2007 18:01:16 -0600

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.

Well, I've recently been personally involved in trying to 
put out just such a fire at one of my consulting clients.

The client company is an oil and gasoline distributor. 
 Each evening the software system I built and maintain for 
them sends E-mails and fax-by-e-mail price updates to 
their customers.  It also automatically generates and 
routes invoices, credit memos (for example, the amounts of 
the 'pay at the pump' credit card transactions they 
handled the day before) to their customers.  They probably 
send something approaching a thousand such 
business-critical E-mails and fax-by-E-mails per day.

All works well until about a week and a half ago, one of 
their computers managed to get infected by some kind of 
exploit (despite every machine in the company having and 
running Symantec Antivirus software which is updated 
daily).  We found the problem within 24 hours and managed 
to clean it all up, (hopefully!) but meanwhile at least 
one or two E-mail blacklists (including XBL) flagged the 
IP address of the company's router, and starting on the 
21st some of their E-mails stopped getting delivered due 
to the blacklisting.  By Saturday, as more ISPs picked up 
on the new list, E-fax (who processes and delivers their 
fax-by-e-mail transmissions) suddenly started bouncing 
even their outgoing fax attempts (even though their 
systems had been clean, as best we can tell) for at least 
two or three days already.

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

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, just 
like so many other companies and individuals have been 
(and, doubtless, will continue to be).

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.... so that 
blocking will affect JUST ONE of their machines and not 
put the whole company out of business.  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.

It has taken me personally much of the last week to try to 
mitigate the problems for my consulting client... managing 
communications with the blacklisting organizations (since 
nobody at the client speaks their technical language), 
making numerous and ongoing system configuration changes 
to reroute outgoing mails, establishing new message 
handling paths, and then going back and regenerating and 
retransmitting thousands of backlogged invoices and 
credits notices that could not be delivered in the normal 
way.  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!)

Not to mention the huge disruption to their "ordinary" 
NON-system-generated e-mails with their clients and 
suppliers.

So, again, I will EMPHASIZE that the question should NOT 
revolve around the finer points of how to implement 
IP-address-based blacklists, who should maintain them, how 
to distribute them, how to phase them out eventually, and 
such CRAP!!  We are arguing the finer points about what is 
INHERENTLY a VERY flawed approach, rotten to its very core 
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.

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

Key to this triage, I believe is:

    1) denying spammers and abusers (in a robust way!) the 
ability to conceal or obfuscate malicious or spam content 
by ruses based on HTML, text-as-image, scripting and the 
like;

    2) forcing at least initial-contact e-mails (those by 
which a sender establishes a trust relationship with the 
intended recipient) be sent in plain text so that they can 
be analyzed effectively by a SpamAssassin-style analysis 
program;

    3) allowing a recipient to control just exactly what 
sort of more advanced content they are ready and willing 
to accept from each specific sender, and (ideally) how 
they wish to additionally establish the legitimacy of that 
sender's messages.  (Prearranged masthead on a newsletter, 
personal SIG file for mail from an individual, 
characteristic keywords in the message or subject line, 
etc etc).

Here on this list, we keep falling back into this nasty 
business of arguing about how an INHERENTLY FLAWED scheme 
(and I'm talking about IP-address-based blacklisting) 
should be done, rather than recognizing ONCE AND FOR ALL 
that it is simply a ROTTEN IDEA FROM THE BEGINNING and 
that we OUGHT to be working on finding a BETTER solution 
which is better long term both from the standpoint of 
CONTROLLING spam, of encouraging (in a practical way) 
responsible computing, and which isn't just encouraging 
these costly, ineffective, and ultimately 
COUNTERPRODUCTIVE games of after-the-fact "whack-a-mole".

We OUGHT to be working on preventing spam (and viruses) 
from getting delivered THE FIRST TIME, rather than 
worrying about locking the barn door after the horse has 
already gotten out...!

Dammit, people, we keep going back to what color fabric 
we're going to use to upholster the "whack-a-mole" mallet, 
rather than coming up with a real SOLUTION for this 
problem...!!!  :-((

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: Steve Atkins <[email-masked]>
Date: Fri, 2 Mar 2007 16:21:20 -0800

On Mar 2, 2007, at 4:01 PM, <[email-masked]> <[email-masked]>  
wrote:

[snip story of "my customer is an idiot with their mailserver and  
their virus farm NATted to the same IP address"]

> Dammit, people, we keep going back to what color fabric we're going  
> to use to upholster the "whack-a-mole" mallet, rather than coming  
> up with a real SOLUTION for this problem...!!!  :-((

The main problem in this case is NATs, and the clueless consultants  
who specify and deploy them. The solution is to not put critical  
services behind them.

Cheers,
   Steve

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 2 Mar 2007 16:29:53 -0800 (PST)

On Fri, 2 Mar 2007, Steve Atkins wrote:

> On Mar 2, 2007, at 4:01 PM, <[email-masked]> <[email-masked]> wrote:
>
> [snip story of "my customer is an idiot with their mailserver and their virus 
> farm NATted to the same IP address"]
>
>> Dammit, people, we keep going back to what color fabric we're going to use 
>> to upholster the "whack-a-mole" mallet, rather than coming up with a real 
>> SOLUTION for this problem...!!!  :-((
>
> The main problem in this case is NATs, and the clueless consultants who 
> specify and deploy them. The solution is to not put critical services behind 
> them.

You maybe forgetting clueless IT managers that force use of NAT as a
policy in some organizations. Even more it maybe defined by circumstances 
and type of router and internet connection they have. Plus such
organizations need something done and and quickly and don't care
if some consultant says they should not be using nat - the question
asked, can you do it or not?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 02 Mar 2007 20:01:19 -0500

william(at)elan.net wrote:
>>> to use to upholster the "whack-a-mole" mallet, rather than coming up
>>> with a real SOLUTION for this problem...!!!  :-((
>>

And/or certainly not share them with vulnerable desktops.  And restrict
port 25 outbound from the NAT except from machines intended to send
email.  Don't share business critical infrastructure with desktops,
because you're at the mercy of what they do.

When an IP acts like a bot, one must expect it to be treated as one.

We don't have a choice.

It also strikes me as odd that an XBL hit would present much of a
problem for more than the first hour or two after it was discovered.
Presuming it was a CBL listing, those can be self-removed, and they take
effect fairly quickly.

> policy in some organizations. Even more it maybe defined by
> circumstances and type of router and internet connection they have. Plus
> such

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 2 Mar 2007 20:03:11 -0500 (EST)

On Fri, 2 Mar 2007, [email-masked] 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.
>
> Well, I've recently been personally involved in trying to put out just such a 
> fire at one of my consulting clients.
>
> The client company is an oil and gasoline distributor. Each evening the 
> software system I built and maintain for them sends E-mails and fax-by-e-mail 
> price updates to their customers.  It also automatically generates and routes 
> invoices, credit memos (for example, the amounts of the 'pay at the pump' 
> credit card transactions they handled the day before) to their customers. 
> They probably send something approaching a thousand such business-critical 
> E-mails and fax-by-E-mails per day.
>
> All works well until about a week and a half ago, one of their computers 
> managed to get infected by some kind of exploit (despite every machine in the 
> company having and running Symantec Antivirus software which is updated 
> daily).  We found the problem within 24 hours and managed to clean it all up, 
> (hopefully!) but meanwhile at least one or two E-mail blacklists (including 
> XBL) flagged the IP address of the company's router, and starting on the 21st 
> some of their E-mails stopped getting delivered due to the blacklisting.  By 
> Saturday, as more ISPs picked up on the new list, E-fax (who processes and 
> delivers their fax-by-e-mail transmissions) suddenly started bouncing even 
> their outgoing fax attempts (even though their systems had been clean, as 
> best we can tell) for at least two or three days already.
>
> Businesses which count on reliable AND TIMELY e-mail transmissions simply 
> cannot have their E-mail transmissions blocked "en masse" like this.
>
> 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, just like 
> so many other companies and individuals have been (and, doubtless, will 
> continue to be).
>
> 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.... so that blocking 
> will affect JUST ONE of their machines and not put the whole company out of 
> business.  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.
>
> It has taken me personally much of the last week to try to mitigate the 
> problems for my consulting client... managing communications with the

<snip>

Can I ask why it was so difficult? Could you not change the IP address of 
the MTA easily? Perhaps your customer had only one? Perhaps you weren't 
aware that was possible? Certainly XBL doesn't list an entire address 
block on day one, so I assume that the infected machine was using the 
companies own smtp server as a smarthost and that is why the entire 
company was inconvinienced. Another possibility for the company is to use 
the ISP smarthost for its mail. It is quite rare for ISP MTAs to be 
blacklisted, though it does happen.  I understand that getting off 
blacklists is slow and difficult to speed up, but why is it the only 
solution?

I also refer you to http://www.nber.org/sys-admin/smarthost.html where I 
list some commercial smarthosts. While not free, the cost would be similar 
to an hour or two of typical consulting rates, for a year of smarthosting, 
by which time the original IP address would be off the blacklists.

Postings such as yours have more weight if they include the relevant IP 
address.

Daniel Feenberg
feenberg isat nber dotte org

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 02 Mar 2007 20:01:19 -0500

We don't have a choice.

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 2 Mar 2007 20:03:11 -0500 (EST)

<snip>

Daniel Feenberg

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Mar 2007 17:10:04 -0800

On Mar 2, 2007, at 4:21 PM, Steve Atkins wrote:

>> Dammit, people, we keep going back to what color fabric we're  
>> going to use to upholster the "whack-a-mole" mallet, rather than  
>> coming up with a real SOLUTION for this problem...!!!  :-((
>

Everyone can agree that Black-hole lists can be a PITA.  Australia's  
has a good approach, but it requires international cooperation.  The  
Opt-Out provisions of the US CAN-SPAM legislation must be struck when  
seeking broader International cooperation.  One can only hope  
legislators do not insist upon mandating a half-baked technical  
requirement, such as requiring everyone to publish SPF records  
without considering the greater problem these records can create.

A solution for coping with the immediate problem would be to relay  
outbound email through a trusted (better managed) provider.

There are also several websites that will assist you in identifying  
the black-hole lists.  If being black-hole listed is the only damage  
from an infected system, consider yourself lucky.

A black-hole search is available at:

http://www.moensted.dk/spam/

It wouldn't hurt to donate to this site, if it helps with your  
problem.  This page provides a link to the mail-abuse.com black-hole  
lists that must be checked separately.

-Doug

---

From: der Mouse <[email-masked]>
Date: Fri, 2 Mar 2007 19:56:36 -0500 (EST)

[[email-masked]]
> 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.

This is true.  That's a good reason to avoid putting mixed services
behind the same world-facing IP - whether with a NAT box, with multiple
daemons on a single host, or anything else.

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

No; they are also guilty of setting themselves up to be victimized.
That they were running something Symantec *could* run on indicates that
they were putting themselves at risk.

A man who writes his PIN on his bank card bears at least some of the
blame if the card is stolen and abused.  (Not all, but some.)  A woman
who routinely leaves her ground-floor windows standing open bears some
(not all, but some) of the blame if her house is burglarized.

And a company that runs Windows bears at least some of the blame when
(note I don't say "if") they get infected with malware.

> Worse, from a Internet strategic standpoint, [this] will force more
> companies to insist on MORE DANGEROUS separate, routable IP addresses
> for each machine in their company.... so that blocking will affect
> JUST ONE of their machines and not put the whole company out of
> business.

What's wrong with just arranging to not get infected in the first place?

> Ultimately, this "solution" just puts dramatically more (and very
> unwanted) pressure on the limited IP address space,

...IPv6...IPv6...IPv6...

(Yes, it's limited too.  The limit is so much higher, though, that in
practice I expect it to be at least another 25-50 years before it
starts to get uncomfortable - longer, if we can figure out how to route
in better ways, less related to connectivity topology.)

> 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 thereby increases the probability that they will actually get
*fixed* rather than just papered over.  I have trouble seeing this as a
bad thing.  (One of the very few bright sides I see in the current crop
of Windows malware is that it bringing evolutionary pressure against
Windows.  This is an excellent example of why I hate monocultures.)

> [...] such an approach would [...] 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 thereby removing any incentive for anyone to even clean up the
infection, never mind cleaning up the principal reason the infection
happened in the first place.  This is good?

["william(at)elan.net" <[email-masked]>]
>>> [...above-excerpted story...]
> policy in some organizations.

That's those organizations' problem.  Cluelessness on *your* part does
not constitute an emergency on *my* part.  (That's a generic "your",
not a personal one.)  Companies that can't/don't find non-clueless IT
managers may go under as a result.  This is a good thing.

> Plus such organizations need something done and and quickly and don't
> care if some consultant says they should not be using nat - the
> question asked, can you do it or not?

If you hire a consultant that way, you deserve everything you get.

Which, yes, may include going out of business.  This is bad...why?
There are many pitfalls in running a business, many mistakes that can
kill the company.  I don't see why you think this one should be
eliminated as a possibility.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 2 Mar 2007 20:29:44 -0500 (EST)

> LOUSY solution IP-address-based blacklists are, in 

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

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

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

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

> 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

---

From: "Al Iverson" <[email-masked]>
Date: Fri, 2 Mar 2007 21:43:58 -0600

> from behind a NAT router.

Take blacklists out of the equation, and it doesn't solve your problem.

Much of spam identifying, filtering, and blocking is based on the
sending reputation of an IP address. 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. A very
common identifier, and widely used to identify a mail source in many
different situations, for years and years.

I grant it's not always the most granular identifier. I just fail to
see blacklists as reason this sucks. Seems to me like you're tilting
at the wrong windmills.

Al Iverson

-- 
Al Iverson on Spam and Deliverabilty, see http://www.aliverson.com
Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission
is granted only to this lists's owners to redistribute to their sub-
scribers and to archive this message on site(s) under their control.

---

From: Stephanie Erin Daugherty <[email-masked]>
Date: Fri, 02 Mar 2007 23:19:03 -0500

Ok... I'm putting on my Nomex suit for this reply.

Posted and mailed:

[email-masked] wrote:
>
> 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.... so that blocking will affect JUST ONE of 
> their machines and not put the whole company out of business.  
Routeable addresses are not inherently less secure. NAT is not the only 
way, or even a good way to secure hosts. It may work for that in some 
situations, but it's less that optimal, and was never intended to 
provide security. (and in fact, there are countless tricks to break 
through NAT anyway these days).

NAT was created to deal with a perceived shortage in IPv4 addresses. 
It's not a magic bullet, and in fact, it's actually harmful in many ways:
http://www.cs.utk.edu/~moore/what-nats-break.html
http://www.faqs.org/rfcs/rfc1627.html

If you choose to present your entire network to the world as being a 
single machine, then, it and any abuse from it will be treated as such, 
that's just a chance you take. In this respect NAT is actually more 
dangerous, as the ability to account for what's happening stops at your 
network's border, and NAT is often substituted for proper security and 
network design - which includes use of application layer firewalls, 
intrusion detection, and application proxies to create and enforce a 
strong security policy.

Put your servers in a real DMZ, with real IPs, and a properly 
constructed firewall. Consider putting your users behind proxy servers 
instead of or in addition to NAT, so that they have exactly the access 
they require, no more, no less. Machines that don't send mail directly 
out to the internet shouldn't have the ability to do so. This is common 
sense.

Intrusion detection would have let you catch this earlier, probably 
before you were listed on DNSBLs.

> So, again, I will EMPHASIZE that the question should NOT revolve 
> around the finer points of how to implement IP-address-based 
> blacklists, who should maintain them, how to distribute them, how to 
> phase them out eventually, and such CRAP!!  We are arguing the finer 
> points about what is INHERENTLY a VERY flawed approach, rotten to its 
> very core 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.
>
There are also ethical implications which would suggest that any 
content-based approach is just as flawed, because it creates an 
infrastructure for censorship just as easily as it creates an 
infrastructure for stopping spam.
> 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).
>
If dear old aunt gertie is leaving her machine on the internet after 
it's been compromised by a virus, she either doesn't care, or doesn't 
know better, and in either case, is doing harm to others by her refusal 
or inability to deal with the problem, so she's arguably just as big of 
a problem as the virus itself.
>    1) denying spammers and abusers (in a robust way!) the ability to 
> conceal or obfuscate malicious or spam content by ruses based on HTML, 
> text-as-image, scripting and the like;
>
>    2) forcing at least initial-contact e-mails (those by which a 
> sender establishes a trust relationship with the intended recipient) 
> be sent in plain text so that they can be analyzed effectively by a 
> SpamAssassin-style analysis program;
>
>    3) allowing a recipient to control just exactly what sort of more 
> advanced content they are ready and willing to accept from each 
> specific sender, and (ideally) how they wish to additionally establish 
> the legitimacy of that sender's messages.  (Prearranged masthead on a 
> newsletter, personal SIG file for mail from an individual, 
> characteristic keywords in the message or subject line, etc etc).
These would help, but they are not enough - and without extensive 
cooperation will never be effective. I want to see better solutions, but 
barring making some solutions mandatory (and I shudder to think of how 
you could do that without gov't involvement, which will never happen on 
a global level anyway), you aren't going to do enough from a content 
standpoint.
> Here on this list, we keep falling back into this nasty business of 
> arguing about how an INHERENTLY FLAWED scheme (and I'm talking about 
> IP-address-based blacklisting) should be done, rather than recognizing 
> ONCE AND FOR ALL that it is simply a ROTTEN IDEA FROM THE BEGINNING 
> and that we OUGHT to be working on finding a BETTER solution which is 
> better long term both from the standpoint of CONTROLLING spam, of 
> encouraging (in a practical way) responsible computing, and which 
> isn't just encouraging these costly, ineffective, and ultimately 
I'll agree that its a horrible idea. At one point, a DNSBL could 
effectively stop a lot of spam. Now, most DNSBL operators and DNSBL 
users have realized that the technology long ago ceased to be useful in 
stopping all but the most persistent and long-lived spam sources, and 
compromised hosts.

So, you might ask, what are DNSBL's still useful for? Mainly, four things:
* Keeping track of compromised hosts, because they present a threat to 
the internet as a whole.
* Keeping track of hosts that shouldn't be sending mail - machines on 
networks where servers aren't allowed for instance.
* Brute-force education of end users and server administrators about 
community standards of security and acceptable behavior on the internet.
* Bringing the problems that allow spam and other network abuse to the 
wallets of those who can do something about it.

It's that last one that's the big one.

Unfortunately, there are some providers who wouldn't kick spammers off 
their network, if not for the fact that DNSBLs would soon force them out 
of business.
DNSBLs are unfortunately very good at this one thing - making "not my 
problem" a big enough issue that ignoring security, permitting abusive 
behavior, or ignoring the basic principles of the internet becomes 
costly enough to become a problem worth fixing.

As a DNSBL operator, I don't like this aspect of it, but it's the same 
principle as behind things like the infamous UDP 
(http://www.stopspam.org/faqs/udp.html). Ultimately, a DNSBL does not 
stop spam. A DNSBL brings the problem to the wallet of someone who can, 
by providing mail admins that care about the problem the tools to block 
mail from those that don't care, or are contributing to the problem 
through ignorance or malice.
> We OUGHT to be working on preventing spam (and viruses) from getting 
> delivered THE FIRST TIME, rather than worrying about locking the barn 
> door after the horse has already gotten out...!
>
> Dammit, people, we keep going back to what color fabric we're going to 
> use to upholster the "whack-a-mole" mallet, rather than coming up with 
> a real SOLUTION for this problem...!!!  :-((
>
I'm open to solutions, but just because the one's we have suck, we 
shouldn't abandon them until such time that we do have something better, 
and have it working. Spam is ultimately both a security problem and a 
financial problem though.

Solutions have to come from all levels, and at the most basic level, the 
critical work is in detecting and preventing intrusions so that abuse 
can only come directly from the abusers themselves.

-Stephanie

---

From: Bill Cole <[email-masked]>
Date: Fri, 2 Mar 2007 23:52:18 -0500

At 6:01 PM -0600 3/2/07, <[email-masked]> wrote:

>being a victim, just like so many other companies and individuals 
>have been (and, doubtless, will continue to be).

Being one of many careless clueless instruments of botnet spammers 
does not make them not partly guilty.

If you connect a machine to the net, you are morally responsible for 
what that machine does on the net. That applies to dumb individual 
users and dumb oil companies alike. IP addresses that are used for 
bad behavior will properly be treated as bad actors by others. This 
is a broader issue than email, it's just that email abuse and 
response to it is the most visible manifestation. Mismanaged PC's are 
doing a lot more than spam and the only general approach

>and connecting to the office wireless LAN)

So why did they configure their network with a common NAT point for 
corporate mail and for badly managed PC's and let those PC's talk 
SMTP to anywhere external through it? This is not a new risk. Worms 
have existed for almost 2 decades. Segregation of corporate servers 
from personal desktops has been a common best practice for at least 
15 years. This company lacked the application of fundamental security 
principles in their network design.

>will force more companies to insist on MORE DANGEROUS separate, 
>routable IP addresses for each machine in their company....

No force at all. There are other options, such as doing separation 
internally and not allowing mismanaged PC's uncontrolled access to 
the outside world through company facilities.

The whole story portrays a fundamental business flaw. If email and 
other Internet services are business-critical, it is irresponsible to 
the business for management to not have technical competence on hand 
to deal with problems, particularly in the area of security.

-- 
Bill Cole                                  
[email-masked]

---

From: "Martin Hannigan" <[email-masked]>
Date: Sat, 3 Mar 2007 00:20:21 -0500

> LOUSY solution IP-address-based blacklists are, in

Yes, they are.

> from behind a NAT router.

This is a normal and accepted method of operating a network for an
enterprise. I do not
believe this has any relevance in the argument of "good" vs. "bad", personally.

[ SNIP ]

> transmissions blocked "en masse" like this.

Email has never been reliable, and can't be counted on to be
timely. There are too many variables. You may have been having
"good luck", but that appears to have run out as far as business
process goes.

Your best bet  is to create some better process around your
mission critical applications. I suspect you will be waiting a long time
for something else to happen.

-M<

---

From: Bill Cole <[email-masked]>
Date: Sat, 3 Mar 2007 00:53:10 -0500

At 11:19 PM -0500 3/2/07, Stephanie Erin Daugherty wrote:

>users have realized that the technology long ago ceased to be useful 
>in stopping all but the most persistent and long-lived spam sources, 
>and compromised hosts.

That is not consistent with the evidence I have on hand.

I deal with multiple receiving sites (corporate and microdomain) and 
know of none where the CBL fails to reject over 2/3 of all SMTP 
connections or has ever had a detectable false positive rate greater 
than 1 per million rejections over a period of over a month, with the 
false positives coming in very brief episodes (commonly describable 
as the consequences of ill-considered NAT designs.) For most sites, 
the reject rate is usually in the 75-80%.

The Spamhaus XBL and Zen lists enhance that performance by 5-10% by 
aggregating the CBL with additional lists, and while I've used them 
for relatively short times (< 6 months) on anything but very small 
sites, I've been unable to find any increase in false positives.

As a first cut against spam, applied without having to examine 
anything other than the connecting IP, DNSBL's remain extremely 
useful.

>* Keeping track of compromised hosts, because they present a threat 
>to the internet as a whole.
>* Keeping track of hosts that shouldn't be sending mail - machines 
>on networks where servers aren't allowed for instance.

That's basically the model of the Spamhaus XBL and PBL.

>* Bringing the problems that allow spam and other network abuse to 
>the wallets of those who can do something about it.
>

Yes, but I think you've missed another application. Applying the 
Spamhaus SBL as a "URIBL" by checking body URI domain parts for 
resolution to SBL-listed address space is usefully effective against 
spam that makes it past CBL and its derivatives. The numbers 
fluctuate wildly (10-40% of what gets past traditional DNSBL 
application) based on fluctuations of DNSBL effectiveness and spammer 
behavior.

>Unfortunately, there are some providers who wouldn't kick spammers 
>off their network, if not for the fact that DNSBLs would soon force 
>them out of business.

I think that's an appealing story that does not always describe 
reality. I know there are some providers who respond to listings, but 
there are some who simply don't, and are unimpeded by that for years. 
The entity formerly known as UUNet (finally seeming to clean up a bit 
since the VZ acquisition,)  the 'new' AT&T (i.e. SBC,) Comcast, and 
the Chinese Internet oligopoly seem impervious to the supposed 
business  impact of DNSBL's.

>DNSBLs are unfortunately very good at this one thing - making "not 
>my problem" a big enough issue that ignoring security, permitting 
>abusive behavior, or ignoring the basic principles of the internet 
>becomes costly enough to become a problem worth fixing.

Not for all providers.

>As a DNSBL operator, I don't like this aspect of it, but it's the 
>same principle as behind things like the infamous UDP 
>(http://www.stopspam.org/faqs/udp.html).

The UDP worked better when it was applied than anything in email can 
because the news network is built on a fundamental building block of 
explicit and strictly bilateral agreements to pass traffic. Sites 
that have agreements with everyone they accept mail from don't have 
major spam problems.

>Ultimately, a DNSBL does not stop spam.

But, they do. I see DNSBL's stopping most spam at multiple sites.

-- 
Bill Cole                                  
[email-masked]

---

From: Stephanie Erin Daugherty <[email-masked]>
Date: Sat, 03 Mar 2007 01:48:07 -0500

Bill,

Thank you for the very insightful rebuttal to many of my arguments.

Bill Cole wrote:
> false positives coming in very brief episodes (commonly describable as 
> the consequences of ill-considered NAT designs.) For most sites, the 
> reject rate is usually in the 75-80%.
>
My experience has been different, but then I'm not administering mail 
for a corporation or major provider either, so my experiences may not 
match yours. My own, admittedly non-scientific, findings have been that 
the more sophisticated spammers use compromised hosts almost immediately 
after they are compromised, or make multiple brute force attempts via 
various compromised hosts until they find one that's allowed to connect.
> business  impact of DNSBL's.
Unfortunately, it doesn't always work, but systematically escalating a 
listing after each successive effort to negotiate with a provider has 
gotten the attention of some of these large providers in the past. 
Unfortunately, this is a big sharp stick that loses it's effectiveness 
every time it's used - as many mail administrators will usually locally 
white list any major provider that's blocked by a DNSBL they use, or 
will stop using a DNSBL that's willing to block major providers.

However, when this is judiciously applied, and coupled with pressure 
from the provider's own customers, it can work and has worked, at least 
to a degree, but it's a very extreme measure that can only be used in 
very extreme circumstances without major loss of a DNSBL's credibility 
(and therefore it's effectiveness).

Spews (IANS)  was  somewhat limited  in this regard,  because although 
they were  willing to escalate listings, they had such a reputation for 
doing so that most of it's users were hardcore spamfighters anyway, and 
not large mail sites.
> explicit and strictly bilateral agreements to pass traffic. Sites that 
> have agreements with everyone they accept mail from don't have major 
> spam problems.
>
You may have hit the nail on the head here as to why current solutions 
aren't working that well, and maybe that's an approach we should strive 
for - an email system built on consensual agreements.

--Stephanie

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 03:00:19 -0500

On Fri, 2 Mar 2007 21:43:58 -0600
> Take blacklists out of the equation, and it doesn't 

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.

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

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 deFrom [email-masked] Sat Mar 03 02:58:52 2007
To: [email-masked]
Date: Sat, 03 Mar 2007 03:00:19 -0500
From: <[email-masked]>
Subject: Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0

On Fri, 2 Mar 2007 21:43:58 -0600
> Take blacklists out of the equation, and it doesn't 

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.

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

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

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.

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 01:59:00 -0600

On Fri, 02 Mar 2007 23:19:03 -0500
  Stephanie Erin Daugherty <[email-masked]> wrote:
>>of this kind 
>>companies to 
>> machine in their company.... so that blocking will 
>>affect JUmonstrates VIVIDLY.

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 01:59:00 -0600

On Fri, 02 Mar 2007 23:19:03 -0500
  Stephanie Erin Daugherty <[email-masked]> wrote:
>>affect JUST ONE of 
> 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.

>It may work for that in some situations, but it's less 
>that optimal, and was never intended to provide security. 
>(and in fact, there are countless tricks to break through 
>NAT anyway these days).

Again, client security isn't really the issue, although 
that IS a benefit, FWIW, of NAT.

> NAT was created to deal with a perceived shortage in 
>IPv4 addresses. It's not a magic bullet, and in fact, 
>it's actually harmful in many ways:
> If you choose to present your entire network to the 
>world as being a single machine, then, it and any abuse 
>from it will be treated as such, that's just a chance you 
>take. In this respect NAT is actually more dangerous, as 
>the ability to account for what's happening stops at your 
>network's border, 

Exactly.  And THAT is a HUGE issue.

>and NAT is often substituted for proper 
>security and network design - which includes use of 
>application layer firewalls, intrusion detection, and 
>application proxies to create and enforce a strong 
>security policy.

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.

> Put your servers in a real DMZ, with real IPs, and a 
>properly constructed firewall. Consider putting your 
>users behind proxy servers instead of or in addition to 
>NAT, so that they have exactly the access they require, 
>no more, no less. Machines that don't send mail directly 
>out to the internet shouldn't have the ability to do so. 
>This is common sense.

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.

> Intrusion detection would have let you catch this 
>earlier, probably before you were listed on DNSBLs.

Again, it's miraculous we caught it as fast as we did, 
given that the company in question really has no inhouse 
IT staff.  I provide their system support, remotely from 
halfway across the country.

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.  (Of course, who can be sure?  The 
blacklisting company doesn't tell us EXACTLY what they 
were blacklisting us for).

>>revolve 
>> figure out bST ONE of 
> 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.

>It may work for that in some situations, but it's less 
>that optimal, and was never intended to provide security. 
>(and in fact, there are countless tricks to break through 
>NAT anyway these days).

Again, client security isn't really the issue, although 
that IS a benefit, FWIW, of NAT.

> NAT was created to deal with a perceived shortage in 
>IPv4 addresses. It's not a magic bullet, and in fact, 
>it's actually harmful in many ways:
> If you choose to present your entire network to the 
>world as being a single machine, then, it and any abuse 
>from it will be treated as such, that's just a chance you 
>take. In this respect NAT is actually more dangerous, as 
>the ability to account for what's happening stops at your 
>network's border, 

Exactly.  And THAT is a HUGE issue.

>and NAT is often substituted for proper 
>security and network design - which includes use of 
>application layer firewalls, intrusion detection, and 
>application proxies to create and enforce a strong 
>security policy.

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.

> Put your servers in a real DMZ, with real IPs, and a 
>properly constructed firewall. Consider putting your 
>users behind proxy servers instead of or in addition to 
>NAT, so that they have exactly the access they require, 
>no more, no less. Machines that don't send mail directly 
>out to the internet shouldn't have the ability to do so. 
>This is common sense.

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.

> Intrusion detection would have let you catch this 
>earlier, probably before you were listed on DNSBLs.

Again, it's miraculous we caught it as fast as we did, 
given that the company in question really has no inhouse 
IT staff.  I provide their system support, remotely from 
halfway across the country.

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.  (Of course, who can be sure?  The 
blacklisting company doesn't tell us EXACTLY what they 
were blacklisting us for).

>>revolve 
> There are also ethical implications which would suggest 
>that any content-based approach is just as flawed, 
>because it creates an infrastructure for censorship just 
>as easily as it creates an infrastructure for stopping 
>spam.

That would be true if the "censorship" were imposed by an 
ISP or some centralized authority.  It's far less of an 
issue if the routing and acceptance criteria is controlled 
by THE RECIPIENT THEMSELVES, who have the ABSOLUTE right 
to determine what does and doesn't go into their inbox, or 
(at a minimum) what they do (routing, reading, discarding 
read-or-unread, etc) regarding the incoming messages they 
receive.

>>example I gave) 
>>same server(s) 
> If dear old aunt gertie is leaving her machine on the 
>internet after it's been compromised by a virus, she 
>either doesn't care, or doesn't know better, and in 
>either case, is doing harm to others by her refusal or 
>inability to deal with the problem, so she's arguably 
>just as big of a problem as the virus itself.

The point is that SHE PROBABLY DOESN'T KNOW.  And probably 
wouldn't understand what it all meant, even if told.

I'm not suggesting that we ought to leave infected spambot 
zombie armies operating freely all over the net.  Indeed, 
my proposals are intended to virtually eliminate (at 
least) E-mail as a (direct) recruitment vector for that. 
 But if you shut down a user because they had been 
infected, eventually you'll shut down nearly everybody.

>>which a 
>>sort of more 

> These would help, but they are not enough - 

I agree.  Content analysis is key, too.  But without in 
the first stage denying the spammers the use of evasion 
techniques based on text-as-image, scripting (decryption 
etc), HTML, linked images, attachments, and so forth, 
content analysis can NEVER be nearly as effective as it 
can be otherwise.

>and without 
>extensive cooperation will never be effective. 

Agreed that spammers KNOWING that their spam has a 
negligible chance of being delivered and read will make 
them less likely to still try to send it.  But meanwhile, 
even just a SINGLE recipient no longer feeling plagued by 
spam and worms is probably worthwhile, at least as 
experienced by THAT user.

> I want to 
>see better solutions, but barring making some solutions 
>mandatory (and I shudder to think of how you could do 
>that without gov't involvement, which will never happen 
>on a global level anyway), you aren't going to do enough 
>from a content standpoint.

I think you can do FAR BETTER from a content standpoint 
(content analysis, such as Spam Assassin, following "a 
priori" blocking of mail from unknown/untrusted senders 
containing HTML or attachments) than you can using any 
kind of IP-based blacklisting or other "reputation" 
scheme.

>>business of 
> I'll agree that its a horrible idea. 

I'm glad we at least agree on THAT point.

>At one point, a 
>DNSBL could effectively stop a lot of spam. Now, most 
>DNSBL operators and DNSBL users have realized that the 
>technology long ago ceased to be useful in stopping all 
>but the most persistent and long-lived spam sources, and 
>compromised hosts.

And, the other point is that you have FAR too much 
collateral damage.

> * Keeping track of compromised hosts, because they 
>present a threat to the internet as a whole.

"Keeping track of" is probably less of interest to anybody 
as a third party than it would be to establish a mechanism 
for robustly alerting someone technically responsible at a 
given sender... IF one could reliably establish WHO the 
actual infected computer or other spammer really was.  It 
would be nice, for example, if one could REALLY notify 
(say) Gertie's ISP so that they could (in theory, anyhow) 
try to contact her to let her know about the problem.

> * Keeping track of hosts that shouldn't be sending mail 
>- machines on networks where servers aren't allowed for 
>instance.

Personally, I think that is still a violation of "net 
neutrality".  While I accept that kind of crap (for 
example, arbitrary restrictions that people have to pay 
dramatically more for a "business account" for their home 
offices since "residential accounts" 'are not allowed to 
run servers') I think that the Net as a whole would be a 
far, far better place if individual users COULD have their 
own Web servers online, rather than having to pay premium 
prices to third-party Web hosting companies.  I would far 
rather have, for example, a Web-based subdirectory on my 
local hard drive where I could place documents (contracts, 
photos, other files) where other authorized users could 
just come by and get them at their convenience.  (For 
example, some years ago I helped a guy who was writing a 
thesis about the early days of the microprocessor and 
personal computing, and I've got a copy of his paper 
online through my personal Web site... which probably 
doesn't get accessed five times a year, and is painfully 
big to store in my ISP-provided "personal Web space".... 
but OUGHT to be available online SOMEWHERE, and certainly 
don't mind having it occupying disk space on my home LAN 
here.)

> * Brute-force education of end users and server 
>administrators about community standards of security and 
>acceptable behavior on the internet.

That's fine for the users technically savvy enough to 
understand that.  Aunt Gertrude is barely able to power up 
her machine and enter an E-mail message.  And there are 
tens of millions of users just like that, Net-wide.

> * Bringing the problems that allow spam and other 
>network abuse to the wallets of those who can do 
>something about it.

Worse, also to those who CANNOT.  :-(

> Unfortunately, there are some providers who wouldn't 
>kick spammers off their network, if not for the fact that 
>DNSBLs would soon force them out of business.
> DNSBLs are unfortunately very good at this one thing - 
>making "not my problem" a big enough issue that ignoring 
>security, permitting abusive behavior, or ignoring the 
>basic principles of the internet becomes costly enough to 
>become a problem worth fixing.

Agreed that it gets people's attention.  (So would setting 
fire to their building, though).  I'm not convinced that 
it is an appropriately measured, limited response.

> As a DNSBL operator, I don't like this aspect of it, but 
>it's the same principle as behind things like the 
>infamous UDP (http://www.stopspam.org/faqs/udp.html). 
>Ultimately, a DNSBL does not stop spam. A DNSBL brings 
>the problem to the wallet of someone who can, by 
>providing mail admins that care about the problem the 
>tools to block mail from those that don't care, or are 
>contributing to the problem through ignorance or malice.

True, but (again) at what I consider to be an unacceptably 
high cost, compared to less abusive methods.

>>from getting 
>>we're going to 
> I'm open to solutions, but just because the one's we 
>have suck, we shouldn't abandon them until such time that 
>we do have something better, and have it working. Spam is 
>ultimately both a security problem and a financial 
>problem though.

Well, I've posted here repeatedly what *I* think is a 
major step forward towards an INTELLIGENT solution for the 
problem... selectively blocking HTML and attachments via a 
fine-grained whitelist, on a sender-by-sender basis as set 
by each recipient, as a first-step prior to passing 
incoming E-mails through a content analysis system.
  
> Solutions have to come from all levels, and at the most 
>basic level, the critical work is in detecting and 
>preventing intrusions so that abuse can only come 
>directly from the abusers themselves.

Eliminating the practicality of delivering viruses and 
worms by E-mail is a major step in the direction of 
reducing the ability of spammers to recruit spambot zombie 
armies.

Gordon Peterson

etter and more effective ways to efficiently 
>>and 
> There are also ethical implications which would suggest 
>that any content-based approach is just as flawed, 
>because it creates an infrastructure for censorship just 
>as easily as it creates an infrastructure for stopping 
>spam.

That would be true if the "censorship" were imposed by an 
ISP or some centralized authority.  It's far less of an 
issue if the routing and acceptance criteria is controlled 
by THE RECIPIENT THEMSELVES, who have the ABSOLUTE right 
to determine what does and doesn't go into their inbox, or 
(at a minimum) what they do (routing, reading, discarding 
read-or-unread, etc) regarding the incoming messages they 
receive.

>>example I gave) 
>>same server(s) 
> If dear old aunt gertie is leaving her machine on the 
>internet after it's been compromised by a virus, she 
>either doesn't care, or doesn't know better, and in 
>either case, is doing harm to others by her refusal or 
>inability to deal with the problem, so she's arguably 
>just as big of a problem as the virus itself.

The point is that SHE PROBABLY DOESN'T KNOW.  And probably 
wouldn't understand what it all meant, even if told.

I'm not suggesting that we ought to leave infected spambot 
zombie armies operating freely all over the net.  Indeed, 
my proposals are intended to virtually eliminate (at 
least) E-mail as a (direct) recruitment vector for that. 
 But if you shut down a user because they had been 
infected, eventually you'll shut down nearly everybody.

>>which a 
>>sort of more 

> These would help, but they are not enough - 

I agree.  Content analysis is key, too.  But without in 
the first stage denying the spammers the use of evasion 
techniques based on text-as-image, scripting (decryption 
etc), HTML, linked images, attachments, and so forth, 
content analysis can NEVER be nearly as effective as it 
can be otherwise.

>and without 
>extensive cooperation will never be effective. 

Agreed that spammers KNOWING that their spam has a 
negligible chance of being delivered and read will make 
them less likely to still try to send it.  But meanwhile, 
even just a SINGLE recipient no longer feeling plagued by 
spam and worms is probably worthwhile, at least as 
experienced by THAT user.

> I want to 
>see better solutions, but barring making some solutions 
>mandatory (and I shudder to think of how you could do 
>that without gov't involvement, which will never happen 
>on a global level anyway), you aren't going to do enough 
>from a content standpoint.

I think you can do FAR BETTER from a content standpoint 
(content analysis, such as Spam Assassin, following "a 
priori" blocking of mail from unknown/untrusted senders 
containing HTML or attachments) than you can using any 
kind of IP-based blacklisting or other "reputation" 
scheme.

>>business of 
> I'll agree that its a horrible idea. 

I'm glad we at least agree on THAT point.

>At one point, a 
>DNSBL could effectively stop a lot of spam. Now, most 
>DNSBL operators and DNSBL users have realized that the 
>technology long ago ceased to be useful in stopping all 
>but the most persistent and long-lived spam sources, and 
>compromised hosts.

And, the other point is that you have FAR too much 
collateral damage.

> * Keeping track of compromised hosts, because they 
>present a threat to the internet as a whole.

"Keeping track of" is probably less of interest to anybody 
as a third party than it would be to establish a mechanism 
for robustly alerting someone technically responsible at a 
given sender... IF one could reliably establish WHO the 
actual infected computer or other spammer really was.  It 
would be nice, for example, if one could REALLY notify 
(say) Gertie's ISP so that they could (in theory, anyhow) 
try to contact her to let her know about the problem.

> * Keeping track of hosts that shouldn't be sending mail 
>- machines on networks where servers aren't allowed for 
>instance.

Personally, I think that is still a violation of "net 
neutrality".  While I accept that kind of crap (for 
example, arbitrary restrictions that people have to pay 
dramatically more for a "business account" for their home 
offices since "residential accounts" 'are not allowed to 
run servers') I think that the Net as a whole would be a 
far, far better place if individual users COULD have their 
own Web servers online, rather than having to pay premium 
prices to third-party Web hosting companies.  I would far 
rather have, for example, a Web-based subdirectory on my 
local hard drive where I could place documents (contracts, 
photos, other files) where other authorized users could 
just come by and get them at their convenience.  (For 
example, some years ago I helped a guy who was writing a 
thesis about the early days of the microprocessor and 
personal computing, and I've got a copy of his paper 
online through my personal Web site... which probably 
doesn't get accessed five times a year, and is painfully 
big to store in my ISP-provided "personal Web space".... 
but OUGHT to be available online SOMEWHERE, and certainly 
don't mind having it occupying disk space on my home LAN 
here.)

> * Brute-force education of end users and server 
>administrators about community standards of security and 
>acceptable behavior on the internet.

That's fine for the users technically savvy enough to 
understand that.  Aunt Gertrude is barely able to power up 
her machine and enter an E-mail message.  And there are 
tens of millions of users just like that, Net-wide.

> * Bringing the problems that allow spam and other 
>network abuse to the wallets of those who can do 
>something about it.

Worse, also to those who CANNOT.  :-(

> Unfortunately, there are some providers who wouldn't 
>kick spammers off their network, if not for the fact that 
>DNSBLs would soon force them out of business.
> DNSBLs are unfortunately very good at this one thing - 
>making "not my problem" a big enough issue that ignoring 
>security, permitting abusive behavior, or ignoring the 
>basic principles of the internet becomes costly enough to 
>become a problem worth fixing.

Agreed that it gets people's attention.  (So would setting 
fire to their building, though).  I'm not convinced that 
it is an appropriately measured, limited response.

> As a DNSBL operator, I don't like this aspect of it, but 
>it's the same principle as behind things like the 
>infamous UDP (http://www.stopspam.org/faqs/udp.html). 
>Ultimately, a DNSBL does not stop spam. A DNSBL brings 
>the problem to the wallet of someone who can, by 
>providing mail admins that care about the problem the 
>tools to block mail from those that don't care, or are 
>contributing to the problem through ignorance or malice.

True, but (again) at what I consider to be an unacceptably 
high cost, compared to less abusive methods.

>>from getting 
>>we're going to 
> I'm open to solutions, but just because the one's we 
>have suck, we shouldn't abandon them until such time that 
>we do have something better, and have it working. Spam is 
>ultimately both a security problem and a financial 
>problem though.

Well, I've posted here repeatedly what *I* think is a 
major step forward towards an INTELLIGENT solution for the 
problem... selectively blocking HTML and attachments via a 
fine-grained whitelist, on a sender-by-sender basis as set 
by each recipient, as a first-step prior to passing 
incoming E-mails through a content analysis system.
  
> Solutions have to come from all levels, and at the most 
>basic level, the critical work is in detecting and 
>preventing intrusions so that abuse can only come 
>directly from the abusers themselves.

Eliminating the practicality of delivering viruses and 
worms by E-mail is a major step in the direction of 
reducing the ability of spammers to recruit spambot zombie 
armies.

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 02:59:58 -0500

On Fri, 2 Mar 2007 20:03:11 -0500 (EST)
  Daniel Feenberg <[email-masked]> wrote:
>>LOUSY solution 
>>Each evening the 
>>their computers 
>>transmissions simply 
>>send price updates 
>>of this kind of 
>>connecting to the office 
> Can I ask why it was so difficult? Could you not change 
>the IP address of the MTA easily? 

No, because:

1)  They use several outgoing mail servers, at least 
several of which are behind their NAT router (and thus all 
have the same single IP address, from the Internet side).

2)  Their "vanity domain" mail server (outside their 
inhouse LAN) is "protected" by the same kind of 
braindamaged IP-address-based blacklist 
("emaildefenseservice", but let's not name names... :-/) 
and thus won't accept their outgoing mail messages either, 
since they come from the company's blacklisted IP router.

3)  Ditto for E-fax, the E-mail-to-fax gateway that the 
client company uses.

4)  Changing the IP address of the company's NAT router 
could only be done by their ISP/telephone company, since 
the IP address belongs to (and is set by) the phone 
company.

> Perhaps your customer had only one? 

Only one NAT router, yes.

> Perhaps you weren't aware that was 
>possible? 

I'm very aware of what is POSSIBLE, but you still have to 
ACHIEVE that and it necessarily involves not just a number 
of other companies (not all of which provide competent 
support 24/7) but also reconfiguring a lot of relatively 
technical software within the victim company itself.  For 
companies like my consulting client, which does not have 
inhouse IT staff, this is at best a challenge.

>Certainly XBL doesn't list an entire address 
>block on day one, 

It listed the company's NAT router, and they have only one 
IP address (well, two actually... their 'modem' and the 
NAT router behind it).  But listing either one of those is 
equivalent.

>so I assume that the infected machine 
>was using the companies own smtp server as a smarthost 
>and that is why the entire company was inconvinienced. 

No.  It was sending (apparently) using its own SMTP 
sending engine, but behind the (single) NAT router and 
therefore from the Internet side was indistinguishable (by 
IP address, anyhow) from any other E-mails coming from 
within the entire company, from any of their inhouse 
outgoing mail servers.

>Another possibility for the company is to use the ISP 
>smarthost for its mail. 

The ISP's "smarthost" would have doubtless blocked the IP 
address as well, due to them using braindead 
IP-address-based blacklisting!!  :-(

>It is quite rare for ISP MTAs to 
>be blacklisted, though it does happen.  I understand that 
>getting off blacklists is slow and difficult to speed up, 
>but why is it the only solution?

It isn't, of course, but none of the "solutions" are 
obvious or necessarily easy for an affected copmany to 
implement, especially depending on how deeply embedded 
their mail sending architecture is within their 
applications.

> I also refer you to 
>http://www.nber.org/sys-admin/smarthost.html where I list 
>some commercial smarthosts. While not free, the cost 
>would be similar to an hour or two of typical consulting 
>rates, for a year of smarthosting, by which time the 
>original IP address would be off the blacklists.

What I eventually did was to arrange an emergency external 
host (NOT using a braindead XBL blacklist!) that the 
company's inhouse systems could use as an upstream MTA, 
thus changing the IP address seen by the people they need 
to reach.

But having the original IP address "off the blacklists" is 
only a temporary solution, only until (inevitably) one of 
the company's machines is eventually infected again, and 
the whole insane Keystone Kops episode will inevitably 
play out again.

> Postings such as yours have more weight if they include 
>the relevant IP address.

The CONCEPT here is what matters;  the specific IP address 
involved in this SPECIFIC incident really isn't important.

But if you think you can shed additional insight by 
knowing it, the IP address is 66.73.52.194 (their router) 
and 66.73.52.193 (their "modem" or whatever they connect 
through).  FWIW, that address is probably going to change 
anyhow because even before this incident, they have 
arranged to change their ISP connectivity provider and I 
expect their router IP address will change as a result.

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 03:00:35 -0500

On Sat, 3 Mar 2007 00:20:21 -0500
  "Martin Hannigan" <[email-masked]> wrote:

> timely. There are too many variables. 

Agreed that it is not 100% reliable.

But it's an ENTIRELY different situation when (for 
example) resending the same E-mail message again (in 
response to a customer complaint that they didn't receive 
it) STILL doesn't get through, after multiple attempts 
over numerous days.... and because of the arbitrary 
blacklisting of an entire company, and which blacklister 
won't even tell us PRECISELY what they are objecting to 
from OUR specific compamy, and only just says "well, it's 
probably this... or maybe that..."

>You may have been having
> "good luck", but that appears to have run out as far as 
>business process goes.

The bottom line is that DESIGNING IN additional 
INTRINSICALLY FLAWED mechanisms like this, as we have been 
talking about here, is TECHNICALLY IRRESPONSIBLE.

> for something else to happen.

The fact that the present way of handling this is screwed 
up is NOT a good reason why every company in the world 
ought to be forced to work around such issues.  And more 
to the point, WE here in the ASRG ought to NOT be making 
such matters WORSE by continuing to let our discussions 
here continue to devolve to discussing fine design points 
about a design which is intrinsically flawed and 
technically irresponsible from the get-go, and which 
should have been discarded a long time ago!

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 02:59:58 -0500

No, because:

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 03:00:35 -0500

Gordon Peterson

---

From: <[email-masked]>
Date: Sat, 03 Mar 2007 02:15:09 -0600

On Fri, 2 Mar 2007 17:10:04 -0800
>> their virus farm NATted to the same IP address"]

In the real world, ISPs typically provide single IP 
addresses and a NAT router to small offices.  They tend to 
charge exorbitant amounts for separate IP addresses (and 
logically enough, in their desire to avoid wasting the 
limited IPv4 address space).

[snip]

> A solution for coping with the immediate problem would 
>be to relay  outbound email through a trusted (better 
>managed) provider.

That is what ultimately I did for them, at least as a 
stopgap measure.  The problem is that if they got infected 
once, they will inevitably get infected again.

> There are also several websites that will assist you in 
>identifying  the black-hole lists.  If being black-hole 
>listed is the only damage  from an infected system, 
>consider yourself lucky.
> 

Thanks for the tip.  Indeed, that looks like a very useful 
site.

Gordon Peterson

---

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

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

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

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

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

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

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 03 Mar 2007 11:19:28 -0500

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

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

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

---

From: Al Iverson <[email-masked]>
Date: Sat, 03 Mar 2007 11:16:31 -0600

[email-masked] wrote:
> 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.

Yeah, sucks. Too bad that's how spam filtering works. Again, railing 
against blacklists doesn't fix it. The death of every blacklist doesn't 
fix it. You want a significant change in spam filtering methodology? 
There are VC firms waiting to hand out money. Go get some, hire some 
smart guys, and build that better mousetrap.

IP-based blocking is here to stay, whether or not any of us like it. All 
of the top ten ISPs/webmail providers employ some form of it, as well as 
many thousands of ISPs beyond the top ten. None of this is specific to 
DNSBLs or germane for a DNSBL BCP.

Waging war *here* against the blunt methodology of IP address-based 
blocking is misguided, and off topic. This is telling people who want to 
shape *an existing process* that the foundation of the process (used by 
others, whom they don't control) is flawed, even though it's already 
used as a common practice in many thousands of situations daily.

 > almost any kind of spam control scheme upon it.

At this point I think it's safe to say that your opinion has been noted.
Do you have anything *else* to contribute, besides telling us that 
IP-based blocking sucks because some guy's office NAT IP was blacklisted 
once and it practically slowed down their email to some domains 
for...hours? If so, I'm interested. Otherwise it's time to fire up the 
kill file, to prevent from getting sucked further into an argument with 
a troll. Nothing personal, but this is a distraction-- somebody with a 
huge chip on their shoulder to the point of religious fervor is 
difficult to take seriously. If you feel so strongly about it that you 
need to shake us to get our attention by using CAPS and writing LONG 
POSTS, then YOU SHOULD GO OUTSIDE and HUG A PUPPY instead of ARGUING 
WITH US. IT'S JUST EMAIL.

Regards,
Al Iverson

---

From: Dan Oetting <[email-masked]>
Date: Sat, 3 Mar 2007 10:56:50 -0700

On Mar 2, 2007, at 5:01 PM, [email-masked] wrote:

> As you know, in a recent thread I commented on what a LOUSY  
> solution IP-address-based blacklists are, in general.
>
> especially for companies which operate a large network from behind  
> a NAT router.
>
> Well, I've recently been personally involved in trying to put out  
> just such a fire at one of my consulting clients.

Well, I recently presented a proposal that would have eliminated most  
of the damage that you experienced. But you trashed my proposal  
simply because it was based on blocking IP addresses.

You need to realize that blocking IP addresses that are sending spam  
is one of the most effective and least costly tools admins have for  
stopping the bulk of the spam tide. Even in your case, there was spam  
coming from your IP address and blocking that address stopped the  
spam and got your immediate attention. The problem as I see it is  
that the current blacklists are too slow to remove the blocks once  
the spamming has been stopped so there is no reward for quickly  
cleaning up or shutting down the infected PC.

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 03 Mar 2007 13:03:49 -0500

> various compromised hosts until they find one that's allowed to connect.

Your sample size is too small, and not particularly representative of
what the rest of the world sees.

Yes, some spammers attempt to use compromised hosts as quickly as
possible.  But the XBL is pretty quick, not all spammers are that good
at that (many compromised machines are compromised multiple ways, and as
quick as you are at utilizing _your_ compromise of it, a previous one
may have got it listed previously), and it don't mean squat with the PBL
whose listings are static, and not reliant on detecting compromised
machines.

We successfully block approximately 97% of all the spam sent our way
(right now averaging about 1M spams/day).  Zen (PBL, XBL and SBL)
together are catching about 80%-90% of that, with SA (including
SURBL/URIBL) doing most of the rest.  With an FP rate on the order of
1-2 emails/day from the DNSBLs.  SA's FP rate is _far_ higher than that.

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 03 Mar 2007 13:06:55 -0500

Dan Oetting wrote:
> The problem as I see it is that the
> current blacklists are too slow to remove the blocks once the spamming
> has been stopped so there is no reward for quickly cleaning up or
> shutting down the infected PC.

If an XBL listing continued to cause significant problems more than a
couple hours of it being detected, there's something wrong at the
blockee's end.  Eg, they didn't use the self-removal.

[Some servers undoubtably do zone transfers relatively infrequently, eg:
once per day, but at the 3 day point, it's not an XBL listing causing
the problem.  Unless they didn't make use of the delisting capabilities.]

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 3 Mar 2007 13:07:16 -0600

> kind of IP-based blacklisting or other "reputation"

SpamAssassin (and other content filters) don't actually work the way
you think they do, on many levels.

The major measurable component of spam is whether or not the sender
has permission to contact the recipient. Content filters in particular
have no view into consent; no way to measure consent. There is no HTML
code or X-Header that reliably provides proof of opt-in. They do some
good things based on modeling of what looks like spam; but it's also
true that things that look like spam are not always spam. False
positive issues you rant about occur just as often with content
filters. Some would claim, even more so!

With a blacklisting, I get a bounce back and can find somebody to
argue with. With the common method of implementing a content filter,
my mail is quietly eaten and I get no information back regarding the
failure to deliver the mail to end recipient. This is worse than IP
blacklisting; less transparent; less obvious; less opportunity for
feedback and investigative recourse.

The fact that you think they're better is likely based on an
incomplete view on your part. You actually probably have no idea how
much of your mail has ever been redirected to a bulk or trash folder
by a content filter.

And of course, not to mention that SpamAssassin, which you hold up as
the better model, has lovingly crafted hooks into it to allow direct
support of IP-based blacklist and other IP-based reputation
mechanisms.

Note to rest of world: I'm not anti-SpamAssassin. I've run it myself
before and likely will again. I'm just pointing out that like just
about every other kind of spam filtering or blocking mechanism, a
content filter is imperfect. It's a bit mind-blowing to see content
filtering held up as this panacea to address the ills of IP-based
blocking, since they're both approximate models of what somebody
thinks is spam, and have flaws inherent to both technology and policy
limitations.

Regards,
Al Iverson

---

From: Bill Cole <[email-masked]>
Date: Sat, 3 Mar 2007 15:48:54 -0500

>feedback and investigative recourse.

That's not an uncommon way of deploying content filters, but it is a 
diminishing model. It is increasingly common that what you get is a 
long pause at the end of DATA and then a rejection in SMTP just as 
with DNSBL use, albeit at a later stage. This is essentially 
universal for content filters hooked into Sendmail via its Milter 
interface (now also present in Postfix) or into Postfix via its 
'before queue, external' filter interface.

  It has also not been terribly uncommon for people to deploy DNSBL 
and other IP-based blocking with ill-considered discarding and 
quarantining.

-- 
Bill Cole                                  
[email-masked]

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 3 Mar 2007 14:57:48 -0600

On 3/3/07, Bill Cole <[email-masked]> wrote:
> diminishing model.

Do you have any data to support that it's a diminishing model, or on
what % of spam is content rejected with a bounce?

I agree that some work this way (and I like the change), but I look at
many thousands of bounces a day, and it's still exceedingly rare.

There area a lot of Barracuda-like things in the world, who accept the
mail before doing anything else, and their only chance to send a
bounce (in how they're implemented currently), is after the fact,
which has its own obvious set of problems.

Regards,
Al Iverson

---

From: John Levine <[email-masked]>
Date: 3 Mar 2007 21:40:02 -0000

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

My company plugs all of its equipment into one outlet using lots of
extension cords, because that's what was on the wall when we moved
into the office.  As the company gets more dependent on electrical
equipment, the fuse keeps blowing and leaves us in the dark.

It is very, VERY important that our power be on, although of course
not important enough to hire an electrician to wire the place
properly, so I blame everything on the unfair and arbitrary fuse
makers.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: "Walter Dnes" <[email-masked]>
Date: Sat, 3 Mar 2007 14:22:20 -0500

Please read up on "default deny" and "principle of least privilege".

On Sat, Mar 03, 2007 at 02:59:58AM -0500, [email-masked] wrote

> >Perhaps you weren't aware that was 

  [...deletia...]

> >Certainly XBL doesn't list an entire address block on day one, 
> 
> It listed the company's NAT router, and they have only one IP address
> (well, two actually... their 'modem' and the NAT router behind it).
> But listing either one of those is equivalent.
> 
> >so I assume that the infected machine was using the companies own
> >smtp server as a smarthost and that is why the entire company was
> >inconvinienced. 
> 
> No.  It was sending (apparently) using its own SMTP sending engine,
> but behind the (single) NAT router and therefore from the Internet
> side was indistinguishable (by IP address, anyhow) from any other
> E-mails coming from within the entire company, from any of their
> inhouse outgoing mail servers.

  Simple question... *WHY WAS THE ROUTER/GATEWAY NOT BLOCKING PORT 25
TO/FROM ALL MACHINES EXCEPT AUTHORIZED INTERNAL MTAS* ???  If your
client had taken that one simple step, none of this would've happened.

> But having the original IP address "off the blacklists" is only a
> temporary solution, only until (inevitably) one of the company's
> machines is eventually infected again, and the whole insane Keystone
> Kops episode will inevitably play out again.

  If your client attacks the rest of the internet... again, the rest of
the internet will defend itself... again.  Shit happens; it's your job
as a consultant to anticipate and protect against it.  I repeat, why was
port 25 traffic allowed to/from any but authorized machines?  And while
we're at it, your client's NAT router should also be blocking...

  - all inbound traffic on privileged ports, excepting authorized ports
    to authorized servers

  - all outbound traffic to/from ports 135..139 and 445, and probably a
    few others as well

  - maybe even go so far as to put all desktop PC's on default deny at
    the gateway, excepting HTTP, HTTPS, FTP, and other necessary stuff.

-- 
Walter Dnes <[email-masked]> In linux /sbin/init is Job #1

---

From: Bill Cole <[email-masked]>
Date: Sat, 3 Mar 2007 18:42:22 -0500

>what % of spam is content rejected with a bounce?

All I have is anecdotal evidence, i.e. I know of sites that have 
switched from discard/quarantine/asynch bounce approaches to 
synchronous filtering at DATA time and rejecting then, and I know of 
none that have switched in the other direction. In addition, I can 
see the fact that user pressure has gotten before-queue approaches 
(now including Milter) into Postfix despite the publicly expressed 
misgivings of Wietse Venema about failure modes. I also can see that 
if one goes looking for cookbooks on how to put together a mail 
system that deals with spam, the answers today mostly are synchronous 
DATA-time filters, not after-queue approaches.

>many thousands of bounces a day, and it's still exceedingly rare.

There are always sampling issues. I don't think my sample is 
inherently any more valid than yours, but

Imagine a world where you have 2 classes of mail receiving site: some 
have filters set up and administered cluelessly and others have 
filters set up and administered by someone clueful enough to 
understand the two simple ideas that one should never trust the 
purported sender on mail that is deemed malicious and that one should 
avoid blackholing mail. Would you expect to see those classes 
bouncing the mail that you are responsible for at the same rates?

>which has its own obvious set of problems.

And there are a lot of Mirapoint boxes, and Sendmail and Postfix 
installations pumping mail through SA at DATA time.

People doing stupid things (like being a Barracuda customer) are 
going to be more obvious problematic and more difficult to deal with.
-- 
Bill Cole                                  
[email-masked]

---

From: der Mouse <[email-masked]>
Date: Sun, 4 Mar 2007 23:40:55 -0500 (EST)

> [M]aybe that's an approach we should strive for - an email system
> built on consensual agreements.

If you want UUCP, you know where to find it.

(Which is mostly to say that all the technology is already in place;
setting up UUCP-over-TCP borders on trivial given a UUCP setup, and,
while mailer support for UUCP has fallen out of favour, I doubt it has
been totally lost.  There certainly are enough people like me who date
back to the UUCP days still around to provide bootstrap expertise.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Mon, 5 Mar 2007 00:00:05 -0500 (EST)

> [...] because of the arbitrary blacklisting of an entire company,

Didn't sound very arbitrary to me; it sounded like the list following
its advertised critiera exactly.

> and which blacklister won't even tell us PRECISELY what they are
> objecting to from OUR specific compamy, and only just says "well,
> it's probably this... or maybe that..."

As is their right; you are not their user.  (The entity blocking the
mail on their advice is.)  That they are willing to talk to you *at
all* is because they're good people.

> The bottom line is that DESIGNING IN additional INTRINSICALLY FLAWED
> mechanisms like this, as we have been talking about here, is
> TECHNICALLY IRRESPONSIBLE.

You keep repeating that these mechanisms are INTRINSICALLY FLAWED, as
though repetition of that assertion would somehow convince us of its
truth.  You'll need more than repeated assertion to do that.

Besides, flawed or not, it's about the best we've got.  If you think
you can do better, build it and try it!  If you're right, I'm sure a
lot of people will be delighted.

> The fact that the present way of handling this is screwed up is NOT a
> good reason why every company in the world ought to be forced to work
> around such issues.

You're right, it's not.  That it's overall the best way we have at
present, that is, or at least much closer to.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Mon, 5 Mar 2007 00:05:06 -0500 (EST)

> Right.  And IP addresses are a LOUSY way to base that, for a whole
> variety of reasons.

Statistically speaking, this appears to be simply false, possibly
except in an "it's the worst way around, except for all the others"
sense.

Even in your case, it worked very well, it seems to me.  It alerted the
subject company to at least three major problems[%], at no greater cost
than a few days' disruption of their email traffic.

[%] (1) That they were running malware propagation systems on their
    inhouse computers; (2) that their network was set up such that the
    resulting infections could spew; and (3) that they didn't have
    proper expertise to deal with it (you implied that your involvement
    with them will go up sharply because of this, so hopefully this
    last, at least, is now alleviated).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign