If the ipv6 use flag is specified with ucspi-tcp is compiled, an ipv6-related patch is applied which modifies tcpserver and hoses it's handling of environment variables and/or ipv4 addresses. This subsequently breaks qmail's ability to do selective relaying based on ipv4 addresses.
A little additional info: A normal /etc/tcp.smtp file might look like the following: 127.0.0.1:allow,RELAYCLIENT="" 10.0.0.:allow,RELAYCLIENT="" :allow This allows hosts in the 10.0.0.* network and from the localhost to relay (forward) email through this qmail server (relaying is allowed because the RELAYCLIENT variable is set). All other addresses are allowed to connect to and deliver mail to the server, but aren't allowed to forward through it. This file is then "compiled" with: tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp </etc/tcp.smtp You can then test the rules file with tcprulescheck: $ TCPREMOTEIP=10.0.0.1 tcprulescheck /etc/tcp.smtp.cdb rule 10.0.0.: set environment variable RELAYCLIENT= allow connection $ TCPREMOTEIP=192.0.0.1 tcprulescheck /etc/tcp.smtp.cdb default: allow connection This works whether or not the patch is applied. However, if you install this package with the ipv6 flag set, run qmail and then try and relay email through this system from 10.0.0.1, the mail will be rejected. If you compile this package without the ipv6 flag set, mail from 10.0.0.1 will be relayed correctly. I used the following to correct this on my system: /etc/init.d/svscan stop emerge -C ucspi-tcp env "USE-ipv6" emerge sys-apps/ucspi-tcp /etc/init.d/svscan start
Yet more info: If you specify "USE=-ipv6" and have the ssl flag set, you'll pick up a different patch when emerging ucspi-tcp. That patch fixes (or, at least, doesn't cause) the ipv4/RELAYCLIENT problem, but breaks qmail-qmqpd (it constantly respawns with shared-memory errors). 'env "USE=-ipv6 -ssl" emerge ucspi-tcp' seems to be the only way to get a version of this package that actually works with qmail.
all these bugs should be fixed in ucspi-tcp-0.88-r7, could you please check?
