Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 918527

Summary: incorrect 'sendmail.mc' line for specifying IPv6 MTA listener
Product: Red Hat Enterprise Linux 6 Reporter: Jaroslav Škarvada <jskarvad>
Component: sendmailAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.4CC: starlight
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 682792 Environment:
Last Closed: 2015-02-03 16:15:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 682792    
Bug Blocks:    
Attachments:
Description Flags
patch to allow BSD-like IPv6 connection listener none

Description Jaroslav Škarvada 2013-03-06 13:13:24 UTC
+++ This bug was initially created as a clone of Bug #682792 +++

Description of problem:

The commented example line 143 of '/etc/mail/sendmail.mc'
is written incorrectly.

Version-Release number of selected component (if applicable):

RPM sendmail-8.13.8-8.el5

The line in question is written

DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')

and should be written

DAEMON_OPTIONS(`Name=MTA-v4, Family=inet')dnl
DAEMON_OPTIONS(`Name=MTA-v6, Family=inet6')dnl

this is per an exchange with Claus Assmann at sendmail.org.

=========

Note however that this presents subsequent issues.

The line as originally written effectively specifies a single
IPv6 listener socket as the last two elements supercede the
first two elements.  Two problems derive from this:

1) Per Clauas, 'sendmail' is not presently intended to accept 
IPv4 connections on PF_INET6 listener sockets even though this 
is the convention with dual-stack OSs.  While it mostly works, a 
bug in the handling of DNSBL lists causes the syslog report for 
blocked connections to have the wrong value show in  arg2=.  
Instead of showing the return value from the DNSBL lookup
(e.g. 127.0.0.2), the IP address of the remote MTA is shown.
Probably other glitches exist.

2) If the correct form is used, Linux produces an error trying
to open the second, IPv6 listener on the global address for port
25.  This behavior is apparently the intended design in the Linux
kernel where it is expected that programs will listen for
both IPv4 and IPv6 connections from a single PF_INET6 listener
socket.  Once accepted, the type of a socket can be checked
and address-specific processing determined then.

Was able to work around this by specifying separate listeners
for each of IPv4 and IPv6 on each physical interface and
for the local loopback addresses.  For example:

DAEMON_OPTIONS(`Name=MTAv4_87, Family=inet, Addr=172.29.87.18')dnl
DAEMON_OPTIONS(`Name=MTAv4_88, Family=inet, Addr=172.29.88.18')dnl
DAEMON_OPTIONS(`Name=MTAv6_87, Family=inet6, Addr=2001:470:885c:87::18')dnl
DAEMON_OPTIONS(`Name=MTAv6_88, Family=inet6, Addr=2001:470:885c:88::18')dnl
DAEMON_OPTIONS(`Name=MTAv4_l, Family=inet, Addr=127.0.0.1')dnl
DAEMON_OPTIONS(`Name=MTAv6_l, Family=inet6, Addr=::1')dnl

However this is inconvenient.

--- Additional comment from Jaroslav Škarvada on 2013-03-06 14:09:53 CET ---

This doesn't seem to be resolved in Red Hat Enterprise Linux 6, cloning.

Comment 2 starlight 2013-03-06 15:06:02 UTC
Created attachment 706046 [details]
patch to allow BSD-like IPv6 connection listener

This patch applies the IPV6_V6ONLY socket option
to IPv6 listeners, the BSD behavior.  It was
written and tested for 8.14.6 but should
work for any recent version.

Allows 'sendmail' to maintain a dedicated
IPv6 wildcard-address socket separate
from the IPv4 wildcard-address listener.

This patch allows the corrected form
of 'sendmail.mc' that specifies separate
IPv4 and IPv6 listeners to function
correctly.

Comment 3 starlight 2013-03-06 15:13:51 UTC
Note that the patch has

   #if /* LINUX && */ NETINET6

because AFIK no #define presently exist
for Linux in the sendmail configuration.

IPV6_V6ONLY is Linux-specific.

Seemed best to allow the upstream
determine how to add it.  This patch
was submited to sendmail.org on
12/28/2012.

Comment 4 Jaroslav Škarvada 2013-03-06 15:16:19 UTC
(In reply to comment #3)
Thanks for the information.

Comment 5 RHEL Program Management 2013-10-13 23:51:29 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 6 Jaroslav Škarvada 2015-02-03 16:12:22 UTC
I see this too risky change for stable release. People may expect IPv6 listener to use dual stack and changing the behavior through the release may break their setups.

I think much safer and better approach is to fix the dual stack support. Is there any other known bug than the minor logging issue with DNSBL? I don't think that fixing it is worth the change/risk.

Also the proposed patch is not in upstream and other problems may arise from it. I am not against the concept (I would prefer option for switching from dual stack to IPv6 only), but I think that Rawhide is much proper place for such experiments. We can test the change there for upstream (if approved by upstream first) as we already did for other experimental change, but I do not recommend it for RHEL (at least for now).

Comment 7 RHEL Program Management 2015-02-03 16:15:53 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 8 starlight 2015-02-03 16:29:48 UTC
I reported this four years ago as a result of
a conversation with semdmail developer Claus
Assmann.

At the time his position was that sendmail is
developed on BSD and BSD semantics should apply,
but more recently he agreed that events have
overtaken this preference and also indicated
that too many installed configurations would
be broken by the change.

Don't know if the logging problem still
exists and I don't care.  Along with any
other latent bugs, it's your problem.
Build from upstream here and continue
to apply the patch.

Personally don't care either way about
the BSD behavior as it was always about
getting it to work properly.

I gave up years ago on attempting to be helpful
in any way to the open source community,
Red Hat in particular.