From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b)
Description of problem:
It would be beneficial if the alternate MTA, postfix, had IPv6 support
as well as sendmail provides this functionality natively.
Please accept the attached patch against the .spec of 2.0.16-2. It
allows at build time to enable IPv6 + TLS, IPv6 or just TLS as before.
Created attachment 96657 [details]
postfix.spec patch to enable ipv6+tls or ipv6 or behave as earlier
Created attachment 96658 [details]
updated patch, fixes dangling %%if
Seconded! IPv6 by default would be really cool.
What level of testing have you done with this patch applied? Are you
running in an ipv6 only environment? Can you confirm that the ipv6
patch has not broken anything for non-ipv6?
I've had Dean's IPv6 + TLS patches enabled pretty much since their
conception. I run them on both FreeBSD and RedHat Linux. I used to run
it on Solaris as well. Most systems are dual-stack, I've got one
that's IPv6 native only.
As far as I know it has broken once for me and that was with LMTP, in
version 1.5 back in 2002. I supplied a suggested patch for him,
changelog notes this.
I used to run the PLD IPv6 patch before this but it was always a pain
in the ass to merge Lutz's tls and the ipv6 patches back then. ;-)
I'm running Dean's patches since about half a year successfully without
any trouble (after some initial bugfixing regarding explicit bind()ing
to interfaces together with Dean - he's very responsive). You can take
a look at mail1/2.cluenet.de. I'm doing TLS and IPv6 (and both
together) all the time, especially between mail2 => mail1. Works like
The mail servers are pretty low-traffic though, around 1500-2000 Mails
per day, but relaying for proftpd.org Mailinglists, so dealing with a
lot of different remote MTAs. IPv6 SMTP session counts (with foreign
MTAs) vary from 10 to 30 per day.
Thanks for the input. I have updated the RPM to add support for Dean's
patches and based on the comments with respect to robustness I have
enabled the IPv6+TLS by default.
Thanks, this is great news. Perhaps one less package to build myself.
Just wondering.. is this going to hit Rawhide before FC2?
A FC2 build was done earlier today that contains this. I'm pretty sure
this will be reflected in rawhide but may take a day or so to
propagate. The package will be postfix-2.0.16-10.
You may want to note this RPM is in part a response to bug with ldap
interactions, it happens to include the ipv6 support, but you may want
to be aware that both postfix and sendmail who had been linking
against v2 of cyrus-sasl had to revert to v1 because ldap which
postfix also uses linked against v1. The library version
incompatibility was causing segmentation faults during ldap
operations. I do not believe there is any loss of functionality with
using v1 sasl except for saslauthd usage. The cyrus-sasl maintainer
need to push a new cyrus-sasl package with saslauthd enabled in v1 and
I have been in contact with him. If you are not using saslauthd you
should not be affected, if you are I would wait for a new cyrus-sasl
rpm. If you're using ldap you're probably aware of the problem and
would benefit from this latest rpm. Like I said earlier, ipv6 support
is tagging along for the ride on this rpm.
Won't this screw up people who are relying on sasldb2? AFAIK
cyrus-imapd in rawhide is linked against sasl2 and using the cyrus
sasldb store for passwords is now impossible.
According to the docs cyrus-imapd 2.1 and up support only SASL2. The
version in rawhide is 2.2.3.
The problem isn't with openldap, is it? According to their FAQ,
starting with OpenLDAP 2.1 only SASL2 is supported as well
<http://www.openldap.org/faq/data/cache/544.html>. Rawhide ships with
openldap 2.1.25. A quick check shows that openldap is linked against
% rpm -q openldap
% rpm -qR openldap|grep sasl
I'm sort of confused ;-) Thanks.
Sorry, you're not the only one who is confused. Fedora does not have
this problem, its unique to the enterprise product (RHEL3) which is
where my focus is because that the group I work in. It's especially
confusing because the spec files cannot identify the mismatch (its a
long story) so I get confused as to which set of rpm's are compatible.
But you are right, Fedora Core 2 does not have this restriction.
Sorry, the summary is its an issue for enterprise, not an issue for
Ok, good to know if/when I eval RHEL3. Thanks for explaining. :)