How about we kill /etc/aliases entirely.

move sendmail's aliases to /etc/mail/aliases
postfix's in /etc/postfix/aliases

and no longer will there be an /etc/aliases.

then you could have an /etc/aliases determined by alternatives.

How about other way around: /etc/mail/aliases and /etc/postfix/aliases
could be symbolic links to /etc/aliases.

That would allow you to switch between programs and aliases would
still stay same. This would also help keeping aliases consistent as
there is one file with actual data. File format is same for both programs.

I think that this approach would be more flexible.

The file format IS the same in the  default configuration, it does not
have to be. Postfix supports multiple filetypes for aliases.

I think separating the two is wiser anyway - application specific
aliases could crop up.

We are talking default configuration, if you need something special,
I am sure you are able to set another file where special Postfix
specific aliases reside. You can use multiple aliases files with
Postfix. I agree that possibly there is no need for
/etc/postfix/aliases symbolic link to /etc/aliases at all. 

I think common scenario is that somebody is migrating from Sendmail to
Postfix. In order to make migration as smooth as possible _default_
Postfix configuration should be compatible with Sendmail. Following
principle of least surprise I think global email aliases should be in
/etc/aliases, as it has been de-facto email aliases place for years.

When you get more experienced with Postfix you can define that global
simple aliases are read from /etc/aliases and other more special
aliases are read from other files or data sources.

/etc/aliases was moved from sendmail to setup so that postfix/exim
could use it - I assumed that postfix *was* using it by default.

/etc/aliases is all the same for sendmail, exim and postfix. There is
no need for application specific aliases files. 

Postfix is/was using /etc/postfix/aliases file to not require
sendmail. Now we have the global /etc/aliases in setup, and postfix
can use this file without requireing sendmail. Sendmail was providing
/etc/aliases in the past.

postfix-2.0.16-13 package comes with default in /etc/postfix/main.cf:
alias_maps = hash:/etc/postfix/aliases

Maybe this should be changed to:
alias_maps = hash:/etc/aliases

Moving bug to Postfix package...

Oh, and /etc/init.d/postfix need fixing too
...
start() {
        # Start daemons.
        echo -n "Starting postfix: "
        /usr/sbin/postalias /etc/postfix/aliases
        /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure
...
there should be then /etc/aliases instead. Aside note, it's funny that
you "eat" postfix error messages.

Wrong, postfix *does* use additional aliases that sendmail / exim
don't, and that's why it's always been configured to use a separate
aliases file. It's not because /etc/aliases was formerly provided by
sendmail....

The mail difference is that root must be aliased for postfix because
of permissions / privilege separation issues from postfix's design.

As a datapoint, SUSE ships both Postfix and Sendmail and has one alias
file /etc/aliases.

Postfix is the default MTA on SUSE.

As do many other distributions which ship Postfix and something else.
Debian, for example, uses /etc/aliases w/ all MTAs

The real issue is whether RH wants a policy of always aliasing root's
email to non-root by default, since that's what using a single file
for all would require....

And then, the issue of where to alias it *to*. Since, if you don't set
up another account....

That's the next political decision ;-)

Hmm, on second thought, that may have changed between Postfix 1 and
Postfix 2

RH's postfix aliases still sez:

# For various security reasons, postfix WILL NOT deliver mail as root, so
# ensure that the root alias is aliased to a HUMAN user, as otherwise
# mail may get delivered to the $default_privs user (nobody).

and then aliases root to "postfix" by default, but that might not
still be true.... I'll go check

Yep, it's still true with Postfix 2. Any external LDA gets run as the
user its delivering to. If it's delivering to a privileged user, the
LDA runs as $default_privs (ie, nobody), so non-aliased root users
can't get mail if you use an external LDA

If you use the Postfix 2 built-in LDA (instead of, say, procmail like
RH's sendmail configuration does), however, it can write to
/var/spool/mail/root (and presumably root Maildirs too).

In the past, RH has shipped Postfix with root aliased to postfix, and
using local (built-in LDA) instead of procmail. In keeping with that,
maybe the best solution would be just to skip the root aliasing, and
note in the release notes that it's no longer aliased, so enabling
procmail now requires more than just uncommenting the $mailbox_command
line in /etc/postfix/main.cf. That would solve the whole aliases and
root user email policy issue in the simplest way, unless I'm
overlooking any other reasons Postfix needed root to be aliased....

somehow I missed getting CC'ed on this, adding myself (as the rh
postfix maintainer)

So are you going to move aliases to /etc directory in
/etc/postfix/main.cf file?

By the way Postfix 2.1 is soon released, I hope you have read this:
http://www.porcupine.org/postfix-mirror/newdoc/PACKAGE_README.html

My initial inclination would be to have /etc/aliases be a sym link to
/etc/postfix/aliases and be managed by alternatives. This provides the
easiest migration between MTA's and is consistent with much of RH's
other MTA configuration. It has the downside of having two alias files
with the possibility of having them get out of sync if people switch.
I think this is bad and will be a source of confusion, one alias file
is better I think. O.K. but this has the downside of not delivering
root mail with postfix, but unless someone has defined a root alias as
a human being in /etc/postfix/aliases and people won't generally do
this unless they are postfix aware so I don't think the root alias
issue is enough rational to keep a separate postfix alias file.

In summary, I think I'm in favor of a single /etc/aliases file and
configue postfix use this. I think this would make most people most
happy with the least amount of confusion.

Do others agree?

Today is the freeze date for FC2 and if we're going to make this
change it would be good to get it into FC2 today. 

Although it would be good to have one aliases file and I think that is
the right technical and product choice I'm concerned about the impact
on customers if we make this change. Here is my thinking, correct any
errors and provide your comments.

Installations that have been running postfix expect the aliases file
to be /etc/postfix/aliases, not /etc/aliases. If we move this file I
don't know of a good way to indicate the change other than via release
notes, which we all know nobody reads. I don't think there is anything
we can do during rpm installation to call attention to the change.

Although making /etc/postfix/aliases a link to /etc/aliases as an
interim solution would be an option I'm not 100% sure that's a good
choice either because /etc/postfix/aliases on an upgrade will probably
be present as a real file and contain user modifed data. I suppose we
could treat it like a %config file, move to
/etc/postfix/aliases.rpm.save and then link /etc/postfix/aliases to
/etc/aliases. The gives us one config file, preserves the legacy file
which transparently appears as the single aliases file, all of which
is good, except that in the past these config files have been
"noreplace" so we're effectively back in the same boat, which is if
the sys admin is not aware that we've changed things behind his back
he is likely to get nailed by this change. He/she will spend several
hours debugging it, and then flame us. We can always respond, "Did you
read the release notes?", but I'm not sure in practice thats going to
mitigate the irritation.

The other choice, which has less impact is to use alternatives to
selectively point to postfix/sendmail specific alias file. This has
the advantage of being transparent to the customer, but might result
in data integrity problems if the wrong file is edited or the MTA is
switched. But I think this is less obnoxious to the end user than
having his previosuly working aliases mysteriously stop working on an
upgrade. This also mitigates the "root alias" issue because it
preserves a postfix specfic alias file.

In summary my suggestion is:

1) preserve /etc/postfix/aliases, leave main.cf and the init script alone

2) have alternatives manage /etc/aliases, when postfix is the selected
mta it points to /etc/postfix/aliases, when sendmail is the selected
mta /etc/aliases points to ? (some yet to be determined file).

Think this has the least impact and sets us up for a future where
there is only one alias file as people get used to it.

Comments? Thoughts? Suggestions? Flames?

Bill, does this play well with the setup package, which is what this
was originally filed against?

No, it really won't play well with setup owning /etc/aliases. It would
need to move back to sendmail.

Managing it via alternatives means that each MTA needs its own copy of
the aliases file, which would be a pain to keep in sync. Of course,
it's  not like the default alias file really changes that much.

Actually I didn't mean setup would own /etc/aliases, rather that it
would be managed by alternatives. The one issue that came to mind is
an order dependency, would the mta have been set by alternatives by
the time setup did anything that touched the alias file?

FWIW I'm not sure I agree the alias file rarely changes. What I do
think is a rare occurance is switching MTA's.

In theory we've passed the FC2 freeze by a few hours. I'm not sure
this issues has been thought out well enough to force the change into
FC2. Is it creating a significant issue that needs immediate
addressing as an FC2 blocker?

Well, the only thing we ship that touches the aliases file is mailman.

Kill /etc/postfix/aliases file.
alias_maps = hash:/etc/aliases

If postmaster can't figure that out, she/he shouldn't be allowed to
run mail server.

If we are going to go the route of merging postfix's and sendmail's
default alias file we should probably understand where they differ and
where they are the same. I'm attaching 3 files whose name should be
obvious as to what it lists.

Created attachment 98629 [details]
aliases only in postfix

Created attachment 98630 [details]
aliases only in sendmail

Created attachment 98631 [details]
aliases in both sendmail and postfix

Please remember, that we have three mta's: exim, postfix and sendmail. 
To move /etc/aliases back to sendmail is not a good decision: exim and
postfix would require an installed sendmail. Exim and sendmail are
using exaclty the same aliases file. 
If postfix needs additional rules, then use an additional aliases file
for it, but common rules can reside in /etc/aliases (not owned by any
mta).

Just merge all alias files to one.

More about required and suggested mailbox names:
http://www.ietf.org/rfc/rfc2142.txt

Thomas has a good point about a single aliases file. Files can only be
owned by one package, not multiple. Therefore some mta package has to
own the single /etc/aliases file and thus requires the installation of
that package even if the mta is not being used. This is not a good
design. I continue to believe what I advocated in comment #18 is the
preferred solution, which is: each mta has their own alias file,
/etc/aliases is a link maintained by alternatives to point to that
file.  If sys admins switch between MTA's there is the chance some
aliases will stop working. But any sys admin who is switching MTA's
around should be cognizant of the issues. It was Petri that said
earlie "If postmaster can't figure that out, she/he shouldn't be
allowed to run mail server."

Thomas and Bill, if you think this approach is O.K. just ACK, and I'll
edit postfix.spec so /etc/aliases is mananged by alternatives and when
postfix is configured /etc/aliases will point to /etc/postfix/aliases.

I believe this is the best approach. There are scripts/utilities out
there which make the assumption the alias file is /etc/aliases, this
way they can be ignorant of which MTA is configured.

Hey, setup provides /etc/aliases, how can you provide alternative for
that in postfix package? Doesn't that conflict? Where does setup
installed /etc/aliases file go when postfix is installed? I still
think that one plain /etc/aliases file managed by setup package is
best for all. This would be a good default... Hey, did you read this
bug from the start at all?

John, just a couple of things to keep in mind:

of the aliases in postfix, but not in sendmail, the only one with
functional effect is the root one. All the others are either good
ideas for standards / ease-of-use (admin, for example) or for
historical reasons (falken), but only the root one will have impact on
how people use the package or are able to use the package

of the aliases in sendmail, but not in postfix, they should probably
be in postfix if they're going to be in sendmail. If RH thinks that,
say, the squid package is better integrated by aliasing the squid
address to something likely to be read, that should probably be done
for sendmail, postfix, and exim, not just sendmail

regarding Comment #29, files can be owned by multiple packages, as
long as the file is identical in each package. I'm not sure what that
fact gains you, though, in this case....

To me, the important issues here for keeping it separate are that:

* RH has shipped postfix using /etc/postfix/aliases for a while, so
there's an established usage
* aliasing root for postfix facilitates some common configurations /
interoperations with other software, and that's a long-standing
practice on RH as well

For uniting them:

* there's the obvious benefits in terms of packaging standardization
and such for just having one standard /etc/aliases for all MTAs
* there's simplicity for admins in standardizing common config files

If you do decide it's necessary to keep them separate, I think using
alternatives is likely to cause more confusion than just having both
/etc/aliases (for sendmail / exim) and /etc/postfix/aliases (for
postfix). After all, having both is what happened on previous RH
releases if you had both sendmail and postfix installed, and people
seemed to manage. The only difference now is that it would happen even
if you had just postfix installed....

I think setup package should merge all system wide default aliases to
/etc/aliases file. Moving back to setup.

Aliases from the postfix-only list that are in rfc2142 merged as of
setup-2.5.34. I do not feel that missing 'foo' or 'falken' aliases are
a holdup. Back to postfix. :)

/etc/aliases contains now
  abuse:          root
  abuse:          postmaster

This is not allowed. Assigning to setup.

Fixed, just the alias to root is there now.

Fixed in rawhide in rpm postfix-2.1.5-2 or newer: Switched over to
/etc/aliases and /etc/aliases.db.

Thomas: Does this mean the default main.cf that gets installed will
now have the alias file as hash:/etc/aliases instead of
hash:/etc/postfix/aliases and main.cf is marked as config noreplace so
as not to break existing installations? I ask in particular because
when mailman is configured to use postfix as its MTA it automatically
updates aliases which default to /etc/postfix/aliases unless
overridden by a config file edit. I want to make sure this doesn't
break. By any chance is /etc/postfix/aliases sym linked to
/etc/aliaes? Does /etc/postfix/aliases continue to exist, or has it
been completely removed?

Yes, there is 'alias_database = hash:/etc/aliases' in main.cf which is
config noreplace in the spec file.

No, /etc/postfix/aliases is not sym linked to /etc/aliases. I have
removed it completely. If there is really a need for a symlink for
aliases (and aliases.db ?), then I can put it in.

I think Mailman should be fixed to not make that incorrect assumption.

O.K. great, as long as its config noreplace nothing should break. I
don't think there is a need for a symlink, that only prolongs the
transition period, better if there is no file there which will force
folks to notice the change.

I will alter the default postfix alias file in the mailman config to
reflect this new Red Hat standard.

But there is a change in the init script in the postalias call. It is
using /etc/aliases, now. 

I think alias_database could be used for this:

	echo -n "Starting postfix: "
	alias_database=$(postconf -h alias_database 2>/dev/null)
	alias_database=${alias_database##hash:}
	[ -z "$alias_database" -o ! -f "$alias_database" ] && {
	    failure
	    echo
	    return 0
	}
	/usr/sbin/postalias $alias_database
	...

Is this ok for you?

It's good idea, but where can you see error message, as there is
nothing in /var/log/maillog and you see just mysterious start up
failure. Printing error message on screen would be good idea.

At start of script #!/bin/sh could be changed to #!/bin/bash to be
more explicit.

FYI: I spoke in error in comment #37, the postfix alias file DOES NOT
appear in the mailman config. Rather it is the /usr/sbin/postalias and
/usr/sbin/postmap commands that appear in the mailman configuration
file and these have not changed. The mailman admin must edit
/etc/postfix/main.cf and add the mailman alias file to the postfix
alias_map variable. It just so happens this is the same postfix
variable that sets the postfix alias file path and although this
changed the change does not effect the mailman part of that variable
setting. Therefore there is nothing in mailman that needs fixing to
accomodate the change in the postfix alias file. I was wrong, sorry
for the red herring.

Created attachment 105348 [details]
patch for postfix-2.1.5-2.1, move alias_database in main.cf to correct place.

Fixed in rawhide in rpm postfix-2.1.5-2.2 or newer.

However the fix silently kills postfix on updates, since the old alias
file is removed *but* is still configured in main.cf since main.cf is
config(rpmsave)

Postfix will say it's running but won't deliver any mail

No, main.cf is config(noreplace):

%attr(0644, root, root) %config(noreplace) %{postfix_config_dir}/main.cf

Sory, that what I intended to write;)

Anyway the end result on a postfix upgrade is
- old main.cf is preserved (as it should be since it is often heavily
customized), pointing /etc/postfix/aliases*
- rpm removes the referenced alias file
- any mail delivery will now fail since postfix will consider it has
been asked to resolved addresses using /etc/postfix/aliases*, and this
is not available

There is a check in the newest version of postfix (postfix-2.1.5-2.2)
not to start if postalias is failing.

Ok, didn't test this one;), thanks

*** Bug 90653 has been marked as a duplicate of this bug. ***