Re: MIME disable option? (hopefully not FAQ)

This would probably be the safest solution, though it would obfuscate the names of the files if you were to look in the hypermail-generated directory itself.

This could easily be accomplished using a simple CGI script that is passed the MIME type (as known or guessed when Hypermail is run) and the saved filename, and which uses the special "PATH_INFO" trick to make the original filename available.

An example of an absolute URL for a web site would look like this:

/cgi-bin/hmdownload.cgi/realfilename?mime_type=image%2Fgif&saved_file=binNNNNN

where "/cgi-bin/hmdownload.cgi" is the actual CGI script, "realfilename" is what the user's web browser sees as the actual filename, the "mime_type" variable is the MIME type of the file (if known), and the "saved_file" is the generated name of the attachment.

The CGI script should have a configuration setting that only lets it look for attached files in a given directory, and it should to do some sanity checking to prevent abuse, like setting "saved_file" to "../../../etc/passwd" or similar.

This may be more trouble than it's worth, though, and simple filename mangling (like prepending "x-") might be better.

Dave

On Tue, 20 Apr 1999, Craig A Summerhill <craig_at_cni.org> wrote:

>I just thought of a fifth (5) possible approach... maybe.
>
>You might be able to use some kind of global hypermail cgi script
>(presumably installed in the master /cgi-bin directory as defined
>by cgidir in the top level Makefile) to mask the path name of the
>MIME attachments which are being called/written. I have seen some
>servers do something like this with CGI or JavaScript. If you
>examine the HTML of the files, there is no indications of the
>real path to the file. But clicking on an icon or hyperlink causes
>a server-side handler to serve the file up. Presumably, it could
>be as easy as a Perl script which does
>
>sub ServeItUp {
>
> print <<EOF;
>
>Content-type: $mime-type
>
>stream the file
>
>}
>
>I'll try to think this out some more, but I think you could securely
>make the attachments available to clients and effecitvely prevent
>crackers from getting into the server. Even if they write some kind
>of 'bad' file to the server, they probably can't do much with it unless
>they know the path...
Received on Wed 21 Apr 1999 07:13:11 PM GMT