QMAIL

QMail delivery Cannot deliver outgoing email

Determine problem recipient mx server

Try manual telnet test to problem mx server using both internet name and numeric IP There are 2 mail servers at m21.net. There is the bulk mail server and the regular old day-to-day incoming and outgoing mail server. The latter is documented on this page.

The mail server sits in the main computer rack at Swiftwill. It is one of the 3500 machines. It has 2 network interfaces. One connects to the DMZ at x.x.x.x(mail.m21.net) and the other is on the Internal Network at 192.168.10.24.

The server runs Centos version 4, which is a free clone of RedHat Enterprise Linux 4. The mail software is Qmail toaster. The only unusual thing about the way it is configured is that I made a huge /var partition and made /home/vpopmail a softlink to /var/qmail so that ALL of the mail related stuff would be in the /var/qmail directory structure. crontab&nbsp The crontab for root looks like this: 34 * * * * /usr/sbin/ntpdate pool.ntp.org >/dev/null 2>&1 0 7 * * * /usr/bin/freshclam 0 2 * * * /opt/m21/bin/backupmail The backupmail script just tars up /var/qmail onto the backup share of the fileserver It keeps 2 days worth of backups. Other Services&nbsp The mail server has all of the standard qmail web administration products. It also hosts the bugzilla.m21.net instance. Blown upgrade&nbsp on 7-july-2008 I did a qmail-toaster upgrade on both mail servers following a successful upgrade of the operating system to CentOS 4.4. The following is an email that I sent to the mailing list about how I repaired it with just a few formatting changes:

A few weeks ago someone posted a message about how he did an upgrade on a production server and it stopped working. He was getting the message "451 qq write error or disk full (#4.3.0)"

I had this same problem happen today. While I do not know what caused it, I suspect that not turning off monit had something to do with it, as monit would have tried to restart qmail every few minutes. Again, this is just a suspicion.

The tangible results of this upgrade failure was that many files and folders throughout the qmail installation ended up being owned by named:named.

One thing you should know about my system is that /home/vpopmail is a softlink to /var/qmail. This allows me to have less directories to back up and to follow a scheme that I used on earlier (pre-toaster) setups. So when I refer to the /var/qmail/domains directory, it is likely to be /home/vpopmail/domains for you if you do not have your schema set up as do I,

What needs to be done to revive the system is to do a lot of ownership changes and some mode changes.

First I ran queue_repair.py -r. I do not know that it actually did a lot of good because things it said that it did, when I checked it did not, but I include it here for thoroughness.

Here are the changes I had to make: chown root:root /usr/sbin/httpd cd /var/qmail ; chown -R qmaill:qmail supervise cd /var/qmail/bin; chown root:qmail qmail-clean qmail-lspawn qmail-rspawn qmail-send qmail-smtpd cd /var/qmail/etc ; chown vpopmail:vchkpw vpopmail.mysql* cd /var/log/qmail ; chown -R qmaill:qmail * cd /var/qmail/queue ; chown -R qmailq:qmail todo cd /var/qmail/queue/todo ; chmod 644 * cd /var/qmail/queue ; chown -R qmailq:qmail mess cd /var/qmail/queue/mess ; chmod 755 * ; chmod 644 */* cd /var/qmail/domains ; chown -R vpopmail:vchkpw * I have no idea of how apache (httpd) got changed, but it had monit sending me alerts, so that was what I had changed first.