Re: Ideas

On Thu, 23 Apr 1998, Daniel Stenberg <daniel.stenberg_at_sth.frontec.se> wrote in response to my message of 22 Apr 1998:
>
> > (Microsoft seems to have made a decision to encode *everything* as
> > MIME by default -- even if it is simply ASCII text with multipart
> > MIME boundaries.)
>
> I made it support multipart mails, although my implementation has a
> few flaws. Everything that isn't text gets replaced with a single line
> in the output HTML saying that a binary attachment was stripped out (I
> think it needs further discussion on what to do with binary data in
> mails.

This needs discussion...

Personally, I would like to see Hypermail place binary attachments in a subdirectory of the target directory. I would suggest a directory called "bins" or "Binary" or somesuch thing -- the actual name doesn't matter much at this point.

Within the HTML markup of the message, where the binary was removed, I would like to see a relative URL inserted into the message which is a pointer to the binary. If the MIME type is known, adding an extension to the file when it is saved to disk would aid a browser in processing the file with a helper application upon retrieval.

   <a href="bins/binary0000.xcl">binary attachment</a>    (where 0000 corresponds to message 0000.html in the superdirectory)

For security reasons, I think that *all* binary attachments should be written to disk with file permissions of 444 (unix server bias, sorry), certainly never with xx7 or x7x permissions. The point is, if the object is executable, *do not* enable the file to be executed.

That has the potential to be a security nightmare if your Web archive and anonymous FTP archive share common file space, and if you have something like wu-ftpd enabled to allow execution of binaries. Somebody could mail a MIME attachment to a list containing a rogue program, log into your FTP server and execute it and gain God only knows what acces to your machine.

This probably requires a different umask setting from the master output one Kent referred to (HM_UMASK). I'd suggest a variable like (HMBIN_UMASK) or something.

> Just a note while I'm writing. Judging from the source code I've read
> and patched in hypermail, I am voting for a complete re-write of the
> the project. It is not in a great shape, and when all these change
> requests come flying in and is supposed to get added onto the existing
> code, it'll get even messier.

I'll admit, I'm not much of a C programmer even if I had the time, so I'll defer to others on what is the best approach for developing a more robust Hypermail. However, upgrading Hypermail is fairly important to me and I'm willing to work on facilitating a process which will get the programming done in a timely manner. (Having me do any programming definately would not accomplish that goal, but I might have other resources to bring to bear on this endeavor if it looks like it will work...)

The other tools that are out there in the net to do this kind of thing (Monarch, etc.) just don't cut it for me due to the volume of mail I am trying to work with. I haven't looked at Pipermail (since I never heard of it til today), but I doubt it is viable either since it requires Python. Perl is a better option than that, but the Perl things I've worked with are god-awfully slow and tremendous resource hogs. As inefficient as Hypermail is, a C source is a must for what I'm trying to do with it...

> And hey, thanks for taking on the project, I can't wait to see it move...

Yeah, let me say thanks too, Kent. As I said this is important to me, and I would like to see it happen.

-- 

   Craig A. Summerhill, Systems Coordinator and Program Officer
   Coalition for Networked Information
   21 Dupont Circle, N.W., Washington, D.C.   20036
   Internet: craig_at_cni.org   AT&Tnet (202) 296-5098