Configuring 'Functionally Split Clusters'

Surgemail can be functionally split across several servers. The main reason to use this is if your mail load is too large for one server (eg 40000 user+) and / or you have a particularly heavy spam loading or webmail client loading.

You can pick and match what you want to support on each server, but typically you would setup say 2 front end systems for spam and virus filtering. A single mail system to handle storage of local mail including access to this using POP and IMAP. And one or more webmai systems which handle the webmail load and talk to the primary mail server when necessary using IMAP.

This is the most efficient way to implement a high reliabilty system with a high level of scalability. Dependant on your user needs this allows you to host up to 100,000 users on your primary mail system.

NEVER implement front end filters like this unless you have to, it is always a mistake to have front end servers unless your load leaves you with no other choice!

Other considerations:

• A functionally split architecture can be combined with mirrorring. You would simply introduce one more system into the above architecture which is a mirror of the primary mail system. As per mirrorring this removes the single point of failure (with associated mail data loss) you would otherwise have if your main mail system were to fail.
• Mail will continue to be accepted by the filter systems if there is a problem with your primary mail system.

Settings you will need to use:

On the 'back end' servers

g_relay_allow_ip "ip.of.filter.server*"
g_gateway_allow "ip.of.filter.server"
g_friends_ignore_trusted "true"
g_spf_skip "ip.of.filter.server*"
g_verify_mx_skip "ip.of.filter.server*"
g_spf_share "ip.of.all.other.servers" (this is a list, not a wild card)
g_xfile_allow "*"
g_autologin_pop "true"

Copy the file srs.secret between all cluster/mx servers so it matches on all systems, this file contains a random number which is used to verify srs and allow emails. This file will only exist once you start using SPF, it resides in the g_home directory.

On the 'front end' servers

Don't define the real domain names on the front end server, it will just use gateway settings. Use a sub domain of the real domain, e.g. "incoming.my.domain"

g_gateway domain="fred.com" to="backend.ip" check="true"
g_gateway domain="xyz.com" to="backend.ip" check="true"
g_spf_skip "ip.of.backend.server*"
g_spf_share "ip.of.all.other.servers" (this is a list, not a wild card)

NEVER implement front end filters like this unless you have to, it is always a mistake to have front end servers unless your load leaves you with no other choice! Unlike most situations it is not wise to start with this layout because you think your load 'might' require it one day!!!

On webmail servers

Don't define the domain at all in surgemail.ini (just use some fake domain name)

In webmail.ini set:

imaphost backend.ip.address
smtphost backend.ip.address
use_id_autologin true