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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg