Subject: Re: [Asrg] Re: Usefulness of wholesale blocking of attachments for SMTP? (various)

From: [email-masked]
Date: Mon, 19 Apr 2004 22:01:35 -0500

>> We need to simply make it very much harder for viruses and worms to infect 
those 
> people's machines.  Closing the attachment transmission window (especially for 
> executable-type attachments) to just a sliver of what it is today will 
certainly 
> help a great deal.  SPF and other such schemes is unlikely to help very much 
at 
> all, because those machines which DO get infected can send viruses, worms, and 
> spam using their authenticated SMTP.  It's outrageous and irresponsible that 
> nearly everyone's mail clients freely accept and allow people to receive and 
> click on things like PIF files, which are virtually NEVER used for anything 
> good.  .EXE files are likewise almost never legitimately needed in E-mail, and 
> those who DO need it usually know why, and from whom they need to be able to 
> receive such stuff.  
> 
> We will NEVER solve the spam problem if we don't get a major handle on the 
virus 
> and worm problem, and A-V software is NOT the ultimate solution because it 
> basically all works on the "blacklist" principle (i.e. "if we don't know about 
> it (yet) then it's probably okay."  While A-V software is a valuable 
component, 
> and certainly helpful in disinfecting a machine once it's been infected, 
> hopefully we can come up with a solution that's better than just go around 
> forever swatting flies.  Let's close the window!!
> 

> I am not sure if it can be closed. 

I'm not sure we can close it 100%, but I don't know that we HAVE to.  

> The latest viruses are being sent around in ZIP files encrypted with a 
password 

Right, and that password sent (!) as an IMAGE file attachment.  Just to make 
sure that an A-V program can't readily decrypt the password and verify the ZIP 
file's contents.

Again, the solution isn't to blacklist the stuff that we KNOW is bad.  The 
better solution at this point is to WHITELIST the stuff that at least has a good 
CHANCE of being good (or, at least, not dangerous!)

> ...which people still manage to open and encryption bypasses virus scanning on 
gateway level. 

Right.  

A-V programs will NOT solve this problem.

> Unless we throw out the baby with the bathwater - forbid all attachments, 
virus writers will always find a way around whatever semi-blocking technique 
we come up with. 

The solution does NOT require that we outlaw all attachments.  What it DOES 
point to is that recipients should open the "permission window" to those trusted 
senders for the types of attachments that they are trusted to send.

By default, an unknown sender would be not allowed to send ANY kind of 
attachments at all.  They would have to send plain ASCII text, no attachments, 
no HTML, if they hoped to have their mail delivered.  

If they felt the need to send HTML or attachments, AND if the recipient 
concurred and trusted them, the recipient could enable the sender's permissions 
so that they could send the "trusted" classes of stuff to that recipient.

> Same for HTML - unless all HTML is forbidden, I do not 
see how any benefit can come from it. 

OK, let's explain.

The use of HTML in E-mail messages would be subject to similar permissions.

By default, an unknown/untrusted sender would not be allowed to use ANY HTML in 
their messages.

Whitelisted senders could send various types of HTML based upon what the 
recipient trusted them to send.  It could be as simple as a relatively 
unsophisticated sender just sending simple formatting stuff (bold, italic, 
underline, maybe fonts, etc) or it could be stuff such as embedded or overlaid 
(background) images, scripting, ActiveX, or other truly more advanced (and more 
potentially malicious) stuff.

Some corporate types really want to include very elaborate stuff in E-mail 
messages... interactive spreadsheets, SQL queries, OLAP cubes, etc., but 
certainly dear old Aunt Margaret doesn't expect her older sister Martha to send 
her sophisticated stuff like that from her room at the nursing home!  There's 
_no_ point in enabling those kinds of things for everyone (including bogus 
folks) by default.

> But forbidding HTML will close many existing use cases which many companies 
and people do every day.

That's why you want to enable those capabilities, SELECTIVELY, for those who you 
want to allow to use them.

The important thing is that you do NOT need to enable these more dangerous 
things GLOBALLY, and there is NO need whatsoever to accept them from people you 
don't know (yet).  It's really a question of setting up your 'selectivity 
window' (just as in a very selective radio tuner) so that you get the signals 
you want, and block everything else.

> The biggest problem with this approach is that while it might work in 
theory, in practice I do not think we can convince any sizable majority 
of Internet users to accept it. 

If it makes a huge difference in (their!) spam and virus/worm volume, I think 
they will be DELIGHTED to cooperate.

But another KEY point... they DON'T HAVE TO all become convinced.  This kind of 
scheme can be implemented for those who wish to use it, and they will derive 
FULL benefit from it, even if nobody else adopts it.  This is a MAJOR 
distinction compared to stuff like SPF, which only really works if (someday, 
maybe) most people are willing to subject themselves to it.

Another key aspect of my proposal is that it's pretty easy to understand.  An 
ISP (or for that matter, corporate IT department) who adopted it on behalf of 
their customers wouldn't have an impossible job trying to get people to 
understand it.  It can be implemented in a way that would make it quite easy to 
understand what it does, and how to control it to achieve the level of 
restrictions that each user deemed appropriate.

> This is the main problem with any proposal - aside from the idea itself, it 
must also be marketed and be convincing enough to be acceptable.

My idea could be implemented even just within a given E-mail client software (or 
as a local E-mail proxy-type antispam system) so you don't HAVE to convince the 
whole world to adopt it.  It works FROM DAY ONE for those who install it.

> However, if you want to take a shot at it and write up a BCP document as 
a short Internet draft, go ahead. There is definatly a good use of some 
attachment blocking such as .EXE files.

It's important to understand that my scheme DOES NOT REQUIRE any kind of 
"official standard" (and in fact, there are advantages to there NOT being a 
single implementation of the concept net-wide).  The way it's implemented can 
actually be a nice "product differentiation" feature of application software 
vendors offering E-mail clients or antispam filtering products.  This is 
actually another good advantage of my approach.

>>>>I don't want to see any solutions that result in some "authority" deciding 
what one can and cannot send. 

>>>Right, only community consensus should be applied.   It is doable.

>> I hope so.

> We must account for a possibility of a community system being subverted. 

Spammers and hackers will CERTAINLY try to do that.

If nothing else, they will attempt to get the gullible recipient to willingly 
deactivate their protection.  I've seen spams containing detailed instructions 
on how to deactivate "no-scripting" restrictions in Outlook...!  Rather like the 
"Aggie Virus" that tells you to manually delete all the files on your C: drive 
and then forward the E-mail to all your friends...!  The dialog box to 
acknowledge such a configuration change needs to include suitably dire-sounding 
warnings to dissuade the unwary from being terminally gullible.

> Any system that does not account for that will be no better than an 
authority. There was a couple research papers floating around that try 
to address the same problem in P2P networks - the problem is solvable if 
it is taken into account.

The more I look at and consider my concept, the more convinced I am that it is 
THE principal key to solving this problem, and doing so in a way that is 
long-term viable.  And the more I look at things like SPF, the more convinced I 
am that they are simply WRONG-headed... they just do NOT solve the real problem, 
and meanwhile cause new problems that might be even more intractable.

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: Yakov Shafranovich <[email-masked]>
Date: Mon, 19 Apr 2004 23:12:25 -0400

> actually another good advantage of my approach.

I wasn't calling for an "official standard" only a document :) If you 
are convinced that your idea is good, than write it up and promote it!

Yakov