on all 3 servers that relay with the outside world, I have # ls -al /var/qmail/control/tlshosts/ total 20 drwxr-xr-x 2 qmaill root 4096 May 23 10:26 . drwxr-xr-x 4 root qmail 4096 Jul 6 17:00 .. -rw-r--r-- 1 root root 0 May 23 10:26 .keep but on all 3, my logs show things like: @4000000042bd09861cf3953c delivery 26315: deferral: TLS_unable_to_load_control/tlshosts// @4000000042bd6f162cf4339c delivery 26518: deferral: TLS_unable_to_load_control/tlshosts// @4000000042bdd7c60af27f74 delivery 26746: deferral: TLS_unable_to_load_control/tlshosts// @4000000042be439611b75cbc delivery 26961: deferral: TLS_unable_to_load_control/tlshosts// @4000000042beb28604b15cd4 delivery 27183: deferral: TLS_unable_to_load_control/tlshosts// @4000000042bf24962f3916a4 delivery 27427: deferral: TLS_unable_to_load_control/tlshosts// @4000000042bf99c52cf3e194 delivery 27645: deferral: TLS_unable_to_load_control/tlshosts// this should not happen under any normal circumstance on line #363 in qmail-remote.c, if (stat(servercert.s,&st) == 0) needtlsauth = 1; , servercert.s gets distorted in such a way that it becomes 'control/tlshosts//', so that stat returns 0 and needtlsauth = 1. a quick and dirty fix would be to remove that directory :/ I heavily use TLS between the machines of my network but between them this problem does not occur. I saw that TLS error only for about 16 messages (+ their retries) since I installed 1.03-r15. I will try to dig deeper tomorrow. Portage 2.0.51.22-r1 (selinux/2004.1/x86, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-hardened-r1-avira i686) ================================================================= System uname: 2.6.11-hardened-r1-avira i686 Intel(R) Xeon(TM) CPU 2.40GHz Gentoo Base System version 1.6.12 dev-lang/python: 2.2.3-r5, 2.3.5 sys-apps/sandbox: 1.2.9 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.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/alias /var/qmail/control /var/service" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox selinux sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_2" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="crypt curl gd gdbm hardened hardenedphp innodb jpeg libwww mysql ncurses nls pam perl pic pie png postgres python readline selinux spell ssl truetype x86 xml xml2 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
I have successfully and persistently replicated the problem by locating an exim server to which my bug always reacts badly the bug is somewhere in http://www.arda.homeunix.net/store/old_software/qregex-starttls-2way-auth.patch the fqdn from qmail-remote.c on line 358 is non-NULL but it sometimes contain invadid data (like nothing or random thigs like " i $ i $.yahoo.com") qmail-remote.c -if(fqdn){ +if(fqdn && (str_len(fqdn) > 0)){ is a check that would make qmail work in my case (but it's definitely not a cure for the bug) I will check if qmail-1.03-r16 also has the problem. it uses a newer version of that patch.
yupiii qmail-1.03-r16 fixes my bug. -r15 bad close at your discretion ;)
ok, good to read that -r16 works. it should get to stable fairly soon anyway.
