John Archie 1.10alpha 1 December 2002 This document is intended to guide a user through an installation of the Majordomo mailing list software and the MajorCool Web-based interface to Majordomo. This HOWTO is divided into four sections. The first is a tutorial for installing Majordomo. The second is a tutorial for installing MajorCool. The MTA appendix is a description of how Majordomo interfaces with an MTA--specifically, Sendmail, Exim, and Postfix. This section generally discusses features common to most MTAs, so it might be of some use to those not using one of the aforementioned MTAs. Finally, there is a FAQ for questions I have received and a List of Terms provides definitions for some of the more abstruse terms. Also, if the official sites for downloading any of the software mentioned in this document are down, the tarballs can be found at my Web site. If you have any comments or suggestions regarding this document, please write me at

comments@majordomohowto.com

. You may copy, modify, and redistribute this document without restriction. I ask that if you modify or translate this document that you inform me; however, you are not required to do so. Thanks go out (in alphabetical order) to a few people for their invaluable help Lee Archie for proofreading James Bruce and Bill Poston for the opportunity to set up my first permanent machine running Majordomo Dan Liston for sending me extensive comments Dan Richter for sending me extensive instructions on configuring Postfix and Majordomo Joseph D. Sloan for reading the Sendmail portion and making helpful suggestions Although I have tried to include all information necessary to perform a basic installation of Majordomo and MajorCool, it is always a good idea to look at more than one source. Below is a list of the resources that I found helpful when configuring Majordomo. Books: Bryan Costales with Eric Allman, sendmail. Cambridge: O'Reilly, 1997. Alan Schwartz, Managing Mailing Lists. Cambridge: O'Reilly, 1998. Free resources: the documentation accompanying Sendmail especially README.cf the documentation accompanying Majordomo especially INSTALL and NEWLIST the Majordomo-Users Mailing List Archive. the documentation accompanying MajorCool Majordomo is, of course, the piece of code that this document revolves around; it consists of a collection of Perl scripts with the sole purpose of managing mailing lists. Download the gzipped source distribution of the latest version of Majordomo from Great Circle Associates and uncompress it [jarchie@majordomohowto ~]$ zcat majordomo-1.94.5.tar.gz | tar xvf - This will create a subdirectory with all of the files necessary to install Majordomo; this directory cannot be the same directory in which Majordomo is to be installed. Majordomo must run under a specific UID and GID so when any of the scripts are run, they will run under Majordomo's UID. Thus, it is necessary to decide what UID and GID Majordomo should run under. Check the /etc/passwd and /etc/group files to find a UID and GID that are not taken. For this example, a UID of 16 and a GID of 16 were chosen. If you are using a shadowed password file, add entries similar to majordom:x:16:16:Majordomo List Manager:/usr/local/majordomo:/bin/sh to your /etc/passwd and add an appropriate entry to /etc/shadow. majordom:*:10883:0:88888:7::: Use the other entries in these files as a guide for exactly what should be added. These are only the values for my system. If you are not using shadowed passwords, only an entry in the /etc/passwd file is necessary. To create a Majordomo group, add a line similar to majordom:x:16: to your /etc/group file. To finish creating the majordom account, set a password for the majordom account. This will allow regular users and become Majordomo to manage mailing lists. [root@majordomohowto majordomo-1.94.5]# passwd majordom Now create the directory where Majordomo will reside once installed. [jarchie@majordomohowto ~]# mkdir /usr/local/majordomo-1.94.5 [jarchie@majordomohowto ~]# chown majordom:majordom /usr/local/majordomo-1.94.5 [jarchie@majordomohowto ~]# chmod 711 /usr/local/majordomo-1.94.5/ [jarchie@majordomohowto ~]# ln -s /usr/local/majordomo-1.94.5 /usr/local/majordomo Creating the majordomo link to majordomo-1.94.5 could ease upgrading to future versions of Majordomo. If you configure your MTA to recognize Majordomo via the majordomo link (as this HOWTO suggests), when upgrading Majordomo, you might not need to reconfigure your MTA. Instead, you might only need to point the majordomo link to the location where the new version of Majordomo resides. The Makefile contains all the information needed to install Majordomo; it is usually necessary to edit lines in the Makefile that refer to system specific settings so, Majordomo will be able to install cleanly on your system. Most of the default settings are correct; however, the following settings, almost invariably, need to be changed on a per system basis. [jarchie@majordomohowto majordomo-1.94.5]$ vi Makefile The settings CC = cc W_HOME = /usr/test/majordomo-$(VERSION) MAN = $(W_HOME)/man W_USER = 123 W_GROUP = 45 TMPDIR = /usr/tmp should be changed to something more appropriate for your system. For example, in my setup, the values were changed to CC = gcc W_HOME = /usr/local/majordomo-$(VERSION) MAN = /usr/local/man W_USER = 16 W_GROUP = 16 TMPDIR = /tmp TMPDIR need only be changed if /usr/tmp/ does not exist on your system. Also, Majordomo will look for perl in /bin/. If perl is not in /bin/ on your system, you can inform Majordomo of perl's location in the Makefile. However, other scripts might look for perl in /bin/perl as well, so it is usually better to create a symbolic link from the real location of perl to /bin/perl. You can find the real location of perl on your system with the which command. For example, [root@majordomohowto ~]# which perl /usr/bin/perl [root@majordomohowto ~]# ln -s /usr/bin/perl /bin/perl Also the majordomo.cf file must be created. An easy way to create this file is to copy the provided sample.cf file to majordomo.cf and edit it. [jarchie@majordomohowto majordomo-1.94.5]$ cp sample.cf majordomo.cf [jarchie@majordomohowto majordomo-1.94.5]$ vi majordomo.cf Again, most of the settings are correct by default, but the following lines might need to be changed for your system from $whereami = "example.com"; $whoami = "Majordomo\@$whereami"; $whoami_owner = "Majordomo-Owner\@$whereami"; $homedir = "/usr/test/majordomo"; $digest_work_dir = "/usr/local/mail/digest"; $sendmail_command = "/usr/lib/sendmail"; $TMPDIR = $ENV{'TMPDIR'} || "/usr/tmp"; to something more appropriate such as $whereami = "majordomohowto.com"; $whoami = "majordomo\@$whereami"; $whoami_owner = "majordomo-owner\@$whereami"; $homedir = "/usr/local/majordomo"; $digest_work_dir = "$homedir/digests"; $sendmail_command = "/usr/sbin/sendmail"; $TMPDIR = "$homedir/tmp"; $whoami and $whoami_owner do not need to be changed for Majordomo to work; however, I changed them because I like to avoid capital letters. $digest_work_dir is a temporary directory where digest files should be placed. This directory should be assigned to wherever you want digests to be stored. If you do not plan to use digested lists, do not worry about this option. $whereami, $homedir, and $sendmail_command should be changed to appropriate values for your system. I recommend changing $TMPDIR to the /usr/local/majordomo/tmp/; this directory will only be writable by majordom making it impossible for other programs to mess with Majordomo's temporary files. Unlike the options in the Makefile, the above options can always be changed after Majordomo is installed by editing majordomo.cf in the directory where Majordomo was installed. (The majordomo.cf file is simply copied during setup.) The next step is to compile the Majordomo wrapper. The wrapper is the only Majordomo component that needs to be compiled because all other code are perl scripts. [jarchie@majordomohowto majordomo-1.94.5]# make wrapper To install the Majordomo files, execute the commands [root@majordomohowto majordomo-1.94.5]# make install [root@majordomohowto majordomo-1.94.5]# make install-wrapper The first command can be done as the Majordomo user (assuming majordom can create or has access to $home_dir), but the second command need be done as root so the installation script can SUID root the Majordomo wrapper. (Since, majordom was created without a login shell or password, if you want to execute the first command as majordomo, you will need to su majordomo as root in order to become majordomo.) Next su majordom and create a file for a test list and a temporary directory for Majordomo. [root@majordomohowto ~]# su majordom [majordom@majordomohowto /root]$ cd [majordom@majordomohowto ~]$ mkdir lists [majordom@majordomohowto ~]$ chmod 711 lists [majordom@majordomohowto ~]$ touch lists/test [majordom@majordomohowto ~]$ chmod 644 lists/test [majordom@majordomohowto ~]$ mkdir tmp [majordom@majordomohowto ~]$ chmod 700 tmp As majordom, edit Majordomo's aliases file (/usr/local/majordomo/majordomo.aliases) and add the aliases for Majordomo and a test list: # Majordomo's aliases majordom: majordomo majordomo: "|/usr/local/majordomo/wrapper majordomo" owner-majordomo: jarchie majordomo-owner: owner-majordomo discard: /dev/null # test list aliases test: "|/usr/local/majordomo/wrapper resend -l test test-list-XXXX,discard" test-list-XXXX: ":include:/usr/local/majordomo/lists/test" test-request: "|/usr/local/majordomo/wrapper majordomo -l test" owner-test: jarchie test-owner: owner-test test-approval: owner-test If you need a review of email aliasing, see . Note that the test-list-XXXX is a secret address; resend will redirect mail that should be sent to the list to test-list-XXXX. Anyone who discovers the test-list-XXXX address can bypass the resend script by sending mail directly to test-list-XXXX. Therefore, you should replace the XXXX portion with some string that is difficult to guess. Finally, set the permissions on Majordomo's aliases file. [majordom@majordomohowto ~]$ chmod 644 majordomo.aliases Majordomo should now be installed; all that need be done for Majordomo to be used is to configure your MTA to recognize Majordomo. As a regular user (not as majordom or as root), run [jarchie@majordomohowto ~]$ cd /usr/local/majordomo [jarchie@majordomohowto jarchie]$ ./wrapper config-test This program can detect most problems in the Majordomo installation. First, configure your MTA to recognize Majordomo as a trusted user. (See .) Second, configure your MTA to recognize Majordomo's aliases. (See .) After configuring your MTA, you might need to restart it so that it can recognize your new configuration. The last two subsections of contain issues specific to Sendmail and Postfix; please read the appropriate section if you use one of those MTAs. Since the MTA is now configured to recognize Majordomo, you can test the list by actually using Majordomo. So, test the operation of the list by issuing a lists command: [jarchie@majordomohowto jarchie]$ echo lists | mail majordomo@majordomohowto.com It should only take a second for Majordomo to reply with a message containing all the lists which are currently set up. Next, try issuing a help command. [jarchie@majordomohowto jarchie]$ echo help | mail majordomo@majordomohowto.com Majordomo should reply with a list of all commands that Majordomo accepts. It might be a good idea to save the message for future reference. To see if the aliases are working properly, try subscribing and unsubscribing yourself to the list. [jarchie@majordomohowto jarchie]$ echo subscribe test | mail majordomo@majordomohowto.com You will receive an email message containing instructions on how to confirm your subscription as well as a letter stating that your command was successful. After sending back your confirmation, Majordomo should send you two letters--one letter stating that your subscribe request was successful and another letter welcoming you to the test list. The owner of the list will also be sent a message stating that you have subscribed to the list. To unsubscribe from a list, send an unsubscribe command: [jarchie@majordomohowto jarchie]$ echo unsubscribe test | mail majordomo@majordomohowto.com You should be sent back a letter stating that your command was successful. Create a file for a new list and create aliases for that list as described in for the test list. MajorCool is a Web-based interface to Majordomo allowing users to add and delete themselves from lists and manage lists that they own. The installation is fairly straightforward; all that need be done is to unzip the files, edit one line in the Configure script, and execute the script. The latest files can be downloaded from Conveyance Digital. [jarchie@majordomohowto jarchie]$ mkdir majorcool [jarchie@majordomohowto jarchie]$ mv majorcool.tar.gz ./majorcool/ [jarchie@majordomohowto jarchie]$ cd majorcool/ [jarchie@majordomohowto majorcool]$ zcat majorcool.tar.gz | tar xvf - Open Configure and [jarchie@majordomohowto majorcool]$ vi Configure change the line that reads PERLBIN="/usr/local/bin/perl" # How to start a perl script to the proper location of perl PERLBIN="/usr/bin/perl" # How to start a perl script otherwise, MajorCool will not be installed properly. When running the Configure script, if the default choice for an option is okay, simply pressing enter will accept the default. [root@majordomohowto majorcool]# ./Configure The Configure script will ask you to hit Enter a few times, and then it will ask for the location of Majordomo and some more questions about the setup of your Web server: What is the installation directory of Majordomo? []: /usr/local/majordomo-1.94.5 Will place the MajorCool programs in /usr/local/majordomo-1.94.5. What is the path to your Majordomo configuration file? [/usr/local/majordomo-1.94.5/majordomo.cf]: Using configuration file name '/usr/local/majordomo-1.94.5/majordomo.cf' Where would you like temp files created when MajorCool runs? [/tmp]: MajorCool needs to install CGI programs, support files, and icons in your Web server directories. What is the root directory for your Web server? []: /var/www Where is the cgi-bin directory for your Web server? [/var/www/cgi-bin]: Will place the programs in /var/www/cgi-bin. What is your server's URL for '/var/www/cgi-bin'? [/cgi-bin]: Where is the image directory for your Web server? [/var/www/icons]: Will place the icons in /var/www/icons. What is your server's URL for '/var/www/icons'? [/images]: /icons Where is the root directory for documents on your Web server? []: /var/www/html The Configure script will ask other questions that are less critical. (The defaults are fine, but you might want to change a few settings to fit your preferences. Unlike some of the Web-server questions, the meanings should be obvious from the context.) When the configuration file that the script generated from your answers is displayed, you should accept the new version: Accept the new version? [yes|no|list|edit|diff]? y The installation script will install the MajorCool files and run the majordomo cgi script which outputs the html file to the console. Check to see if the installation worked by viewing the majordomo cgi script from the Web. [jarchie@majordomohowto ~]$ lynx http://localhost/cgi-bin/majordomo Also, when new lists are added, MajorCool will not recognize them until mj_key_cache is run as majordom: [majordom@majordomohowto ~]$ ./mj_key_cache Since Majordomo is responsible for managing email lists, Majordomo must be tightly integrated with a MTA. Each MTA discussed can be configured by editing a configuration file. For Sendmail, you can configure sendmail.cf; this file is usually located in /etc/ or /etc/sendmail. For Exim, you can configure exim.conf; this file is usually located in /etc/exim/. For Postfix, you can configure main.cf; this file is usually located in the /etc/postfix/ directory. If your MTA configuration file is not in one of these locations on your system, you should consult the documentation that came with your operating system or search for the file with find. For example, to find the sendmail.cf on your system, use the command [root@majordomohowto ~]# find / -name sendmail.cf -print Alternatively, some administrators do not want to edit the sendmail.cf file directly. It is possible to use M4 macros to create the sendmail.cf from a file (usually sendmail.mc in /etc/) that contains the necessary information to generate the sendmail.cf. The purpose of the M4 configuration is to provide an easy way to create the sendmail.cf file. The idea is that the file using the M4 macros is easier to understand than the sendmail.cf file. By running the m4 preprocessor, a sendmail.cf file can be generated. For example, to generate /etc/sendmail.cf from /etc/sendmail.mc, you would use the command [root@majordomohowto etc]# m4 /etc/sendmail.mc > /etc/sendmail.cf When referring to the file used to generate sendmail.cf, I assume that the file is called sendmail.mc. MTAs are usually programmed to make it difficult for people to create "perfect" forgeries of email. For example, when a user sends a message via SMTP, the source IP address is typically logged, and when a user sends a message by giving it directly to the MTA, the MTA will usually put a warning message in the header specifying the user who really sent the message. However, some programs need to be able to send messages masquerading as other users, and having this extra security line appended to the header is annoying. MTAs usually handle this problem by having trusted users. In order for Majordomo's resend script to work properly, majordom must be a trusted user since the program needs to resend mail from other users. If you would like to edit Sendmail's configuration file directly, add the line Tmajordomo to the sendmail.cf file. If you prefer to use M4 macros, add the following line to your sendmail.mc file, and regenerate sendmail.cf. define(`confTRUSTED_USERS',`majordomo') In exim.conf, look for a line similar to trusted_users = mail If the line exists, add majordom as a trusted user. Note that Exim separates items in a list with a ":" and no whitespace. The modified line should look similar to trusted_users = mail:majordom If the line does not exist, add the line trusted_users = majordom to the main configuration section (the first part) of exim.conf. Postfix does not have untrusted users; therefore, it is not necessary to make Majordomo a trusted user under Postfix. An MTA's aliases file (often /etc/aliases) is used for redirecting email. For example, once Majordomo is installed, an entry in an aliases file usually reads majordomo-owner: jarchie This entry means that all mail addressed to majordomo-owner@majordomohowto.com will be resent to jarchie@majordomohowto.com. Notice it is unnecessary to append the @majordomohowto.com to jarchie because both users are on the same host. If one wanted to redirect the message to a different user on a different host, one must add the @majordomohowto.com portion. Another type of entry in the aliases file allows email to be redirected to multiple addresses listed in a file. test: ":include:/usr/local/majordomo/lists/test" This entry states that any message sent to test@host.com will be redirected to all the addresses listed in the file /usr/local/majordomo/lists/test. The test file might look something like this: johnarchie@emeraldis.com srobirds@yahoo.com acreswell@geocities.com Majordomo is able to add or remove addresses from a list by using this feature. When a subscribe request is processed, the user's email address is appended to the test file; when an unsubscribe request is processed, the user's email address is removed from the test file. One can also add or remove addresses manually simply by editing the file with a text editor. Since Majordomo need be able to process commands sent to it via email, the MTA must be able to execute the Majordomo program and pass the message to it. This is done by adding another type of entry to the aliases file: majordomo: "|/usr/local/majordomo/wrapper majordomo" The program /usr/local/majordomo-1.94.5/wrapper is a wrapper (SUID root that sets the active UID and GID to the UID and GID of Majordomo (usually majordom and majordom) and runs the Majordomo program. The quotation marks around the second part of the alias entry are used to tell Sendmail that this part of the entry is all one statement; the quotation marks would be unnecessary if there were not a space between wrapper and majordomo. The | is known as a "pipe;" it is used to tell Sendmail to send the email to the wrapper via the standard input. (Since all the wrapper does here is to call majordomo, the email is actually being sent to Majordomo.) The wrapper accepts one parameter--the parameter of the program it is supposed to execute. (Any parameters after the first will be passed to the program the wrapper is executing.) For security reasons, the wrapper only executes programs located in the Majordomo directory, /usr/local/majordomo-1.94.5/. This restriction prevents a programmer from using the wrapper to run programs that should not have Majordomo privileges. (For example, wrapper /bin/vi would allow any user to edit any Majordomo configuration file.) When a message is sent to majordomo@host.com, Sendmail starts up the wrapper which, in turn, starts up majordomo, and Sendmail sends the message to the majordomo script via the standard input. Majordomo then extracts the commands from the message and responds appropriately. Majordomo's aliases can be added to the main aliases file. However, creating a second aliases file for the Majordomo aliases, such as /usr/local/majordomo/majordomo.aliases, is a good idea. To have a /usr/local/majordomo/majordomo.aliases, Sendmail must be able to generate a database (/usr/local/majordomo/majordomo.aliases.db). The easiest way to accomplish this is to go ahead and create an empty database for Sendmail to overwrite. [root@majordomohowto majordomo]# touch majordomo.aliases.db [root@majordomohowto majordomo]# chmod 644 majordomo.aliases.db If you want to edit the sendmail.cf directly, add the following line to your sendmail.cf file. OA/usr/local/majordomo/majordomo.aliases If you prefer to use M4 macros, add the following line to your sendmail.mc file, and regenerate sendmail.cf. define(`ALIAS_FILE',`/etc/aliases,/usr/local/majordomo/majordomo.aliases') On some systems, you must run newaliases to update the aliases database after modifying the aliases file. Add the following directors to the configuration portion of the exim.conf file. (If this section is not clearly marked in the comments of your exim.conf, you can safely add the director for a second aliases file after the system_aliases director.) # Majordomo's Aliases File additional_aliases1: driver = aliasfile file_transport = address_file pipe_transport = address_pipe file = /usr/local/majordomo/majordomo.aliases search_type = lsearch user = majordom Note that the user = majordom specifies that Exim will change its user to majordom before redirecting mail to aliases in majordomo.aliases. Thus, by giving a user access to the majordomo.aliases file, you don't need to give that user the ability to execute programs under the user Exim runs under. Add hash:/usr/local/majordomo/majordomo.aliases to the alias_maps option in the main Postfix configuration file (usually /etc/postfix/main.cf). Note that items in a list are separated by commas. For example, if there is a current entry similar to alias_maps = hash:/etc/aliases modify that entry to look like alias_maps = hash:/etc/aliases, hash:/usr/local/majordomo/majordomo.aliases Note that after modifying Majordomo's aliases, you will have to rebuild the aliases database. Postfix uses this database (not the aliases file itself) to lookup mailing aliases. For example, as majordom [majordom@majordomohowto ~]$ newaliases -oAhash:/usr/local/majordomo/majordomo.aliases Unfortunately, sophisticated spammers can expand mail lists using the SMTP EXPN command. Also with EXPN, spammers can discover the address to which Majordomo's resend script sends mail. For this reason, administrators should disable EXPN when serving mailing lists. A good way to tell if you have EXPN enabled is to actually telnet to the SMTP port on your machine and try it. If EXPN is enabled, you will see something like [root@majordomohowto ~]$ telnet localhost 25 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. expn test 220 majordomohowto ESMTP Exim 3.35 #1 Wed, 27 Nov 2002 19:05:02 -0500 250 <|/usr/local/majordomo/wrapper resend -l test test-list-XXXX,discard> In sendmail.cf, add the line O PrivacyOptions=noexpn If you prefer to use M4 macros, add the following line to your sendmail.mc file, and regenerate sendmail.cf. define(`confPRIVACY_FLAGS',`noexpn') In exim.conf, you can specify the hosts that can execute the EXPN command. To disable the EXPN remove the line that sets the smtp_expn_hosts option. For example, if your configuration file has a line that reads smtp_expn_hosts = * simply delete it. As far as I know, EXPN is not implemented under Postfix; so there is no need to disable it. For certain setups, some security measures that Sendmail uses can prevent Majordomo from working properly. In these cases, it might be necessary to disable or work around these security measures. If Sendmail is using smrsh, then the only programs that can be executed are those under a secure directory (usually /etc/smrsh/). The best solution to run the wrapper from the aliases file is to create a symbolic link to /usr/local/majordomo/wrapper from /etc/smrsh/wrapper. This will inform sendmail that Majordomo's wrapper is a safe program to execute from Sendmail's aliases file. [root@majordomohowto ~]# ln -s /usr/local/majordomo/wrapper /etc/smrsh/wrapper I recommend giving majordom its own login shell so users can simply su majordom to maintain Majorodmo's mailing lists. However, if you plan on having a non-root, non-majordom user add and manage mailing lists, you will need to make the majordomo.aliases file group writable. However, you should keep in mind the security issues involved when giving someone access to an aliases file. If a user has write permission on an aliases file, she should be a trusted user. By putting an entry into the aliases file (such as the one used to execute wrapper) a user can execute programs with the privileges of Sendmail (usually daemon, mail or, in older versions, root). This gaffe would allow people to run code as the user under which Sendmail runs. To some extent, this risk can be reduced by using smrsh; however, one must still be careful as to what files are in the Sendmail's secure directory (usually /etc/smrsh). Another important security issue is that the user who can access the aliases file can append or write to files that belong to daemon by using file redirection (a >> or > instead of a |). Even so, this breach, too, can be countered by adding a line to the sendmail.cf file, limiting what files can be written to, through the aliases file. For example, the line O SaveFileEnvironment=/path/to/safe/files in sendmail.cf will only allow files in the directory /path/to/safe/files to be overwritten from an aliases file. Alternatively, if you prefer to use M4 macros to generate your configuration, adding the line define(`confSAFE_FILE_ENV',`/path/to/safe/files') to your sendmail.mc and regenerating sendmail.cf will have the same effect. In the case of include or .forward files, commands or redirections are run as the user who owns the file (and only if the user has a valid shell). Therefore, if a file is group writable, a member of the group can execute commands as the user who owns the file. In other words, any user in the majordom group could execute commands as the majordom user (if majordom has a valid login shell). However, if you still want to have group writable files, you must include the lines O DontBlameSendmail=GroupWritableAliasFile O DontBlameSendmail=IncludeFileInGroupWritableDirPath in your sendmail.cf file. Alternatively, if you prefer to use M4 macros, add the following line to your sendmail.mc file, and regenerate sendmail.cf. define(`confDONT_BLAME_SENDMAIL',`GroupWritableAliasFile,IncludeFileInGroupWritableDirPath') Postfix appends a Delivered-To: header when a message is delivered to an address. This feature allows postfix to catch mail loops; however, the Delivered-To: header interferes with the operation of Majordomo. First, when using moderated lists, moderators must manually remove the Delivered-To: header before sending the approved message back to the list. (Otherwise Postfix will recognize that the approved message has already been sent to the list, and Postfix will stop the mail "loop.") Secondly, the Delivered-To: header reveals the secret address that delivers mail to everyone on a list; this behavior allows people on the list to discover this secret address allowing them to bypass the resend script. The easiest solution to this problem is to avoid using moderated lists and accept that some people will be able to bypass resend. If this is unacceptable, better solutions are discussed in the Postfix FAQ. Why does sendmail give the error, sh: wrapper not available for sendmail programs? smrsh will only allow sendmail to execute certain files. See . digest a collection of new messages mailed to the members of an archived list as one message. A list is called "digested" when it is archived and, periodically, a digest is sent out. Group ID GID an identification number assigned to files, directories, and processes to restrict access--similar to UID except multiple people can be a member of a group. On Unix-type systems, groups can be set up (defined in the /etc/group file). When a user name is a member of a group, she can access files created with that GID (assuming permissions allow it). Mail Transfer Agent MTA a program, such as Sendmail, responsible for passing mail from one location to another. Set Group ID SGID a file attribute which allows a program to run with specific group privileges, no matter who executes it. smrsh (SendMail Restricted SHell) the shell that Sendmail uses to execute programs. smrsh puts restrictions on the programs that can be run to make it safer than using a regular shell such as the Bourne Shell. Set User ID SUID a file attribute which allows a program to run as a specific user, no matter who executes it. User ID UID an identification number assigned to files directories, and processes--similar to GID except every user has a unique UID. Every process must run under a UID (the one-to-one relationship between the UID and user name is defined in /etc/passwd). The process' UID determines what the program can access. In general, a regular user can change the permissions on files that she owns unless the UID is 0 (the root user). In that case, root can modify any files on the system. wrapper a program used to start another program; usually a wrapper is SUID or SGID, so it can bestow privileges onto another program that the other program would not normally have.