cleaning up MIME external-body attachments....

Greg A. Woods woods at
Sat May 26 17:15:29 UTC 2001

[ On Saturday, May 26, 2001 at 02:32:13 (-0400), Valdis.Kletnieks at 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.

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

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

>  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      <gwoods at>     <woods at>
Planix, Inc. <woods at>;   Secrets of the Weird <woods at>

More information about the NANOG mailing list