Common MailMan Problems

 

MailMan works correctly but I can't see any images!
Most likely this is because you have MailMan installed in a "cgi-bin" directory and your server is configured to assume that anything in that directory is a script that should be executed when it is accessed. Scripts like MailMan need to be executed when they are accessed because they are producing dynamic output, but static content like images should not be executed. If you try to run them then you will get an error. Most likely your server also has a series of errors in its log that correspond to the times that your web browser tried to access each image and the server could not execute the image.

The solution to this problem is to set things up so that your server delivers the images and the "s_style.css" file as simple static content rather than trying to run them.

One way to do that is to reconfigure your web server so that it looks for the ".cgi" extension when it is trying to figure out what is a script and what isn't. For Unix machines, the overview of how to set that up is in the Unix installation instructions in the section titled "Configure your web server to run MailMan as a CGI script". If you move MailMan to some directory on your server that isn't in your "cgi-bin" directory then you can add a section to Apache's "httpd.conf" file specifically for that MailMan directory that teaches your server that anything with a ".cgi" extension should be executed, and that it is also allowed to serve image files directly from that directory. You could do that and it would not affect any other scripts that are currently sitting in your "cgi-bin" directory.

If you don't want to do that for whatever reason, then there is at least one other simple option. You can move all of your image files to some second location that is accessible to your server. Don't forget to move the file "s_style.css" as well as the "i_*.gif" image files themselves. That way your server doesn't try to execute the image files, it just serves them out as static files. If you do that, then there is a single line that you would need to configure in MailMan to tell it where to find its images. MailMan is perfectly happy doing that.

We recommend the first method because we think that it's cleaner to have everything in one directory. In some cases people don't want to do that or they can't because they don't have access to their server configuration. In those cases the second method works just fine.

 

My server gives me this error: "Can't locate Socket.pm in @INC", what does that mean? How do I remedy this?

That indicates that your Perl interpreter can't find the Perl module Socket.pm. That module should be a standard part of your Perl 5 installation, if it is not found then your Perl installation is damaged or incomplete. This is an extremely common problem with older Solaris servers for some reason, downloading the latest version of Perl and reinstalling will almost always fix this problem.

 

When I download attachments from MailMan, the file name of the attachment is wrong. Why? How do I remedy this?

When a user selects an attachment from a message for downloading, MailMan generates that attachment on-the-fly and sends it through the HTTP server to the user's browser. MailMan includes the necessary HTTP header information for the user's browser to determine the file name, but many broswers, most notably Microsoft's Internet Explorer, either ignore these headers or just don't handle them very well. The result is that when a user downloads an attachment, your browser may present the user with a "Save As" box with the file name filled in as the name of this script, a string or random characters, or any number of other un-graceful things.

We provide a mechanism for working around the problem. If you set up a directory that is writeable by MailMan and readable by your web server, then MailMan will write out the attachment file to that directory temporarily, and redirect the user's browser to that file. When the user logs in or out MailMan will ensure that the user's files in this temporary directory are removed. A user that exits MailMan without logging out and never logs back in could potentially leave stale attachment files on the server, so occasional monitoring of the temporary directory for stale files would be appropriate.

Also note that this mechanism could be considered a privacy problem since a user's attachments are deposited temporarily into a world-readable directory rather than generated on-the-fly the way MailMan normally would do. MailMan tries to remove the temporary files as soon as possible, but they are still there for a while. We have left the decision up to each individual administrator as to whether or not to use this feature. Most people seem to prefer allowing MailMan to generate attachments on-the-fly for simplicity, ease of administration, and security/privacy, but some people think that the attachment file name thing is a critical issue. The decision is yours.

Copyright © 1999 - 2002 Endymion Corporation
All rights reserved.
Carpe Noctem