I was fed up by the complexity of a reputed simple nullclient sendmail configuration under IRIX. So I decided to use a mini-qmail installation on each IRIX host to give messages to our central CommuniGate Pro mail server. This is how I did it.
Each host runs mini-qmail and delivers to a central QMQP server.
Multiple QMQP servers could be used to enhance reliability.
It was sufficient to follow D. J. Bernstein's guide to Installing mini-qmail. No need for qmail entries in /etc/group or /etc/passwd on the null clients, but it was strangely necessary to temporarily have them on the build host for the install programs to work.
/var/qmail/bin
-rwxr-xr-x 1 root sys 126 Mar 13 11:56 datemail* -rwxr-xr-x 1 root sys 114 Mar 13 11:56 elq* -rwxr-xr-x 1 root sys 27304 Mar 13 11:56 forward* -rwxr-xr-x 1 root sys 44972 Mar 13 11:56 maildir2mbox* -rwxr-xr-x 1 root sys 22788 Mar 13 11:56 maildirmake* -rwxr-xr-x 1 root sys 44836 Mar 13 11:56 maildirwatch* -rwxr-xr-x 1 root sys 179 Mar 13 11:56 mailsubj* -rwxr-xr-x 1 root sys 115 Mar 13 11:56 pinq* -rwxr-xr-x 1 root sys 25200 Mar 13 11:56 predate* -rwxr-xr-x 1 root sys 115 Mar 13 11:56 qail* -rwxr-xr-x 1 root sys 89444 Mar 13 11:56 qmail-inject* -rwxr-xr-x 1 root sys 42232 Mar 13 11:56 qmail-qmqpc* lrwxr-xr-x 1 root sys 11 Mar 13 12:06 qmail-queue -> qmail-qmqpc* -rwxr-xr-x 1 root sys 43416 Mar 13 11:56 qmail-showctl* -rwxr-xr-x 1 root sys 23376 Mar 13 11:56 sendmail*
/var/qmail/control
-rw-r--r-- 1 root sys 13 May 15 12:55 defaulthost -rw-r--r-- 1 root sys 17 Mar 13 12:08 idhost -rw-r--r-- 1 root sys 19 May 15 13:14 me -rw-r--r-- 1 root sys 8 Mar 13 12:19 plusdomain -rw-r--r-- 1 root sys 15 Mar 13 11:59 qmqpservers
(I guess idhost could also be a symbolic link to /etc/sys_id on IRIX.)
defaulthost is used to create the envelope sender address based on the user name of the host. Take care that the name chosen can accept message bounces.
Installing mini-qmail mentions defaultdomain - but since I would recommend defaultdomain to be the same as me it is not needed.
Since the QMQP server does nothing with the messages submitted, I don't think it's necessary to have any /var/qmail structure or controls on the mail server.
Once the /var/qmail directory structure is created, the legacy sendmail command-line program at /usr/lib/sendmail must be changed to /var/qmail/bin/sendmail.
Not mentioned in Installing mini-qmail is the defaulthost control. If the host is a self-administered workstation, such as torero.ncac.gwu.edu, then set defaulthost to the workstation's hostname. Otherwise set defaulthost to the proper mail domain (ncac.gwu.edu). Cron programs would use the defaulthost value while users would be expected to override this with the qmail-inject environment variable QMAILDEFAULTHOST.
Pine
Some of the hosts also have a MUA such as Pine,
and it makes sense to reconfigure Pine to use QMQP delivery
instead of sending to the CommuniGate Pro SMTP Module.
Find your system-wide pine.conf and put
sendmail-path=/usr/lib/sendmail -oem -oi -t
Other MUAs.
After a twenty minute telephone conversation with an Inter7 consultant, I don't think it is possible to use qmail-qmqpd as is and write to the CommuniGate Pro Submitted folder by merely configuring a standard qmail installation. I'll have to rewrite qmail-qmqpd to accept QMQP messages and once the message is safely on the server, deliver it to CommuniGate Pro.
I see that two options exist for delivery to CommuniGate Pro once the qmqp service accepts the messages.
I think the PIPE Module makes the most sense. Here are the parameters for the CommuniGate Pro command-line mailers:
usage: mail [-iInv] [-d BaseDirectory] [-s Subject] [-c addresses] [-b addresses] [addresses] usage: sendmail [-i] [-t] [-d BaseDirectory] [-f FromAddress] [-F SenderName] [addresses]
These are intended to be compatible with the traditional mail and sendmail commands. Unfortunately, qmail could not be configured to pipe the message to sendmail -t, which should be enough to submit the message to the PIPE Module.
Relaying dilema: Messages submitted via the PIPE module are marked as "received from a trusted source," so they can be relayed without restrictions. This will bypass the authenticated relaying requirement on the mail server. The shared systems have accounts that do not have e-mail accounts and normally would not be permitted to relay using the mail server. The sendmail nullclient had to go through the SMTP module which does not allow relaying to hosts that have not authenticated.
One really nice feature to have if this could be integrated with CommuniGate Pro better is checking the value in the from field before using it as a return-path: in the submitted message. Right now CGP will accept the message, find out it's not routeable and then generate a mailer-daemon message to postmaster.
A typical null client host will be a Unix workstation that is under the care of our center. Typically, hosts will be in the ncac.gwu.edu domain. The sendmail nullclient configuration I am departing from is:
VERSIONID(`@(#)null-client.mc 0.4 (NCAC) 5/22/2000')
OSTYPE(irix6)dnl
undefine('ALIAS_FILE')
MASQUERADE_AS(ncac.gwu.edu)dnl
FEATURE(nullclient, `mail.ncac.gwu.edu')
Most of the messages generated on these hosts will be from processes run by the clock daemon for accounts root or adm. In most installations, messages will be sent to postmaster, and on the mail server messages to <postmaster> will forward to me.
I can imagine a situation with user administered Linux hosts that could use the mini-qmail installation as well. In those cases, postmaster@host.example.net, should be directed to the user administrator's account.
This might be done on the CommuniGate Pro server with routing records, such as:
<postmaster@host1.example.net> = user@example.net
<*@host1.example.net> = *@example.net
<postmaster@host2.example.org> = user@example.org
<*@host2.example.org> = *@example.org
But I think it would be better if the rewriting was done by qmail. (Because none of these hosts will be running an MTA and could not accept messages addressed to root@host1.example.net from outside our center anyway. mini-qmail would be effectively replacing the local delivery on these hosts.)
qmail-qmqpd accepts incoming QMQP messages and uses qmail-queue to write them to the qmail queue.
My plan is to copy qmail-qmqpd, make minimal changes, and call it cgp-qmqpd. And copy qmail-queue, make the necessary changes, and call it cgp-submit. cgp-submit will be SUID qmailq and SGID mail to write messages to the Submitted folder, the folder's group must be mail to preserve compatibility with the legacy mailers.
The latest version is p3 for qmail-1.03 and can be found here.
Download qmail and follow the installation instructions for QMQPD, then untar my source code modifications over the qmail directory. Change conf-cgp if necessary, and run the CGPMakefile.
make -f CGMakefileInstall under the CommuniGate Pro base directory.
/var/CommuniGate/bin
-rwxr-xr-x 1 root qmail 13372 Jan 25 10:11 cgp-qmqpd -rws--s--x 1 qmailq mail 12488 Jan 25 09:33 cgp-submit
and create the traditional qmail queue related directories
drwx------ 2 qmailq qmail 512 Apr 7 01:01 intd drwxr-x--- 25 qmailq qmail 512 May 22 2003 mess drwx------ 2 qmailq qmail 512 Apr 7 01:01 pid
The only thing that needs to be started is cgp-qmqpd. It needs it's own user account, qmaild (1009), and belong to a group called nofiles (1002). I started it with:
tcpserver -x /etc/qmqp.cdb -u 1009 -g 1002 0 628 cgp-qmqpd
qmailq user (1012) and qmail group (1003) also need to exist for cgp-submit. None of the other qmail user and groups need to exist on the MTA.
Return-Path: <jason@example.net.> Received: by mail.example.net (CommuniGate Pro PIPE 4.1b6) with PIPE id 946070; Wed, 21 May 2003 21:41:57 -0400 Received: (qmail 35693 invoked from network); 22 May 2003 01:41:42 -0000 Received: from lou.example.net (128.164.26.3) by mail.example.net with QMQP; 22 May 2003 01:41:42 -0000 Date: 22 May 2003 01:41:42 -0000 Message-ID: <20030522014142.281988.qmail@lou.example.net> From: "Jason Mader" <jason@example.> Cc: recipient list not shown: ; Subject: Hello! Hello world.
The QMQP from field is rewritten as Return-Path: and the to field is rewritten as Envelope-To: in the resulting RFC822 message.
Now the only thing necessary to allow the Unix hosts to use the QMQP service is to add the IP addresses in /etc/qmqp.tcp and build the database. Currently this file contains the test system IP:
128.164.26.3:allow
:deny
Then create /etc/qmqp.cdb:
tcprules /etc/qmqp.cdb /etc/qmqp.tmp < /etc/qmqp.tcp
That's it. Go ahead and get rid of the sendmail kludge and mail queues that came with the system.
For testing purposes, here's an example netstring of a very simple mini-qmail message:
45:0:,17:jason@example.net,17:jason@example.net,,