Subject: [Asrg] Re: Usefulness of wholesale blocking of attachments for SMTP? (Lane Sharman et al)

From: [email-masked]
Date: Sun, 18 Apr 2004 10:49:02 -0500

I'm going to combine my comments regarding several related posts on this thread.

> What interests me is point of origin detection, identification and 
blocking. 

Fine, except that it doesn't really solve the spam problem.  If spammers have to 
use "real" return addresses (with valid SPF and certificates and all the rest) 
on their spam E-mail, they will.  It is only out of "being nice" that they 
currently generate bogus return addresses, largely to avoid harassing "real" 
users with undeliverable bounces and complaints.

Once you identify the "real" machine where the transmission occurred, more 
likely than not it will turn out to be a zombie-infected spambot.  So you get to 
throw bricks at a fellow victim.  Fat lot of help that does!

> In other words, what addition to the SMTP protocol would make 
it possible to identify, for example, "unstamped email being sent out in 
bulk mode". 

What does that achieve?  All it does it require spammers to send STAMPED spam.  
As for "bulk mode", if you have recruited/infected enough zombie machines, you 
don't even have to send it out in bulk mode.

Anything that a legitimate sending computer can send via SMTP (or any variant 
you choose to define) can be sent by an infected zombie spambot computer via 
SMTP (or the defined variant).  You have changed things (I guess that makes SOME 
people feel better) but you haven't really solved the problem.

The problem isn't really the spam mail itself (although I agree that it comes at 
some cost) as much as it is the fact that it (a) chews up inbox space, (b) 
wastes bandwidth, and (c) annoys the recipient.  

Suitably clever content filters (once it's not possible to evade them by 
HTML-based tricks) can get rid of much of the spam, thus preventing many/most 
cases of (c).  

Inbox space and bandwidth waste are greatly reduced by spammers learning that 
sending bulky attachments or (also bulky) HTML-burdened E-mail is the kiss of 
death on the spam they send out.  This helps (at least) with (a) and (c).

The best way ultimately to put a serious dent in spam (and worms/viruses) is for 
it to be perceived as largely futile.  And if 99.99% of the junk (or more) never 
even gets delivered to a human being, this has got to help achieve that.

> Statistically, isn't it possible to identify an instance of 
a bulk email event on the net?

Perhaps it is, although it's hard to define "a bulk email event".  What if NO 
TWO of the "bulk" e-mail messages are identical?  What if they "originate" at a 
multitude of zombie spambot machines?  I think that ultimately it's probably 
better to detect unwanted E-mail by a variety of pattern matching heuristics 
(and I make use of a variety of these in my own personally written SPITBOL-based 
incoming E-mail filter) and simply reroute to a deadletter box (or just route to 
the bit bucket) messages which are clearly unwanted.

More troubling, what do you do about spam which is NOT the result of "a bulk 
email event" but which is more individualized or somehow (perhaps slightly) more 
targeted than that?

> Anyway, I am doing my share to block spam as close to the point of 
origin as possible but I am still not happy. 

Some of it is truly quite difficult to identify in an overall, anticipatory kind 
of way.  But the great majority of it can be identified without TOO great a 
difficulty.  One frustration is the increasing spammer use of "one-shot" 
disposable domain names, that presently each individual recipient must block 
separately.  There needs to be a good way for a cooperative effort here, such 
that the first folks to detect a spam mailing can rapidly alert others which 
domain names are involved.  Then those domain names can be added to filters in 
use by other users.

Rather than making mail filters poll a central site (these have in the past been 
victimized by DDOS attacks), maybe one approach here might be to set up a 
Yahoogroup that could be used to rapidly distribute these "disreputable domain 
names" and IP addresses along with a utility which would add them to the 
recipients' HOSTS files (and from there, to their incoming mail filters).

> Just today, I was at a friends office and my outgoing email was blocked 
because cliff.concentric.net is now on a spam list.

Yes, and that's one of the problems with SPF, "authenticated users", 
certificates and other such schemes.  Ultimately it's not very helpful to throw 
rocks at fellow victims.

[snip]

>>   I mail-server I use regularly (Indiana University) has taken, in 
>>response to worms and other malware useing .pif. zip, exe, etc 
>>attachments to spread their damage, has taken the (IMO) rather drastic 
>>step of blocking almost *all* attachments ...

That's sort of the approach of Microsoft's new version of Outlook, where they 
allow blocking by attachment extension.  That's better than nothing, but it 
needs to be SOMEWHAT finer:  it needs to allow the recipient to enable specific 
attachment types (and certain classes of HTML markup) to be received from 
specific approved-and-trusted senders.

>>  Coincidentally, another list I'm on had a post from the admin of a
>local university, talking about spam.  Here's what he said.
>
>(quote)
>   I don't support any Windows systems, yet I seem to spend a huge amount
>of time dealing with problems relating to Windows non-security.  During the
>fall/winter term we had to deal with
>
>   1) When students returned to Residence in September, at least half of
>      their machines were infected.

One of my colleagues recently dealt with a client whose system was "having 
assorted problems".  Upon installing Spybot-Search-and-Destroy over TWO HUNDRED 
instances of spyware were found on the unwitting user's computer.  There were 
additional Spyware programs that SPYBOT S&D did NOT find, besides.

Microsoft has definitely gotten the message about security, and although they're 
not moving as quickly as (or necessarily in the direction that) I'd like, 
they're making some big strides.  It's hard to rapidly turn such a huge ship.

>   2) Anemic Internet connectivity because our commercial traffic shaper
>      would go bonkers trying to maintain state on connections initiated by
>      network virus infected machines.
>   3) Overloaded Internet pipe due to coordinated DOS attack from trojan
>      infected machines.  It's amazing how much traffic an infected, recent
>      model Intel machine with a switched 100Mbps connection can generate!

Right, and once you have HUNDREDS of those...!!

Again, the solution to this is NOT just antivirus/antiworm programs that detect 
specific known ones.  All viruses and worms are at their most prolific BEFORE 
*any* A-V program detects them.  

The fact is that MOST users do NOT have a legitimate need (or even DESIRE) to 
receive executable programs as E-mail attachments (and those who maybe don't 
know better should be warned by a suitably dire-sounding warning message in the 
dialog box before they can be wheedled by a convincing-sounding E-mail into 
enabling that).  Once viruses can't use E-mail for delivering attachments...

You don't want what Outlook (now or soon) offers:  either .exe attachments or 
not.  Too many users will VERY RARELY need them, so enable them... :-(   You 
want it so they must be enabled for (only!) SPECIFIC INDIVIDUAL senders.

This creates a delivery window that's small enough that a broadcast virus or 
worm will have a very tough time navigating their way through it.

>   4) Infected Windows machines are now a major source of spam.  After
>      doubling the performance of our mail server in August we were
>      astonished to find only a few months later that it was being pounded
>      into the ground by the growing stream of spam related mail.

Right, and that's precisely why SPF, certificates, DNS modifications, and sender 
authentication schemes are ALL doomed to fail... because nothing at all prevents 
spambot zombies from sending their junk using the unwitting owner's legitimate 
sending credentials.

Windows machines aren't particularly more susceptible to this than Macs or Linux 
boxes are, other than their ubiquity makes them a more appealing target for 
hackers and spammers to target.

If everybody were running Linux instead, then we'd see all the same stuff 
happening on Linux.

>   5) Spammers frequently use bogus @UNIVERSITY addresses on their mail
>      and so all undeliverable messages are bounced to us.  We are typically
>      receiving over 1 million such bounce messages every day!  

Right.  That's part of why schemes that add yet more "authentication" traffic 
(challenge/response, DNS queries, etc etc) to the net as a way of dealing with 
spam are counterproductive.  Bouncing spam messages back to supposed senders 
(whether the return address is bogus or not) is also as a rule singularly 
unhelpful.

> Since the
>      spam mail that is the source of this problem originates from thousands
>      of infected machines there is no solution other than to throw more
>      hardware at it.

Even if you can identify where it "really" came from.

But that's also why we will never get very far controlling the spam problem 
unless and until we also make it harder for viruses and worms to infect 
machines.  My proposals regarding HTML and attachments and whitelisting them in 
a finely-grained way from approved senders provide a unified mechanism which 
goes a LONG way towards solving BOTH problems using one coherent, single-ended, 
easy-to-implement, recipient-controlled, immediate-gratification, high-payback 
common approach.

Again, the virus/worm problem isn't only just a throw-rocks-at-Microsoft problem 
(well, at least not for the traditional reasons) but would still happen in Linux 
or Mac boxes as well, if they were so ubiquitous as to present an appealing 
target for hackers.

>   6) When my desktop Windows machine at work was upgraded to Windows XP
>      the machine was infected before the installation was finished.  It
>      took four full virus scans and three reboots before it was clean.
>(end quote)
>
>  See #5.  The deployment of RMX/SPF would make a huge difference to
>this site.  The bounce messages from forged spam could be
>automatically scanned and discarded.

It SOUNDS like it would, but ultimately it doesn't help very much.

First, not all mail that passes SPF tests can be guaranteed to not be spam (due 
to zombie spambots that could send with appropriate credentials).

Second, mail that FAILS SPF tests can not be guaranteed TO be spam (vanity 
domains, traveling salespeople, mail from Internet cafes, Yahoogroups and other 
mailing lists, etc etc etc)

The fact is that you can't really say that "spam has forged From: addresses".  
Some of it does, today, even most of it maybe, but if you and everyone else 
block the mail that does you can COUNT on the fact that tomorrow, spammers won't 
do that anymore.

I don't think that forcing them to make that change is particularly helpful, 
either for spam recipients or for the victims whose E-mail addresses suddenly 
get flooded with complaints for spam they didn't knowingly send.

(How would it help your university (or the people involved!) if those million 
bogus messages a day, instead of falling on the floor or being bounced by your 
mail servers, all went into legitimate student or staff Inboxes instead?  Think 
about that for a while.)

>  This situation is not unique.  Spam (and insecure Windows machines)
>constitute a clear and present danger to the net.  

Of course.  Let's just make sure that the solution(s) that we propose are not 
worse than the problem they're designed to solve.

> I'm saddened to see
>my prediction of 3 years ago fulfilled: Everyone else's email systems
>will end up looking like mine; overloaded and useless due to the
>overwhelming flood of spam.

We all agree that there's a problem.  We just disagree (apparently) on what will 
and what won't fix it, and will or won't cause MORE of a problem in the process 
of doing so.

> --------------000601090602070901020908
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

> {!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  {meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  
One of the things that has been SINGULARLY unhelpful toward addressing the 
problem of overloaded mail servers is this plague of HTML-burdened "alternative" 
copies of E-mail messages.  It is rare indeed that these provide genuinely 
valuable additional content;  instead they usually are loaded with gratuitous 
graphic gizmos, Web bugs, possibly malicious scripting, misrepresented clickable 
links, and text-as-image designed to evade content filters.  While I'll accept 
that some folks can argue that their needs for HTML-burdened E-mail is 
legitimate, certainly a lot of it is not.  Mail with HTML-burdened attachments 
is typically 3x-5x larger than it would be as plain ASCII text.

If HTML-burdened attachments were removed from non-whitelisted senders' E-mail 
(and this would catch at least most of today's spam) then such mail would be 
70-85% smaller in volume than it is today.  

I'm NOT suggesting that "all HTML-burdened E-mail is spam" (although MUCH of it 
coming from unknown/untrusted senders is!).  

True, spammers will respond to the "sending HTML is the kiss of death" 
realization by sending their E-mail spam as plain ASCII text (which then is 
easier for filters to identify) but in ANY case, the size of the remaining 
plain-text mails is far smaller.  Like 75-85% smaller.  Win-win.

> It seems to me that there would be some of the following in a bulk email 
solution. Because, for sure, there are a lot of legit bulk emailers.

> a) an accreditation process which would include certification of a legit 
sender. The sender has to present himself/herself before a physical post 
office for example.

I don't want to see any solutions that result in some "authority" deciding what 
one can and cannot send.  That's just begging for censorship, and we've got 
quite enough of that already.  We need to have the freedom to send basically 
anything, INCLUDING mail criticizing the government or other censoring body.

> b) a bulk stamp purchase agreement is executed and paid for by the 
originator.

Postage schemes for E-mail is repugnant.  It's just a way to turn it into a 
profit center for those who control it.  When WATS lines were first proposed, a 
big part of the argument in favor was that 85-95% of the cost of a long distance 
phone call was the cost of billing you for it.  WATS (800-) lines were supposed 
to disconnect all that extra overhead, thus justifying the huge price reduction. 
 (Of course, that's not the way it worked out and it's most all still 
incrementally billed, but one can still believe the original "it's the cost of 
billing you for it" argument).

US-based phone companies have wanted for decades to bill individually for local 
calls (the way most phone companies in other countries do) but thankfully, we've 
managed to beat that back so far.  Let's not lose that (HUGELY important!) war 
in the E-mail space.

> c) a set of designated relay servers would be designated to "affix the 
stamp" on behalf of the originator, the bulk sender.
d) any relay could verify that a stamp instance as valid with a remote 
lookup; 

This "remote lookup" just adds more network overhead (and thus cost) to the cost 
of carrying ALL traffic, including the legit stuff.

[snip]

> Of course we must remember that bulk email is not necessarily bad. 
> There are many instances of legit bulk email (e.g. acceptance letters 
> from a college, bank statement notifications, etc.). So knowing that a 
> specific email is bulk is only half the problem, once you know it is 
> bulk there needs to be a determination as to whether it is legit or not.

Of course, spam could be NOT "bulk" mail too.  Ultimately, you want to test for 
and identify SPAM.  "bulk or not" might provide a (maybe minor) input to that 
function, but is NOT enough to identify (or identify as NOT) spam.

One can certainly envision a spambot worm that would periodically drop 
personalized one-of-a-kind spams into the infected machine's Outlook "outgoing 
mail" folder, possibly even complete with the owner's sig file, SPF or other 
From: address authentication, certificate even, and everything.  That's NOT 
going to look, most likely, like "bulk" mail, but it CERTAINLY is still spam.

> This is what Project Lumus, TEOS and some other mechanisms try to do - 
> whitelist or accredit legit bulk emailers. 

That's almost as repugnant as making sure that all the radio stations and news 
papers in a given market hew the same political philosophy.

I don't want to see "solutions" that result in some agency (whether public or 
private) deciding whether a given person or company's political opinion can be 
distributed to a wide audience or not.

> Of course, a single unified 
> framework of standard for the entire Internet on exchanging 
> accreditation and reputation data is something that might solve this 
> as well, so far there hasn't been sufficient interest in that area 
> (the SMTP-VERIFY subgroup was looking into it as some point).

Again, the problem is that an "accredited" machine belonging to a trusted user 
can easily be taken over by a zombie spambot and used to pump out spam.  

We want to identify and stop spam and worms, REGARDLESS of who sends them or 
why.

[snip]

>>a) an accreditation process which would include certification of a legit 
>sender. The sender has to present himself/herself before a physical post 
>office for example.

> Right.  There's a bunch of possibile reputation systems here, from
ISIPP's IADB o the proposed .mail domain

Again, it doesn't ultimately solve the problem.  You're creating a bureaucracy 
(which ultimately will become a too-powerful big profit center, just like 
NetworkSolutions/Verisign became for DNS) that eventually will become 
belligerant and hard to rein back in.

> You're conflating two unrelated things here.  Authenticating senders is
a fine idea.  That's what proposals such as SPF and Domain Keys do, with
no stamps needed.

It only SOUNDS like a good idea, until you realize that in the end analysis, IT 
DOESN'T SOLVE THE REAL PROBLEM.  And in the process, it creates a number of 
problems for legitimate users.

> E-postage is a horrible idea because it introduces more problems than
it is supposed to solve.  

This is true of MANY of the solutions we've talked about here.

> See my white paper at http://www.taugh.com
for a longer discussion of the insoluble problems with e-postage.

I agree that E-postage is a repugnant idea, and CERTAINLY DESERVES to be a 
non-starter.  We need to get a huge wooden stake and drive it through the heart 
of that one, to KEEP it dead permanently.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections!  http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

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

---

From: "Jed Margolin" <[email-masked]>
Date: Sun, 18 Apr 2004 13:59:51 -0700

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Sunday, April 18, 2004 8:49 AM
Subject: [Asrg] Re: Usefulness of wholesale blocking of attachments for
SMTP? (Lane Sharman et al)

> I'm going to combine my comments regarding several related posts on this
thread.
.
.
.
.
> even gets delivered to a human being, this has got to help achieve that.
.
.
.

I suspect that many spammers are the people who buy what appears to be
spam-in-a-box software packages offered in late-night infomercials.

If the legal system can't go after the people who are selling the
spam-in-a-box products, perhaps under the category of Truth in Advertising
the TV stations who air the infomercials can be required to add warning
announcements to the effect that, "The following product is used for sending
unsolicited commercial email, commonly known as spam."

Jed Margolin