Email routing

[grantwilson]

Hi guys, I wonder if someone can offer me a solution.

I have a site running Scalix 11.04 community edition at headoffice. I have a few branches connected directly to head office with 64K diginet lines.

In an effort to conserve bandwidth we want to install a standard Linux Postfix mail server at each remote office and configure them with subdomains so that when the remote users email each other the emails stay internal and do not get routed to head office.
At the head office I thought about just adding a rule into the /etc/postfix/virtual file to route the users email to the new subdomain. The problem is that when users at the headoffice mail other users on the same domain the emails do not read the virtual file and the mail is kept internal so the mail doesnt get to the remote location. Ideally I would like to keep the user at the remote site as a user on headoffice server incase of a hardware failure at the remote site, that way the remote user could always use SWA at the headoffice, even if its for just sending emails. I thought about creating an "Internet user but then that user doesnt have SWA access. Any ideas would be greatly appreciated.

[KevinAnderson]

I'm not normally a sales guy, so please don't misunderstand this, but what you should think about is moving to an enterprise edition.

In Enterprise, the servers all become aware of each other, so routing is handled directly between the servers. Additionally, you can add several sites as different MX records, then if one server/Inet connection is down, email will arrive at another site, and wait until the first site is back up, and then immediately be pushed out.

Webmail in enterprise knows about the other servers too, so even if a remote office user has email delivered to the remote office, when they connect to the head office's SWA, it will "pass through" to retrieve the email from a remote site. Don't confuse that with replicated email, which (in honesty) is what you're talking about.

User administration is also centralized between all of the servers into SAC. So when you add a new user, it will know if the user should be created on the Head Office server, or if it should be on a remote server, and that will be done automatically.

Lastly, and this is more of a sales speech, Enterprise offer features that community does not, and in a multi office environment, they will matter. Off the top of my head, I'd be especially concerned with:
1) The Recovery Folder. It's a recycle bin for email. Save yourself retrieving from backups.
2) Support. Enterprise will include formal support to assist with setup/problems.
3) Centralized Administration of users.
4) Calendaring, Shared Addressbook, Public Folders, etc.

You'll have some of these features already for some users, but do give Enterprise some thought.

Kev.

[grantwilson]

Hi Kev. Good sales speech

I think Enterprise is definitely to better way to go.

I think the options are really the following. The users at the remote sites dont require collaboration services, just simple mail services.

1. Users at remote site dont run a local mail server and just use the SWA at headoffice.
This will eliminate traffic by emails being sent up and down but SWA access would naturally increase bandwidth use per simultaneous session

2. Users at remote site dont run a local mail server and just do POP collects from Head office. This is the current setup.

3. Users at remote office run a local mail server on a subdomain. Users at head office server are created as Internet users. This will get mail to remote locations but will obviously lose SWA access and other Scalix features.

4. Upgrade to Enterprise edition. Load Scalix Enterprise on all remote mail servers.

I must stress that these sites are connected with 64K Diginet lines so bandwidth is very limited.