So, I’ve been having this problem with Qmail on our CentOS 5.6 machine. Some domains aren’t receiving emails. Strange problem and it was hard to find the fix. But, apparently it looks like an issue related to ipv6 and Qmail. Reverting to different Qmail drivers fixed the problem. If you run across this, here’s your fix.
Rebooting the hardware node to enabled IPv6 isn’t always an option for obvious reasons. The quickest solution to this problem was posted by Igor and Boris earlier in the thread:
http://forum.parallels.com/showpost.php?p=454947&postcount=16
http://forum.parallels.com/showpost.php?p=616590&postcount=27
Since Boris site is in German, here is the outline:
wget http://autoinstall.plesk.com/PSA_10.1.1/dist-rpm-CentOS-5-x86_64/opt/maildrivers/plesk-mail-qc-driver-10.10.1-cos5.build1010110120.18.x86_64.rpm
wget http://autoinstall.plesk.com/PSA_10.1.1/dist-rpm-CentOS-5-x86_64/opt/maildrivers/psa-qmail-1.03-cos5.build1010110112.13.x86_64.rpm
rpm -Uvh plesk-mail-qc-driver-10.10.1-cos5.build1010110120.18.x86_64.rpm –force –nodeps
rpm -Uvh plesk-mail-qc-driver-10.10.1-cos5.build1010110120.18.x86_64.rpm –force
rpm -Uvh psa-qmail-1.03-cos5.build1010110112.13.x86_64.rpm –force
/etc/init.d/qmail restart
/etc/init.d/xinetd restart
Check the queue:
/var/qmail/bin/qmail-qstat
Force send if necessary:
kill -ALRM `pgrep qmail-send`
Check the queue again:
/var/qmail/bin/qmail-qstat
Once the queue is empty, leave the temporary fix in place until parallels patches, or switch the postfix as a perm solution: http://kb.parallels.com/en/5801
A much cleaner and less time consuming method of fixing this problem without imposing an outage to customers…