Bug 202357

Created attachment 134464 [details]
proposed specfile patch

Ok, it looks like this likely came about when we rebased the package, so I
don't think this is a bug in the actual program, per-se, but more a packaging
problem.

The specfile has this in the %post section:

# upgrade configuration files if necessary
sh %{postfix_config_dir}/post-install \
	config_directory=%{postfix_config_dir} \
	daemon_directory=%{postfix_daemon_dir} \
	command_directory=%{postfix_command_dir} \
	mail_owner=%{postfix_user} \
	setgid_group=%{maildrop_group} \
	manpage_directory=%{_mandir} \
	sample_directory=%{postfix_sample_dir} \
	readme_directory=%{postfix_readme_dir} \
	upgrade-package

While not spelled out explicitly in the readme files per-se, the PACKAGE_README
file seems to indicate that this command is deprecated as of version 2.1. The
attached patch changes this to run postfix set-permissions
upgrade-configuration (which sort of looks like the correct way to do this in
new versions).

Does this look reasonable? We may want to make a similar change in Fedora as
well...

Hmm, actually, I may be wrong here. postfix upgrade-configuration... eventually
runs post-install, with similar args to what we're doing now. So it's not clear
to me that this patch will make any difference.

Graham, can you confirm whether you had actually tried restarting postfix before
running upgrade-configuration, and that the errors still continued?

I need to narrow down whether this problem was actually solved by running
postfix upgrade-configuration here, or whether the restart is what actually did it.

As I recall I did try restarting postfix - it contains an annoying misfeature in
that it negatively caches failures, meaning the only way to get mail flowing
again after a failure that has been corrected is to restart.

Restarting didn't make a difference, I only found the solution after hunting it
down with Google.

A second server in the secure mail cluster was also upgraded via up2date, and it
too stopped delivering mail to others in the cluster, implying that a restart
did occur during the upgrade. Running postfix upgrade-configuration and a manual
restart fixed that one.

QE ack for 4.5.

What have you configured for 2.1, what needs to be chnaged from 2.1 to 2.2?

Can you please post the 2.1 config and the changes to the new config after
postfix upgrade-configuration?

New pkgs(postfix-2.2.10-1.1.el4.*): 

Have tested TLS support in postfix as root and as normal user "testuser"
and it works in both cases - when email client uses "TLS, if available"
or "TLS" for secure connection:

1, First add TLS support to postfix:
   a, telnet localhost 25 =>
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 s390x-4as.z900.redhat.com ESMTP Postfix
EHLO s390x-4as.z900.redhat.com
250-s390x-4as.z900.redhat.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS   (<- TLS support added )
250 8BITMIME

2, Configure email client to use TLS:
   a, e.g in Mozilla - create new Email account,and click "View settings for 
   this account" link and in "SMTP Server:" dialog window check either
   "TLS, if available" checkbox or "TLS" checkbox for "Use secure connection:" 
   option

3, Successful TLS usage can be viewed in /var/log/mailog: 
. . .
Feb 16 04:43:08 s390x-4as postfix/smtpd[6554]: TLS connection established from
localhost.localdomain[127.0.0.1]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256
bits)
Feb 16 04:43:08 s390x-4as postfix/smtpd[6554]: E117A3C53E:
client=localhost.localdomain[127.0.0.1]
Feb 16 04:43:08 s390x-4as postfix/cleanup[6562]: E117A3C53E:
message-id=<45D57CAC.1060401@s390x-4as>
Feb 16 04:43:08 s390x-4as postfix/qmgr[6273]: E117A3C53E:
from=<testuser.redhat.com>, size=770, nrcpt=1 (queue active)
Feb 16 04:43:08 s390x-4as postfix/smtpd[6554]: disconnect from
localhost.localdomain[127.0.0.1]
Feb 16 04:43:14 s390x-4as postfix/smtp[6563]: E117A3C53E:
to=<jlieskov>, relay=int-mx1.corp.redhat.com[172.16.52.254], delay=6,
status=sent (250 2.0.0 l1G9hl3G021144 Message accepted for delivery)
Feb 16 04:43:14 s390x-4as postfix/qmgr[6273]: E117A3C53E: removed
. . . 
   
Didn't reproduce the "TLS malfunction" on old packages, just verified the
possible "TLS" support by new postfix packages -> leaving this one in ON_QA. 

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.

http://rhn.redhat.com/errata/RHBA-2007-0268.html