Server 4.0 upgrade, Mail no longer finding alias

You add mail aliases in Server by right-clicking the user in the Users list and selecting Advanced Options from the popup menu.

To create mail aliases for local users (not network users), edit the file

/Library/Server/Mail/Config/postfix/aliases

as desired, then run

sudo newaliases -C /Library/Server/Mail/Config/postfix

and restart the Mail service.

Login aliases and email aliases seem to be treated differently in server 4.0, at least for network users.

To add alternative email addresses, select "edit user" and add alternative email addresses directly where indicated. No need to restart mail.

This updates /Library/Server/Mail/Config/postfix/virtual_users behind the scenes.

Hi Sandorferenczy,

OS X Server updates seem to regularly break aliases .... I posted problem with then back when Server 3 was introduced and have once more had problems with them in Server 4.x

To try to get to the bottom of the problems, I did some testing using band new VMWare Fusion Yosemite 10.10.3 install and then updated this with Server 4.1 install.

Here are various findings:

1. By default an OS X install includes the postfix mail system that sits behind OS X Server (www.postfix.org).

2. This install has the following aliases related files included:

1. "/etc/aliases" - which is actually a soft link to "postfix/aliases"

2. "/etc/aliases.db" - which is the hash map created from "/etc/aliases" source file

3.. This default install has all the main postfix configuration files in the directory: "/etc/postfix"

1. The postfix startup configuration file: "/etc/postfix/main.cf" has all the alias related directives commented out

4. On installing OS X Server the following additional and duplicate postfix configuration file area is created.

1. "/Library/Server/Mail/Config/postfix"

2. This new configuration directory also contains the aliases files: "aliases" & "aliases.db"

3. And most importantly the launch script: "/System/Library/LaunchDaemons/com.postfix.master.plist"

4. If you open the property list (.plist) file you will see the command line arguments provided to start the mail system

5. The new OS X Server is started based on the launch script and this can be validated by doing:

1. "ps -ax | grep postfix"

2. If mail server is running you should see "<pid-number> master -f /Library/Server/Mail/Config/postfix/main.cf"

3. This shows that the mail server has been started with the configuration from the OS X Server install

4. Now you can start to work out what is going on....

6. All this is important as if you reading the man pages included if has examples that assume you are working with a standard configuration.

So if you do a command "postconf config_directory" command it might tell you that postfix is using the config in "/etc/postfix", when in fact it is not...

7. So by default with OS X Server mail (I know this is true for Server 3 & 4) the config used is the one in "/Library/Server/Mail/Config/postfix"

1. Now that you are identified the config location, the following are the key items to look for in "main.cf"

2. "alias_maps = hash:/<location>" - this will tell you the location of the "<aliases>.db" file

3. "alias_database = hash:/<location>" - this will tell you the location of the "aliases" file used to generate the hash/db file above

4. "local_recipient_maps = proxy:unix:passwd.byname $alias_maps" - this command is very important

... it is what cause the mail server to trivially reject mail to uses that are not defined. This looks at the known login user ids (via proxy) and

the $alias_maps - which are as above in item 2...

5. "virtual_alias_maps = $virtual_maps hash:/<virtual-users-location> - if you are hosting multiple mail domains within a single server

8. This now gives you flexibility to:

1. Put traditional "aliases" & "aliases.db" at any location you would like and manage then in standard way

2. Have aliases which are by fully qualified domain names as "virtual_users"

3. Use Server Users administration interface via the "Advanced Options..." to create aliases that are held within "Open Directory"

NOTE: In my set up I have machine which is dedicated "Open Directory" master and then replicate this to mail host.

I think this may require that any user within "Open Directory" should be flags as being able to login in order for them to be visible as local recipient,

but have not tested to confirm this. I was finding some strange behavior and enable local accounts on "Open Directory" master and this

appeared to fix problem, with local_receipient , but I also changed other things, so need to confirm this.

NOTE 2: I think that Postfix is cache'ing for lookup to avoid going back to map files and proxy server , which is why there sometimes appears to be very strange

behaviour at time, as it takes a while for update to propagate. Stop / Start mail server to avoid this.

I hope this provides helpful information to anyone trying to diagnose problems with Aliases and OS X Server.

Cheers,

Zebity.

OS X Server ,

I have done some further testing and checking to try to work out the aliases behavior.

The critical line in "/Library/Server/Mail/Config/postfix/main.cf" file is:

local_recipient_maps = proxy:unix:passwd.byname $alias_maps

This forces postfix mail server to verify that the mail recipient is a known user and is essential to avoid mail to unknown user entering into mail system and they replying with a "cannot deliver message" back to the "from/reply-to" identity which could be a false one and hence your mail system becomes a target for spam relay via return to sender messages.

To test the behaviour you will get you can use the "postmap" command.

For example to test the aliases an alias in the <aliases>.db file you can use the following command:

# postmap -q test-name -c /Library/Server/Mail/Config/postfix hash:/<aliases>

If the alias is found it will provide the destination identity... such as: my-name

For recipients that are know local user identities you can test via:

# postmap -q local-name -c /Library/Server/Mail/Config/postfix proxy:unix:password.byname

If the user is found you will get the shadow passwd line as response: local-name:********:12345:20:Example Name:/Users/local-name:/bin/bash

postfix does not look at details of the response, just if I gets something or nothing and if it gets something then it will accept mail to that receipient.

So now for the three ways you can add aliases"

1. Via the <aliases>.db file which must be in the location specified by $alias_maps = hash:/<location> directive in main.cf

2. Via the "Advanced Options..." aliases list that available from "Server" application "Account/Users" function

3. Via the "Email Addresses:" that is available from the "Edit User.." function from "Server" application "Account/Users" function

I have tested 1 & 2 and the behaviour is that:

1. If you use <aliases> & <aliases>.db mechanism then the recipient is returned via hash:/<aliases> test

2. If you use "Advance Options" aliases list then the recipient is returned via proxy:unix:passwd.byname

I suspect that if you use option 3 then the result is that that mail address will be added in the /Library/Server/Mail/Config/postfix/virtual_users file and you can then test this by doing:

# postmap -q <name>@<mail>.<domain> -c /Library/Server/Mail/Config/postfix #hash:/Library/Server/Mail/Config/postfix/virtual_users

The response should be the local id that this maps to...

Again I hope this is helpful.

I have now found that I have a clear way to help test and debug the various different ways that Aliases are handled...

Cheers,

Zebity.

Zebity,

First thank you for the incredibly detailed information. I've been struggling with alias issues ever since I updated from Server 10.6 on 10.6 to Server 4 on 10.10.1. Any chance you've tested your findings with Server 4.1? I found some stability with your method 1 of modifying the aliases file and running newaliases. This was my only solution in 10.6 and since the aliases rarely change for me, it's a workable option. You'd think distribution list emails would be an incredibly basic and bulletproof function of any basic mail server but apparently not. I'd love to find a simpler method ofr my limited local admin to be able to maintain distribution lists/aliases if it's now more stable to use the UI in server 4.1.

Beware of the aliase queues getting stuck on an email and having to be manually cleaned out. I routinely had that issue when I configed my users as OD network users. I finally ditched OD and all it's ridiculously fragile nature under Server 4 and set up everything as local users with the aliases all in the aliases file and hash.

Kevin

Hi Morphire,

yes I have done all my latest testing with Server 4.1

Key thing to remember with ALL postfix command is to override the default config directory for all commands:

Thus for me, I keep my <aliases> files as follows:

/etc/aliases -> postfix/aliases -- soft link to file in /etc/postfix/aliases

/etc/postfix/aliases -- the actual aliases file I use

/etc/aliases.db -- the generated hash file

/Library/Server/Mail/Config/postfix/aliases -> /etc/postfix/aliases -- again link to the master aliases file

/Library/Server/Mail/Config/postfix/aliases.db -> /etc/aliases.db -- again link to the has file

and my alias directives in /Library/Server/Mail/Config/postfix/main.cf are:

...

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

virtual_alias_maps = $virtual_maps hash:/Library/Server/Mail/Config/postfix/virtual_users

local_recipient_maps = proxy:unix:passwd.byname $alias_maps

virtual_alias_domains = $virtual_alias_maps hash:/Library/Server/Mail/Config/postfix/virtual_domains

...

To update the aliases.db hash table...

# cd /etc

# sudo postalias -c /Library/Server/Mail/Config/postfix aliases

or

# sudo newaliases -c /Library/Server/Mail/Config/postfix aliases -- notes new aliases is just link to postfix Sendmail compatibility interface

then do this or stop / start the mail service via Server application

# sudo postfix -c /Library/Server/Mail/Config/postfix reload

As you can see I have updated the /Server/Library/Mail/Config/postfix alias related files and config to point back to the standard /etc/aliases area...

This is more paranoia rather than necessity.

You also need to recheck after every new OS X update install that the alias directives and files are all still ok.

BTW I am still using Open Directory and it seems to be working ok... The trick is to do the "postmap" check to validate that the "local_recipient_maps" directive is working ok. Open Directory is an additional complication, but it has advantage of allowing replica directories to be created will means if one directory blows up then you still have others you can use.... but you have to be very careful when upgrading as all Server instances need to be on the same version, as Open Directory does not have backward compatibility,

I have a dedicated VM just for the Open Directory master and then replicate from this to other machines.

I hope this helps with your question... I have deliberately done to some details, as after many frustrations with OS X Server updates it was the only way I could get to bottom of the strange behaviour.

Cheers,

Zebity.