Separate mail server for each site

Question

Level 1

39 points

Separate mail server for each site

We have Head Office and Small Office.

Our mail server is in Head Office - traffic to and from the mail server is over the fast LAN - no problems.

In Small Office, we have two employees, let's call them Snail and Shoe.

Currently Snail and Shoe use the mail server in Head Office. When Snail emails Shoe, the message travels all the way to Head Office saturing the slow link upstream. Shoe then downloads the email from Head Office, which then saturates the slow link downstream.

If Snail and Shoe are on the same LAN in the small office, there shouldn't be any reason for the message to travel all the way back to head office, so my question is:

How do I set up a secondary email server in Small Office using the same email domain in such a way that it would integrate with Head Office?

I envisage a scenario where if Snail sends an email to Shoe, it would go to a local email server in Small Office. The local email server in Small Office would then check if Shoe is located in Small Office or whether he's in Head Office. Seeing that he's in the local Small Office, the local mail server would then keep the message in Small Office. Shoe will then download it from Small Office's local mail server, saving the slow link from saturation.

How do I do set up the servers this way?

Xserve, Mac OS X (10.6.7)

Posted on Sep 1, 2011 8:49 PM

Reply

Answer 1

Best reply

John Lockwood

Level 6

13,685 points

Sep 2, 2011 3:59 AM in response to dmare

As long as these remote users need to be in the same domain name for email as the main office, I don't think Apple's own mail server is going to be able to do what you want. This is the sort of thing MS Exchange historically is better at. I am not however suggesting you go that route.

You could however look at Kerio Connect. This can run on various server operating systems including Mac OS X, and can also link to Open Directory for authenticating users (or use its own standalone system). In your case the main benefit of Kerio is that is does have a feature added last year called a 'dsitributed domain'. This allows you to have servers at multiple sites all running the same email domain name. I would also say that Kerio has far better support for iOS devices than Apple's own server (ironic as that sounds) as Kerio uses the same ActiveSync technology as used by MS Exchange.

See http://www.kerio.com and http://www.kerio.co.uk/blog/distributed-domain-bringing-offices-together

Reply

Answer 2

dmare Author

Level 1

39 points

Oct 4, 2011 1:01 AM in response to John Lockwood

Thanks John,

Have considered Kerio Connect, but believe we should be able to achieve the same with postfix - certainly the author of postfix says so:

Sure. The idea is to use location-independent email addresses (user@example.com) for the

population.

The mail domain is distributed across multiple physical servers,

some of which may also be primary MX for the distributed domain.

Each mail server forwards mail to the "right" physical server

using a shared alias database.

/etc/postfix/main.cf:

myorigin = $mydomain

mydestination = $myhostname $mydomain localhost.$mydomain localhost

virtual_alias_maps = some replicated database (i.e. OpenDirectory in our case)

In the replicated database:

#lookup value lookup result

user1@example.com user@postfixserver1.example.com

user2@example.com user@postfixserver2.example.com

The replicated database has one record for all recipients including

root, postmaster, and so on. Replication can be done with rsync,

LDAP, *SQL, and so on.

To receive some email addresses on the server itself, see:

http://www.postfix.org/STANDARD_CONFIGURATION_README.html#some_local

In addition, each mail server needs to have a local database table

for its own users. Those users can be the UNIX system password file,

a Postfix virtual alias domain, or a Postfix virtual mailbox domain.

I believe I can use Inspector to create virtual_alias_maps entries for every user to specify its local address.

What I'm wondering about is the local users on each server - how exactly does postfix and LDAP integrate?

I've asked a similar question here (but it was relating to a different question): https://discussions.apple.com/thread/3137447?answerId=16160751022#16160751022

I believe the relevant line in /etc/postfix/main.cf / postconf -n is:

local_recipient_maps = proxy:unix:passwd.byname $alias_maps

(http://www.postfix.org/LOCAL_RECIPIENT_README.html)

I'm not sure what the proxy:unix:password.byname part means, but $alias_maps is defined below:

alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases

/etc/aliases has all the postmaster, abuse, etc. entries - none of the actual users' accounts.

/var/mailman/data/aliases has all the entries for the mailing lists - none of the actual users' accounts.

This leaves me with either:

local_recipient_maps not being the correct setting

or

The part I don't understand: proxy:unix:passwd.byname being the list of actual mail users

How exactly does this work, because I'd have to modify this so that only some users are considered local users whilst other users' traffic is forwarded to other servers?

Reply

Answer 3

Oct 4, 2011 2:14 AM in response to dmare

The underlying email server software on Mac OS X is standard widely used and respected open-source software like as you mention postfix, and also dovecot, amavis, spamassassin, etc.

The problem is that Apple only give basic access to their capabilities and for anything more you have to dig in to the configuration files and do it all by hand. Even email groups is poorly handled by Apple.

I find Kerio Connect far less painful to deal with. I would in your case consider having a central Open Directory master, and each office to have an Open Directory replica. Each account would then work at each office (for Open Directory), and Kerio would authenticate users via Open Directory.

There is a free evaluation version of Kerio Connect.

PS. As I mentioned, Kerio will definitely make life easier for iOS devices, you even get remote wipe.

Reply