Update from yum for ucspi-tcp-0.88 on CentOS4 breaks SMTP relay!

SiteWorx Bugs
1

Shortly after yum did its nightly updates my SMTP server started to refuse relaying of mail for several reasons. Looking at the yum logs, it looks like it pulled the updated RPM from:

http://updates.interworx.com/iworx/RPMS/rhe4x/i386/ucspi-tcp-0.88-200.rhe4x.iworx.i386.rpm

Which has a modification date/time of Aug 2.

Now the -S tcpserver option no longer works, so apparently it is no longer using mysql auth to check incoming IP for allowed relay. Apparently the rpm knew this, because it renamed

/var/qmail/control/sql to /var/qmail/control/sql.rpmsave ??

Also, if I remove the -S option, SMTP auth is still failing. Inside outlook I’m receiving the error message in my email client (Outlook):

[SIZE=1]‘destuser@destdomain.com’ on 8/3/2006 3:55 AM
CHKUSER relaying rcpt: from <sourceuser@mydomain.com:sourceuser@mydomain.com:> remote <clientmachineID:unknown:x.x.x.x> rcpt <destuser@destdomain.com> : client allowed to relay

The message seems to indicate that they are being allowed to relay. I have searched google for anything related to this, and it only comes up with one hit

http://article.gmane.org/gmane.mail.qmail.chkuser.devel/4

Somehow the success message is being logged back across the network channel instead of to the correct log destination file.

None of these problems were occuring before the updated package of ucspi-tcp-0.88-200.rhe4x.iworx.i386.rpm

Is there any way to roll back to the previous version? We cannot send any mail right now – we are broken because of this update. Please help!

[/SIZE]

2

Actually it looks like latest update to qmail or qmail-pop3d causing the problem!

I downloaded and compiled ucspi-tcp myself and applied the mysql patch to allow use of -S. However, this did not change the problem.

Looking at the yum.log file, it looks like qmail and qmail-pop3d were updated also:

Aug 02 21:39:07 Updated: ucspi-tcp.i386 0.88-200.rhe4x.iworx
Aug 02 21:39:36 Updated: qmail.i386 1.03-209.rhe4x.iworx
Aug 02 21:39:59 Updated: clamav.i386 0.88.3-100.rhe4x.iworx
Aug 02 21:40:11 Updated: qmail-pop3d.i386 1.03-209.rhe4x.iworx
Aug 02 21:40:16 Updated: simscan.i386 1.2-100.rhe4x.iworx

It must be the case that the new qmail or qmail-pop3d packages are causing problems.

Is there any way I can obtain the older RPM packages? Can someone reccommend an easy, iworx friendly way to recompile qmail / qmail-pop3d making sure to undefine CHKUSER_ENABLE_LOGGING in chkuser_settings.h so that it won’t log this message??

(see http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html#vpopmail_dep_features)

Thanks.

3

khdev4u,

Please open a support ticket and we’ll check this out.

Thanks,
Socheat

4

Issue resolved!

Thanks to the very helpful support team at interworx for working through this issue with us. I’m definitely impressed with the level of their support. I’m posting what we found out for others to find and learn from.

Apparently the latest qmail update from yum for centOS supports STARTTLS natively. So clients such as Outlook can use port 25 and check “my SMTP server requires a secure connection” and it will try STARTTLS. But for ports other than 25 Outlook will attempt to negotiate SSL first (which requires stunnel on the listening end).

The new qmail build has additional CHKUSER logging enabled, which was causing problems. Interworx found a solution at:

[SIZE=2]http://www.opensubscriber.com/message/vchkpw@inter7.com/60209.html[/SIZE]

Essentially, stunnel needs to run in foreground mode. The newer versions of stunnel use a config file instead of command line switches. My /service/smtp-ssl/run file now looks like:

#!/bin/sh
QMAILDUID=id -u vpopmail
NOFILESGID=id -g vpopmail
MAXSMTPD=cat /var/qmail/control/concurrencyincoming
BLACKLIST=cat /var/qmail/control/blacklists
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
RBLSMTPD="/usr/bin/rblsmtpd"
HOSTNAME=hostname
VCHKPW="/home/vpopmail/bin/vchkpw"

exec /usr/bin/softlimit -m 6400000
/usr/bin/tcpserver -H -v -R -p -x $TCP_CDB -c “$MAXSMTPD”
-u “$QMAILDUID” -g “$NOFILESGID” 0 465
/usr/sbin/stunnel /var/qmail/control/stunnel_smtpd.conf 2> /dev/null

Do NOT route stderr to stdout (do not do 2>&1)

It’s very important to route stderr to a file or /dev/null or it won’t work. My stunnel config file looks like:

cert = /var/qmail/control/stunnel-servercert.pem
exec = /var/qmail/bin/qmail-smtpd
execargs = qmail-smtpd /home/vpopmail/bin/vchkpw /bin/true
foreground = yes

With that in place now all messages from CHKUSER are logged to /dev/null (or the file you specify in the service run file) instead of to stdout (which tcpserver would send across the network).

Thanks again to interworx support for helping to diagnose and resolve the issue.

5

Happy to help Kevin.

I just wanted to clarify two things:

  1. This problem only affected smtp-over-ssl setups (which is not setup on InterWorx servers by default). Normal port 25 smtp, and alternate port 587 smtp, work fine after the update.

  2. The aformentioned package updates were built and distrubted us (InterWorx) and not the CentOS folks.

There are a number of improvements / new features with these updates, and we’ll be putting together a forum post describing them in the not-too-distant future. :slight_smile:

Paul