Re: [exim] Is a secondary MX worth the effort?

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Patrick von der Hagen
Ημερομηνία:  
Προς: exim-users
Υ/ο: exim-users
Αντικείμενο: Re: [exim] Is a secondary MX worth the effort?
Am Donnerstag, den 08.11.2007, 11:11 -0500 schrieb Ken Price:
[...]
> And if that is indeed the case, I go back to my original question: "Is
> a secondary MX worth the effort?"

To be a little bit more precise, you ask wheter a secondary MX located
offsite (!) is worth the effort. You have not asked about running
several MX servers on your primary site, where I consider a must-have
and which usually is no problem, since all servers should be able to
access the same resources (e.g. user-database) easily.

Now, about running a secondary MX offsite....
if you run such a server and just accept all messages, relay them to
your primary which might reject them, then you cause lots of backscatter
and will run into problems. Of course, if the server really only does
act as secondary MX, you might not really care about it being
blacklisted, but don't forget to create some whitelists on your own
antispam-setup to ignore your secondary mx being blacklisted...
And don't forget to hire some more staff to handle complaints.


A secondary MX is acceptable if and only if you can run it like your
primary. You have a replicated user-database to reject invalid
recipients, the same antispam-setup, the same antivirus-setup, etc.
Given your concrete situation, this can be difficult (expecially
regarding the user-database) and quite expensive (hardware,
antispam-appliances, etc.).


To sum up:
going the easy way by running a stupid secondary will cause trouble and
will cause some kind of punishment. It is not worth the effort.
Going the right way can be quite demanding and expensive. Do some math
to calculate your investment and then consider the possible advantages
and then decide wheter or not it is worth both effort and money. Effort
being just another kind of money, actually....


Short summary:
no.
--
CU,
Patrick.