Subject: Re: [Asrg] How about we do something about spam?

From: <[email-masked]>
Date: Tue, 30 Jan 2007 22:07:51 -0600

[problem of botnets as spam originators]

> Isn't the solution to decline ALL mail from obvious pool 
>addresses? I hear 
> the argument that you can't put pool addresses in a 
>DNSBL because next 
> week the bot will have a different address. So put the 
>whole pool in the 
> BDSBL. 

The solution to the problem is actually AMAZINGLY 
simple... I know that a lot of y'all have this fixation on 
IP-based solutions, but a FAR better solution (rather than 
attempting to block spam AFTER the botnets are recruited) 
is to block the virus/worm code-containing E-mail messages 
BEFORE they infect those computers.

And that is really rather easy... you simply block any 
HTML or attachments (and particularly EXECUTABLE 
attachments) that isn't coming from a sender that is known 
and trusted by the recipient TO SEND THEM EXECUTABLE 
CONTENT.

Note that MOST users (probably 98-99%) will not whitelist 
ANYBODY to send them executable content in E-mails...!

The other way that botnets are recruited are by people 
visiting infectious Web sites, but that is a problem for a 
different list.

> ...This will result 
>in a security  
> disaster when an MTA holding thousands of private keys 
>becomes  
> compromised.  Clients transmitting or signing email MUST 
>be  
> identifiable and spam MUST be made illegal.  Lack of 
>SMTP client  
> identification and spamming is _directly_ responsible 
>for the spread  
> of much of today's malware!

The fixation on "client identification" (like SPF does) 
isn't very effective for the simple reason that an 
infected machine can send spam using all of that machine's 
certifications and habitual outgoing mail server.

Likewise, a person can need to send legitimate mail from 
an inhabitual location (such as a cruise ship Internet 
cafe).

What IS (much more!) effective is to determine whether an 
outgoing (/arriving?) mail message LOOKS "LIKE" the mail 
that the legitimate user of the now-infected machine 
habitually sends to a given correspondent.  Ideally, that 
"looks like:" rule and criteria would be different for 
each correspondent recipient.

> The criminal element has demonstrated individuals can 
>not be easily  
> tracked in today's Internet.  Those in the business of 
>transmitting  
> messages should identify their clients and not abuse 
>network  
> resources by allowing bulk unsolicited promotions of any 
>sort.   

What is 'legal' and 'not legal' will depend on from which 
country the messages originate.  "Identifying clients" 
doesn't accomplish much if a legitimate, honest user finds 
that their machine has been infected.  What do you want to 
do, sue the previous, also-innocent victim?

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: Seth Breidbart <[email-masked]>
Date: Tue, 30 Jan 2007 23:43:36 -0500 (EST)

> and trusted by the recipient TO SEND THEM EXECUTABLE 

Pray tell, how am _I_ to block the executable content from some dialup
luser on level3's machine?  All _I_ can do is block his emissions from
_my_ machines.

> ANYBODY to send them executable content in E-mails...!

Are you considering .jpg to be executable?

> visiting infectious Web sites, but that is a problem for a 

But the *spam* emitted by those machines _is_ a problem for this list.

Seth

---

From: Dan Oetting <[email-masked]>
Date: Tue, 30 Jan 2007 23:13:37 -0700

From: 	  [email-masked]
	Subject: 	Re: [Asrg] How about we do something about spam?
	Date: 	January 30, 2007 11:11:25 PM MST
	To: 	  [email-masked]

On Jan 30, 2007, at 9:07 PM, [email-masked] wrote:

> The solution to the problem is actually AMAZINGLY simple... I know  
> that a lot of y'all have this fixation on IP-based solutions, but a  
> FAR better solution (rather than attempting to block spam AFTER the  
> botnets are recruited) is to block the virus/worm code-containing E- 
> mail messages BEFORE they infect those computers.
>
> And that is really rather easy... you simply block any HTML or  
> attachments (and particularly EXECUTABLE attachments) that isn't  
> coming from a sender that is known and trusted by the recipient TO  
> SEND THEM EXECUTABLE CONTENT.

At the risk of giving the criminals more ideas, what if there is a  
stealth virus that watches who you send executable attachments to and  
every once in a while attaches itself to one of those emails by  
infecting the application that you are already sending?

> Note that MOST users (probably 98-99%) will not whitelist ANYBODY  
> to send them executable content in E-mails...!

 From a quick survey, I would say that 90% of the participants on  
this list don't even consider it a possibility that a silly windows  
virus in an email attachment could infect their machine. Most of the  
rest would be adequately protected. Some though may actively seek the  
viruses so they can disassemble them. But then, this isn't a typical  
user population.

A substantial portion of the net user population are actively  
exchanging executable files. I even get the occasional executable  
file from my dad forwarded through a long chain of friends. He  
complains sometimes about not being able to open them at home but  
forwards them to his office where they will run.

> The other way that botnets are recruited are by people visiting  
> infectious Web sites, but that is a problem for a different list.

There are lots of other vectors for passing malicious code to  
machines willing to suck it in.

But I don't believe in blocking legitimate activity to stop a few  
criminals that also use that activity. If an ISP can block executable  
attachments in the "hope" of preventing a users machine from getting  
infected then they can just as easily unplug that users machine from  
the net IF it gets infected and starts abusing the net. If an ISP  
wants to be proactive they could supply anti-virus tools like a Linux  
installer for their customers.

-- Dan Oetting

---

From: Devdas Bhagat <[email-masked]>
Date: Wed, 31 Jan 2007 20:11:07 +0530

On 30/01/07 22:07 -0600, [email-masked] wrote:
<snip>

> BEFORE they infect those computers.
Ideally. On the other hand, that option is often not in our hands.

> and trusted by the recipient TO SEND THEM EXECUTABLE 
Recipients are very often not in a position to make that judgement.
Also, how many of those trojans spread via browser exploits, spyware, or
other similar techniques? The email exploit vector is mostly focussing
on getting people to visit websites rather than actual distribution of
exploit code.

Now the idea of suing people who allow their hosts to stay infected is
one I like. A few headline making cases and we *might* have results.

Devdas Bhagat

---

From: David Maxwell <[email-masked]>
Date: Wed, 31 Jan 2007 11:05:21 -0500

> ANYBODY to send them executable content in E-mails...!

The reason people have a fixation on IP-based, or signature-based
identification mechanisms is simple.

Without a guarantee of 'identity', you can't whitelist someone. You'll
end up adding a whitelist entry which viruses will forge mail from in
order to get to your inbox.

A whitelist is simply an end-user accredited reputation service. Like
all reputation mechanisms, it makes no sense if the entity being queried
for can not be proven to be the same as the one being vouched for.

-- 
David Maxwell, [email-masked][email-masked] --> Although some of you out
there might find a microwave oven controlled by a Unix system an attractive
idea, controlling a microwave oven is easily accomplished with the smallest
of microcontrollers. - Russ Hersch - (Microcontroller primer and FAQ)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 31 Jan 2007 09:34:41 -0800

> for can not be proven to be the same as the one being vouched for.

There should be a generalized rule to not automatically process
information from unknown sources.  Processing includes fetching images,
running scripts, validating digital signatures, and verifying IP address
authorization (especially when this might require hundreds of
transactions).  Such a rule will not expose internal handling and
minimizes risks associated with DDoS attacks.

Only when a _trusted_ source has been verified, should the message be
annotated.  A recipient's address book could be one method of
determining a trusted domain where out-of-band verification techniques
can be employed.  DKIM can enable opportunistic security once autonomous
association is permitted.  Autonomous association allows the use of DKIM
to scale and to obtain "critical mass". 

DKIM permits message replay.  A message signed by a major ISP can be
replayed from any other location.  The DKIM signature might prevent
false positive detection of phishing attempts, but it would be risky in
many cases to use a DKIM signature as a basis of acceptance
white-listing.

A means to correlate DKIM domains with that of a verified SMTP client
could permit DKIM serving as a basis of acceptance.  A similar strategy
could be used for qualifying DSN. See:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

-Doug

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 11:39:49 -0600

On Wed, 31 Jan 2007 11:05:21 -0500
> order to get to your inbox.

Well, it IS likely that desperate spammers would try to 
forge mail to seem like it comes from widely-trusted 
senders who recipients are likely to have some kind of 
whitelist entries for.

On the other hand, that still limits spammers and viruses 
in terms of WHAT they can send, and encourages legitimate 
senders to not send types of content which are likely to 
be misused for malicious purposes by forgers.

> A whitelist is simply an end-user accredited reputation 
>service. 

If it were a simple go/no-go whitelist, yes.  The fact of 
it being a fine-grained whitelist is a horse of a 
different color, because it also creates a narrow 
sender-specific keyway through which mail from THAT 
SPECIFIC sender must fit in order to be accepted.

> Like

While that's a valid point, I'll also point out that once 
an E-mail has gone through an intermediary MTA, (in fact, 
even BEFORE then) it's hard to be 100% sure where it 
originally came from in IP address terms, either. 
 Spammers OFTEN forge counterfeit, bogus Received: headers 
too.

So what's to prevent them from forging a Received: header 
with a trusted-sender IP address?

The bottom line is that the best way to decide that an 
E-mail is legitimate or not is by examining THE TOTALITY 
of the information available, and that goes well beyond 
the information in the headers.  It includes relating the 
CONTENT of the mail to what the recipient expects from 
that sender.

If someone got, for example, an e-mail that claimed to be 
from me but which was all in chinese characters, they 
would probably quickly conclude that my return address was 
forged.

The fact remains that putting so much effort behind 
IP-address-based solutions will NEVER yield as good a 
solution as a solution which includes message content 
analysis ("SpamAssassin" or similar), ALONG WITH 
fine-grained, sender-specific rules which robustly deny 
spammers nearly all the tricks that they use to evade 
content analysis filtering.

And the OTHER major thing we need to do is to come up with 
a set of "best practice" guidelines (probably based on the 
"fine grained whitelist" and suitable default rules like 
I've proposed here) which basically eliminate E-mail as a 
recruitment mechanism for zombie spambot armies.  Forcing 
spammers to directly use their own machines for spamming 
would put a MAJOR crimp in their operations, and help make 
virtually all the other anti-spamming approaches to be a 
lot more effective.

I honestly don't understand why we're even still arguing 
about this.  It's obvious that it makes for a HUGE 
improvement, and obvious that it can be implemented 
without having to re-engineer the whole E-mail system or 
the whole Internet.

The biggest area of discussion is that it would 
(admittedly) be nicer to truncate the unwanted E-mail 
earlier in the distribution chain.  But that's not 
critical, at least from the end-user position.

More to the point is that if we DO implement this at the 
end-user position, nearly everywhere, spammers simply will 
give up trying to send E-mail that they KNOW will get 
through in only such tiny numbers that it simply isn't 
worth the effort anymore.

At THAT point it doesn't matter where we truncate the 
flow, because the only people still trying are those who 
are simply trying to play with the infrastructure of the 
Net, and:

   1)  there isn't any money to be made doing that;

   2)  it's about as satisfying as trying to argue with a 
vending machine that stole your money.

So it probably isn't NECESSARY to stop the transit earlier 
in distribution, if it WILL be stopped SOMEWHERE enroute 
(even at the end).

At least we can offer relief to the great majority of 
Internet users, and reduce the remaining problem (if there 
still is one) to something that ISPs and backbone 
operators can deal with.

BTW, that's another reason for my proposal that we limit 
the maximum size of non-whitelisted E-mails, too... so 
hopefully the bandwidth used by such residual spam 
messages will become smaller, as a percentage of total 
backbone traffic, as legitimate higher-volume traffic 
(video webcams, high-quality streaming audio, video 
streaming, etc) become dominant.  Hopefully it will also 
help discourage the spammers possibly shifting to bulkier 
types of messages which clog inboxes and the limited 
bandwidth of dialup users.
   
Gordon Peterson

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 11:54:42 -0600

> can be employed.  

I certainly agree that a major part of the solution is to 
not process dangerous E-mail arriving from 
unfamiliar/untrusted senders.

That said, we need to provide a default rule which allows 
receiving "safe" mail from new, first-time senders 
(long-lost friends, Customer Service requests from 
customers, etc), subject to SpamAssassin-like 
determination that it doesn't "look like" spam.

As for DKIM, I don't have strong opinions one way or the 
other at this point, but continue to remind folks that 
sometimes people send legitimate E-mail messages from 
inhabitual locations.  This could be a cruise ship 
Internet cafe, an Internet E-mail sending room in a post 
office in Beijing, or a "business center" in a hotel.  I 
think it's far more important WHAT IS IN the E-mail than 
where it "came" from.

Gordon Peterson