Bug 98128 – mail-mta/qmail-1.03-r15 and control/tlshosts

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description petre rodan (RETIRED) 2005-07-06 08:26:20 UTC]

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

[Comment 1 petre rodan (RETIRED) 2005-07-07 06:57:45 UTC]

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.

[Comment 2 petre rodan (RETIRED) 2005-07-07 07:12:15 UTC]

yupiii qmail-1.03-r16 fixes my bug.
-r15 bad
close at your discretion ;)

[Comment 3 Robin Johnson 2005-07-07 08:56:12 UTC]

ok, good to read that -r16 works.
it should get to stable fairly soon anyway.