|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: cleaning up MIME external-body attachments....
[ On Saturday, May 26, 2001 at 02:32:13 (-0400), [email protected] wrote: ] > Subject: Re: EMAIL != FTP > > And there's something that people are overlooking here - the *clean up* > afterwards. Sure - I can upload the file to a server and send an e-mail > with a pointer to it. > > BUT WHEN AND HOW DOES THAT FILE GET CLEANED UP? Well, if your computer is online all the time then you'd be publishing a link directly to it, i.e. to the original file, and so obviously you don't want to "clean it up"! :-) > Now let's say I had uploaded it to a server. When do I know that it's > safe to remove it? Well, without even thinking too much you could just ask each recipient to send you back a quick confirmation after they had done the download.... I guess the point&click nuts among us would want to automate this despite the fact that e-mail delivery notifications can't be relied upon.... > If I wait 3 days and remove it, I've possibly > screwed somebody over. Forget that - I'll just leave it on the server > indefinitely. So now instead of needing 1M of spool space for the few > minutes it takes to send it out, I'm tying up 1M of spool space > until I clean it up by hand. Somehow, this is just *screaming* a > "tragedy of the commons" scaling failure at me ;) 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). 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) > Oh - and did I mention that the prior business relationship with most > of these 25 was a business card from last week's SANS? This means > that if I had uploaded it to a server, I'd have to worry about how > to grant access rights for that document. I'm lucky that there's > nothing confidential in *that* white paper - 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? > 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. -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <[email protected]> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|