Bug 186277 - CVE-2006-0058 Sendmail race condition issue
CVE-2006-0058 Sendmail race condition issue
Status: CLOSED ERRATA
Product: Fedora Legacy
Classification: Retired
Component: sendmail (Show other bugs)
unspecified
All Linux
high Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
rh73, rh90, 1, 2, 3
: Security
: 186927 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-22 12:35 EST by Marc Bejarano
Modified: 2007-03-27 00:42 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-04 20:28:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my sendmail config file. (7.22 KB, text/plain)
2006-03-24 15:02 EST, Kristo Kriechbaum
no flags Details
Logfile snippets (1.43 KB, text/plain)
2006-03-24 15:07 EST, Kristo Kriechbaum
no flags Details

  None (edit)
Description Marc Bejarano 2006-03-22 12:35:54 EST
Sendmail race condition issue

CERT has reported a race condition issue in sendmail which may lead to
arbitrary remote code execution.

CERT has assinged this issue the name VU#834865

this is the FL version of bug 184465
Comment 1 David Eisenstein 2006-03-22 15:41:29 EST
From CERT VU#834865[1]:

The Problem

Sendmail contains a race condition caused by the improper handling of
asynchronous signals. In particular, by forcing SMTP server to have an I/O
timeout at exactly the correct instant, the attacker may be able to execute
arbitrary code with the privileges of the Sendmail process.

More information is available in the Sendmail version 8.13.6 release page[2]
and the Sendmail MTA Security Vulnerability Advisory[3].

Versions of Sendmail prior to 8.13.6 are affected.

II. Impact
A remote, unauthenticated attacker could execute arbitrary code with the
privileges of the Sendmail process. If Sendmail is running as root, the
attacker could take complete control of an affected system.

III. Solution
Upgrade

This issue is corrected in Sendmail version 8.13.6[2].

Patches to correct this issue in Sendmail versions 8.12.11[4] and 8.13.5[5]
are also available.

Refer to the Sendmail MTA Security Vulnerability Advisory[6] for steps to
reduce the impact of this vulnerability.

References:
 1. CERT VU#834865:                <http://www.kb.cert.org/vuls/id/834865>
 2. Sendmail 8.13.6 release page:    <http://www.sendmail.org/8.13.6.html>
 3. Vulnerability Advisory:    <http://www.sendmail.com/company/advisory/>
 4. ftp://ftp.sendmail.org/pub/sendmail/8.12.11.p0
 5. ftp://ftp.sendmail.org/pub/sendmail/8.13.5.p0
 6. http://www.sendmail.com/company/advisory/#mitigation

Also:
  * CVE-2006-0058: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058
Comment 2 David Eisenstein 2006-03-22 16:14:22 EST
Red Hat issued RHSA-2006-0264 and RHSA-2006-0265 today for these issues.
<http://rhn.redhat.com/errata/RHSA-2006-0265.html>  RHEL 2.1
<http://rhn.redhat.com/errata/RHSA-2006-0264.html>  RHEL 3 & 4.

All Legacy distros are affected.  Affected packages for each distro:
  * RHL 7.3:  sendmail-8.11.6-27.73
  * RHL 9:    sendmail-8.12.8-9.90
  * FC1:      sendmail-8.12.10-1.1.1
  * FC2:      sendmail-8.12.11-4.6
  * FC3:      sendmail-8.13.1-2

In order to fix RHL7.3, RHL9 and FC1, we will need to upgrade those versions
to sendmail-8.12.11 in order to apply the patch available from upstream.  Or
we might just want to re-spin the RHEL 2.1 package, at least for RHL 7.3.
Perhaps we can respin the RHEL 3 package for RHL9, FC1, & FC2.

My suggestion for FC3 is that we just implement sendmail-8.13.6 instead of
upgrading to sendmail-8.13.5 and patching.


Here's the text from RHSA-2006-0265 advisory (for RHEL 2.1):

"A flaw in the handling of asynchronous signals was discovered in Sendmail.
A remote attacker may be able to exploit a race condition to execute
arbitrary code as root. The Common Vulnerabilities and Exposures project
assigned the name CVE-2006-0058 to this issue.

"By default on Red Hat Enterprise Linux 2.1, Sendmail is configured to only
accept connections from the local host. Therefore only users who have
configured Sendmail to listen to remote hosts would be able to be remotely
exploited by this vulnerability.

"In order to correct this issue for Red Hat Enterprise Linux 2.1 users, it
was necessary to upgrade the version of Sendmail from 8.11 as originally
shipped to Sendmail 8.12 with the addition of the security patch supplied
by Sendmail Inc. This erratum provides updated packages based on Sendmail
8.12 with a compatibility mode enabled. After updating to these packages,
users should pay close attention to their sendmail logs to ensure that the
upgrade completed sucessfully."
Comment 3 David Eisenstein 2006-03-22 16:17:44 EST
I take back my suggestion for FC3.  RHEL 4 released sendmail-8.13.1 today,
presumably patched for this problem, so we could just use those sources.
Comment 4 Jeff Sheltren 2006-03-22 18:09:49 EST
David, thanks for the research.  I'll look into backporting RHEL patches, and
hopefully post updated packages very soon.
Comment 5 Bradley 2006-03-22 22:07:59 EST
Note that the sendmail patch doesn't work on rh73 if you build with ssl support,
because the SSL version that comes with that doesn't provide SSL_get_[rw]fd.

Does anyone know what the 'gcc296' patch in the RHEL2 sendmail package is meant
to fix? changelog doesn't point to anything specific, and we've been running
stock 8.12.11 on rh7.3 (compiled with gcc296) for the last year or so without
issues.
Comment 6 Jesse Keating 2006-03-22 22:47:36 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Packages for sendmail problem CVE-2006-0058 Sendmail race condition issue

RHL7.3 package pulled directly from RHEL2.1.  7.3's sendmail was too
old for the patch, so like RHEL2.1 did, pulled in the newer version
but built it into compat mode.

RHL9, FC1, and FC2's package are all the same, based on FC2's sendmail
with the patch applied, and FC1 and RHL9s packages provide /etc/alias
and RHL9's is built w/out -fpie (not available in the compiler).

FC3's package just adds the patch.

All packages add BuildRequires: groff so that man pages will build.

These should get extra testing due to version upgrades necessary to
apply patches.

http://geek.j2solutions.net/rpms/legacy/sendmail/

9442f310b50ab21962feb69004324752a705e598 
./7.3/SRPM/sendmail-8.12.11-4.22.8.legacy.src.rpm
03e40f075a5fe6793f8e7b5dc1fad24d8aeca411 
./7.3/i386/sendmail-devel-8.12.11-4.22.8.legacy.i386.rpm
ccd79b18310db610cfeeff97a3a807347888250f 
./7.3/i386/sendmail-8.12.11-4.22.8.legacy.i386.rpm
c904cd0037dead018d212be03f6bce2507af25e0 
./7.3/i386/sendmail-cf-8.12.11-4.22.8.legacy.i386.rpm
8d4a3bc5d33d35955d8d2c536cf8717cb69d304e 
./7.3/i386/sendmail-doc-8.12.11-4.22.8.legacy.i386.rpm
921719465dd9184e161787abce8023d6ffc633ff 
./fc1/SRPM/sendmail-8.12.11-4.25.legacy.src.rpm
662be990c4dc5559e35fe07222fb061618b2ec4f 
./fc1/i386/sendmail-devel-8.12.11-4.25.legacy.i386.rpm
58a67f3403be4bfcd4e69a4ddd4d57d56d95f41f 
./fc1/i386/sendmail-doc-8.12.11-4.25.legacy.i386.rpm
a62936d6e7bf86d74d083ef49416264ae320d023 
./fc1/i386/sendmail-8.12.11-4.25.legacy.i386.rpm
f47c4b5c4e283b6c3d2afe7dc703e4e231aeebd7 
./fc1/i386/sendmail-cf-8.12.11-4.25.legacy.i386.rpm
053dd6ee565d3e071951c205b013f3e19c17c511 
./fc3/SRPM/sendmail-8.13.1-3.legacy.src.rpm
95fa2ca8970fbdd441fe483d27262412911a38eb 
./fc3/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm
7642014c3a37da2c971165e383f1b3a8d0536f1a 
./fc3/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm
1372277299112c57827c392c1ab2a974de44c570 
./fc3/i386/sendmail-8.13.1-3.legacy.i386.rpm
c539ab544982ec1163381bdea9db23291956a728 
./fc3/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm
59b713db0c3ab1899f9c0c91e3fd9188d97455c7 
./fc3/x86_64/sendmail-devel-8.13.1-3.legacy.x86_64.rpm
49be60337bf663c136be4abc0909e5e9831782e9 
./fc3/x86_64/sendmail-cf-8.13.1-3.legacy.x86_64.rpm
58b2a98e7524ff5bf2675c8a3a47726dce920cee 
./fc3/x86_64/sendmail-8.13.1-3.legacy.x86_64.rpm
46025d459f9724e9c77730486e0adf009692485b 
./fc3/x86_64/sendmail-doc-8.13.1-3.legacy.x86_64.rpm
a3166b6b0227f450498561acd80042636019aff1 
./9/SRPM/sendmail-8.12.11-4.24.legacy.src.rpm
0b61665414349d5b885e50dbf5649edfab079eca 
./9/i386/sendmail-doc-8.12.11-4.24.legacy.i386.rpm
77cc98ee8bd520b8b220b99254871ac57d3e4455 
./9/i386/sendmail-cf-8.12.11-4.24.legacy.i386.rpm
69efec9b25ab3d48bdd180d71070abbdc497ed0b 
./9/i386/sendmail-devel-8.12.11-4.24.legacy.i386.rpm
f36924313332e8fc85b11cfe5fdc263b9db48179 
./9/i386/sendmail-8.12.11-4.24.legacy.i386.rpm
7d9135551126681633b5999947bc69cf0fcb2d4c 
./fc2/SRPM/sendmail-8.12.11-4.26.legacy.src.rpm
4a7f960685eac046f2cc60c8cbd0a569ec7e64f2 
./fc2/i386/sendmail-cf-8.12.11-4.26.legacy.i386.rpm
c4c0fc021fc6d912ceaa1ce4af2183dcba306252 
./fc2/i386/sendmail-doc-8.12.11-4.26.legacy.i386.rpm
3ee7c42846137c5217bc80a22d56a92c8a2b301f 
./fc2/i386/sendmail-devel-8.12.11-4.26.legacy.i386.rpm
fb8928621816392580ebee32b31d7518483adf65 
./fc2/i386/sendmail-8.12.11-4.26.legacy.i386.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIhsd4v2HLvE71NURAqbeAKC7h+1fg48iOxS1UtpdXpbokvwHRwCfagp2
Eqx59MizSOr4cCtmw4Iv9Sc=
=2H4y
-----END PGP SIGNATURE-----
Comment 7 Jesse Keating 2006-03-22 23:28:12 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

7.3 packages respun for:

- - Use right name in changelog
- - enable alternatives

a9c43e6e124e89b5583a096b3c5b378e8552a66c 
7.3/SRPM/sendmail-8.12.11-4.22.9.legacy.src.rpm
3c8b76e1180fef2eafda9479a9cce7a2350c6617 
7.3/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm
aa639e9c26e2e24c0fd2c447c824a4f9eca310fb 
7.3/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm
b5e18e0536c7c5fbdd721d2a74995c98b18eaf29 
7.3/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm
60fe825ab8e0a1c376db3bd4567ff468c4e0fa67 
7.3/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIiUr4v2HLvE71NURAmshAKCANyAYQOfSUIzRvEO1RXYsEfVHFgCgtedk
g6inFg6Sy8smr1aQdcuVTLA=
=WEQ5
-----END PGP SIGNATURE-----
Comment 8 Jesse Keating 2006-03-22 23:33:30 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Er... wrong packages.

Here are the right ones:

a9c43e6e124e89b5583a096b3c5b378e8552a66c 
7.3/SRPM/sendmail-8.12.11-4.22.9.legacy.src.rpm
48adbe1fa8ea9a5661d072322679cd4187d406b6 
7.3/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm
da92a27da0ebf9179925c64ed6e77f283a200dfd 
7.3/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm
c9dbb555a482f42cccbcda4d2bde99525a4f87f8 
7.3/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm
52c4a6d18122c7edfaa20795edf2914fa350ffda 
7.3/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIiZd4v2HLvE71NURAgFKAJ9KInXyQ8Nwb0ZI2ECVHgH+jbRgvQCgvyqY
1iwOILP6mUn1w0ZxfdWvuVY=
=T2Yn
-----END PGP SIGNATURE-----
Comment 9 Jesse Keating 2006-03-23 00:38:42 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rebuilt RHL9 for
- - correct alias file
- - use sasl1
- - BuildReq gdbm-devel

Rebuilt FC1 for
- - correct alias file

1fcea0854577e577a65307f554b779fe5e1d895e 
9/SRPM/sendmail-8.12.11-4.24.1.legacy.src.rpm
e7327cc244fee93808d8e4d2b0ad442fcdac9d5b 
9/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm
680eda3987ea2f6eb48d067c340220d34062fdb5 
9/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm
99f3014e97bbfcdac59b0d5ee8def509ad5650b0 
9/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm
de2c2dfc0fb63fd07e68a9c8c8d9f1172c9e7855 
9/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm
7fa8de1a72b4b3b1baab1b4d0247be25b2490383 
fc1/SRPM/sendmail-8.12.11-4.25.1.legacy.src.rpm
df92215793717ae80e7d867037de263acb0d0c5f 
fc1/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm
002073c4317f9af5fdb5bbbb5e606abd8ad58b47 
fc1/i386/sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm
aedbbedbdea17d9bf95cac16ef5323c8068ace2e 
fc1/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm
973223a7106ab14a693dbb379aeb49ffacca2802 
fc1/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIjWf4v2HLvE71NURAvnOAJ4lduFvP/lEFEBOzPVF0RT3KMucpQCfbUMf
eSdLTXAiuKMpYHATC+f7p8w=
=o6Xv
-----END PGP SIGNATURE-----
Comment 10 Marc Deslauriers 2006-03-23 00:51:38 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did QA on Jesse's packages:

a9c43e6e124e89b5583a096b3c5b378e8552a66c
7.3/SRPM/sendmail-8.12.11-4.22.9.legacy.src.rpm
1fcea0854577e577a65307f554b779fe5e1d895e
9/SRPM/sendmail-8.12.11-4.24.1.legacy.src.rpm
7fa8de1a72b4b3b1baab1b4d0247be25b2490383
fc1/SRPM/sendmail-8.12.11-4.25.1.legacy.src.rpm
7d9135551126681633b5999947bc69cf0fcb2d4c
fc2/SRPM/sendmail-8.12.11-4.26.legacy.src.rpm
053dd6ee565d3e071951c205b013f3e19c17c511 fc3/SRPM/sendmail-8.13.1-3.legacy.src.rpm

- - rh73 package matches RHEL21 with appropriate changes
- - fc2 package matches previous release with upstream patch added
- - fc1 package matches fc2 with appropriate changes
- - rh9 package matches fc2 with appropriate changes
- - fc3 package matches previous release with upstream patch added

+PUBLISH


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIjldLMAs/0C4zNoRAncVAJ0WOFX62XYV53OlYNijcD83hXkoQQCfbIbl
7bfFApHclwXQTGvcn1Yr4Z8=
=q3JN
-----END PGP SIGNATURE-----
Comment 11 Tom Yates 2006-03-23 10:55:20 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

e7327cc244fee93808d8e4d2b0ad442fcdac9d5b
sendmail-8.12.11-4.24.1.legacy.i386.rpm680eda3987ea2f6eb48d067c340220d34062fdb5
sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm
99f3014e97bbfcdac59b0d5ee8def509ad5650b0
sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm
de2c2dfc0fb63fd07e68a9c8c8d9f1172c9e7855 sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm

i note i got these packages direct from jesse's server
(geek.j2solutions.net) rather than via yum.  that said, they install OK.
creating a new cf file via m4 works OK.  mail comes and goes OK.

+VERIFY RH9

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIsYZePtvKV31zw4RAl6iAJ9DVcd2ZP7VWzO9Pkmeb9tKNmgO/QCghAed
QtcfB5sda4EiL9q5/RTmTl4=
=uT5A
-----END PGP SIGNATURE-----
Comment 12 Marc Bejarano 2006-03-23 11:51:01 EST
i'm impressed by the speed at which this is moving forward, but it still sucks
that the FL team didn't have the advance notice that all the other "vendors"
have.  anyone know how to get a rep from FL onto the vendor-sec list (or
whatever it's called) so that we can prepare fixes to release at the same time
everybody else does?

had this been an easier hole to exploit, there would be a LOT of compromised
RH73 and RH9 boxes out there right about now :(
Comment 13 Jesse Keating 2006-03-23 11:58:18 EST
I did have advance notice and I was on vendor-sec.  However like you said this
was a hard hole to exploit, and we were in the middle of upgrading our build
system.  Had this been an easier hole to exploit, we would have had test
packages ready prior to the public announcement.
Comment 14 David Eisenstein 2006-03-23 13:21:49 EST
This bug was pushed to updates-testing at 02:50am EST 2006-03-23 (11:50pm PST
2006-03-22) by Jesse.  Needs verify.

The updates-testing announcement can be found here:
<http://www.redhat.com/archives/fedora-legacy-list/2006-March/msg00171.html>

Thanks, Jesse!!
Comment 15 David Eisenstein 2006-03-23 13:39:40 EST
Ah, Tom!  Thanks for your verify in comment #11!  :-)

(I rpm-build-compared the files you tested with the files pushed to updates-
testing, and they contain exactly the same binaries and files.)
Comment 16 Bradley 2006-03-23 15:53:31 EST
The first paragraph of the announcement refers to 'An updated tar package'; that
should presumably be 'Updated sendmail packages'
Comment 17 Jesse Keating 2006-03-23 15:56:47 EST
Indeed heh (;
Comment 18 Bradley 2006-03-23 16:56:24 EST
Maybe something in the message about checking the .cf file, too? the rh7 8.11
.cf file used with 8.12 ends up having annoying features like ident enabled by
default.
Comment 19 Curtis Doty 2006-03-23 16:57:55 EST
The rh7.3 package includes a sendmail.mc that says to use make to rebuild
sendmail.cf. However, the included Makefile is missing the %.cf target.

Workaround is to remember the old way: m4 /etc/mail/sendmail.mc >/etc/sendmail.cf
Comment 20 Jesse Keating 2006-03-23 17:01:04 EST
Comment #18 and comment #19 both seem like good things to include in the release
announcement.  Thanks for the feedback.
Comment 21 Jeff Sheltren 2006-03-23 17:57:36 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for 7.3 packages:
80f02c886b020e6d6ef17389c22c8b530fb05a48  sendmail-8.12.11-4.22.9.legacy.i386.rpm
285816881a55fe4b8a74fee48205c8ceedaee5e5  sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm
b4154a342e7747d980b7acaf352649ddc1dcc40d 
sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm
81a36048a12cc5c08a8e93490dde6817c402ae54 
sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm

Packages install cleanly
Sendmail restarted ok
Sent multiple messages through sendmail without any problems

RH73 VERIFY++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEIykVKe7MLJjUbNMRAqFeAJsHW0SS/53dio1jyBS4DuFzJjtJ4QCgiC6W
rK6VZU3kcucTgYxcnAb+uFw=
=4feC
-----END PGP SIGNATURE-----
Comment 22 Jeff Sheltren 2006-03-23 18:06:54 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for FC1 packages:
df880ab03eaeb2f82be81bee96c28392984a4b86  sendmail-8.12.11-4.25.1.legacy.i386.rpm
729bcaeb1269b65728f014bbbedb5c1a54a5158e  sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm
256ff91b67ecc7680a5f2fb97b3b32142bb80d18 
sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm
65725c811c4c7eede9f88c006a13c15e458d353f 
sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm

Packages install cleanly
Sendmail restarted ok
Sent multiple messages through sendmail without any problems

FC1 VERIFY++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEIyrtKe7MLJjUbNMRApwKAKC4IeXxEldtoz7RiNoICrwlChVE9ACcC3L6
yh4o+qlC68LInzy9k9R+mQo=
=bl0b
-----END PGP SIGNATURE-----
Comment 23 David Eisenstein 2006-03-23 19:26:08 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA on FC1 packages:

df880ab03eaeb2f82be81bee96c28392984a4b86__sendmail-8.12.11-4.25.1.legacy.i386.rpm
729bcaeb1269b65728f014bbbedb5c1a54a5158e__sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm
256ff91b67ecc7680a5f2fb97b3b32142bb80d18__sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm
65725c811c4c7eede9f88c006a13c15e458d353f__sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm

  * Packages install just fine
  * Did rpm-build-compare on main sendmail package.  Differences are
    reasonable.  sendmail 8.12.11 requires openldap and openssl, which
    8.12.10 did not; but I don't see that as a problem.
  * Starts up fine.
  * Was able to send and receive several emails just fine.  No burps.
  * Was able to use the sendmail-cf files to do "make sendmail.cf" in the
    /etc/mail directory.  Worked just fine.
  * I concur that it is a good idea to emphasize that folks check their
    .cf files.

 VERIFY++ FC1
 
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFEIz1Lxou1V/j9XZwRAs5yAKCRcJgU5NaSu54IYVtfygXz6QigdgCg7pU/
UqTHbwM7tpTu5gu2zPw0Vtc=
=KPCT
-----END PGP SIGNATURE-----
Comment 24 Marc Deslauriers 2006-03-23 19:32:43 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I installed the FC3 package:

95fa2ca8970fbdd441fe483d27262412911a38eb
fc3/i386/sendmail-cf-8.13.1-3.legacy.i386.rpm
7642014c3a37da2c971165e383f1b3a8d0536f1a
fc3/i386/sendmail-doc-8.13.1-3.legacy.i386.rpm
1372277299112c57827c392c1ab2a974de44c570 fc3/i386/sendmail-8.13.1-3.legacy.i386.rpm
c539ab544982ec1163381bdea9db23291956a728
fc3/i386/sendmail-devel-8.13.1-3.legacy.i386.rpm

- - Installed OK
- - Restarted OK
- - Received and delivered mail

+VERIFY


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEI0AYLMAs/0C4zNoRAqKXAJ9uAveY49KhkdhqVhz6hJaMDTKBQQCgvwcs
kFQ6ZUCkFlCSBOIl3QRuPbE=
=fy8K
-----END PGP SIGNATURE-----
Comment 25 Jeff Sheltren 2006-03-23 19:41:59 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for FC2 packages:
7e44b02696338832e2dfc0057aeb58c98511d0d2  sendmail-8.12.11-4.26.legacy.i386.rpm
d159f0c92bd530799b75341d18b5b2cbe5aa5a0a  sendmail-cf-8.12.11-4.26.legacy.i386.rpm
8421bfb2eb2f2b3fddb35e905fdcfecd0fb8088c 
sendmail-devel-8.12.11-4.26.legacy.i386.rpm
b659d2733afa3d6f4df840a395c6eae3a5c07d50  sendmail-doc-8.12.11-4.26.legacy.i386.rpm

Packages install cleanly
Sendmail restarted ok
Sent multiple messages through sendmail without any problems

FC2 VERIFY++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEI0FqKe7MLJjUbNMRAnlrAKC1z81NN1o/+lelrGJt9GdTgsTJPACgnfGK
dfj7tQovOZR9r9ea9inyTd4=
=jY03
-----END PGP SIGNATURE-----
Comment 26 David Eisenstein 2006-03-23 19:45:36 EST
Is there any other testing we need to release?
Comment 27 Pekka Savola 2006-03-23 22:05:08 EST
Comments #18 and #20 seem troubling to me.  It seems inappropriate if the
software upgrade just simply overwrites the config file, and requires manual
intervention to fix the configuration.

Would this be easily fixable without serious caveats?
Comment 28 David Eisenstein 2006-03-23 22:36:15 EST
I don't believe that the software upgrade simply overwrites the config. file.
It didn't on my install on FC1.

The RHL7.3 sendmail.spec file has these lines:
%config(noreplace)              /etc/sendmail.cf
%attr(0644,root,root) %config(noreplace)        /etc/mail/sendmail.mc
%config(noreplace)              /etc/mail/local-host-names

... and many more like it in the %files section.

I think the concern in comment #18 was that upgrading using the new 8.12.11
sendmail software in combination with the *old* 8.11.6 config file has some 
perhaps unanticipated side effects...
Comment 29 Bradley 2006-03-23 22:50:50 EST
Right - it doesn't replace it. It seems to work anyway, though.
Comment 30 Russell Odom 2006-03-24 05:04:25 EST
On RH9, since upgrading from 8.2.8 (the previous FL update) this morning, the
users on my local network are unable to send mail. In /var/log/maillog I see
messages like:
Mar 24 09:36:47 biscotti sendmail[21526]: k2O9acSr021526: clares.zolv.com
[192.168.0.141] (may be forged): possible SMTP attack: command=AUTH, count=4
Mar 24 10:03:53 biscotti sendmail[22105]: k2OA3kCj022105: clares.zolv.com
[192.168.0.141] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during
connection to MTA

I can send mail from the local machine OK.

[root@biscotti mail]# rpm -qa | grep sendmail
sendmail-8.12.11-4.24.1.legacy
sendmail-cf-8.12.11-4.24.1.legacy
sendmail-devel-8.12.11-4.24.1.legacy
[root@biscotti mail]# uname -a
Linux biscotti.zolv.com 2.4.20-43.9.legacy #1 Sat Apr 30 19:18:42 EDT 2005 i686
i686 i386 GNU/Linux

I'm not sure if this is something in my local config (I can post config files if
necessary) or a problem with the release. Anyone have any ideas?

I'm going to roll back to 8.12.8 for now.
Comment 31 Jeff Sheltren 2006-03-24 05:21:54 EST
Regarding comment #30 I think it must be something in your config.  I just
installed the packages on a RH9 machine and I'm able to telnet to port 25 (from
a remote machine) and send messages that way.  Did you change your configs when
you upgraded, or are you still using the same config files?
Comment 32 Russell Odom 2006-03-24 05:47:16 EST
Same (customised) config files as before the update (I made sure the .cf files
were definitely rebuilt after the update, but no joy).

In /etc/mail/access this line enables relaying from our network:
192.168.0       RELAY

Here's a few excerpts from /etc/mail/sendmail.mc that may be relevant (let me
know if I can post anything else that might help):
define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

For users, the symptom of the problem is that users (mostly using Thunderbird)
get a box asking them for their password when sending mail, but their password
is not accepted. Since people use laptops from home and the office, SMTP
authentication is enabled in the clients.

Interestingly, I started getting error e-mails like the following from Webmin's
service monitor (running on same machine) as soon as I'd upgraded, which could
be related:

From: root@biscotti.zolv.com (Cron Daemon)
To: root@biscotti.zolv.com
Subject: Cron <root@biscotti> /etc/webmin/status/monitor.pl
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

Error
-----
No mail program was found on your system!
-----

I have rolled back to 8.12.8 from
http://download.fedoralegacy.org/redhat/9/updates/i386/ and all is once again
working (with the same config).
Comment 33 Kristo Kriechbaum 2006-03-24 14:29:40 EST
I am having an issue similar to comment #30.  Using the updated packages for
FC1 (8.12.11-4.25.1.legacy) I am unable to send mail using TLS.

I get errors like:
robotics saslauthd[27723]: do_auth         : auth failure: [user=klk]
[service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
robotics sendmail[28132]: Password verification failed

in /var/log/messages.  I am using the exact same config files as before the
update.  I downgraded to 8.12.10-1.1.1 and everything works as expected.

I can attach my config file or other logs if that would help.
Comment 34 Jesse Keating 2006-03-24 14:47:26 EST
seems that sasl might not be working right.  I'm not entirely sure how to
further investigate, are you absolutely certian that there was no config change
between the two versions?
Comment 35 Kristo Kriechbaum 2006-03-24 15:02:43 EST
Created attachment 126665 [details]
my sendmail config file.
Comment 36 Kristo Kriechbaum 2006-03-24 15:04:43 EST
I am absolutely certain that the config file is the same.

I just checked again to make sure:
- started with 8.12.10-1.1.1 (FC1)
- backed up sendmail.mc just in case...
- mail is sent with no problems.
- upgraded to 8.12.11-4.25.1.legacy.  Only sendmail, -doc, and -cf were
upgraded.  No other packages changed.
- copied backed-up sendmail.mc to /etc/mail, ran "make", restarted sendmail.
- mail can't be sent, mail client (kmail) says: The server responded: "5.7.0
authentication failed"
- downgrade back to 8.12.10-1.1.1
- mail sends just fine.

So the only thing changing is sendmail.  I have made an attachment with my
config file.  I'll also make one with snippets of /var/log/maillog and
/var/log/messages when things fail/work.
Comment 37 Curtis Doty 2006-03-24 15:06:53 EST
Just a WAG... If you had hacked up or removed the old /etc/pam.d/smtp, the
upgrade would have installed the new one which is now named
/etc/pam.d/smtp.sendmail.

Also, /etc/mail/certs/is not valid on some of the older distros. You need to go
back to /usr/share/ssl/certs/ or wherever...
Comment 38 Kristo Kriechbaum 2006-03-24 15:07:37 EST
Created attachment 126666 [details]
Logfile snippets

Snippets from /var/log/messages and /var/log/maillog.  It may indicate that the
problem is on the client side, but nothing on the client is changing between
tests.
Comment 39 Alexander Dalloz 2006-03-24 15:27:05 EST
Kristo, check your /etc/sysconfig/saslauthd. It seems to use MECH=pam, which is
ok. Then check to have /etc/pam.d/smtp, which should be a symlink target from
origin /etc/pam.d/smtp.sendmail. The content has to be

#%PAM-1.0
auth       required     pam_stack.so service=system-auth
account    required     pam_stack.so service=system-auth

Make sure saslauthd is running.
Comment 40 Alexander Dalloz 2006-03-24 15:33:19 EST
RHL 7.3 update

Why is the Sendmail binary linked against SASLv2? RHL 7.3 came with SASL 1.5 only.

$ ldd sendmail.sendmail | grep sasl
        libsasl.so.7 => /usr/lib/libsasl.so.7 (0x006ea000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x0076d000)

Did someone test the update for 7.3 to be working with SMTP AUTH?
Comment 41 Jesse Keating 2006-03-24 15:51:14 EST
Which sendmail package for 7.3 did you install?  Can you give me a sha1sum of
it?  The specfile used explicitly enables saslv1 not v2.
Comment 42 Kristo Kriechbaum 2006-03-24 16:30:17 EST
In reference to Comment #39, everything is as you specified.
Comment 43 Alexander Dalloz 2006-03-24 16:41:21 EST
Jesse

http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm
$ sha1sum sendmail-8.12.11-4.22.9.legacy.i386.rpm
80f02c886b020e6d6ef17389c22c8b530fb05a48  sendmail-8.12.11-4.22.9.legacy.i386.rpm

I do not run RHL 7.3 myself but on comp.mail.sendmail was a report by someone
complaing the update requiring saslauthd. So I investigated the package by
defalting it using rpm2pio. `ldd /var/tmp/usr/sbin/sendmail.sendmail' shows what
I pasted in #40.
Comment 44 Jeff Sheltren 2006-03-24 18:07:32 EST
I can't reproduce the sasl issue on a 7.3 box:

$ rpm -q sendmail
sendmail-8.12.11-4.22.9.legacy
$ ldd /usr/sbin/sendmail.sendmail | grep sasl
        libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40106000)
Comment 45 Curtis Doty 2006-03-24 22:16:16 EST
As an FYI aside, the postuninstall script uses readlink but the rpm does not
reflect the dependency on tetex. I just update another old rh73 system with
minimalist packages and saw the error:

/var/tmp/rpm-tmp.77878: readlink: command not found
Comment 46 Pekka Savola 2006-03-25 10:15:56 EST
Yeah, the packages seem to be broken on so many levels, though some of it caused
by RHEL...

The packages will need to be re-rolled, IMHO.  Due to the alternatives bug,
sendmail doesn't even restart anymore (as /usr/sbin/sendmail no longer exists,
the init script just exists), and hence the daemon is still vulnerable.

d9c001d8a34f11f528ff6be2a9f8dd15818caf40  sendmail-8.12.11-4.22.9.legacy.src.rpm

With rpm-build-compare.sh, I note the following problems in RHL73 just by
looking at the spec file for 10 minutes:
 - as mentioned, readlink doesn't exist, so scripts fail in two places
 - alternatives is "no" though earlier specfile enabled it (through 'errata >= 73')
 - hesiod-devel buildprereq went missing

Some other broken stuff but doesn't affect RHL73: if old_setup is "no" (RHL73 is
yes), aliases file is sourced from **/etc/***

+%if "%{old_setup}" == "yes"
 Source3: aliases
+%else
+Source3: /etc/aliases
+%endif
Comment 47 Marc Deslauriers 2006-03-25 11:54:47 EST
Wow...something happened there somewhere. The rh73 packages were specifically
rebuilt to include alternatives, but somehow ended up in updates-testing with
alternatives turned off.
Comment 48 Marc Deslauriers 2006-03-25 12:01:16 EST
Ok, here's the problem. The binary packages and the source package in RH73
updates don't match, although they have the same release number. The binary
packages have alternatives in with a relevant "- Enable alternatives" entry in
the changelog. The source rpm is from a previous build that omits the
alternatives modification. Somehow, the wrong source rpm got pushed to
updates-testing.
Comment 49 Marc Deslauriers 2006-03-25 22:01:41 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The FC2 and FC3 seem fine.

Here are fixed packages for rh73, rh9 and fc1 to QA. They should take
care of the issues people are having with the previous upgrades.

7.3 changelog:
* Sat Mar 25 2006 Marc Deslauriers <marcdeslauriers@videotron.ca>
8.12.11-4.22.10.legacy
- - Added hesiod-devel to BuildRequires
- - Reverted to previous alternatives files
- - Removed new triggers
- - Modified instructions in sendmail.mc

9 changelog:
* Sat Mar 25 2006 Marc Deslauriers <marcdeslauriers@videotron.ca> -
8.12.11-4.24.2.legacy
- - Reverted statistics file to /etc/mail
- - Reverted to previous alternatives files

fc1 changelog:
* Sat Mar 25 2006 Marc Deslauriers <marcdeslauriers@videotron.ca> -
8.12.11-4.25.2.legacy
- - Reverted statistics file to /etc/mail
- - Reverted to previous alternatives files
- - Added gdbm-devel to BuildRequires

7.3:
c57140069224f247c71bbdb87a9b4320d0b65a8d  sendmail-8.12.11-4.22.10.legacy.i386.rpm
c834e9b1089a1a6b7796209f0ce0e2fa87ca60b7 
sendmail-cf-8.12.11-4.22.10.legacy.i386.rpm
eac9d007dffbbcf7efb3e025e680407a737008f6 
sendmail-devel-8.12.11-4.22.10.legacy.i386.rpm
24a25b9e22ffb6bf32895d2af99f28c83062883e 
sendmail-doc-8.12.11-4.22.10.legacy.i386.rpm
http://turbosphere.fedoralegacy.org/logs/redhat-7.3-core/65-sendmail-8.12.11-4.22.10.legacy/i386/

9:
f2fe962096c186bbd45ae5494951aae3042b9d68  sendmail-8.12.11-4.24.2.legacy.i386.rpm
d576a57e9e5e5d023c162a37590ecf55c24bbba2  sendmail-cf-8.12.11-4.24.2.legacy.i386.rpm
d0805a6b17baf313756480b0ca8db614959b286f 
sendmail-devel-8.12.11-4.24.2.legacy.i386.rpm
46cd5e43f83f456bcdef06df638ee55ce70d7afc 
sendmail-doc-8.12.11-4.24.2.legacy.i386.rpm
http://turbosphere.fedoralegacy.org/logs/redhat-9-core/66-sendmail-8.12.11-4.24.2.legacy/i386/

1:
0fd91369abb6a9202046bfef39e60dbb50d453fa  sendmail-8.12.11-4.25.2.legacy.i386.rpm
4b4571061a33a151bfd9b4541a7895b286028112  sendmail-cf-8.12.11-4.25.2.legacy.i386.rpm
225ab50da0fb3153293f9a51de70cbe06c202bcc 
sendmail-devel-8.12.11-4.25.2.legacy.i386.rpm
90d0e9b1c2438ee7fb1e0d06f69cdb858a695273 
sendmail-doc-8.12.11-4.25.2.legacy.i386.rpm
http://turbosphere.fedoralegacy.org/logs/fedora-1-core/67-sendmail-8.12.11-4.25.2.legacy/i386/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEJgXqLMAs/0C4zNoRAmP0AKDCzbWF098q5GyLch9aSqxeDOKaFQCgjTNa
c6EIqAka2wvV3Tf/5utHpEo=
=7BEG
-----END PGP SIGNATURE-----
Comment 50 Pekka Savola 2006-03-26 03:39:22 EST
Hmm.. I didn't quite understand the reason why you reverted to the old
alternatives stuff: you seem to be partially simulating the case where
alternatives is "no", even though it was already enabled in RHL73 so many years ago?

If old_setup is set to "no", the packages still depend on the contents of
/etc/aliases on the build machine (when it runs $RPM_BUILD_ROOT/usr/bin/makemap)
on RHL9.  That's not cool.  (There's a lot of other nastiness in RHL73/RHL9 wrt
old_setup -- old_setup=no is not correct on RHL73 while old_setup=yes is not
correct on RHL9..)

Perhaps on RHL73, removal of the readlink could be replaced with:
 ls -l /etc/alternatives/mta | sed s":.* /:/:" | sed s":.* -> ::"

 .. where the first sed strips out everything except the filename and path,
and the second sed reads the symlink if it exists.

+       daemon /usr/sbin/sendmail $([ "x$DAEMON" = xyes ] && echo -bd) \
+           $([ -n "$QUEUE" ] && echo -q$QUEUE)

doesn't pass at the end $SENDMAIL_OPTARG, so if you do reload(), do you
lose arguments if you defined any?

On RHL9, the defined CERT dirs don't exist under /etc/mail/. 
/usr/share/ssl/certs do though, but weren't enabled.  I guess it's bad practice
to point to cert dirs that don't exist, maybe dnl these from .mc?

RHL9 supports sasl2, but it wasn't enabled in the previous RHL9 sendmail update
in 2003; it's not clear to me as I don't use SASL whether we should keep the old
practice or upgrade sendmail to use sasl2.

In RHL9, smmsp is no longer confTRUSTED_USER.  Apparently RH removed this in Sep
2003, so I guess it's OK.




Comment 51 Marc Deslauriers 2006-03-26 09:48:49 EST
The reason everyone is having problems is because the sendmail update we
released contains three more files that were assigned to alternatives. When the
package gets upgraded, sendmail is already configured in the systems
alternatives system, so the three new symlinks don't get created. There are
three possible ways around this problem, 1- remove sendmail from alternatives
during the upgrade before adding it back in to force alternatives to re-create
the symlinks, 2- try and get alternatives to recreate the symlinks with a funky
postun trigger, 3- revert the three files to their previous behaviour with the
previous sendmail release. After much thought, it appeared the simplest way was
to revert to the way the previous sendmail package worked.

Starting with FC2, sendmail doesn't provide the /etc/aliases anymore. The
old_setup flag indicates in the spec file if we want an aliases file or not. It
should be turned on for rh73, rh9 and fc1. I'm not sure why you say it's turned
off in rh73, or why you say it shouldn't be turned on in rh9. Please explain.

The readlink section of the spec file was to upgrade sendmail in RHEL21. This is
unnecessary with our rh73 upgrade.

The initscript doesn't pass the $SENDMAIL_OPTARG in the reload function as it
doesn't actually start sendmail, it just sends it a -HUP. No need to pass
arguments there.

The defined CERT dirs under /etc/mail don't exist on any release. The included
makecert.sh command creates them for you, as documented in the .mc file.

For rhl9, the previous sendmail didn't use sasl2. There may have been a reason
for that. It would be better to use sasl1, as the previous release did.



Comment 52 Pekka Savola 2006-03-26 13:17:41 EST
OK, I guess the second option would have been easier if readlink had been
available on RHL73.. But the functional difference is probably not significant
enough to change to 2) and use an alternative to readlink..

Sorry for confusion, yes, old_setup is enabled for both rhl73 and rhl9.  What I
meant to say is that the non-default option (in this case "no") is broken on
both src.rpm's.  It's arguable whether this is more than a cosmetic problem or a
way to shoot yourself in the foot..
Comment 53 Bishop Clark 2006-03-26 16:24:16 EST
sendmail-8.12.11-4.24.2.legacy (RH9):

sendmail.mc
-dnl define(`STATUS_FILE', `/etc/mail/statistics')dnl
+define(`STATUS_FILE', `/var/log/mail/statistics')dnl
 - 8.12.8-9.90 sendmail.mc says /etc/mail/statistics
 - 12.11-4.24.2.legacy sendmail.mc says /var/log/statistics
   - and activates it!
 - rpm-qlp of 12.11-4.24.2.legacy CONTAINS /etc/mail/statistics
 - recommend revert back to old location

-dnl define(`confCACERT_PATH',`/usr/share/ssl/certs')
-dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')
-dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')
-dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
+define(`CERT_DIR',`/etc/mail/certs')
+define(`confCACERT_PATH',`CERT_DIR')
+define(`confCACERT',`CERT_DIR/cacert.pem')
+define(`confSERVER_CERT',`CERT_DIR/cert.pem')
+define(`confSERVER_KEY',`CERT_DIR/key.pem')
+define(`confCLIENT_CERT',`CERT_DIR/cert.pem')
+define(`confCLIENT_KEY',`CERT_DIR/key.pem')
 - changes locations
 - changes CACert filename
 - changes server/client key filename
 - activates bogus config
 - recommend keep or DNL the new lines, but revert the locations back to the
older supplied locations.  Activating the config with new locations is
introducing either a bug or a feature, and either may not be recommended.

This package DOES appear to fix bug 186579, but ships with immediate concerns of
its own.



Comment 54 Bishop Clark 2006-03-26 18:12:08 EST
sendmail-8.12.11-4.25.1.legacy (FC1) contains the same random change to the
sendmail.mc.  I don't have an FC2 system,but I notice the FC3 packages *don't*
include any new features/changes, and I'm definitely for the idea of keeping the
MCs very similar to their normal formats -- not only because they'll be the same
as originally released for all RH-derived distros released in almost a decade,
and not only because it's an added feature of the type I've been told we don't
like to add into updates, but also because I've learned the headache of
supporting even a change as innocuous in appearance as this one.

sendmail-8.12.11-4.25.1.legacy also do the Alternatives work in %post when
upgrading from the next most recent version:
[root@fishy /]# ls -l /etc/pam.d/smtp* /usr/lib/sendmail*
-rw-r--r--  1 root root 116 Mar 23 00:22 /etc/pam.d/smtp.sendmail
lrwxrwxrwx  1 root root  16 Mar 26 17:41 /usr/lib/sendmail.sendmail ->
../sbin/sendmail

I'd suggest 8.12.11-4.25.1 fails QA based on the random feature with the
location change, and the alternatives concern.
Comment 55 Marc Deslauriers 2006-03-26 22:44:39 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In response to comment 53, here are updated packages for RH9 and FC1:

- - Reverted statistics file path in mc file
- - Reverted CERT paths in mc file
- - Don't enable statistics by default

rh9:
6ee6122a976ff1aa32d784cb817caf9aa53daa97  sendmail-8.12.11-4.24.3.legacy.i386.rpm
0b690b7dfd72d962c6a44897fb826ddc3c73e699  sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm
7648da4c91b79a035ea7cad78e58eeff73c04b2e 
sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm
aa9cd92fa507433ed612f1b6889277f4fd46bdcd 
sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm
fab24bdbf1d46fb7d488de2fab60ed0da5dabaeb  sendmail-8.12.11-4.24.3.legacy.src.rpm
http://turbosphere.fedoralegacy.org/logs/redhat-9-core/68-sendmail-8.12.11-4.24.3.legacy/

fc1:
a5e3f8c6aa59aa48ce78fb96cc03601173ba9f98  sendmail-8.12.11-4.25.3.legacy.i386.rpm
2a2299397fd86ca7c06ebfe2c4ca047385ee2988  sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm
ed85bed5db216b77949ddf4ac6e0721ae7688a52 
sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm
544a83a270864e118be0f98064eebaff1c783b10 
sendmail-doc-8.12.11-4.25.3.legacy.i386.rpm
e39214f5c41d727fe776ea36c37673ebb31ec7fa  sendmail-8.12.11-4.25.3.legacy.src.rpm
http://turbosphere.fedoralegacy.org/logs/fedora-1-core/69-sendmail-8.12.11-4.25.3.legacy/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEJ2GkLMAs/0C4zNoRArnrAJ4g5amzMQknJhQ3TmJwdg5L1ybX1QCgkEkw
qXgPGk3DCXc464i4tNdtx7M=
=JDxT
-----END PGP SIGNATURE-----
Comment 56 David Eisenstein 2006-03-27 11:10:04 EST
*** Bug 186927 has been marked as a duplicate of this bug. ***
Comment 57 Eric Jon Rostetter 2006-03-27 15:51:19 EST
One of my complaints is it is overwriting my /etc/init.d/sendmail file (RHL 9).
Seems like we should patch the spec file:

555c555
< %config %{initdir}/sendmail
---
> %config(noreplace) %{initdir}/sendmail

This would create a /etc/init.d/sendmail.rpmnew if there is a custom script,
which is what I expect personally.  I don't think there are any changes to
the init script which are needed for the update; rather they just make it
more robust and add a reload() and so on.  I think leaving the custom script
in place will work fine, though I've not exhaustively researched the scripts.

Anyone else agree or disagree?
Comment 58 Eric Jon Rostetter 2006-03-27 16:00:50 EST
We might want to mention in the release note that the new /etc/init.d/sendmail
script as well as the new /etc/mail/Makefile now rebuild the sendmail.cf file
from the sendmail.mc file...  This means if someone has been editing/customizing
their sendmail.cf file without modifying/customizing the sendmail.mc file,
then installing our package and rebooting, or installing our package and
doing a "make all" in /etc/mail, will remove all their customizations and
perhaps shutdown their mail services (and I don't think there is any way
to recover without backups).

This is kind of a critical point as some people do hand-edit sendmail.cf without
ever touching sendmail.mc, perhaps even deleting sendmail.mc which our script
might then replace with a stock one, and this could really bite them...
Comment 59 Marc Deslauriers 2006-03-27 18:15:12 EST
In response to comment #58:

I'm not sure why you think the behaviour has changed. The previous rh9 sendmail
release does it also. Am I missing something?
Comment 60 Eric Jon Rostetter 2006-03-27 18:35:40 EST
Because I was confusing versions?  7.3 doesn't do this, 9 does; and your
updates seem to keep that the same way.  Sorry for the noise, although it
still wouldn't hurt to mention it even though it is "expected" behaviour...

In any case, I stand corrected; the rpms are doing exactly what the RH rpms
did for both 7.3 and 9.
Comment 61 Jeff Sheltren 2006-03-27 19:42:14 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for updated 7.3 package (comment #49):

b719f1d31d54a3326aa718faced760f1f854807f  sendmail-8.12.11-4.22.10.legacy.src.rpm

sendmail Source matches previous package
Only other source change is to sendmail-redhat.mc where the comments
are changed to reflect how to build the cf file

Spec file changes look good and should correct problems people
are experiencing with alternatives


QA for updated RH9 package (comment #55):

fab24bdbf1d46fb7d488de2fab60ed0da5dabaeb  sendmail-8.12.11-4.24.3.legacy.src.rpm

sendmail source matches previous package
Other source changes are:
removing makecert.sh
included .mc uses /etc/mail/statistics instead of /var/log/mail/statistics
included .mc uses /usr/share/ssl/certs instead of /etc/mail/certs
Those all seem like valid changes to me as it reverts to previous expected behavior.

Spec file changes all look good (reverting to behavior of previous rh9 package)

RH73 PUBLISH++
RH9 PUBLISH++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEKIckKe7MLJjUbNMRAnsGAJ0XmGXjPVNsyKXrUfw7I3RzH2PkdQCffGk2
vJOrVSrXb/RkflMAUXxJ4vg=
=qwoJ
-----END PGP SIGNATURE-----
Comment 62 Pekka Savola 2006-03-28 00:22:43 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
QA w/ rpm-build-compare.sh:
 - source integrity good
 - spec file changes minimal from the already-updated version,
   large from the original FC1 version but should be OK..
 - no patch changes from the previous release, should be OK from the
   original FC1 version.
 
+PUBLISH FC1
 
e39214f5c41d727fe776ea36c37673ebb31ec7fa  sendmail-8.12.11-4.25.3.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
 
iD8DBQFEKMl7GHbTkzxSL7QRAiifAJ41HBH2xvSlAGh7WlKNbSwWqNz6tQCgpZKA
iKspNi2OdTpM8818oBAgH+k=
=Cw/J
-----END PGP SIGNATURE-----
Comment 63 Marc Deslauriers 2006-03-28 19:34:32 EST
Updated packages for rh73, rh9 and fc1 were pushed to updates-testing
Comment 64 Jeff Sheltren 2006-03-28 20:17:45 EST
If some of the people who were having problems with the previous packages could
test out the new packages in updates-testing, that would be very helpful!
Comment 65 Kristo Kriechbaum 2006-03-29 16:11:11 EST
I can report that the FC1 package in updates-testing (8.12.11-4.25.3.legacy)
seems to work fine for me.  I do not have the problem first noted in comment #33.
Comment 66 Troed Sångberg 2006-03-30 05:50:30 EST
Seconded. On RH9 with legacy updates I got the secure SMTP auth problem after 
the published update. Updating from updates-testing solved it.

No other changes were made manually either before or after the update between it 
and the one in updates-testing.

I've just done some quick checks, mainly that auth now works and that my 
virtusertable is functioning. Hopefully there are no "hidden" problems.
Comment 67 Tom Yates 2006-03-30 08:23:02 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02
sendmail-8.12.11-4.24.3.legacy.i386.rpm6b7b437bb58ac9f805185ae992da9a157a0d755d
sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm
ae48cf1d3a5d8f5bfc789a408de392fe27e84b73
sendmail-devel-8.12.11-4.24.3.legacy.i386.rpm
4571b20f603bf6f90558aa09107f5b2ae17e8111 sendmail-doc-8.12.11-4.24.3.legacy.i386.rpm

installs OK.  mail come and goes OK, although as in comment #11 i reiterate
that i generate my own sendmail.cf by hand, which i again did before
verifying the functionality.

+VERIFY RH9

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEK9yxePtvKV31zw4RAv48AKCFQKc6WOrOBkqiGqssTgdvuPvdwwCgtIve
j2ET8esmXC0crpE/1eKoIFA=
=IpwP
-----END PGP SIGNATURE-----
Comment 68 Pekka Savola 2006-03-30 10:21:24 EST
I'd say the FC1 comment is good enough to decrease the timeout to one week
unless issues come up.. :-)
Comment 69 Eric Jon Rostetter 2006-03-30 14:22:20 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
++VERIFY for RHL 9
 
Downloaded packages:
9f1caeadce45e2922f6bc29ea0f4e7bce4e26d02
sendmail-8.12.11-4.24.3.legacy.i386.rpm
 
6b7b437bb58ac9f805185ae992da9a157a0d755d
sendmail-cf-8.12.11-4.24.3.legacy.i386.rpm
 
Package installed fine on a single machine.  All previous problems I saw
on that machine are now fixed.
 
Vote for release for RHL 9.  ++VERIFY
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
 
iD8DBQFELDFD4jZRbknHoPIRAtgKAJ4mNOUFHnA6wx4T1jTD42ey6bZ5FgCfeGlz
1uqibmD5mAuN2JSWLhGb+1s=
=gUWv
-----END PGP SIGNATURE-----
Comment 70 David Eisenstein 2006-04-03 19:51:02 EDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Test of FC1 sendmail-8.12.11-4.25.3.legacy.i386.

3f6edb4bdcd42cca1f01fce9482d3ac10b56f530__sendmail-8.12.11-4.25.3.legacy.i386.rpm
7aaa9743d312b7ebc95baa83e186acaa267f6915__sendmail-cf-8.12.11-4.25.3.legacy.i386.rpm
dfabadaa764d471b2c5963547643ca4bbe5ca0e7__sendmail-devel-8.12.11-4.25.3.legacy.i386.rpm
121433ec0c71a163993cf2a94f33fa67df786b11__sendmail-doc-8.12.11-4.25.3.legacy.i386.rpm


   * sha1sums and gpg signatures ok

   * upgrading from original FC1 sendmail (8.12.10), seems to install well:
      - Pre-install scriptlet worked fine.
      - Package file Installation -- Config files:
         . left /etc/aliases alone (I'd modified it), built new
           /etc/aliases.db;
         . replaced /etc/mail/access (I'd not changed it);
         . replaced /etc/mail/Makefile (I'd not changed it);
         . skipped /etc/mail/local-host-names (I'd modified it);
         . left my /etc/mail/sendmail.cf alone, but created the packaged
           file as sendmail.cf.rpmnew;
         . same for /etc/mail/sendmail.mc;
         . replaced /etc/mail/submit.cf (I'd not changed it);
         . replaced /etc/mail/submit.mc (I'd not changed it);
         . replaced /etc/mail/trusted-users (I'd not changed it);
         . replaced /etc/pam.d/smtp (I'd not changed it);
         . replaced /etc/rc.d/init.d/sendmail (which it would do whether
           or not I changed it);
         . replaced /etc/sysconfig/sendmail (I'd not changed it);
         . kept (or replaced) the symlink /usr/lib/sendmail -> 
           ../sbin/sendmail

      - Post-install scriptlet appeared to work fine.  No surprises.
      - Alternatives system appears to be set up correctly, reverted to the
        alternatives used in sendmail-8.12.10; no missing alternative files.
      - Pre-uninstall scriptlet does nothing ([ 1 = 0 ]), which is correct,
        as this is a sendmail update/upgrade.
      - Erase of sendmail-8.12.10 packaged files skipped all files, since
        they all were replaced by the 8.12.11-4.25.3 package.  Good.
      - Post-uninstall scriptlet restarted sendmail 'condrestart' (which
        only stops and starts sendmail if it is already running).  Good.

   * Looks like previous issues have been taken care of:
      -  /etc/pam.d/smtp   not missing (auth should work)
      -  /usr/lib/sendmail not missing
      -  /usr/share/man/man8/sendmail.8.gz not missing
      -  in new sendmail.mc file, status file left at /etc/mail/statistics
         and left undefined ('dnl'); and certificate directory reverted to
         /usr/share/ssl/certs and also left undefined.

   * It works.  Was able to send message from FC1 box to a hotmail account
     and receive mail from hotmail to the FC1 box's sendmail.

  VERIFY++ FC1 sendmail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFEMbNvxou1V/j9XZwRAg+jAJsHDFqU/vXc0KuyJ3Pg2L4zlT7zWwCdH3Zv
Os/+BIGY6IOz6ZvbvQzc8PI=
=+AUH
-----END PGP SIGNATURE-----
Comment 71 Pekka Savola 2006-04-04 06:59:01 EDT
FWIW, sendmail works fine on RHL73 as well, but as I recompiled it, I didn't
want to write it as a verify vote.. 

The timeout is due today in any case, so this is going to be released in any case..
Comment 72 Marc Deslauriers 2006-04-04 20:28:07 EDT
Packages were released to updates.
Comment 73 Russell Odom 2006-04-10 06:34:31 EDT
A bit late I realise, but I just tested on RH9 and all is working correctly
(none  of the problems in comment 30 and comment 32). Thanks to all concerned!

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