dealing with w32/bagle

Thu Mar 4 16:40:02 UTC 2004

Jeff Shultz wrote:

> ** Reply to message from "Laurence F. Sheldon, Jr."
> <LarrySheldon at cox.net> on Wed, 03 Mar 2004 22:04:44 -0600
> 
>>Curtis Maurand wrote:
>>
>>> Until there's an easy way of getting a file to your friend down the 
>>>street that's as easy as sending an email, we're stuck with this.
>>
>>There are actually several, some with features much superior to using
>>email as the truck.
>>
>>The problem with them is:  Nobody wants to consider them.
> 
> Okay, so what are several ways to share files with a friend, where you
> don't share any accounts or passwords, and where only your friend will
> be able to access them?
> 
> FTP'ing to a web site is out - you either have no guarantee that
> they'll be the only one to be able to access the file, or you have to
> mess with password protected websites, not something a person is going
> to do to send the kids photos to Grandma.

Actually FTP can be made secure.

That and all of the other ideas I might propose require some development
work and some change of attitudes.

Here is the answer igave in private email to fundentally the same
question:

quote
My personal favorite that at one time would have been the easiest to
develop has a MUA that "attaches" the document by storing the text
in an HTTP-accessible archive (on the sender's machine?  on the sender's
MTA machine?) and including a URL in the email.

My personal objection to embedded attachments is not a product of the
virus rage going on--it goes back a lot farther and has to do with
system efficiency, security and privacy issues.  (Consider a situation
that I have found to common:  Person A sends a message transmitting a
document containing sensitive information to person B.  For reasons that
make sense, Person A sends "CC" or "BCC" copies to persons C, D, E, and
F.--perhaps to "document" the transmission to B. C-F have no interest in
the document, just the fact that it was transmitted.  But the get copies
of it.

A in the process of preparing the message mentions that the document
will be made public at a meeting on a future date.

E realizes that persons G and H need to be at that meeting and
"forwards" the message _and_the_document_ to them.  (In one case in my
past, "G" was the last person in Creation that should have gotten the
document early.)

If the message is stored under PKI with A's key all of that and the
system overhead goes away.

There are others.
unquote