I have a number of mail servers where mail enters, get spam scanned etc and then forwarded to mail box servers. This used to be customer facing and had web interfaces and statistics etc but I am now scaling all this down to just manage my own and some friends domains.
Rather than maintain all the web interfaces that I really could not care for I’d rather manage this with Puppet, my ideal end result would be:
exim::route{"devco.net":
nexthop => "my.mailbox.server",
spamthreshold => 10,
spamdestination => ":blackhole:",
has_greylist => 1,
has_spam_check => 1,
has_whitelist => 1
}This should add all the required configuration to deliver mail arriving at the mail relay for devco.net to the server my.mailbox.server. It will set up Spam Assassin scans and send all mail that scores more than 10 to the exim specific destination :blackhole: that would simply delete the mail. I could specify any valid mail destination here like a file or other email address. I won’t be covering the has_* entries in this guide, they just control various policies in my ACLs on a per domain basis.
I’ll first cover the Exim side of things, clearly I do not want to be editing exim.conf each time so I will read the domain information from a file stored on the server. These files will be stored in /etc/exim/routes/devco.net and look like:
nexthop: my.mailbox.server
spamthreshold: 10
spamdestination: :blackhole:
In order to accept mail for a domain Exim needs a list of valid domains it will accept mail for, so as our routes are named after the domain we can just leverage that to build the list:
domainlist mw_domains = dsearch;/etc/exim/routes
Next we should pull from the file the various settings we store there:
NEXTHOP = ${lookup{nexthop}lsearch{/etc/exim/routes/${domain}}}
DOMAINREJECTSCORE = ${eval:10*${lookup{spamthreshold}lsearch{/etc/exim/routes/${domain}}}}
DOMAINSPAMDEST = ${lookup{spamdestination}lsearch{/etc/exim/routes/${domain}}}
ACL_SPAMSCORE = acl_m3This creates handy variables that we can just use in our routes and spam configuration, I won’t go into the actual setup of spam assassin scanning as that’s pretty standard stuff better documented elsewhere. In the spam assassin ACLs just store your $spam_score_int in ACL_SPAMSCORE.
To deliver the mail either to the specific spam destination or to the next hop we just need to add 2 routers to the routes section. These are order dependant so they should be in the order below:
spamblock:
driver = redirect
condition = ${if >= {$ACL_SPAMSCORE}{DOMAINREJECTSCORE}{true}{false}}
data = DOMAINSPAMDEST
headers_add = X-MW-Note: Redirecting mail to domain spam destination
domains = +mw_domains
no_verifyHere we’re just doing a quick if check over the stored spam score to see if its bigger or equal to the threshold stored in DOMAINREJECTSCORE and then set the data of the route – where the mail should go – to the configured address from DOMAINSPAMDEST. This router will only be active for domains that this Exim server is a relay for and it adds a little debug note as a header.
The actual mail delivery that is being used in place of the normal dnslookup route is here:
mw_domains:
driver = manualroute
transport = remote_smtp
domains = +mw_domains
user = root
headers_add = "X-MW-Recipient: ${local_part}@${domain}\n\
X-MW-Sender: $sender_address\n\
X-MW-Server: $primary_hostname"
route_data = MW_NEXTHOPThis router is also restricted to only our relay domains, it adds some headers for debug purposes and finally sets the route_data of the email to the next hop from MW_NEXTHOP thus delivering the mail to the destination.
That’s all there is to do on the Exim side, it’s pretty standard stuff. Next up the Puppet define:
define exim::route($nexthop, $spamthreshold, $spamdestination, $ensure = "present") {
file{"/etc/exim/routes/${name}":
ensure => $ensure,
content => template("exim/route.erb")
}
}And the template for this define is also extremely simple:
nexthop: <%= nexthop %>
spamthreshold: <%= spamthreshold %>
spamdestination: <%= spamdestination %>
I could stop here and just create a bunch of exim::route resources but that would be code changes, I prefer just changing data. So I am going to create a JSON file called mailrelay.json and store it with my Hiera data.
{
"relay_domains": {
"devco.net": {
"nexthop": "my.mailbox.server",
"spamdestination": ":blackhole:",
"spamthreshold": 10,
"has_dkim": 1
},
"another.com": {
"nexthop": "ASPMX.L.GOOGLE.COM.",
"spamdestination": ":blackhole:",
"spamthreshold": 10
}
}
}I assign all my incoming mail servers a single class that would look roughly like this:
class roles::mailrelay {
include exim
include exim::mailrelay
$routes = hiera("relay_domains", "", "mailrelay")
$domains = keys($routes)
exim::routemap{$domains:
routes => $routes
}
}The call to Hiera fetches the entire hash from the mailrelay.json file and stores it in $routes. I then use the keys function from puppetlabs-stdlib to extract just the list of domains into an array. I then pass that into a define exim::routemap that iterates the list and builds up individual exim::route resources.
The routemap define is just as below, I’ve shortened it a fair bit as I also have validation logic in here to make sure I pass valid data in the hash from Hiera, the stdlib module has various validator functions thats really handy for this:
define exim::routemap($routes) {
exim::route{$name:
nexthop => $routes[$name]["nexthop"],
spamthreshold => $routes[$name]["spamthreshold"],
spamdestination => $routes[$name]["spamdestination"]
}
if ($routes[$name]["has_dkim"] == 1) {
exim::dkim_domain{$name: }
} else {
exim::dkim_domain{$name: ensure => absent}
}
}And that’s about it, now my mail routing setup, DKIM signing and other policies are managed in a simple JSON file in my Puppet Manifests.
