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 attachment 50782 [details, diff] 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. ***
