I am setting up a new server to replace an existing one. The existing server is using a TLS patched qmail, and the new server is a gentoo machine using the highly-patched qmail. When the old machine tries to send mail to the new machine, the old machine logs this: Jan 18 13:40:01 rackspace qmail: 1137613201.389203 delivery 2090: deferral: TLS_connection_to_x.x.x.x_died:_error:00000000:lib(0):func(0):reason(0)/ at the same time, the new server logs this: @4000000043ce9eed07c05254 tcpserver: ok 20841 .x.x.x:25 ns1.orthoresident.com:x.x.x.x::59897 @4000000043ce9eed07c0563c relay-ctrl-check[20841]: Debug: IP x.x.x.x not found. @4000000043ce9eed08349fc4 tcpserver: end 20841 status 11 @4000000043ce9eed0834ab7c tcpserver: status: 0/40 the 'status 11' returned by tcpserver on the receiving server is being returned by the program being run by tcpserver. This is the line for my `ps`: /usr/bin/tcpserver -p -v -R -x /etc/tcprules.d/tcp.qmail-smtp.cdb -c 40 -u 201 -g 200 0.0.0.0 smtp /var/qmail/bin/qmail-smtpd rackspace.mudbugmedia.com /var/vpopmail/bin/vchkpw /bin/true According to: http://marc.theaimsgroup.com/?l=qmail&m=108702351002075&w=2 -- a status 11 most likely means a signal 11/ sigsegv Also, these errors generally seem to be introduced by patches. Other references to this error pulled up these change logs: http://www.fehcom.de/qmail/spamcontrol.html http://www.mcmilk.de/qmail/ This is a potentially a large problem, as it may mean that any other TLS enabled server attempting to connect to a server as described here, they would not be able to communicate.
Portage 2.0.53 (hardened/amd64/multilib, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r5 x86_64) ================================================================= System uname: 2.6.14-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -pipe -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://gentoo.chem.wisc.edu/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="amd64 apache2 bzip2 chroot clearpasswd crypt curl doc expat gmp gpm hardened hardenedphp idn imagemagick imap ipalias jpeg justify libwww mhash mpm-prefork mysql ncurses nls nptl pam pcre perl pic png python qmail readline ruby sendfile sftplogging spamassassin ssl symlink tcpd threads udev userlocales utf8 vchroot vhosts xml2 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS uname -a: Linux rackspace 2.6.14-gentoo-r5 #2 Wed Jan 11 07:32:38 CST 2006 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
The segfault in this case is related to the pie/ssp enabled gcc. Using gcc-config to turn the compiler to a non-hardened version to recompile qmail will prevent the segmentation faults from occurring. However, this is still a valid bug, and is potentially worsened since it is not immediately apparent from the logs that it is occurring (as the logs just say 'status 11' and not something more obvious such as 'qmail-smtpd segmentation faulted') and that it only occurs with other TLS/SSL enabled smtp servers.
Which qmail ebuild version? Can you provide us with a backtrace?
Segfault has been fixed in qmail-1.03-r16 due to an update in the patches.