Bug 146732 - CAN-2005-0337 open relay bug in postfix ipv6 patch
Summary: CAN-2005-0337 open relay bug in postfix ipv6 patch
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: postfix   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Thomas Woerner
QA Contact: David Lawrence
Whiteboard: impact=low,public=20050131
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-01 02:46 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-16 14:56:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:152 low SHIPPED_LIVE Low: postfix security update 2005-03-16 05:00:00 UTC

Description Josh Bressers 2005-02-01 02:46:31 UTC
*** This bug has been split off bug 146731 ***

------- Original comment by Josh Bressers (Security Response Team) on 2005.01.31
21:44 -------

Affects:                Postfix with IPv6 patch on Linux
Credits:                Peer Heinlein


Postfix is an MTA written by Wietse Venema with security in mind. The
code has a great security record.
Dean Strik provides an IPv6 patch for Postfix releases.

To read IPv6 addresses and netmasks on Linux, the patch uses

Problem description

In some cases, the /proc/net/if_inet6 file is not available. The most
common reason being that Postfix runs chrooted without /proc mounted in
the chroot. A programming error in the IPv6 patch could result in
Postfix relaying emails to destinations that have IPv6 addresses for
their MX hosts.

If /proc/net/if_inet6 is not available, so Postfix does configure any
IPv6 addresses, the permit_mx_backup code erroneously returns success
for relay permissions to any IPv6 host.

The Postfix IPv6 patch documentation (IPV6_README) does note that

 - It is not currently supported to use Postfix network daemons
   (such as smtp and smtpd) chrooted on Linux systems without
   mounting the proc filesystem under /var/spool/postfix/proc
   This is because the proc filesystem is required on Linux to
   obtain the system's IPv6 address information.

So the configuration where /proci is NOT available to Postfix is not


The problem is specific to the Linux operating system in unsupported

Postfix does not come chrooted by default. The IPv6 patch does not
change this behaviour. Packagers/distributors however may have changed
this setting.

The permit_mx_backup setting is not used by default and must be
specificially configured by the Postfix administrator.

If Postfix cannot read the /proc/net/if_inet6 file and permit_mx_backup
is used, then Postfix will wrongly relay mail only to sites that have
IPv6 addresses (AAAA RRs in DNS) configured for at least one MX host.

Because of these four points, the impact of the relaying bug is very

Affected versions

Since the problem is in the IPv6 patch to Postfix, the version numbers
used here are those of the IPv6 patch. An administrator can query the
patch version number by issuing the command

        postconf tls_ipv6_version

Patch versions up to and including 1.25 are vulnerable to this problem.
Associated Postfix versions include Postfix 2.1.x and 2.0.x.

Postfix 2.2 snapshots with IPv6 included in the base Postfix
(2.2-20050111-nonprod and up) are NOT vulnerable to the problem.

IPv6 and TLS+IPv6 patch 1.26 provide a correction of the problem.


Peer Heinlein reported the problem to the IPv6 patch author.


Several workarounds exist for the problem:

 a) Do not run the Postfix smtpd program chrooted.
    This can be achieved by editing master.cf and putting an 'n' in
    the chroot column of the smtpd line;
 b) Make the /proc filesystem available under the chroot.


Upgrade the Postfix IPv6 patch to version 1.26 or higher. The patches
are available from


Comment 1 Mark J. Cox 2005-02-07 09:29:57 UTC
removing embargo

Comment 2 Mark J. Cox 2005-03-16 14:56:29 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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