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

[blocking executable attachments]

> > 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.
> 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_ machine.
What one does is to block incoming messages based on a 
fine-grained whitelist, and with a default for 
non-whitelisted senders which is at least "safe" (no 
attachments, no HTML, less than some maxmium size). 
Instead of a gross no-nogo whitelist, the whitelist would 
list which features would be expected (and allowed) in 
E-mails from familiar and trusted senders.  After that 
initial triage, the remaining E-mails would still be 
checked by a SpamAssassin-type content filter (which could 
actually do a quite respectable job, given that 
text-as-image, embedded links, scripting, and most all the 
other classic spammer tricks would be simply ineffective.
> > Note that MOST users (probably 98-99%) will not 
> > whitelist 
> > ANYBODY to send them executable content in E-mails...!
> Are you considering .jpg to be executable?
No, although that could be its own whitelist/permissions 
category.  I wouldn't allow ANY image types for 
non-whitelisted senders, mainly because that allows 
spammers to send "text as image" to avoid content 
scanning.
 
> > The other way that botnets are recruited are by people 
> > visiting infectious Web sites, but that is a problem for 
> > a 
> > different list.
> But the *spam* emitted by those machines _is_ a problem 
> for this list.
Absolutely.  But if we put measures into effect to make 
one very unlikely to ever get their machine infected via 
an incoming E-mail, then we can hugely reduce spambot 
recruitment.
[next comment]

> Subject: [Asrg] please disregard message from me sent to 
> asrg list by accident
> My apologies.  Can't go trusting 
> "autocomplete" to always do the
> right thing.  I wonder if the fellow who is working on
> per-correspondent statistical
> profiles will incorporate flagging for confirmation of 
> outbounds as
> well that do not
> match what is normally sent _to_ a peer:  that feature 
> might have helped in this
> case.
While outbound spam detection might be useful at an ISP 
it's not likely to make a big dent in spam, simply because 
spammers either avoid the ISP's restricted mail servers or 
because they don't use a traditional ISP at all.  Also 
note that some "customers" represent a large array of 
subusers (say, a Starbuck's).  One can't reasonably expect 
those E-mail messages to resemble each other...!
[next comment]

> [...at the risk of giving spammers new idea, 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?
The fact is that very few folks, Internet-wise, ever send 
legitimate executable files as attachments to anybody. 
And few people will ever whitelist ANYBODY to send them 
executable attachments (or similarly dangerous ActiveX or 
scripting etc).  Those people (and they are a sizeable 
majoirty of the folks on the net, I believe) will 
basically NEVER get any E-mail viruses or worms.
Those who DO expect to get E-mail messages containing 
executables from their correspondents are probably also 
savvy enough (most of them, at least) to not be taken in 
by bogus messages pretending to be something they are not.
Now, it is certainly possible that a rogue program COULD 
corrupt a (say) compilation, so an in-theory-clean program 
was in fact infected BEFORE SENDING.
But again, we've still put a MAJOR crimp in virus/worm 
distribution, and if we do that well enough the spammers 
will give up on that venue (much like they've mostly given 
up on boot sector viruses on floppies).
> > 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. 
Sure, if you're running a (say) Alpha processor or some 
such, or for that matter if you're using an IBM mainframe 
for your E-mails, then a Windows virus isn't going to do 
much to you.
On the other hand, most of the participants on this list 
are a whole lot more savvy anyhow than the folks who are 
most likely to get their machines infected.
That's why it's not at all adequate to build defenses into 
(say) Exchange;  they need to be in Outlook and Outlook 
Express (for example) so that the great unwashed masses 
will have (and use) those defenses.
> 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.
And those who wish to receive them for such research 
purposes could simply ignore the warnings and enable them. 
Again, they probably aren't the problem areas for zombie 
recruitment.
> A substantial portion of the net user population are 
> actively  
> exchanging executable files. 
Sure, and some people don't use condoms, either.  That 
doesn't mean that we should do anything to enable or 
promote that sort of unsafe behavior.
> 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.
Obviously that's evidence of malfeasance by his office's 
system admins.
When I get such a "long list of forwards" of executables, 
I generally look at who sent it to me, see if it looks 
like they INTENDED to send it (or was it a hostile alien 
bot from their machine which sent it?), etc etc.  And even 
then, I tend to put it in my "zoo" (critter quarantine) 
folder, for several months and then may eventually check 
it out if nothing has indicated a problem with the file 
based on other, less cautious recipients.
> > 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.
Perhaps, but in any case OUR task here is dealing with 
E-mail.  Our charter is not "the infinitely robust 
operating system".  Not that that's a bad thing, but it's 
not really our problem HERE, at the moment.
> But I don't believe in blocking legitimate activity to 
> stop a few  
> criminals that also use that activity. 
The point is that you're not "blocking" ANYTHING that the 
recipient wants to receive.  That's because the recipient 
can whitelist anybody they like to send them any kind of 
content they like.  It only just says that (probably 
bogus) mail from unknown/untrusted senders will be 
quarantined and probably never released.
> If an ISP can 
> block executable  
> attachments in the "hope" of preventing a users machine 
> from getting  
> infected 
I don't propose that the filtering be done by the ISP, 
although the principle certainly doesn't preclude the 
filtering from being done at the ISP, but (again) under 
the specific direction (perhaps the default one) set by 
the individual recipient.
> then they can just as easily unplug that users 
> machine from  
> the net IF it gets infected and starts abusing the net. 
The problem is that even an infected machine might still 
need to send occasional, legitimate E-mail messages.  They 
also might need access to the Net to locate and download 
disinfection software, etc.
Disconnecting a computer from the Net is not a good 
solution, IMHO.
> If an ISP  
> wants to be proactive they could supply anti-virus tools 
> like a Linux  
> installer for their customers.
Many of the bigger ISPs DO provide antispam software, but 
antispam software (with few exceptions) only identifies 
and blocks KNOWN exploits.  Most viruses are at their most 
dangerous and prolific BEFORE they are recognized by ANY 
antispam program.  The nice thing about what I propose is 
that most folks would simply never receive an E-mail virus 
ever again, even if they didn't update their viruses 
defenses for many years.  No more daily/weekly/monthly 
updates of virus signatures.
[next comment]

> > ...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.
> Ideally. On the other hand, that option is often not in 
> our hands.
I believe it is probably desirable to implement such a 
filter at the RECIPIENT, either at the recipient's ISP, or 
at the recipient's machine itself.  ISPs can recommend 
solutions.
> > 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.
> Recipients are very often not in a position to make that 
> judgement.
And by default, executable attachments would be disabled 
from delivery to most users.  They could re-enable that 
(or other dangerous stuff) but only after being warned 
about the hazards, and why they should not do so unless 
they know EXACTLY what they are doing and WHY they are 
doing it, etc.
> Also, how many of those trojans spread via browser 
> exploits, spyware, or
> other similar techniques? 
Some, surely.  But our charter HERE isn't really "Web 
browser safety", that's really an issue for another group.
Meanwhile, I still believe that eliminating E-mail as a 
vector for virus/worm distribution will ENORMOUSLY help 
both the virus/worm problem, AND the spam problem.
> The email exploit vector is 
> mostly focussing
> on getting people to visit websites rather than actual 
> distribution of
> exploit code.
Sometimes yes, sometimes no.  Increasingly, Web browsers 
are being configured out-of-the-box to not run executable 
content without checking with the user, first.  (And that 
process could probably be improved further).
> 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.
I don't think that suing other victims is ultimately a 
very good solution to the problem.
[next comment]

> > simple... I know that a lot of y'all have this fixation 
> > on 
> > IP-based solutions, ...
> 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. 
Well, you certainly can't whitelist them on the basis of 
IP address;  I might send E-mails during my vacation from 
a cruise ship Internet cafe or from a post office Internet 
E-mail center above a post office in Beijing.  What 
matters more isn't the IP address, it's whether I send 
E-mail that still looks like what I send to a specific 
recipient.
And I don't even think it really matters all that much 
whether we have a "guarantee of identity" anyhow, although 
it might be nice (if it's possible without major 
inconvenience).
> You'll
> end up adding a whitelist entry which viruses will forge 
> mail from in
> order to get to your inbox.
Viruses on some other machine will probably not know what 
YOUR whitelist permissions are based on.  And individual 
recipients are likely to have different whitelist 
permissions anyhow.  The result is a twisty and narrow 
path which is difficult for a virus or worm to navigate 
through.
I'm not saying that it's impossible that viruses won't 
suddenly be more specific about whose From: addresses they 
forge (say, Borland or Symantec or someone that 'more' 
users might otherwise trust to send them executable 
attachment).  But most viruses won't know WHICH recipients 
are set up to receive THAT sort of content from THAT 
E-mail address.
> 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.
I disagree that "it makes no sense".  I don't believe that 
it HAS to be 100.0000% perfect.  I think it basically has 
to be good enough that spammers and worm authors decide 
their time is better invested doing something else.
[next comment]

> 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).  
I think that's one reasonable interpretation.  Things 
which COULD be dangerous, or which are commonly used to 
avoid antispam content scanning, ought to simply be 
considered "a priori" evidence of hostile intent if it 
hasn't been negotiated and cleared with the individual 
recipient in advance.
> Such a rule will not expose internal 
> handling and
> minimizes risks associated with DDoS attacks.
Yes.

> 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.  
I don't think it's probably necessary (or even desirable) 
to use more elaborate "verification techniques".  I might 
be visiting a friend and need to send one of MY E-mail 
messages from HIS machine.  That shouldn't cause any 
grief, really.
> A means to correlate DKIM domains with that of a 
> verified SMTP client
> could permit DKIM serving as a basis of acceptance.  
I believe that vanity or personal domains should be able 
to be used from inhabitual locations.  That's why I 
believe these sorts of 'verified SMTP client' stuff is 
misguided.  (It's neither necessary nor suffient to 
determine 'spamminess").
[next comment]

> > The reason people have a fixation on IP-based, or 
> > signature-based
> > identification mechanisms is simple.
There is an old adage among programmers... "Software 
should be as simple as posssible, BUT NO SIMPLER!!!"
[next comment]

> Put another way, zombie botnets are the enabling 
> technology of spam
> (phishing, etc.)
>
> Easier said than done I realize, but it's inherently 
> illegal to create
> and operate zombie botnets, and I don't mean just in the 
> US, most
> anywhere on the planet.
[snip]

> It's as if I could make this message appear in 100 
> million mailboxes
> in the next few hours, despite many efforts to the 
> contrary.
> I couldn't. You couldn't.
>
> It takes a zombie botnet.
>
> There are other issues, but I'm focusing on this one as 
> the most
> egregious and, I hope, easiest to agree on in terms of 
> contribution to
> the problem and legal/moral unambiguity.
I agree... it is much harder to get the spam problem under 
control simply because of spambot recruitment.
And I don't think it's all that hard to take a BIG bite 
out of that.
[next comment]

> By making spam illegal, the act of transmitting a high 
> volume of  
> unsolicited messages would then clearly serve as 
> evidence of crime.
Right, but probably not on the part of the OWNER of that 
infected machine.  He is probably just another innocent 
victim himself.
> This would place accountability onto the provider.  The 
> efforts  
> behind SPF and DKIM are aimed at passing blame to a 
> hapless  
> customer.  Thousand of domains might share an SPF 
> authorized server  
> which is likely to have only a few IP addresses.  
An example would be a domain provider like Domain Direct 
or GoDaddy.  But as a customer of EACH of those, I still 
could be traveling and need to send a message (using MY 
domain name) from a cruise ship Internet cafe or post 
office E-mail kiosk.  I have NO control over which SMTP 
server processes my message.
> Making spam illegal would make networks many orders of 
> magnitude safer.
CAN-SPAM has done REMARKABLY little to cut down on 
spamming.
I think a far better solution is simply to allow the 
recipient to efficiently refuse mail they don't want, or 
don't trust.
> Make a law that requires 
> providers sign all  
> public messages with their own keys.  There should even 
> be laws that  
> prohibit signing with a customer's key.  
So what about mailing lists, such as Yahoogroups?

> Customers can 
> reference  
> specific keys used on their behalf instead.  There 
> should be laws  
> against the use of highly danger authorization schemes, 
> such as SPF/ 
> Sender-ID.  
I think SPF is a very poor solution.

> Poisoning or destroying DNS is easily 
> accomplish with  
> this loathsome technology.  A technology also aimed at 
> side stepping  
> accountability.
I don't like SPF either.

> > There is no other way we know of to send out on the 
> > order of one  
> > billion emails per day for a cost which even approaches 
> > the  
> > expected value of those messages and would so 
> > successfully evade  
> > already commonplace blocking and filtering methods.
> > Does anyone disagree with that?
> Enforcement must make any spam illegal AND hold 
> providers  
> accountable.  
I don't think "providers" have all that much control.

> To ensure enforcement, allow anyone 
> damaged to seek  
> legal relief.
Talk about encouraging rampant lawsuits.  (What happens 
when the spammers THEMSELVES sue as if they are the 
injured party...??!)
> There are few providers that want to consider their 
> accountability as  
> part of the cost of doing business.  No one can afford 
> to clean up  
> the mess being made.  
The way that spam will ultimately be controlled is by 
making it hard enough that it's more trouble than it's 
worth.
> Content or intent do not need to be considered.  The 
> volume and lack  
> of solicitation provides key differences.  
I'll provide a counter-example.

A manufacturer does not "solicit" customer service E-mails 
(well, at least not from specific, known consumers).  They 
still need to be able to receive e-mails (at least of 
"limited" types) from previously unknown-to-them senders.
> The lack of 
> solicitation  
> allows for rather easy methods of enforcement.  One 
> grows weary  
> logging trespasses that can only be considered privately 
> as bad.   
I think legal means are ultimately problematical because 
of the indeterminate jurisdictions involved.  What's more, 
the problem can be solved adequately without lawyers and 
courts.
> Those making these private assessments remain exposed to 
> civil  
> proceeding as a result.  Spam must be illegal to stop 
> it.  
I disagree.

Among other things, it is VERY difficult to prove in a 
court of law WHO caused the spam to be sent.
People will stop sending spam when it ceases to be 
worthwhile.

[next comment]

> Providers must control access, block abusers, and be 
> held accountable
> when they fail to do so.  When someone spams, they must 
> be blocked.
So you block Aunt Matilda because her machine got 
infected.  Now what?
> Sending volumes of unsolicited messages is rather easy 
> to detect, 
How do you know (and prove) that they are unsolicited?

> where
> miscreants can be blocked quickly.  When this traffic is 
> from customers
> using compromised systems, then each problematic 
> customer's outbound
> messages must be blocked.
I don't think that must be done.  I believe my approach 
allows them to continue to send legitimate mail, and 
allows an effective triage of legitimate from illegitimate 
mail.
> Of course, the next concern might be malware placed in 
> websites, even
> things like Wikipedia might contain malware.  There must 
> be efforts made
> to ensure blogs are properly defanged as well.
Agreed, but that is a separate issue than OUR charter 
HERE.
I am concerned about E-MAIL as a vector.


[next comment]

> Make spam illegal and hold providers accountable 
> instead.
Who do you sue?  How do you prove who caused the spam to 
be sent?  What court has jurisdiction?  Who has to pay the 
lawyers involved?

Gordon Peterson
http://personal.terabites.com
1977-2007  Thirty year anniversary of local area 
networking
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg