cleaning up MIME external-body attachments....

Sat May 26 19:32:19 UTC 2001

On Sat, 26 May 2001 13:15:29 EDT, Greg A. Woods said:

> The space occupied on the HTTP (or FTP) server isn't "spool space".
> It's already destined as "archive space" (many ISPs don't even back it
> up and state flatly that it's the user's responsibiilty to keep archive
> copies in case of disaster or whatever).

OK. So the thing lives in /tempurls instead of /var/spool.

The point was that quantity X of disk was going to be needed
for at least a week or to, instead of probably just a few minutes.

You get 100K customers all using several X of disk for a week instead of
a few minutes, you better be planning on more disk..

> Of course an ISP might provide a few GB of cheap disk for "temp" URLs in
> people's home pages that'd get cleaned up automaticaly after a few
> days/weeks/whatever of inactivity.  (http://my.isp/~me/temp/ is a
> symlink/alias/whatever created by the ISP into this temp space)

My point was that you may need more than just a few GB of cheap disk for this.

> Don't you know how to encrypt files?  Hopefully any confidential e-mail
> message you send is encrypted so why wouldn't you encrypt the
> external-body content with the very same key before uploading it to a
> public server?

Hmm.. OK.. so I can either use a symmetric key scheme and figure out how
to distribute 25 copies of the key for this file, or I use public key
scheme and encrypt each one to the recipient's public key (and park 25
seperate copies on the server, aggrivating the problem I mentioned above).

Did I mention that:

a) PKI is still a pipe dream
b) I'm *well* aware of how to encrypt files - I'm the guy who is continually
being asked what the <bleep> an application/pgp-signature is.
c) this infrastructure is getting more and more complicated.. ;)

As I said - I'm glad the draft wasn't proprietary information.

> > I'm pretty sure that
> > I'd hit any number of snags and screw-up trying to put a .htaccess
> > restriction that actually worked....
> 
> You certainly would not want to do anything so complex and pointless.

Especially not when just PGP'ing the mail and sending it already does all
the necessary securing of the infrastructure....
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 211 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20010526/af9cad6c/attachment.sig>