Bug 112491 - patch: rfe: ipv6 support
Summary: patch: rfe: ipv6 support
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: postfix (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: All Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-21 01:52 UTC by Kaj J. Niemi
Modified: 2007-04-18 17:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-20 22:03:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
postfix.spec patch to enable ipv6+tls or ipv6 or behave as earlier (1.96 KB, patch)
2003-12-21 01:52 UTC, Kaj J. Niemi
no flags Details | Diff
updated patch, fixes dangling %%if (2.12 KB, patch)
2003-12-21 02:04 UTC, Kaj J. Niemi
no flags Details | Diff

Description Kaj J. Niemi 2003-12-21 01:52:16 UTC
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.

Comment 1 Kaj J. Niemi 2003-12-21 01:52:57 UTC
Created attachment 96657 [details]
postfix.spec patch to enable ipv6+tls or ipv6 or behave as earlier

Comment 2 Kaj J. Niemi 2003-12-21 02:04:28 UTC
Created attachment 96658 [details]
updated patch, fixes dangling %%if

Comment 3 Daniel Roesen 2004-01-09 16:44:59 UTC
Seconded! IPv6 by default would be really cool.

Comment 4 John Dennis 2004-01-12 22:20:02 UTC
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?

Comment 5 Kaj J. Niemi 2004-01-12 22:42:42 UTC
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. ;-)

Comment 6 Daniel Roesen 2004-01-12 23:26:47 UTC
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
a charm.
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.

Comment 7 John Dennis 2004-01-20 22:03:57 UTC
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.

Comment 8 Daniel Roesen 2004-01-20 23:06:50 UTC
Thanks, this is great news. Perhaps one less package to build myself.

Comment 9 Kaj J. Niemi 2004-02-17 21:47:25 UTC
Just wondering.. is this going to hit Rawhide before FC2?

Comment 10 John Dennis 2004-02-17 21:59:51 UTC
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.



Comment 11 Kaj J. Niemi 2004-02-17 22:16:41 UTC
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.

Comment 12 Kaj J. Niemi 2004-02-17 22:29:48 UTC
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.

Comment 13 John Dennis 2004-02-17 23:02:32 UTC
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

Comment 14 Kaj J. Niemi 2004-02-17 23:11:57 UTC
Ok, good to know if/when I eval RHEL3. Thanks for explaining. :)

Note You need to log in before you can comment on or make changes to this bug.