:: blog:qmail ::

I'm working on getting qmail set up for TIGHAR on a Fedora 9 system. I'm taking the manly approach: configuring, making, installing, and configuring by hand.

(At times, I think I've had enough of manliness. Next time, may well start with yum and see how far it can take me.)

Besides qmail, I've installed:


Helpful links

Source files

Some lessons learned


Two books are better than one

I've got Dave Sill's qmail Handbook as well as John R. Levine's qmail. Both have been helpful.

Don't mess with directory permissions

Qmail and vpopmail are very sensitive to ownership and permissions. I don't know how I messed things up as badly as I did, but I spent a couple of worried hours finding out what would work.

The great breakthrough was the suggestion someone made to su to vpopmail and try changing directories. I made great progress after that.

Don't chmod -R qmail or vpopmail directories. You'll be sorry! I was anyway.

Starting svscan without rebooting

After following all of Dave's instructions, nothing was happening. I had to run /command/svscanboot & to kick things off. Worked like a charm. Folks who know linux know stuff like that. They don't have to searching for it.

Fake MTA?

  • For now, I've just set etc/yum.conf to ignore updates for sendmail:
exclude=php* sendmail*

What does that ampersand mean?

This must be another thing that's just so obvious that nobody talks about it. In a .qmail file, &moleski@canisius.edu means “forward mail to that address.” A line in the qmail file without an ampersand means “deliver directly to that mailbox on the local system.” At least that's how it seems to me. The books and websites sometimes use the ampersand and sometimes don't–without explaining what they're doing.

I wanted to be able to have one copy left in my Maildir and one sent elsewhere. This .qmail in my home directory did the trick:




iptables (firewall) and qmail

I had to fool around with the firewall–there seemed to be some odd interactions.

  • Open port 110 for the POP server:
-A OUTPUT -s -p tcp -m tcp --sport 110 --dport 1024:65535 -m state --state 
  • Open port 2525 for Hermes:
-A INPUT -p tcp -m tcp --dport 2525 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT 
  • Open port 3306 for mysql:
-A INPUT -s -p tcp -m tcp --dport 3306 -j ACCEPT 

Getting svscan to start after a reboot (Fedora 9)

I tried using “yum install” on daemontools.

The installation script ends by saying, “Adding svscanboot to inittab… init should start svscan now.” But in Fedora, inittab has been usurped by Upstart:


cron job for clearopensmtp




set sticky bit for vchkpw


chown vpopmail:vchkpw ~vpopmail/bin/vchkpw

chmod 4711 ~vpopmail/bin/vchkpw

chmod u+s ~vpopmail/bin/vchkpw

vchkpw "can't write SQL logs"

In the daemontools log, the associated error message is: “vmysql: can't read settings from /home/vpopmail/etc/vpopmail.mysql”.

~vpopmail/etc/vpopmail.mysql is where the configuration is written for vpopmail to access the MySQL database.

Relaxing permissions on that file lets vchkpw access the file for smtp-auth.

"vpopmail user not found"

Reset the sticky bit on vchkpw (see above).

vchkpw fails

Error message: setgid 89 failed errno 1.

Peter Palmreuther: “Either you compiled vpopmail with user vpopmail belonging to group with ID 89 and changed the group id some times later or vchkpw is executed with a UID not allowed to setgid(89).”

John Simpson's vfixpermissions script solves this problem–but hexes imap-auth!

What I did as a workaround was to change the ownership of /home/vpopmail/bin/vchkpw to root (chown root.root vchkpw) as well as setting the sticky bit (chmod 4711 vchkpw). The problem is to satisfy the demands of two different contexts with a single set of ownerships and permissions:

  • vchkpw for IMAP and POP access to mailboxes.
  • vchkpw for SMTP-auth to send mail from remote computers–needs to setuid and setgid to execute next program.

I don't understand the problem. It does seem that vchkpw sets its uid and gid to 89 (otherwise, where else would the error message in the MySQL log come from?), so once it reaches that part of the program, security is restored.

I suppose what I really need to do is go read some code.

vchkpw.c suggests that the setgid command is preparatory

for executing the next program in line after vchkpw:

  /* The user is authenticated, now setup the environment */ 

  /* Set the program's effective group id */ 

  if ( ConnType != SMTP_CONN && setgid(pw_gid) == -1 ) {

    snprintf(LogLine, sizeof(LogLine), "%s: setgid %lu failed errno %d %s@%s:%s", 

      VchkpwLogName, (long unsigned)pw_gid, errno, TheUser, TheDomain, IpAddr);

    vlog(VLOG_ERROR_INTERNAL, TheUser, TheDomain, ThePass, 

                              TheName, IpAddr, LogLine);



  /* Set the program's effective user id */ 

  if ( ConnType != SMTP_CONN && setuid(pw_uid) == -1 ) {

    snprintf(LogLine, sizeof(LogLine), "%s: setuid %lu failed errno %d %s@%s:%s", 

      VchkpwLogName, (long unsigned)pw_uid, errno, TheUser, TheDomain, IpAddr);

    vlog(VLOG_ERROR_INTERNAL, TheUser, TheDomain, ThePass, 

                                TheName, IpAddr, LogLine);



In the case of the run file I'm using to start tcpserver on port 465, the 'program' to be executed is /bin/true–in other words, no program at all.

These are the sticky bit settings I tried that didn't solve the problem:

4711setuid bit is set
6711setuid and setgid bits are set
7711setuid, setgid, sticky bits are set

(All about linux permissions.)

I didn't try 1711, 2711, 3711, or 5711. Who knows? Maybe one of those would work.

courier imap

Upstart script for authdaemond


Location: /etc/rc.d/init.d/courier-authlib

Test the script: /etc/rc.d/init.d/courier-authlib start

I think this came out of my (failed) experiments with building

the RPMs. It's a nice script.

#! /bin/sh


# chkconfig: 2345 15 85

# description: Authlib - Courier authentication library.


# modified by MXM, SJ to match output from source files





if test ! -f /usr/local/etc/authlib/authdaemonrc


	echo "/usr/local/etc/authlib/authdaemonrc does not exist, forgot make install-configure?"

	exit 1


case "$1" in


        cd /

        # Start daemons.

        touch /var/lock/subsys/courier-authlib

        echo -n "Starting Courier authentication services:"

	$sbindir/authdaemond start

	echo " authdaemond"



        echo -n "Stopping Courier authentication services:"

	$sbindir/authdaemond stop

	echo " authdaemond"

        rm -f /var/lock/subsys/courier-authlib



	$0 stop

	$0 start



        echo -n "Starting Courier authentication services:"

	$sbindir/authdaemond restart

	echo " authdaemond"



exit 0

Contents of "Readme Now or Suffer"

The very best laugh I've had this week.


Resist the urge to just run configure, make, then make install


Read INSTALL (the first half of it is good enough), and follow it to the

letter.  I mean it.  I am not kidding.

(Many fruitless hours later): Well, I was warned …

This How to Forge article seems to be working better than anything I tried. I had gotten the authlib installed without any difficulty but couldn't pass the “make check-am” test no matter what I tried. It's probably because I'm on an x64 system. Or because I missed the one key line in the INSTALL that makes all the difference.

Curses, foiled again!

/bin/sh ./smaptestsuite | ./testsuitefix.pl | sort | cmp -s - ./smaptestsuite.txt

make[2]: *** [check-am] Error 1

make[2]: Leaving directory `/usr/src/redhat/BUILD/courier-imap-4.5.1/imap'

make[1]: *** [check] Error 2

make[1]: Leaving directory `/usr/src/redhat/BUILD/courier-imap-4.5.1/imap'

make: *** [check-recursive] Error 1

error: Bad exit status from /var/tmp/rpm-tmp.19598 (%build)

RPM build errors:

    Bad exit status from /var/tmp/rpm-tmp.19598 (%build)

Back to compiling from the source. Looked intently on where make check was failing. Searched. Found that I could configure without SMAP. Passed the make check test!

./configure \

--with-mailuser=courier \

--with-mailgroup=courier \

--with-mysql-libs=/usr/lib64/mysql \

--with-mysql-includes=/usr/include/mysql  \

--with-authmysql --with-authmysql=yes \

--with-authvchkpw \

--without-authldap \


Missing paren in courier-authlib README

/usr/local/src/courier-authlib-0.62.4|README.authmysql.html left a closing paren out of the SQL query.


        id                    char(128) DEFAULT '' NOT NULL,

        crypt                 char(128) DEFAULT '' NOT NULL,

        clear                 char(128) DEFAULT '' NOT NULL,

        name                  char(128) DEFAULT '' NOT NULL,

        uid                   int(10) unsigned DEFAULT '65534' NOT NULL,

        gid                   int(10) unsigned DEFAULT '65534' NOT NULL,

        home                  char(255) DEFAULT '' NOT NULL,

        maildir               char(255) DEFAULT '' NOT NULL,

        defaultdelivery       char(255) DEFAULT '' NOT NULL,

        quota                 char(255) DEFAULT '' NOT NULL,

        options               char(255) DEFAULT '' NOT NULL,

        KEY id (id(128)));




Missing Forwards after Qmailadmin upgrade

I started with qmailadmin-1.2.0, then upgraded it to qmailadmin-1.2.12. 1.2.0 showed the vpopmail .qmail-{name} aliases correctly–it was thrilling! After the upgrade, none of the forwards were visible to me, but I could not redefine them. Qmailadmin knew they were there.

I think the problem is that I compiled qmailadmin with valias. At a guess, 1.2.0 was more relaxed about mixing the old system with the new. I just deleted all of the .qmail-{name} files that I so laboriously created from the linux alias file earlier this week, and then re-entered them through qmailadmin, one at a time.

For multiple forwarding addresses, first create an alias with one forwarding address; then edit it and tack on another address as needed until the forwarding list is complete.

ucspi-ssl -- sslserver

EXTERN.h not in include path

package/compile for ucspi-ssl-0.70 stops with this error: “EXTERN.h: No such file or directory”.

EXTERN.h is here: /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/

They say it is a common problem.

I'm hoping that a sim link from the real location to the default search directories might solve the problem. But right now, it's nap time!

  ln -s /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/ /usr/lib/perl5

Nope. Still not found. Time to read some source code.

It's not complicated. All it says is to include EXTERN.h.

  ln -s /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/EXTERN.h \


OK. In src/conf-perl, this line worked to get the message across:

  perl -I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/EXTERN.h

Then the error message showed that the message was received:

@INC contains: /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi ...

Another part of the error messages suggested I needed another RPM.

 yum install perl-ExtUtils-Embed

That got rid of one error message. Still no joy with EXTERN.h.

Get rid of my links before I forget about them:

rm /usr/local/src/ucspi-ssl+tls/host/superscript.com/net/ucspi-ssl-0.70/src/EXTERN.h
rm /usr/lib/perl5/CORE

Took the -I parameter out of perl-conf.

Then it worked, albeit with some warnings.

“O, great mystery of being!”

testing qmail installation

My ISP blocks port 25

This was a big DOH!

I kept trying to test the new sslserver by telneting from home.

It looked like it was dead in the water–no response whatsoever.

I played with the site fireall (iptables).

I played with my own firewall (Vista SP2).

I don't know how many combinations of Thunderbird setup I tried for configuring the SMTP server.

Hours went by in obsessive-compulsive efforts to find out what I had done wrong.

The butler did it!

{insert string of expletives}

qmail smtpd log says: "status 25600"

The problem: connection denied

Trying to test Simpson's qmail recipe, I would telnet localhost 25 and get the expected dialogue. Then I would try to telnet to the domain on port 25 and not get connected.

In the /var/log/qmail/smtpd/current log, the transaction looked like this immediately after restarting qmail using qmailctl restart:

@400000004a59f0b034b5bc7c command-line: exec tcpserver -vR -l tighar.tighar.org -c 30 -u 511 -g 508 -x /home/vpopmail/etc/tcp.smtp.cdb 0 25   recordio qmail-smtpd  2>&1

@400000004a59f0b034f2c964 tcpserver: status: 0/30

@400000004a59f0ba172da5ac tcpserver: status: 1/30

@400000004a59f0ba172da5ac tcpserver: pid 2787 from

@400000004a59f0ba172da5ac tcpserver: deny 2787 tighar.tighar.org: mail.tighar.org:

@400000004a59f0ba172da5ac tcpserver: end 2787 status 25600

@400000004a59f0ba172da5ac tcpserver: status: 0/30

If status is other than 0, then it indicates an error.

Looking at the same transaction from the other side, telnet tighar.org 25 failed immediately with “Connection closed by foreign host.”

The solution: fix cdb

When I was having trouble configuring qmail last week, I set up /home/vpopmail/etc/tcp.smtp to deny all connections other than localhost. I forgot that I had done that. Somewhere along the line, trying to simplify matters and reduce the number of variables in the situation, I had removed the “-x /home/vpopmail/etc/tcp.smtp.cdb” parameter from the /var/qmail/supervise/qmail-smtpd/run file, so that the only control on relaying came from the /var/qmail/control/rcpthosts file.

When I compiled and installed John Simpson's version of qmail, I restored the “-x /home/vpopmail/etc/tcp.smtp.cdb” parameter. It pointed to the .cdb compiled from …/tcp.smtp:

# The active tcp.smtp text file and compiled .cdb are:

#		/home/vpopmail/etc/tcp.smtp

#		/home/vpopmail/etc/tcp.smtp.cdb 


#This rule file is meant to be compiled with:


# cat /home/vpopmail/etc/tcp.smtp | tcprules /home/vpopmail/etc/tcp.smtp.cdb /tmp/tcpsmtp.cdb


#and meant to be used by tcpserver with the -x argument:


# tcpserver -x /home/vpopmail/etc/tcp.smtp.cdb ...


# http://cr.yp.to/ucspi-tcp/tcprules.html

# http://cr.yp.to/ucspi-tcp/tcprulescheck.html


#  tcprulescheck /home/vpopmail/etc/tcp.smtp.cdb


# tcpserver is called by /service/qmail-smtpd/run


# then use "qmailctl restart" to make the new cdb take effect




As a consquence, following my instructions, the smpt daemon denied all connections to everybody else but localhost.


I understand why some of the qmail gurus dislike new qmail users. This problem was entirely of my own making. I shot myself in the foot. There are many different ways to do that with qmail.

Ah, well. Nothing to do but forge ahead. qmail does work. The problem isn't qmail; my problem is me.

svc stop/start and svsstat

I'm learning how to set up a svs script that will call qmail-smtpd for smtp-auth using vkchkpw.

svc -u /service/qmail-tlsstart
svc -d /service/qmail-tlsstop
svstat /service/qmail-tlsstatus


/var/qmail/bin/qmailctl is a script that provides the proper svc calls to start, stop, and report the status of various and sundry qmail components.

Simpson's Big Patch & smtp-auth

Qmail-TLS patch

This works with netqmail 1.06, although it is labeled for 1.05.

/var/qmail/control/servercert.pem and /var/qmail/control/clientcert.pem must contain both the unencrypted private key as well as the certificate:


... actual contents of unencrypted private key go here ...



... actual contents of certificate go here ...


The private key has to be unencrypted so that the server can use it without waiting for someone to enter the password for the key.

compiler errors

qmail-smtpd.c:122: error: conflicting types for 'protocol'

qmail-smtpd.c:35: error: previous definition of 'protocol' was here

qmail-smtpd.c: In function 'main':

qmail-smtpd.c:1020: warning: return type of 'main' is not 'int'

make: *** [qmail-smtpd.o] Error 1

Adding this line early on in qmail.smtpd.c solves the problem of the return type for main (I think):

void main(int argc,char **argv);

The protocol variable looked like this (after a patch):

const char *protocol = "SMTP";

I changed it to:

char *protocol = "SMTP";

testing Qmail-TLS

# telnet localhost 25


Connected to localhost.

Escape character is '^]'.

220 tighar.tighar.org ESMTP






250-SIZE 0



220 ready for tls


telnet> quit

Connection closed.

qmail toaster


date Milestone
2009-06-29Logged in at 8:47 PM and started obeying instructions.
2009-06-303:01 AM: first e-mail received and delivered to my Maildir at TIGHAR.
Later in the day: Hermes and qmail working; sendmail, xinetd, & milter-greylist removed
2009-07-01First piece of mail retrieved from qmail and vpopmail.
2009-07-02Did an exceedingly manly build of courier auth & imap. Both demons seem to run. Not tested.
  • 5:20 PM: ~ 5 hours to make one fake record for courier-imap and read it with authtest. Had to rebuild some stuff. Even manly men sometimes make mistakes.
  • 7:00 PM: autorespond, ezmlm, and qmailadmin up and running. 8:30 PM: discovered that courier-imap developer no longer supporting vpopmail. Time to try Dovecot!
  • 3:22 AM: Dovecot running and responding on all ports from localhost. I need to rig the firewall for two SSL ports next.
  • 4:01 PM: I've given up on SSL for the moment. I've got IMAP and POP access to the same mailbox (dovecot + vpopmail + vchkpw + qmailadmin) and forwarding addresses have been reworked (for the third or fourth time).
  • 1:06 AM: Ditched Hermes. It greylisted splendidly, but somehow interfered with qmail's rcpthosts (I speculate) and let ALL patient spam be relayed. I stripped the system down to bare bones--no .cdb, just one line in RCPTHOSTS. Spam is still going through to valid addresses. I think I'll give greylite another shot tomorrow. I'm smarter now than I was a few days ago.
  • 1:45 PM: Rebuilt dovecot from source code per the instructions. Seems to be working.
  • Finished configuring Dovecot. Took some time to organize my [[tighar:root|notes to myself about the website setup]]. Organized a few tiny scripts. Haven't started figuring out how to authorize SMTP services for outgoing mail.
  • 10:11 AM: Got Thawte key working for TSL access. Changed dovecot.conf to require secure connections. First e-mail received through secure connection.
  • Spent the daylight hours convincing myself that I could not put a newer AGP card into a 2003 motherboard for a friend in the community. So sad!
  • Got a second copy of sslserver running on port 465. That's a start. But I don't have a vchkpw method (yet) to allow relaying mail from authorized users to non-TIGHAR addresses.
2009-07-08Worked on rehabilitating a laptop for my nephew (AMD Mobile Athlon 64, 2 Ghz, 90 GB drive, 500 MB RAM). Tried Fedora Core 11. It ran. I couldn't see a clear path to get it to play DVDs–and I was worried that Joe and his family would have trouble maintaining a Fedora setup. Went back to Windows XP.
2009-07-09Rounded out the XP setup with a few hundred updates, Firefox, Thunderbird, Open Office, Picasa, and Gimp. I ordered a 1 GB stick of RAM to max out the laptop's capacity. Found all of the drivers needed for the hardware (e-machine, model 6809 or thereabouts). It has a very pleasant screen and the keyboard is OK. It weighs a ton and the plastic trim around the hinges is cracked (I hope it's just trim and not the hinges themselves!). I think I'll pack some JB Weld into the cracks–it might help to stabilize them. (Nope. On closer inspection, I figured that it would do more harm than good …
  • After a few days off to think about things, I decided to go with John Simpson's Big Patch. I think it is the easiest way //for me// to integrate vchkpw with smtp-auth. Took just a few minutes to download qmail 1.03 from djb's website, apply the Big Patch, and "make setup check."
  • Next challenge: configuring the patched version of qmail through Simpson's run script.

    No joy. Dave B. had invited me over for pork & beans and a nice documentary about flying five B-25s across the Atlantic, so I tried (and failed) to put everything back the way it had been.

  • ~10:30 AM: Found my mistake--a leftover '':=deny'' instruction in my .cdb file. smtp services on port 25 seem to be working again. Lunch time!
  • 11:23 PM: "Know when to fold 'em." I don't know enough about SSL to debug sslserver. Even when I don't get the "status 11" segfault error, I'm not getting communication between sslserver and my client. It just hangs up and goes nowhere.
  • Tomorrow: qmail authentication patch. I guess I'll go back to netmail 1.06. Maybe. I hate to give up on SSL and TLS. Ah--there are different routes to get there--woops!--which gives me more stuff to think about. It may be that I didn't obey these directions carefully enough the first time I tried them. I might start over with a fresh copy of the sslserver source and go through this tutorial line-by-line. Pasta faggiole!
  • 10:46 AM: I thougt TLS was working. Patched (and thought that I had fixed rejected blocks) for qmail-authentication-0.6.8. I seem to have been wrong. I must have been wrong. Got "status 11" segment fault again from sslserver when I tried to connect.
  • More qmail auth stuff.
  • 2:00 PM: Got qmail-TSL working with netqmail 1.06. Time to try combining the auth patch.
  • 3:52 PM: Seems to have both things working--at least when using telnet localhost 25.
  • 8:56 PM: Got further than before. STARTTLS is working. Username and password are requested. Then we go in circles--requesting the password again and again. Blech. Next thing to try: qmail toaster. Not tonight!
  • 5:57 AM: Couldn't sleep. Hassled by anxieties about all the stuff I'm not getting done--school, family, other volunteer chores. I also wanted to see what was going on with logwatch. The e-mail came through fine. That was a relief! I didn't see it yesterday morning.
  • 8:29:31 AM: First successful delivery via smtp-auth! I just kept checking permutations and combinations of directives in the run script (/var/qmail/services/qmail-tls/run). I also recompiled vpopmail. Something worked.
  • I couldn't bring myself to run the qmail Toaster installation scripts. I didn't want to rock the boat with Dovecot, the forwards that I've set up via qmailadmin, the TLS/SSL certificates, etc., etc. I just had too many commitments in place to want to go back to a clean-sheet installation. Next time, however, I'll probably give the Toaster a whirl. The whole point of that system is to make sure that all patches work well together. It looks like a pretty excellent system.
  • 8:51 AM: The thought crossed my mind that I hadn't tested POP and IMAP access after getting SMTP-auth working. O, my prescient spirit! Whatever I did to fix SMTP knocked out Dovecot.
  • 1:31 PM: Went round in circles like the skit in //I Love Lucy//: pushing one drawer closed made another pop out. The heart of the matter seems to be ownership and permissions for vchkpw (along with a handful of other smaller issues).
  • 3:00 PM: Notes finished. Again.
  • 8:05 PM: First test message sent and received from SquirrelMail.
2009-07-16 Did a page of documentation for users. Not a lot to say.
Bottom line: 17 days, on and off, to get all components working.


POP working

qmail admin


both IMAP and POP available

SMTP-AUTH (sending mail)

2009-07-14 08:29:20 info msg 286044: bytes 638 from <moleski@tighar.org>

           08:29:20 starting delivery 3: msg 286044 to remote moleski@canisius.edu

           08:29:31 delivery 3: success: ...

Note to Dave Sill

“Dave, if you ever read this message, let me offer you my undying thanks for everything you've done for qmail over the years” (John Simpson).

Yes, but

vpopmail clearopensmtp problem

This really doesn't bother me any more. I set up the clearopensmtp cron job an eternity ago when I was following the old “POP before SMTP” path for SMTP authentication. I'm now headed toward STARTTLS & vkchkpw for smtp-auth.

Modify quotas

cd /usr/local/src/vpopmail-5.4.27/

./vmoduser -q NOQUOTA tighar.org


./vmoduser -q NOQUOTA someone@tighar.org

Ignore quotas for tighar.org. I'm doing this because I didn't patch something to have the quotas work right–stuff wasn't getting subtracted when e-mail was deleted. <sigh>

Tighten Dovecot security -- imaps & pop3s

Up next

  • Force https login for SquirrelMail.
  • Update the list of source files
blog/qmail.txt · Last modified: 2017/07/13 20:33 (external edit)
Recent changes RSS feed Creative Commons License Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki