LPI Linux Certification/Configuring Mailing Lists
Detailed Objective
editWeight: 1
Description: Install and maintain mailing lists. Monitor and resolve problems by viewing the logs.
- Key knowledge area(s):
- Install, configure and manipulate mailing lists
- Mailman configuration files, terms and utilities
- Majordomo configuration files, terms and utilities
- Ezmlm configuration files, terms and utilities
- The following is a partial list of the used files, terms and utilities:
- Not applicable
Configuring mailing lists
editMajordomo is a mailing list management program. Its goal is to handle all incoming mails to a particular email address, and re-distribute them to a list of email addresses. Majordomo also handles adding and deleting an email address from its lists.
Since Majordomo is responsible for managing E-mail lists, Majordomo relies heavily on a MTA such as Sendmail, Smail, Qmail or Postfix.
aliases file (usually /etc/aliases) is used for making aliases for E-mail addresses. For example, once Majordomo is installed, usually an entry in the aliases file reads:
majordomo-owner: jarchie
This entry means that all mail addressed to majordomo-owner@host.com will actually be sent to jarchie@host.com. Notice it is unnecessary to append the @host.com to jarchie because both users are on the same host. If it were desired to redirect the message to a different user on a different host, one would have to add the @host.com portion.
Another type of entry in the aliases file allows E-mail to be redirected to multiple addresses listed in a file:
testlist: :include:/usr/local/majordomo-1.94.5/lists/testlist
This entry states that any message sent to testlist@host.com will be redirected to all the addresses listed in the file /usr/local/majordomo-1.94.5/lists/testlist. The testlist 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 taking advantage of this feature. When a subscribe request is processed, the user's E-mail address is appended to the testlist file; when an unsubscribe request is processed, the user's E-mail address is removed from the testlist file. One can also add or remove addresses manually simply by editing the file with a text editor such as vi.
Since Majordomo needs to be able to process commands sent to it via E-mail, Sendmail 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-1.94.5/wrapper majordomo"
The program /usr/local/majordomo-1.94.5/wrapper is a wrapper (SUID and SGID majordomo or daemon depending on the configuration) that 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 E-mail to the wrapper via the standard input. (Since all the wrapper does here is to call majordomo, the E-mail 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. (i.e, 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 out of the message and responds appropriately.
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.
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. Also, Majordomo must be a Sendmail trusted user
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 was chosen. You have to decide on the location where the Majordomo scripts will reside. If you are using a shadowed password file, add entries similar to
majordomo:x:16:16:Majordomo List Manager:/usr/local/majordomo-1.94.5:
to your /etc/passwd and add an appropriate entry to /etc/shadow.
majordomo:*: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
majordomo:x:16:jarchie
to your /etc/group file. Appending your username to the end of the line will give you access to the Majordomo files that are group writable.
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.
PERL = /bin/perl CC = cc W_HOME = /usr/test/majordomo-$(VERSION) MAN = $(W_HOME)/man W_USER = 123 W_GROUP = 45
should be changed to something more appropriate for your system. For example, in my setup, the values were changed to
PERL = /usr/bin/perl CC = gcc W_HOME = /usr/local/majordomo-1.94.5 MAN = /usr/man W_USER = 16 W_GROUP = 16
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.
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";
to something more appropriate such as
$whereami = "kes.emeraldis.com"; $whoami = "majordomo\@$whereami"; $whoami_owner = "majordomo-owner\@$whereami"; $homedir = "/usr/local/majordomo-1.94.5"; $digest_work_dir = "/usr/local/majordomo-1.94.5/digest"; $sendmail_command = "/usr/sbin/sendmail";
$whoami and $whoami_owner do not need to be changed for Majordomo to work; however, I changed them because I like to avoid typing 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. Unlike the Makefile, these options can always be changed after Majordomo is installed by editing majordomo.cf in the directory where Majordomo was installed. (The configuration 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 everything else is a collection of perl scripts and, therefore, is not compiled.
$ make wrapper
To install the Majordomo files, execute the commands
# make install # make install-wrapper
The first command can be done as the Majordomo user (assuming majordomo can create or has access to $home_dir), but the second command needs to be done as root so the installation script can SUID root the Majordomo wrapper. (Since, majordomo 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.)
Sendmail aliases must be created for Majordomo so commands sent to Majordomo can be processed by majordomo, and an alias for the Majordomo owner must be created so people can E-mail you through the standard owner-majordomo address. Add the following entries to your aliases file :
majordomo: "|/usr/local/majordomo-1.94.5/wrapper majordomo" owner-majordomo: jarchie majordomo-owner: jarchie
Then test your configuration, as a regular user (not as majordomo or as root), run :
$ /usr/local/majordomo-1.94.5/wrapper config-test
This program can detect most problems in the Majordomo installation.
To create a list, create a file with the name of the list in the Majordomo lists directory. For example, to create a list called test, create a test file as Majordomo :
[root@kes /]# su majordomo [majordomo@kes /]$ touch /usr/local/majordomo-1.94.5/lists/test
and add the related aliases :
test: :include:/usr/local/majordomo-1.94.5/lists/test owner-test: jarchie test-request: "|/usr/local/majordomo-1.94.5/wrapper request-answer test" test-approval: jarchie
Now test the operation of the list by issuing a lists command to Majordomo :
[jarchie@kes jarchie]$ echo lists | mail majordomo
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@kes jarchie]$ echo help | mail majordomo
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@kes jarchie]$ echo subscribe test | mail majordomo
You will receive an E-mail message containing instructions on how to confirm your subscription as well as a letter confirming that your command was successful. After sending back your confirmation, Majordomo should send back 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 a unsubscribe command
[jarchie@kes jarchie]$ echo unsubscribe test | mail majordomo
You should be sent back a letter stating that your command was successful.
For some lists, it may be desirable to have Majordomo process messages before they reach the list. For example, Majordomo has the resend script to automatically filter messages based on content (such as taboo words), to prevent people from sending Majordomo commands to the list, and other features. To use these options, it is necessary to use a better set of aliases such as :
test: "|/usr/local/majordomo-1.94.5/wrapper resend -l test test-list" test-list: :include:/usr/local/majordomo-1.94.5/lists/test owner-test: jarchie test-owner: jarchie test-request: "|/usr/local/majordomo-1.94.5/wrapper majordomo -l test"
The last entry allows someone simply to send a message to test-request@kes.emeraldis.com with the text subscribe rather than sending a letter to majordomo@kes.emeraldis.com with the text subscribe test. Also, note that if sendmail is using smrsh, the above aliases should reference the copy of the wrapper in the safe path--usually /etc/smrsh/wrapper.
It is common for Majordomo's permissions to be set incorrectly causing Majordomo to work improperly. Fortunately, Sendmail and Majordomo typically, give decent error messages indicating a problem. For example, the lists directory must be executable by the user sendmail setuids to, typically mail or daemon. If sendmail cannot execute lists, the permissions must be loosened.
[root@kes root]# chmod +x /usr/local/majordomo-1.94.5/lists
Another common problem is caused by the lists directory being group writable. To solve this problem, one can ether clear the group writable bit, or use the sendmail option IncludeFileInGroupWritableDirPath
Majordomo is intended to run on a isolated system; there are a couple of well-known security holes in the scripts that allow any local user capable of executing wrapper to execute code as the majordomo user. If Majordomo must be run on a system providing users with shell access, then it is advisable to tighten up permissions on the wrapper. This can be done by clearing the world executable bit and chgrping the wrapper to the user that needs to run the Majordomo scripts. For example, if Sendmail and MajorCool are both being used to execute the wrapper use the commands
[root@kes root]# cp /usr/local/majordomo-1.94.5/wrapper /etc/smrsh/wrapper [root@kes root]# chmod 4750 /usr/local/majordomo-1.94.5/wrapper [root@kes root]# chown root:nobody /usr/local/majordomo-1.94.5/wrapper [root@kes root]# chmod 4750 /etc/smrsh/wrapper [root@kes root]# chown root:mail /etc/smrsh/wrapper
to secure the system. This will allow sendmail (while running under mail) to execute /etc/smrsh/wrapper while allowing the webserver's MajorCool (running under nobody) to execute /usr/local/majordomo-1.94.5/wrapper. This solution, however, will allow anyone with the UID or GID of mail or nobody to also obtain access to the majordomo account. To protect the nobody account, it is important not to allow normal users to make use of server side includes or cgi scripts unless those services do not run under nobody.
Key terms, files and utilities : Majordomo MTA
Exercises
edit