SMTP Relay Redundancy

Hi,

> I have two MTAs on the DMZ each connected to a

> different leased line. I would like the MTA in the

> internal network to deliver external mails to each

> MTAs with equal load.

Create a DNS record that has two MX records of equal priority - use that as the tcp_local daemon host on the internal MTA.

> Should one of the leased line

> is down, the MTA will try the other link immediately

> upon message delivery failure via the faulted link.

I'm a little unclear of this.. does your structure look like:

internal MTA -> (leased line 1) -> external DMZ MTA 1 -> (some connection)

internal MTA -> (leased line 2) -> external DMZ MTA 2 -> (some connection)

OR

internal MTA -> (LAN link) -> external DMZ MTA 1 -> (lease line 1)

internal MTA -> (LAN link) -> external DMZ MTA 2 -> (lease line 2)

> Is it possible with Messaging Server alone?

The first case is resolved by use of the MX records - if the internal MTA cannot reach one of the external DMZ MTA systems (e.g. lease line link is down)it will try the other DMZ MTA host.

The second case is more of a networking issue. Are external DMZ MTA1/2 on the same LAN network in this scenario?

> We have used DNS round robin before but the result is

> not satisfactory.

Why weren't they satisfactory?

Regards,

Shane.

shane_hjortha at 2007-7-11 23:28:02 >

Hi,

> When one of the link is down, the DNS cache remains.

> It often takes a couple of hours before the internal

> MTA is switched over to the other DMZ MTA.

The MX record approach will be better then because messaging server *should* split the outgoing email load between the two equal priority MX hosts.

> I would

> like the internal MTA to try alternately between the

> two DMZ MTA within minutes.

You are still left with the issue that only 50% of the email will get to the destination as half of the email will still be delivered to the DMZ host that has the non-functional outgoing leased line. The internal MTA has know way of knowing that the external DMZ MTA has no connectivity - how could it unless you cut the LAN link between the internal host and the affected DMZ host?

This sounds more of a networking issue, why don't you do this:

DMZ MTA 1

|-> leased line 1

||

| (local LAN) > router

||

|-> leased line 2

DMZ MTA 2

That way it doesn't matter which leased line is offline the router should handle it with the appropriate BGP routing etc.

This is how we dealt with the same issue with our South African campus that had two leased lines from two different companies due to the unreliability of Internet links (the physical cables between the campus and the local exchange kept being dug up and stolen).

Regards,

Shane.

shane_hjortha at 2007-7-11 23:28:02 >

Hi,

Well I can think off at least one very hackish solution off the top of my head.

Run a cron-job on the DMZ MTA's that pings a remote address. If there is no response, stop the dispatcher - that way the internal MTA's will see that the dispatcher is not contactable and will try/deliver to the other hopefully 'working' DMZ MTA.

./imsimta stop dispatcher

In the process of stopping the dispatcher you could also alert the system-admins through some mechanism.

By only stopping the dispatcher you prevent any new emails being 'stuck' on the DMZ host which has lost outside contact.

Handling the situation where the leased line comes back up and starting the dispatcher automatically whilst also catering for cases where you have manually shutdown the MTA for maintenance etc. I leave as an exercise for the reader :)

Regards,

Shane.

shane_hjortha at 2007-7-11 23:28:02 >