5.3. The domain-specific data

For each hosted domain there are several key things each satellite MX machine needed to know:

For the domain hosted.org these settings would be stored beneath the directory /srv/hosted.org in the following fashion:

Table 5-2. Per-Domain settings.


This file would contain the hostname(s) to which non-SPAM email messages should be directed.

See delivering non-SPAM email for details of how this was used.


This file would contain the username of the account which owned the domain.

(A domain could only be owned by a single user.)


This directory would contain one file named after each valid user upon the domain.

Alternatively it would contain the single file named "*" if wildcard handling were enabled.


This directory would contain a file named after each enabled check.

If the file was present then the check was enabled for this particular domain, otherwise it was disabled.


This directory would contain subdirectories for whitelisted senders, domains, and hosts.

These whitelist values would allow mail to be delivered even if it would otherwise have been rejected.

The majority of our checks were either "on" or "off", for example the use of the URL blacklist was either enabled or disabled for a particular domain. If the check were enabled for the domain then the file /srv/hosted.org/checks/urlbl would be present. If that file were not present then the check would be disabled for that domain.

Other tests were a little more complex and had to have special handling. For example the hosts which connected to our servers could be tested against various DNS blacklists. If these tests were disabled then the file /srv/hosted.org/dnsbl/zones wouldn't be present on disk. If it were present then it it was assumed to contain the list of zones to test against.

In terms of efficiency being able to decide a test was enabled via a simple stat() call was very efficient, and this system actually seemed to perform better than the previous one where MySQL because a bottleneck.