17.2 Setting Up mini-qmail
| Installing mini-qmail requires two steps: installing a QMQP server or two, and then installing the mini-qmail QMQP client. 17.2.1 Setting Up a QMQP ServerIf you already have an SMTP server running, setting up QMQP is easy, because its configuration is much simpler. The only pitfall is that QMQP has no relay protection at all, so you have to make sure that only your own QMQP clients connect to the servers. QMQP doesn't queue, which means that clients discard mail if they can't deliver it to a server immediately, so you should set up at least two QMQP servers if possible. First, create the rules file to permit connections only from your network. Create /var/qmail/rules/qmqprules.txt: # only allow connections from our network :deny 172.16.42.:allow Replace the 172.16.42. line with your own network range(s), of course. If you created a Makefile for your SMTP rules file, add the QMQP rules file to it, too, and then run make to create qmqprules.cdb: default: smtprules.cdb qmqprules.cdb smtprules.cdb: smtprules.txt cat $> | /usr/local/bin/tcprules $@ smtprules.tmp qmqprules.cdb: qmqprules.txt cat $> | /usr/local/bin/tcprules $@ qmqprules.tmp Now it's time to create the directories for the QMQP service: # mkdir /var/qmail/supervise/qmail-qmqpd # mkdir /var/qmail/supervise/qmail-qmqpd/log # mkdir /var/qmail/supervise/qmail-qmqpd/log/main # chown qmaill /var/qmail/supervise/qmail-qmqpd/log/main And create /var/qmail/supervise/qmail-qmqpd/run: 1. #!/bin/sh 2. limit datasize 3m 3. exec tcpserver \ 4. -u000 -g000 -v -p -R \ 5. -x/var/qmail/rules/qmqprules.cdb 0 628 \ 6. /var/qmail/bin/qmail-qmqpd 2>&1 In line 4, use the values on your system for qmaild. Note on line 5 that the service is running on port 628. Finally, create /var/qmail/supervise/qmail-qmqpd/log/run. It's identical to its smtpservice equivalent: #!/bin/sh exec setuidgid qmaill \ multilog t s4000000 ./main Once you have all the files created, symlink the supervise/qmail-qmqpd directory so svscan starts it up: # ln -s /var/qmail/supervise/qmail-qmqpd /service If you look at log/current you should see the initial tcpserver status line: tcpserver: status: 0/40 If you're using more than one QMQP server, repeat this exercise on the other server(s). If you use the same directory structure on each server, you might be able to use cp -Rp to copy the whole thing over rather than recreating each file and directory by hand. 17.2.2 Setting Up QMQP ClientsOnce you have the server set up, the QMQP client is easy. mini-qmail does no queueing and no local delivery, so what little it does do all runs as whatever user calls it. As a result, you don't need to define any user or group IDs, nor do you need to create the queue or ~alias directories. Usually the easiest thing to do is to build qmail on the server, then copy the pieces to the QMQP client machines. All of the QMQP files are read-only, so if you have multiple client systems, all of these files can be shared except for idhost, which must have different contents for each host. What you should install includes:
Once these files are installed, and assuming you've started your QMQP servers, you should be able to send mail using Mail or any other mail application. Send yourself a message, make sure it's delivered, and check that it includes a header like this one: Received: from client.example.com (172.16.42.201) by server.example.com with QMQP; 13 Feb 2003 01:37:41 -0500 The QMQP client produces no logs at all, but you can check the logs on the QMQP server to see what incoming connections have occurred. 17.2.3 Using QMQPQMQP has three common uses: on a cluster of machines with a mail smarthost, on a network firewall, and for load-sharing with mailing lists. 17.2.3.1 Using a smarthostOn a network with multiple machines, it usually makes sense to use one or two of them as the mail hosts. That makes the mail system easier to administer, because you only have to manage the configuration on the mail hosts. The rest of the hosts, even if they're doing only one thing, such as running a database or serving web pages, usually send out a little bit of mail with status reports, logs of daily cleanup jobs, and the like. On the machines that aren't mail servers, install mini-qmail, being sure to install qmail's version of sendmail to catch all the mail sent by daemons and cron jobs. Be sure to disable any startup scripts that attempt to run sendmail as a daemon, because the mini-qmail version of sendmail doesn't do that. 17.2.3.2 Setting up a mail firewallIf you have a firewall or bastion host separating your internal network from the outside world, good security design mandates that you run as few services on the bastion host as possible. If that host is the only one visible to the outside world, it has to run an SMTP daemon, but you can use mini-qmail to pass incoming mail directly to the smarthost, minimizing the processing on the bastion host. On that host, install mini-qmail and ucspi-tcp. Set up tcpserver and qmail-smtpd in the usual way described in Chapter 3 and Chapter 4. In /var/qmail/control, create the files me with the name of the host, rcpthosts with the domain names for which the host receives mail, and qmqpservers with the address of the internal mail host. You can also create databytes if you want to limit the size of incoming messages. Even though this setup provides no queueing on the bastion host, if the internal mail host doesn't respond to QMQP when an incoming message arrives, qmail-qmqpc (masquerading as qmail-queue) will fail, and that will make qmail-smtpd fail with a 451 temporary error, which should make the sending host hold on to the message and try it again later. In most cases, you'll want to do some spam filtering at the gateway using DNSBLs and perhaps qmail-filter. See Chapter 9 for details. 17.2.3.3 Mailing list load sharingMailing list software needs a specialized kind of load sharing. A typical mailing list message is delivered to the list manager program, which validates it in various ways, and then remails it to the potentially very large set of addresses on the list. Most list managers also have management interfaces that accept commands via email or a web page to add and remove list members, create and reconfigure lists, and otherwise maintain the lists. It makes sense to run the list management software on one host or set of hosts, and the mail deliveries on another. Fortunately, this is really easy to arrange. For list managers that interface directly to qmail (ezmlm/ezmlm-index and majordomo2 at this point), outgoing list mail is sent by running qmail-queue. To move the delivery work to another computer, it needs only to run qmail-qmqpc rather than qmail-queue. Ezmlm supports this directly; if the list's directory contains the file qmqpservers, outgoing mail uses QMQP. If qmail-qmqpc is patched appropriately (the patch comes with ezmlm-idx), it can read the list of QMQP servers from that file rather than the default in /var/qmail/control/qmqpservers. Majordomo2 has no direct support for QMQP, but because it's written in Perl, it takes about 10 seconds to find the place in the file QQEnvelope.pm that refers to qmail-queue and change it to qmail-qmqpc. I use a two-host majordomo2 setup, and it works very well for me. Other list managers that aren't aware of qmail either inject mail with sendmail or via SMTP. For mail sent by SMTP, merely configure the package so that the SMTP connection is to the other computer rather than to localhost. Most packages don't send list mail via sendmail due to the argument size limits, using it only to send administrative messages to single users that don't put a lot of load on the mail system. If you do want to reroute the mail injected by sendmail, and you've installed the QMAILQUEUE patch, you only need to ensure that the QMAILQUEUE environment variable is set to /var/qmail/bin/qmail-qmqpc whenever the list package runs, something like this: #!/bin/sh export QMAILQUEUE=/var/qmail/bin/qmail-qmqpc exec /usr/lib/listmanager "$@" |
