We currently have two MX servers in the same physical rack, they are sharing the same greylist database, and everything seems to work well. The two MX have different priorities and they are on two different physical servers, so we get redundancy if one of the two fails.

(FYI, the database is on a virtual machine on a redundant hardware cluster: while the db system as a whole is a Single Point of Failure, the hardware it runs on is not, eliminating most of the possible failure modes)

We'd like to introduce a new (or a pair of) MX in a different datacenter, to achieve full redundancy of the incoming mail systems (our DNS servers are already distributed over different DCs), but we can't connect it to the very same MySQL server since that would defeat the redundancy in the first place.

What is the correct way to implement greylisting in such a setup?

Can I just let every location / MX group have its own greylist db, or will that pose any problem or inefficiency? Is there any reason to configure MXes in the same site with the same/different priority or that doesn't matter? (of course different sites will always have different priorities)

EDIT / CLARIFICATION: first replies seems to suggest to setup MySQL replication (either master/slave or two way) or explain how to do that: been there, done that. I can put up a two way MySQL replication between data centers if I need/want to.

My question was focused on if I need to replicate / share the greylist db or if I can do without shared knowledge between the different greylisting MXes, not how to implement shared knowledge.

  • ...I'll bite. If you have a greylist, and it's been created by process FOO for server BAR, why is that greylist not equally as valuable to server PUB when your mail has failed over? I mean, if you're not concerned with the greylist being up to date for your mailserver, why are you even bothering with it in the first place? I think that's why so many of us are focusing on replication. – Driftpeasant Dec 3 '11 at 18:54

The worst-case scenario is if your primary data centre goes offline after an initial delivery attempt, the secondary data centre takes over and it has no record of the first delivery attempt. It will treat the follow up delivery attempt as the initial delivery attempt and will tell the relaying server to try again later.

Since the delay time is often only 5 minutes, this means that the greatest possible delay is about 10 minutes. Initial delivery at 0 minutes, second delivery to a different mail server at 5 minutes and then the final accepted delivery at 10 minutes.

Given that delay periods other than 5 minutes are possible, the worst case is actually a delay of double of whatever the normal delivery delay is in the case when a data centre fails.

If this is acceptable to you in a data centre failover situation then you won't need to share your greylisting database. If it isn't, then replication would be the way to go.

  • MX priorities: if they are different, then the first MX will get most of the mail, and greylisting will mostly work as if there is only one mail server receiving the mail. If the priorities are equal, then the retrys will often go to another receiving server, and you will commonly see delays unless the DB is common to the servers. In any case, you can reduce the greylisting delay to 1 minute and still avoid most spam. – rleir Oct 29 '13 at 14:28

I'm guessing the greylist isn't ludicrously large or active... why not master/slave replication on the MySQL database to the remote datacenter?

  • Master/slave replication isn't a good idea in this scenario. It puts a non trivial amount of complexity in the system (not the replication itself, that's easy, but the automatic master/slave switch on the sql servers and the automatic sql server selection on the clients), not to mention the most probable failure is intermittent network between the DCs, leaving you with split brain and resync issues. – Luke404 Dec 3 '11 at 16:35

I would suggest you use replication to synchronise your mysql database between both location.

Depending on the structure of your databases there are many possibilities, but a common setting is to configure each cluster to generate independent serial keys and make them replicate each other. For example in my.cnf:

auto-increment-increment = 5
auto-increment-offset = 1  ( and 2, 3, 4 , 5 on your other clusters )

In case of crash each cluster keeps a log of the not-yet-replicated-transactions locally so that when the other side comes up the transactions are delivered.

Edit: Ok, you need to synchronise your clusters else you will greylist the same ip address independantly on each of your clusters, which might in practice multiply the greylist time by the number of clusters you setup. By the way, why don't you set the same MX priority to all your MX entries?

  • Your reply seems to assume that I actually need shared knowledge between the greylisting databases and individual dbs are not a good idea: what's the motivation behind this? It's far easier to setup simple independent MySQL dbs if you don't have any specific reason to do otherwise. I've edited and tried to clarify my question. – Luke404 Dec 3 '11 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.