RE: Hypothetical design question

["Alun Jones" <alun () texis com>]

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Harmon
> Sent: Friday, January 30, 2004 12:49 PM
>
> The MTA:  I'm getting the impression that most of the writers 
> here agree
> that the MTA is a lousy place to put our solution.  Me too;  Doing it
> there violates the end-to-end paradigm and places mail transmission in
> general at risk from bugs, "friendly fire", compatibility probems, or
> changes in the external situation.

Playing devil's advocate here, it's also a centralised solution (less
administration costs, more chance of getting it right once than getting it
right a hundred/thousand times), and reduces bandwidth costs between the MTA
and the MUA.  It also allows you to relax rules for internal email, because
the MTA can reliably tell the difference between internal and external.

> The Operating System:
> Obviously, the OS is a powerful and tempting venue for meddling.  It
> might actually be practical to work here, *if* the OS 
> provides the tools
> and constraints needed to enforce automatic sandboxing.  Whoops, that
> lets out Microsoft.... :-~

Are there any OS providers that aren't let out by that particular barn door?

Again, playing DA, there's always the possibility that .NET might help save
the day - if you only allow execution of .NET applications, there is a
sandbox environment at play there.  .NET is remarkably good at preventing
you from shooting yourself in the foot - although it does come with the
price of preventing you from shooting at anything with f, o or t in its
name. :-)

> Then too, we'd be demanding total 
> trust not
> only from users, but from site and network administrators as 
> well.  We'd
> expose the whole machine both to our direct failures and to 
> any OS bugs 
> we might trigger with our meddling.  We also get to manage a chunk of 
> configuration and coding for the system as a whole, which needs to 
> interact with code we don't own, can't change, and can't get full 
> internal specs on.  Oh yeah, and all this is supposed to be "secure". 
> Riiight.

Whatever solution you implement relies to an extent on trusting the OS to be
as secure as it's documented to be.

But now, for my final DA position, I'd like to challenge your taxonomy of
places that the problem can be addressed, as well as your implicit
assumption that it has to be addressed at only one place.

By the nature of this list, pretty much all of its members are developers,
and so we're always going to think that code is the first line of attack in
solving a problem.  What has not been considered here is a societal "fix" or
workaround.

If we can trace emails (and the protocol already allows this, if the MTAs
are written and configured to do it), then we can start disconnecting
infected hosts, either by preventing all IP access from them, or simply by
rejecting future emails passed to us.  We can also start shunning the people
who get infected through their own stupidity, automatically rejecting their
email.  We can start working harder to track down the source of viruses, and
to prosecute those that produce them.  It's a far more serious crime than it
is portrayed by laws and by the media - much like stealing ten cents out of
everyone's paychecks, we may not feel a significant damage individually, but
en masse, the result of a virus should be enough to send someone to prison
for several years.

I don't buy the plea that it's the action of an unaware individual who is
simply too naive to know the damage of what he's doing.  Virus authors
should be locked away from computers and society for a few years.  They're
intelligent enough to know what they are doing, and are either malicious or
sociopathic.

So, are there any other points where a fix could be applied, that David
missed out of his taxonomy?  Could we apply other approaches at the router
(like AOL, who redirects any port 25 access to its own internal mail
servers, that append the user's true identity to the headers)?

Alun.
~~~~
-- 
Texas Imperial Software   | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place   | [EMAIL PROTECTED]
Cedar Park TX 78613-1419  | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.