Bugzilla Bug 34983

When i emerge ucspi-tcp with -ipv6 use flag, qmail reads rcpthosts even if im 
added in tcp.smtp.
It compiles with no error or warning message.
Compiling it without ipv6 flag works.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

do you mean to say that qmail is not letting you relay when it should?
provide lots more detail please, including 'emerge info'.
qmail version too!

Qmail has nothing to do with it really, i havent recompiled qmail, only the
tcpserver package. That works.
Im pretty sure that it is the tcpserver which fails to match the adresses in
tcp.smtp.cdb. When this happens, qmail wont let me relay.
btw: i meant to write +ipv6 flag, not -ipv6 flag.

Emerge info:
Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.20)
=================================================================
System uname: 2.4.20 i686 AMD Duron(tm) Processor
Gentoo Base System version 1.4.3.10p1
ACCEPT_KEYWORDS="x86"           
AUTOCLEAN="yes"                 
CFLAGS="-O2 -mcpu=i686 -pipe"   
CHOST="i686-pc-linux-gnu"       
COMPILER="gcc3"                 
CONFIG_PROTECT="/etc /usr/share/config /usr/kde/2/share/config
/usr/kde/3/share/config /var/bind /var/qmail/control /var/qmail/alias"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-O2 -mcpu=i686 -pipe" 
DISTDIR="/usr/portage/distfiles"
FEATURES="sandbox ccache autoaddcvs"
GENTOO_MIRRORS="http://gentoo.linux.no"
MAKEOPTS="-j2"                  
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.linux.no/gentoo-portage"
USE="x86 -X -gtk -gnome -alsa -kde -xv -imlib -sdl -qt -motif -opengl -apache
apache2 mysql ssl tcpd libwww perl png -ipv6 xml xml2"

which version of ucspi-tcp were you using before, and what version are you
using now that is broken?

Ive been using version 0.88-r5 of ucspi-tcp all the time.

could you please attach your tcp.smtp or email it to me privately
(robbat2@gentoo.org) ?

I can't reproduce your error at all.
TCPREMOTEIP=10.0.0.1 tcprulescheck tcp.smtp.cdb
rule 10.:
set environment variable RELAYCLIENT=
allow connection

Please include some of the actual error you are getting from qmail, because I certainly can't reproduce it.

Also, if you are using rblsmtpd in your qmail setup, you need to add RBLSMTPD="" to each of your relay rules here.

I'm not getting an error, tcpserver just refuses to set RELAYCLIENT for the
addresses in tcp.smtp.cdb

tcprulescheck works, even though tcpserver wont

ok, after banging my head on the table for a few hours i finally found out i
have
this exact same bug :)

it isnt related to qmail persay, it's just that we noticed it while using qmail
here's a pretty simple test setup to reproduce the bug:
env USE=ipv6 emerge ucspi-tcp
cat << EOF > testrules
127.0.0.1:allow
:deny
EOF
cat testrules | tcprules testrules.cdb testrules.tmp
tcpserver 0 1 env &
nc localhost 1  # <- this will work (no rule file given and default is to
allow)
# now kill that tcpserver with `fg` and CTRL+C
tcpserver -x testrules.cdb 0 1 env &
nc localhost 1  # <- this will fail (even thought it shouldnt ...)
sed -i 's|deny|allow|' testrules
cat testrules | tcprules testrules.cdb testrules.tmp
nc localhost 1  # <- this will work (like it should have in the first place
...)

even if you run tcprulescheck on the file, it'll report that it should work
(just
like Stian reported)
env TCPREMOTEIP=127.0.0.1 tcprulescheck testrules.cdb
rule 127.0.0.1:
allow connection
it will give this output for before and after the sed in the above example even
though we see that it'll fail since it didnt match the first allow rule

thuuuuuuuuus it is our opinion that the ipv6 breaks stuff horribly ! :)

bug traced down to ::ffff:127.0.0.1 being treated differently to 127.0.0.1
they need to be treated the same.

the ipv6 + ssl stuff has changed for ucspi-tcp, please try the new version and
see if the same problem is still present.

still broken over here ...

env USE="ipv6" emerge ucspi-tcp # this installed 0.88-r8
/etc/init.d/svscan restart
<try to send mail via 127.0.0.1 but relaying is denied>
env USE="-ipv6" emerge ucspi-tcp
/etc/init.d/svscan restart
<send mail via 127.0.0.1 and it works>

U could solve it, by writing the rules -ur /etc/tcp.smpt file- in ipv6 format,
so 127.0.0. becomes ::ffff:127.0.0.

Same problem here. The "prepend ::ffff:"-workaround works, but it's just a
workaround, not a solution.  

any update robbat ?

vapier: i haven't succeeded in tracing it in the source code :-(.
if you want to take a shot at it, you're welcome.

clearing up my bug tracking

*** Bug 69410 has been marked as a duplicate of this bug. ***

I ran into the same problem this morning... It seems that "+ipv6" is now common
standard. I upgraded from ucspi-tcp-r8 to -r9 last week, and that update broke
relaying. After forcing "-ipv6", things seem to work fine.

The ebuild should definately print out a warning like "if you're going to
compile tcpserver with IPv6, you'll have to change your tcprules file" or
similar.

You've to modifiy your tcprule-file. It now (with USE=ipv6) needs something
like this for IPv4 addresses:
::ffff:1.2.3.4:allow,RELAYCLIENT=""

This is by design.

it's crappy design

how hard is it to go 'oh, this looks like an IPv4 address' and then prepend ':ffff:' ?

Yes, I also see ipv6 is magically added to my "emerge info" output. I had to
put into make.conf "-ipv6" as of ucspi-tcp-0.88-r9.

vapier: It's not crappy design, it's by RFC. ::ffff:1.2.3.4 is defined in RFC
1884, section 2.2.3. We cannot fix this.

http://www.faqs.org/rfcs/rfc1884.html

RFC 1884, Section 2.2.3 says:       3. An alternative form that is sometimes
more convenient when         dealing with a mixed environment of IPv4 and IPv6
nodes is         x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values
        of the six high-order 16-bit pieces of the address, and the 'd's       
 are the decimal values of the four low-order 8-bit pieces of the        
address (standard IPv4 representation).  Examples:              
0:0:0:0:0:0:13.1.68.3               0:0:0:0:0:FFFF:129.144.52.38          or in
compressed form:               ::13.1.68.3               ::FFFF:129.144.52.38  
Please note the term "alternative form" in the first sentence. The RFC does not
require this syntax to be used, quite to the contrary (it says "sometimes", not
"often").  

i dont recall telling anyone to change a RFC

we're talking about the CONFIG FILE for ucspi-tcp ... a package that supports BOTH ipv4 and ipv6 ... internal CONFIG FILES have NOTHING to do with RFC's

USE=ipv6 doesnt say 'hey, i only want to support ipv6, screw ipv4' ... it says 'i want ipv6 support in addition to ipv4' ... last i checked, the a.b.c.d notation for IP addresses was ipv4

ucspi-tcp-0.88-ipv6.diff14.bz2 [1] has been released on 2004-05-26 [2]. A quick
glance over the changes suggests that the bug discussed here has been fixed:

>        if (!flagallownorules) drop_rules();
>      }
>      else {
> -      if (rules(found,fdrules,remoteipstr,remotehost,flagrem
> +      int fakev4=0;
> +      char* temp;
> +      if (!forcev6 && ip6_isv4mapped(remoteip))
> +       fakev4=1;
> +      if (fakev4)
> +       temp=remoteipstr+7;
> +      else
> +       temp=remoteipstr;
> +      if (rules(found,fdrules,temp,remotehost,flagremoteinfo
>        close(fdrules);
>      }
>    }
> @@ -240,7 +273,7 @@


Please update the patch.

[1] http://www.fefe.de/ucspi/ucspi-tcp-0.88-ipv6.diff14.bz2
[2] http://www.fefe.de/

Confirmation: The updated ipv6 patch fixes this bug.

Why is this bug assigned to net-mail? base-system, it's your package, I
wouldn't want to step on your turf, please take care of it, as it seems to have
a solution already.

Keeping net-mail on CC

it's with net-mail because when this bug first existed, they were the sole
managers of it

they're still the people with the know how (robbat2), no point in trying to
dump it onto base system :p

Created an attachment (id=50782) [edit]
Patch for ucspi-tcp-0.88-r9.ebuild to upgrade it to ucspi-tcp-0.88-r10.ebuild

cd /usr/portage/sys-apps/ucspi-tcp
cp ucspi-tcp-0.88-r9.ebuild ucspi-tcp-0.88-r10.ebuild
patch < .../path/to/this/patch
ebuild ucspi-tcp-0.88-r10.ebuild fetch digest
vi ChangeLog
repoman commit

in cvs finally.

*** Bug 82147 has been marked as a duplicate of this bug. ***