Subject: [Asrg] Cutting down spam load

From: [email-masked]
Date: Fri, 20 Jun 2003 01:03:23 -0500

> The notion of outlawing MIME, Base64, HTML, etc among consenting MTAs
and MUAs is red herring.  No one can seriously propose eliminating them.

> However, you would cut down you spam load significantly if you rejected
all mail with "Content-type: text/html" SMTP or MIME entity headers
from strangers.  24672 or 73% of the 33807 spam in my 39 day rolling
log of what has been sent toward my traps and filters has that mark.
(It should be 40 days, but I had an attack of bad hands and eyes
this morning.)

It's actually even better than that... since the spam which is HTML-burdened is 
[each] usually 3-5x (or MORE, oftentimes) bigger than spam which isn't.  So 
you'd block (in this case) 73% of the spam MESSAGES but probably 90% or more of 
spam BYTES by this *simple*, easily implemented strategy.

If you have good enough log statistics, check to see what percentage of spam 
BYTES would actually be blocked by taking out messages containing text/html 
message type indications in entity headers.  It would also be interesting to see 
how many spams (and percentages of overall spam BYTES) contain attachments 
(message text as JPG/GIF images, or (not used so often recently) .DOC files or 
whatever.  My approach would end up truncating the great majority of those, too.

AND, don't forget, another big benefit is blocking NOT ONLY JUST spam, but also 
viruses/worms/trojans.  In many cases, those are sent from 'legitimate' senders 
and without hijacking open relays... so things like spf wouldn't help (even IF 
you could realistically speaking block 'non-verifiable' senders, which is way 
less than clear) but my permissions-list approach would block probably 80-90% or 
more of such malicious stuff, too.  By blocking (by default) ALL attachments 
coming from people you don't normally expect to get attachments from, you're 
blocking malicious code, too.  Sure, you'll open up the "attachments allowed" 
window for people you trust and authorize to send those, but that's going to 
typically be a small percentage of the people you'd normally maybe receive 
(ordinary) E-mails from.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.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: Vernon Schryver <[email-masked]>
Date: Fri, 20 Jun 2003 07:02:12 -0600 (MDT)

> From: [email-masked]

> ...

That's true but not impressive, because the total number of bytes involved
in all email is trivial per user.  Typical web pages are 10 times larger
than typical email, including spam.  Typical users receive only about 10 
mail messages/day (judging from DCC numbers at a bunch of ISPs).  I think
typical users look at more than 10 web pages/day..

Of course, if you have 35,000,000 users or even just 10,000, you have
reason to care about the bytes spent used for their mailboxes.  However,
until you arrange to compress their mailboxes, you don't really care.

> whatever.  My approach would end up truncating the great majority of those, too.

Plenty of spam is tiny and on average it's small.  If you are spammer,
you can generally send twice as many 2.5 KByte messages/day than 5
KByte messages.  That pressure might be why base64 encoding has
decreased radically in my traps in the last few months.  Base64 costs
the spammer a 33% increase (4 encoded bytes for every 3 plaintext)
without offering any defense against non-trivial filters.  That pressure
might also explain why the <!--HTML.comment--> noise had become rare
by a week or two ago.  (My guess for the resurgance in the last week
or 10 days is that a spamware vendor has a new set of suckers who
don't understand this.)

>and without hijacking open relays... 

That's a red herring, because many outfits already filter attachments
for worms.

More important, the problem for your idea is not selling it here but
in Redmond.  Until Microsoft stops encoding mail in HTML by default,
perhaps by only turning on HTML when the user does some formating,
ISPs cannot filter HTML by default.  I really wish they could and
would, but I'm not quite crazy enough to confuse my wishes with reality.

Vernon Schryver    [email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 20 Jun 2003 11:24:01 -0400

At 01:03 AM 6/20/2003 -0500, [email-masked] wrote:
>[..]

We do research into fighting spam, not viruses and worms. How does blocking 
attachements going to stop spammers?

---

From: [email-masked]
Date: Fri, 20 Jun 2003 16:19:30 -0500

>attachements going to stop spammers? 

Although

  1)  some spammers have been known to install spambots and zombies in unwitting 
users' systems, and those are installed via attachments;

and

  2)  text-as-image attachments are occasionally used by spammers to circumvent 
content/keyword scanners,

the real point is that by this one permission-based whitelist approach, we can 
use one, cohesive, straightforward, and incrementally deployable approach to 
take a big bite out of BOTH spam AND viruses/trojans... arguably the two biggest 
and most pressing problems we have on the Internet today.

Meanwhile, in so doing, we'll also help prevent the irresponsible and wasteful 
growth of (unnecessary) HTML-burdened E-mail, which all by itself could be 
expected to perhaps make as much as a 30-50% or more reduction in the total 
E-mail load, net-wide.

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 20 Jun 2003 16:59:19 -0400

>users' systems, and those are installed via attachments;

That is true and Barry Shein has pointed this out before. However, your 
approach still does not solve the issue of dealing with ASCII spam.

>and most pressing problems we have on the Internet today.

TODAY, what about tomorow? How long will it take spammers to adapt? Mere days.

>expected to perhaps make as much as a 30-50% or more reduction in the total

We are not in the traffic reducing business. If we would be why not 
advocate the use of gzip compression on all HTTP transactions? That would 
save tremendous amount of time as well?

Yakov