This document is an attempt to answer some of the more frequently asked questions concerning MailMan, a web-based email interface from Endymion Corporation. An HTML copy of this document is stored online at http://www.endymion.com/products/mailman/faq.htm. You might want to check online for a more recent version. This document is not intended to act as marketing materials for MailMan or for Endymion, this document is intended to assist us in providing fast and efficient technical support for MailMan users, 24 hours a day. We have attempted to address all levels of reader, from those only barely familiar with Internet-related software to those with the task of actually implementing and maintaining MailMan installations. Readers of this document are the real judge of how successfully we have managed to pull that trick off though. Let us know if you have any serious issues with the information contained here. We have also tried to use simple and straightforward English, since our users come from all over the world. If we have used any idioms that are difficult to understand in your particular region, please let us know so that we might make this document more universally comprehensible.

1) Overview
1.1.) What is MailMan?
1.2.) What could I use MailMan for?
1.3.) Could MailMan be used for kiosk applications?
1.4.) How is MailMan different from HotMail, YahooMail, ExciteMail, etc?
1.5.) Where would I find current information on MailMan?
1.6.) What's the short version of how MailMan works from a technical standpoint?
1.7.) What are some of MailMan's more notable features?
1.8.) Can I customize the interface of MailMan?
1.9.) What is the difference between the Standard and the Professional editions of MailMan?
1.10.) What is the difference between MailMan and Sake Mail?

2) Requirements
2.1.) What are the basic requirements for setting up a MailMan installation?
2.2.) Do I need the file "cgi-lib.pl" to run MailMan?

3) Compatibility
3.1.) What standards and protocols does MailMan comply with?
3.2.) Is MailMan compatible with SSL?
3.3.) Is there a MailMan translation available for the xxxx language?
3.4.) What is new in version 3?

4) Licensing
4.1.) Is MailMan free?
4.2.) Why is the MailMan source code no longer open?
4.3.) What constitutes a single "installation" of MailMan?
4.4.) Why are you picking on Scientology?

5) Installation
5.1.) What is the difference between the different installation distributions?
5.2.) What are the files included in a MailMan distribution?
5.3.) What is the basic installation procedure?
5.4.) What is the installation procedure for a Unix system?
5.5.) What is the installation procedure for an NT system?
5.6.) I installed MailMan and it doesn't work, what do I do?
5.7.) What does it mean when I try to run MailMan and the server says "Can't locate mmcgilib.pl"?

6) Operation
6.1.) How would I use MailMan in conjunction with a "primary" mailer on my home or office system?
6.2.) Wouldn't IMAP be very well-suited to this type of scenario?
6.3.) When I try to send a message, I get: "Error 550: Relay (permission) denied.", what's up?
6.4.) I get this message every single time I use MailMan: "Your MailMan session was initiated from a different network address than your current location. For security reasons, MailMan will not continue. You must log in again from this location to continue." How do I stop it?
6.5.) Mailman has been working fine for a while, but now it returns an error about "premature headers." How do I fix this?

7) Customization
7.1.) How do I customize MailMan to blend into my site and provide a branded interface to my users?
7.2.) Is it possible to "rig" a MailMan installation with a default POP3 or SMTP server address so that the user doesn't have to enter them?
7.3.) Is it possible to "rig" a MailMan installation with a default POP3 or SMTP server address so that the user can't modify them even if they want to?
7.4.) Is it possible to 'rig' a MailMan installation to never display the frames interface?
7.5.) Is it possible to override the domain name displayed in the "From" box when a user is sending email?
7.6.) My HTTP server requires me to move the image files into a directory other than MailMan is installed in, but that breaks the image references, what do I do?
7.7.) The "message input" box is too large, and won't fit in my browser. How can I make it smaller?
7.8.) Is it possible to generate a link in my web application that will log a user directly in to MailMan?

8) Common Errors and Problems
8.1.) What is a 403 Error? Why does my server tell me "Forbidden"? How do I remedy it?
8.2.) What is a 404 "Not Found" Error? What does it mean? How do I remedy this?
8.3.) What is a 501 Error? What is an "Internal Server Error"? How do I remedy this?
8.4.) What is a "premature end of script headers" error? Why does it show up after about a month of use? How do I remedy this?
8.5.) My server gives me this error: "Can't locate Socket.pm in @INC", what does that mean? How do I remedy this?
8.6.) When I download attachments from MailMan, the file name of the attachment is wrong. Why? How do I remedy this?

This section provides an overview of the basic top-level questions about what MailMan is and what it does.

1.1) What is MailMan?

MailMan is a system that provides any user with an interface to his or her own email account from any web browser anywhere in the world. MailMan is a piece of software that runs on a web server as a part of an existing web site that interacts with a mail server and displays the results through the web server. The output that MailMan produces is pure HTML, and can be understood by any web browser, including very 'thin' browsers such as text-based browsers or kiosks.

1.2) What could I use MailMan for?

A MailMan installation could support a free email advertisement site. A different installation of MailMan could provide essential email access for the students at a small community college or the students at a large university. A different installation of MailMan could allow the users of a neighborhood ISP to access their local email accounts through the web without configuring a mail reader. A different installation of MailMan could provide access to any email address anywhere in the world for the patrons of a cyber cafe. Another installation might allow business workers to stay in touch while away from their desks, even while at a pay kiosk in an airport or at a borrowed workstation at another corporation. Another installation might allow a family to keep in touch with friends through Grandma's WebTV box while visiting for Christmas. MailMan is a very general-purpose application that simply provides access to existing email systems. The possibilities are virtually endless.

1.3) Could MailMan be used for kiosk applications?

We designed MailMan with applications such as standalone kiosks in mind. The only caveat that we would mention is that when you design an interactive kiosk, privacy issues become a big concern. You do not want a user to be able to walk up to a kiosk and see the mail that a previous user was reading. To this end, please be very careful in the selection of an appropriate web browser for kiosk applications. Specifically, please note that the Microsoft Internet Explorer (all known versions 1.0 through 5.00, as of this writing) does not conform to accepted Internet standards for the expiration of web pages from page caches (the "Expires:" HTTP response header, see RFC 1945 for more details on this directive). The Microsoft Internet Explorer also does not conform to accepted Internet standards for directing a browser to not cache web pages in the first place (the "Cache-control:" response header, see RFC 2068 for more details on this directive). Because of these non-conformance issues, Endymion strongly recommends against using any version of the Microsoft Internet Explorer for kiosk applications involving MailMan. Netscape Navigator, Opera, and many other popular web browsers properly conform to Internet communications protocol standards and are very well suited for kiosk applications.

1.4) How is MailMan different from HotMail, YahooMail, ExciteMail, etc?

Free Internet mail services such as the ones mentioned above provide the same basic services that MailMan does, but they provide them through a proprietary web site, generally with the purpose of selling advertisements to a guaranteed repeat audience. Free email sites provide the user with a mailbox and the server to access theD:\emacs-20.4\bin/ mailbox. MailMan is different because it is simply a piece of software, a technology to be applied in any number of ways. MailMan works in conjunction with other mail servers in order to process incoming and outgoing mail, communicating with those servers though well-accepted Internet standards such as the POP3 and STMP protocols. The primary advantage of MailMan is that administrators can control their own MailMan installations. They have the power to specify what mail servers MailMan connects to, what MailMan looks like when it runs, who has access to MailMan, etc. When you use MailMan, you are accessing the same email account that you normally access, not a new account that was created just for you to access through a free email service. Some free email services allow you to access your own email address through the service, but you are still forced into using someone else's web server and you are forced into watching someone else's advertisements. With MailMan you have much more control.

1.5) Where would I find current information on MailMan?

The "official" MailMan information site is at the Endymion Corporation web site, at http://www.endymion.com/products/mailman.

1.6) What's the short version of how MailMan works from a technical standpoint?

The heart of MailMan is a CGI application written in Perl, version 5. The mail application generates MailMan's user interface dynamically by reading template files filled with HTML code, processing them, and producing output for the user through a web server. To obtain useful email information, MailMan obtains a user's email account authentication information directly from the user (a username, password and server name) and communicates with the user's POP3 email server the way that any client-side mail software ordinarily would. The user sees a list of messages and can select messages for viewing, deletion, and other normal mail tasks. If a user wishes to reply to a message, forward a message, or create a new message, MailMan communicates with an SMTP mail server to send the outgoing message the way that any ordinary client-side software would.

1.7) What are some of MailMan's more notable features?

The current version of MailMan supports a frames-based interface that provides the user with a message list in a top frame and individual messages in the bottom frame. This feature makes browsing your mail through a web interface very simple and stress-free and eliminates some of the lag issues that are normally associated with web-based email. No other web-based email system that we know of supports this type of sophisticated interface.MailMan can receive message attachments through any web browser. Message attachments can be MIME encoded using either Base64 or Quoted-Printable encoding, or they can be simple Uuencoded binaries. If you are using a browser that supports file uploading (Netscape 2.0 and above and Microsoft's Internet Explorer 4.0 and above, as of this writing) then you can also send message attachments.

1.8) Can I customize the interface of MailMan?

Yes. One of the primary benefits of MailMan is that the entire interface that is presented to the user is the result of a collection of template files that contain ordinary HTML. These templates can be modified in any way as long as they still contain certain vital keywords that allow MailMan to insert valuable information. These keywords are of the form "MailMan(SOMETHING)", and are responsible for showing MailMan's template processor where to insert information on-the-fly. Leave those keywords and snippets in place and you can modify the surrounding HTML as much as you like. Endymion Corporation places no restrictions on how you modify the templates, you are not obligated to preserve our logos or links back to our site. We are thrilled peachy when custom installations preserve credit and provide links back to Endymion Corporation, of course (especially for our non-commercial users, hint, hint) but we don't feel right requiring you to display our logo or links to us.

1.9) What is the difference between the Standard and the Professional editions of MailMan?

The primary difference between the Standard Edition and the Professional Edition is a simple operational rule: the Standard Edition is not allowed to store anything on the HTTP server that it runs on. This precludes the Standard Edition from offering some of the features that you might expect to see in a mail client, such as folders, address books, user signatures and other persistent settings. The purpose of this rule is that the Standard Edition requires virtually no maintenance once it is properly configured. You won't ever have to worry about user quotas, disk allocation, monitoring your user message stores for integrity, backups, or any other administration issues. The Standard Edition is perfect for web sites that are hosted at Internet presence providers that provide limited disk space, or for applications where administration either isn't an option or isn't desired. The Standard Edition can be thought of more as a 'viewer' for a POP3 server than a complete mailer. The only messages that you see are the messages that are actually on the POP3 server at that time.

1.10) What is the difference between MailMan and Sake Mail?

Sake Mail is conceptually equivalent to MailMan, but with one critical difference: Sake Mail is not a CGI script. Sake Mail is an application that runs as a plug-in for your web server using the Java Servlet API. Sake Mail produces pure, simple HTML just like MailMan, it sends no Java applets or JavaScript of any kind to your users, so that any web browser can use it, including text-based browsers. Since Sake Mail is a persistent plug-in for your server, it does not need to be loaded and interpreted by your web server each time a user presses a button or clicks on a message. This means that it is immediately available to handle responses at all times, which lowers the time that users wait for a response. It also means that the memory and CPU resources needed for each user on your server are much lower, so you can scale your installation to much larger numbers of users with Sake Mail than you ever could with MailMan or any CGI application. Persistence also allows Sake Mail to cache its interface template files in memory, which eliminates disk accesses during request handling. This lowers your server's memory consumption, increases drive throughput for legitimate operations, and lowers your server's CPU load. Sake Mail has several different modes of operation, one mimics the behavior of the Standard Edition of MailMan (with the addition of a message draft saving feature), one mimics the behavior of the Professional Edition, and it also fully supports IMAP. For serious installations, we strongly recommend using an IMAP server and Sake Mail over any edition of MailMan. For extremely large installations, Sake Mail provides the ability to link your mail installation to a database back-end, rather than storing messages as flat text files. Sake Mail also provides more sophisticated MIME decoding and message attachment handling capabilities than MailMan.

This subsection answers questions regarding hardware, software, and network requirements for running MailMan.

2.1) What are the basic requirements for setting up a MailMan installation?

In order to install either edition of MailMan you must have a functioning web server that has the ability to run Perl CGI applications. We strongly recommend Apache (information on Apache is available at http://www.apache.org simply because we are very familiar with it and it is known to work very well almost everywhere. MailMan has been installed on virtually every web server that we have ever heard of, including Microsoft IIS under NT, Xitami http://www.imatix.com/, the proprietary web server used by Best Internet, etc. Your server must have Perl, version 5 installed. For Windows servers we strongly recommend using the ActivePerl interpreter, http://www.activestate.com. We have tested MailMan on systems running Windows 95, Windows 98, Windows NT 4.0, BSD, and Linux. Additionally, we have users that run MailMan on machines running SGI Irix, Solaris, and others. We have never tested MailMan on any operating system for Apple Macintosh computers and we have no idea whether it will work under MacPerl or not. Other than Macintoshes, MailMan has no known operating system incompatibilities.

2.2) Do I need the file "cgi-lib.pl" to run MailMan?

In older installations of MailMan, the file "cgi-lib.pl" was included in the installation, and was critical to the running of MailMan. No current version of MailMan requires this file, however. MailMan now needs the perl library "cgi.pm," which in included in all distributions of perl5. If MailMan is not running, and you cannot find "cgi.pm," you should reinstall perl5.

This section discusses issues of Mailman's compatibility with standards, security systems, and languages.

3.1) What standards and protocols does MailMan comply with?

MailMan uses CGI to communicate with the host web server. For more information about CGI, consult Nick Kew's CGI FAQ at http://www3.pair.com/webthing/docs/cgi/faqs/cgifaq.shtml

3.2) Is MailMan compatible with SSL?

Mailman should be completely compatible with a Secure Socket Layer.

3.3) Is there a MailMan translation available for the xxxx language?

During the initial development of MailMan, we played a fairly passive role in the translation of MailMan templates to other languages. The design of the templates for the Standard Edition have stabilized quite nicely though, and we have become very interested in obtaining translated templates so that we can make them available to other users. Most of the requests for foreign (to us) language versions of MailMan have been coming from Universities. We are planning on providing these collections of translated template files free of charge to anyone that is interested, so if you have translated MailMan to any language other than English, we are very interested in obtaining the right to redistribute your templates. We don't care if your templates contain your custom branding instead of the original, out-of-the-box gear theme. We think that it's especially cool when people make translations and still use our out-of-the-box gear theme, but of course that's not necessary. As long as you don't mind us redistributing your branded look, we will make it available. Hopefully we will eventually have several different translations for each of the more common languages. We are also very interested in less common languages though, such as Icelandic or Finnish. Please contact support@endymion.com if you have a translation that you would like to make available. The translation packs will eventually be available from the "Download" section of our web site. We have already settled agreements for German and French translations, but we also are interested in other languages.

3.4) What is new in version 3?

If you are a user of version 2 of MailMan, you will notice several improvements in version 3. Behind the scenes, the primary modification in version 3 is that MailMan now uses CGI.pm instead of cgi-lib.pl. This makes things cleaner and more modern and allows us to distributed MailMan as a single file, plus templates. On the surface, the biggest change in version 3 is the new template set. We thought that the templates that we designed in-house looked good until we saw what Hypnopaedia Studios was able to do with them. We hired Hypnopaedia to produce the templates for version 3 and we think that they make our old templates look primitive by comparison. Hypnopaedia is available for MailMan customization contracts.

This section describes the licensing structure of MailMan.

4.1) Is MailMan free?

No, MailMan is not free. An employee of Endymion Corporation originally started MailMan as a spare time project in 1996. The first version of MailMan was released through the Endymion Corporation web site in 1997 under the GNU Public License, in the hope that people would find the software valuable and contribute to its development. In the time since then, many people have downloaded MailMan and used the application and some have even contributed suggestions and bug fixes, but nobody has undertaken further development. Since MailMan has survived the test of time, Endymion Corporation has decided to pronounce MailMan an official, supported product. We have invested the time and resources in developing MailMan version 2.0, a vast improvement over the original freeware incarnation of MailMan, and we are offering it for license.

4.2) Why is the MailMan source code no longer open?

MailMan began life as a GPL product. Because of our desire to help to move the world forward just a little bit at a time by sharing our efforts with others and because of a general sense of honesty and openness, we originally made the source code for MailMan available to the world under the same non-commercial license that allowed you to install and use MailMan. Unfortunately, we were almost immediately (less than a week after the release) bitten by pirates. Apparently there are people out there that are unable or too lazy to develop something like MailMan by themselves, so they just removed the "Endymion Corporation" headers from the source code and started trying to sell MailMan as their own product. Because of these pirates and other abuses we are making the true MailMan source code available only to licensees. This does not preclude non-profit organizations from obtaining the MailMan source for modification. If you represent a verifiable non-profit organization and you are interested in obtaining the MailMan source code, just contact support@endymion.com for information about obtaining the source code through your non-commercial license. The final effect of our closing the source code is actually very small. Organizations that have a legitimate need for the source code for examination or modification need to license MailMan anyway, and we continue to make the source available to verifiable non-profits.

4.3) What constitutes a single "installation" of MailMan?

A single installation of MailMan is defined as both a unique URL and server that is used to access the MailMan application. Most MailMan installations will require exactly one server and exactly one URL. For instance, Endymion Corporation maintains only one installation of MailMan, on a single server that handles our entire corporate web site, with a single URL, http://www.endymion.com/products/mailman/demo/mmstd.cgi. If your MailMan installation will be supported by more than one server, all with the same URL, each server must be licensed. In a more likely scenario, if you operate several virtual domains from the same server and each virtual domain makes use of a MailMan installation, each different URL that MailMan is known by must be licensed. Having several different virtual domains all access a single installation of MailMan by the same URL on the same server technically only requires one license according to our definitions, but we are a small company and that's not a very nice thing to do to us. Please consider doing the right thing and licensing each installation.

4.4) Why are you picking on Scientology?

We're not. Our intent is to provide MailMan for free to private individuals and to organizations that are acting selflessly and could use the applications but might not be able to budget for it. For-profit organizations foot the bill in our little Robin Hood game. We don't think that this is too much to ask, since the bill that we're talking about is miniscule. The Church of Scientology does not fit into our definition of "an organization that acts selflessly and might not be able to pay for a license." We have nothing nasty to say about Scientology or the Church of Scientology other than that. To each his own.

This section describes how to install MailMan.

5.1) What is the difference between the different installation distributions?

There are two different distributions of each edition of MailMan version 3.0.x, a Unix distribution and an NT distribution. In reality either distribution should work on any server, but we have found it to be more convenient for our users to package the application in a way that is more targeted to the final platform. The primary difference between the two distributions is that the files in the NT distribution have been processed so that the lines in the mail MailMan source file end with a CRLF, while the lines in the same file in the Unix distribution are terminated with a simple LF. If you don't know what that means, don't worry about it, it's really not that important usually. Another difference is that the main MailMan source file in the Unix distribution is called "mm(something).cgi", while the same file in the NT distribution is called "mm(something).pl". We have found that this arrangement reduces confusion in most cases. If you disagree about our file naming conventions you are perfectly welcome to rename the files to whatever you want.

5.2) What are the files included in a MailMan distribution?

A MailMan distribution contains three major parts: the templates, the scripts, the graphics, and documentation. There will be some minor differences between the editions of MailMan (standard or professional), but these are not of great note.

5.3) What is the basic installation procedure?

The OS-specific installation instructions provide more detail on Mailman installation. This section provides a simple overview of the process.

5.4) What is the installation procedure for a Unix system?

This item provides a more detailed explanation of the above procedure for Unix systems. Before you install MailMan, make sure that you have Perl 5 installed. On most Unix systems, especially web hosting systems, Perl will already be installed. If Perl is not installed, or if Perl version 5 is not installed, consult your system administrator.

5.5) What is the installation procedure for an NT system?

This item provides a more detailed explanation of the above procedure for NT systems. Before you install MailMan on an NT system, make sure that you have Perl 5 installed. For more information on where to get Perl 5 and how to install and configure it for NT, please consult Evangelo Prodromo's Perl for Win32 FAQ at http://www.endcontsw.com/people/evangelo/Perl_for_Win32_FAQ.html

5.6) I installed MailMan and it doesn't work, what do I do?

When Mailman installation fails, it's usually a common error. Check these things first.

5.7) What does it mean when I try to run MailMan and the server says "Can't locate mmcgilib.pl"?

The most likely cause of an error complaining about not being able to find "mmcgilib.pl" is that MailMan is "lost". This happens when your server runs your CGI applications with a current directory other than the actual directory that the application is located in. If your MailMan installation is in "/public_html/mailman/mmstdo.cgi" for instance, your server might instantiate MailMan with "/public_html/mailman/mmstdo.cgi" as the current directory, in which case everybody is happy. It also might instantiate MailMan with "/usr/local/somedir/" as the current directory, in which case MailMan has no way of locating its own templates and dependencies.

This section describes how to work MailMan from a user's point of view.

6.1) How would I use MailMan in conjunction with a "primary" mailer on my home or office system?

We wish that there were other sources that we could reference that could explain the basics of using several different mailers at once. Unfortunately we don't know of any. If you know of any good write-ups with suggestions for novice users on this subject please let us know.

6.2) Wouldn't IMAP be very well-suited to this type of scenario?

Yes, IMAP is the perfect solution to the problem of synchronizing multiple different internet client applications. IMAP supports persistent mail storage in folders on the server side so that all mail clients, regardless of location, have a synchronized impression of what the user's current mail situation is like. MailMan does not currently support IMAP because it is aimed at a different market niche. MailMan is designed as a product that enables administrators of existing POP3 servers to easily add web mail support for their users. If you are setting up a web mail system from scratch, then an IMAP server would be ideal. Our Sake Mail product is much better suited to this than MailMan. Information on Sake Mail is available at http://www.endymion.com/products/sake/mail/. Sake Mail is basically equivalent to MailMan in concept, but is a newer product that was designed from the ground up for enhanced performance and scalability over a Perl/CGI solution. Sake Mail supports both POP3 and IMAP, and is generally more full-featured than MailMan.

6.3) When I try to send a message, I get: "Error 550: Relay (permission) denied.", what's up?

Most well configured SMTP servers will not allow a user from outside of their own local domain to send a message to users that are also outside of that domain. You can send a message in from outside, or out from inside, but you can't send a message to your buddy at IBM through the MindSpring SMTP servers if you are, say, at AOL. This is to prevent spammers from abusing SMTP servers. This will happen if you are using a MailMan installation at a different location than your SMTP server. The easiest way to solve this problem would be to configure MailMan to use an SMTP server that will grant permission to the HTTP server machine that MailMan is installed on to send messages. You can also provide a default name for a server that is known to allow messages from the HTTP server machine.

6.4) I get this message every single time I use MailMan: "Your MailMan session was initiated from a different network address than your current location. For security reasons, MailMan will not continue. You must log in again from this location to continue." How do I stop it?

This is a security feature to prevent a MailMan session from getting 'hijacked' from another address. MailMan keeps track of the IP address that your session was initiated from and if subsequent requests come from a different IP address it produces that error. Getting cut off from an ISP's dialup line and reconnecting will usually cause this error. Even if you are not actually jumping around from address to address, sometimes the configuration of the server can cause an appearance that you are. Clusters of caching proxy servers can cause this problem, as can lots of new IP routing features.

6.5) Mailman has been working fine for a while, but now it returns an error about "premature headers." How do I fix this?

Mailman's demos are designed to expire after 30 days of use. Until Mailman v3.0.10, this expiration process was rather sudden- the cgi scripts powering Mailman would simply refuse to run. When the scripts seize up like this, the common response from the webserver is "Server Error: the script returned premature headers." As of Mailman v3.0.10, this process has been replaced with an output message letting users know that Mailman has expired. Of course, this problem should not occur on licensed copies of Mailman.

This section describes the inner working of MailMan for installation administrators that want to customize their installations.

7.1) How do I customize MailMan to blend into my site and provide a branded interface to my users?

All of MailMan's output is defined by a collection of HTML templates. The templates are the ".htm" files that begin with "t_" in your distribution. We have provided a sample look and feel for MailMan that you are welcome to use for as long as you like. When you begin the customization process, simply open the templates in any HTML editor and make your modifications. Remember that the behavior of MailMan is dictated by hidden fields contained within the HTML templates, so make sure that you go slowly and check your results often, as it may be possible to 'break' your installation by accidentally deleting or modifying important keywords. We hope to provide more detailed information on what MailMan's keywords are and what they mean in this document at a later date.

7.2) Is it possible to "rig" a MailMan installation with a default POP3 or SMTP server address so that the user doesn't have to enter them?

Yes. The POP3 server used is referred to in the HTML templates by the substitution keyword "SERVER". Hunt down everywhere that MailMan allows the user to supply this value through a form field. The only place where this should happen is in the template "t_login.htm". Find this form field:

7.3) Is it possible to "rig" a MailMan installation with a default POP3 or SMTP server address so that the user can't modify them even if they want to?

Yes. Find the locations of the servers as described above, and remove the entire "<input>" field from your templates entirely. The incoming server will need to be removed from "t_login.htm", and if you want to rig your SMTP server also then you would need to remove the outgoing server specification in "t_messageform.htm" and. Finally, set the configuration variables "$strIncomingServer" and "$strOutgoingServer" in the MailMan script itself, as illustrated in the comments. Those variables are set toward the top of the script. If you set these values, then even if a hacker attempts to spoof a login page to redirect MailMan to a different server, it will always use the servers that you specify.

7.4) Is it possible to 'rig' a MailMan installation to never display the frames interface?

Yes, just change the "NOFRAMES" input check box in "t_login.htm" to:

7.5) Is it possible to override the domain name displayed in the "From" box when a user is sending email?

Yes. MailMan will automatically guess an email address based on the user's POP3 username and the server name. In most cases this address is either a lot more specific than necessary (i.e., "support@mail.it.endymion.com" instead of "support@endymion.com") or completely wrong (i.e., "endy-support@shell1.ba.best.com" instead of "support@endymion.com"). You can override the default domain name by setting the "$strFromDomainName" configuration variable to the domain name of your choice. In both of the examples above, we would set the value to "endymion.com". This value can only be used for setting the domain of the user that is currently logged in.

7.6) My HTTP server requires me to move the image files into a directory other than MailMan is installed in, but that breaks the image references, what do I do?

It is not possible for MailMan to include a "MailMan()" keyword in the templates so that the image URLs can be automatically rewritten. This is because the keyword would make the image URLs invalid in the raw HTML template files, which would make customizing the templates with an HTML editor very difficult. Originally there was no way to correct your image URLs other than by actually editing the templates, but this is an inconvenient solution. To rectify this situation and make things easier for site maintainers, we have included the "$strURLImageLocation" configuration variable. This variable contains a string that will be prepended to the image URLs when the template is processed at runtime. To use this variable, set it to the exact value that you want prepended to image names in order to make them into URLs that will point to your image directory. For instance, if you bury your images in an "images" directory under the directory where MailMan is installed, set this to 'images/' (with the slash). If you put your images in a completely different directory, something that is rooted, like '/mailman/images/' might be what you are looking for. In the most extreme cases you can do away with relative URLs entirely and provide a complete absolute URL like the one below:

7.7) The "message input" box is too large, and won't fit in my browser. How can I make it smaller?

We've done our best to make sure Mailman is cosmetically pleasing on as many different kinds of browsers as possible; however, there have been some reports of the "message input" field being too large, thus making it quite cumbersome to write an email.

7.8) Is it possible to generate a link in my web application that will log a user directly in to MailMan?

Yes, if you are generating a dynamic web page with user information, then you can create a link that will log the user straight in to MailMan. Simply create a link to your MailMan installation that includes parameters for the information provided by the login form. For example, to log in to a MailMan installation at http://mail.mycompany.com, your link would look like this:

This section discusses some of the common errors and problems that occur during normal Mailman use.

8.1) What is a 403 Error? Why does my server tell me "Forbidden"? How do I remedy it?

A 403 "Forbidden" error is a generic HTTP error that your server will send if it thinks for some reason that you should not be allowed to to have access to the file or script that you have requested. This error can be caused by a lot of things. The key thing to remember though, is that if you see a 403 error, then your server has probably already located the resource that you have requested and verified that it exists. This is a good thing, it means that you're almost there. If you take a URL that generates a 403 "Forbidden" error and modify it slightly so that it is invalid or spelled incorrectly, then you should no longer see a 403 error, you will probably see a 404 "Not Found" error instead. If you are seeing a 403 "Forbidden" error, then that means that your server is probably at least locating the script and trying to run it.

8.2) What is a 404 "Not Found" Error? What does it mean? How do I remedy this?

A 404 Error or Page Not Found Error is the general error message that most webservers return when they cannot located a requested file. This error can be caused by a lot of things. A few possible causes for this error:

8.3) What is a 501 Error? What is an "Internal Server Error"? How do I remedy this?

A 501 Error or Internal Server Error is the general error message that most webservers return when things on the server-side aren't running correctly. The error code itself doesn't contain any information on what is wrong, and therefore doesn't give any real help in diagnosing and fixing problems. The key thing to remember though, is that if you see a 501 "Internal Server Error", then your server has probably already located the script that you have requested and verified that it exists, and even tried to run it. This is a good thing, it means that you're almost there. The only bad thing is that the script is breaking at some point before it produces viable output. If you take a URL that generates a 501 "Internal Server Error" and modify it slightly so that it is invalid or spelled incorrectly, then you should no longer see a 501 error, you will probably see a 404 "Not Found" error instead. If you are seeing a 501 "Internal Server Error", then that means that your server is probably at least locating the script and trying to run it, just that it breaks for some reason.

8.4) What is a "premature end of script headers" error? Why does it show up after about a month of use? How do I remedy this?

A "premature end of script headers" error is an error message returned by many webservers as a way of saying "the CGI script didn't do anything." The error itself doesn't really do much to explain the nature of the problem, so there are a few ways to troubleshoot this error. First and foremost, check whether you're using a licensed copy of MailMan or whether you're using a demo. Next, check your version number.

8.5) 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 Solaris servers for some reason, downloading the latest version of Perl and reinstalling will almost always fix this problem.

8.6) 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 writable 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. 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.