An edge server in front

An edge server is a second inbuxa on a machine the internet can reach, such as a small cloud server. It does two jobs for the server that stores your mail, called the internal server here:

• Incoming: it answers port 25 for your domains, checks the mail, and passes it on to the internal server. If the internal server is down, the edge keeps the mail and tries again.
• Outgoing: the internal server sends everything through it, signed in with an account of its own.

This suits an internal server at home or on a private network, and it replaces a Postfix relay in front of one. Both machines run an ordinary inbuxa install, and everything below is settings: nothing extra to install.

The edge stores no one's mail. It has a data store all the same, because mail waiting to be passed on is kept there.

Before you start

• Two servers set up, each with its own default domain. The edge's domain can be anything you own, such as edge.example.com. The domains people use, example.com here, stay on the internal server.
• The MX records of your domains point to the edge only.
• The edge can reach the internal server on port 25, and the internal server can reach the edge on port 465.
• The edge's IP address. The examples use 203.0.113.10.

Every setting below is in the console. A rule is a condition and a value, and the first rule that matches wins, so where a step says a rule goes first, it means at the top of the list.

On the edge

1. A route to the internal server

Under Settings › Mail flow › Sending › Routes and relays, add a Relay route:

Name	internal
Address	the internal server's name or address
Port	25
Protocol	SMTP

The edge asks for STARTTLS as it would with any server. If the internal server's certificate comes from your own CA, add that CA to the edge machine's trusted certificates, or turn on Allow invalid certs on this route if the network between them is your own.

2. Send your domains that way

Under Settings › Mail flow › Sending › Delivery strategy, add a rule to Routing, first:

If	Then
contains(['example.com', 'example.org'], rcpt_domain)	'internal'

List every domain the internal server receives mail for. It has to come before the is_local_domain(rcpt_domain) rule, or step 3's first way would make the edge keep the mail itself.

3. Which addresses it accepts

The edge can't ask the internal server whether an address exists. There are two ways to handle that.

Check addresses in your directory. If your accounts live in LDAP or SQL, the edge can look them up there, and mail to an address nobody has is refused at the door with 550 Mailbox does not exist. This is the better way when you have a directory.

1. Add the directory under Settings › Security › Sign-in › Directories, as on the internal server. See Directories.
2. Under Management › Domains, add each of your domains on the edge, with that directory as its Directory, and DKIM management set to Manual, so the edge makes no signing keys of its own (see step 5).

Each person the edge finds in the directory becomes an account on the edge, as on any server with a directory. Their mail still goes to the internal server: step 2's rule sees to that.

Accept every address at your domains. Without a directory, let the edge take any address at your domains. Under Settings › Mail flow › Advanced › Recipients (RCPT TO), add a rule to Allow relaying:

If	Then
contains(['example.com', 'example.org'], rcpt_domain)	true

Leave the fallback as it is, !is_empty(authenticated_as), so nobody else can relay through the edge. Don't add your domains under Management › Domains on the edge this way.

The cost: mail to an address that doesn't exist is accepted by the edge, refused by the internal server, and then the edge sends a bounce to the sender. When the sender address was forged, as it often is in spam, that bounce goes to a stranger.

The console's security checks mark a changed Allow relaying as critical. On an edge that is expected: check the rule names only your domains.

4. An account for the internal server

Under Management › Directory › Accounts, add an account in the edge's own domain for the internal server to sign in with, such as relay@edge.example.com, with a long password.

By default an account may only send as its own addresses. This one sends everyone's mail, so under Settings › Mail flow › Advanced › Sign-in (AUTH), add a rule to Must match sender, first:

If	Then
authenticated_as == 'relay@edge.example.com'	false

Without it, every message from the internal server is refused with 501 5.5.4 You are not allowed to send from this address, and its sender gets a bounce.

Two more things apply to this account:

• Limits. A limit on what one signed-in person may send applies to this account as a whole, for everyone behind the internal server. If you set Sending and receiving limits on the edge, make the per-person numbers big enough for all of them together.
• Legacy mail. Turning off all legacy protocols stops SMTP sign-in, and with it the internal server's sending. Leave at least one on, on the edge. See Protocols.

5. Signing

The internal server signs its people's mail with DKIM as they send it, and the signatures pass through the edge untouched. The edge needs no keys for your domains, which is why step 3 sets their DKIM management to Manual.

On the internal server

1. Send through the edge

Run the sending guide and choose Through a relay service, then Another relay:

• Server: the edge's name, port 465, encrypted from the start.
• Sign-in: the account from step 4 and its password.

Mail for the internal server's own domains stays there. Everything else goes to the edge.

2. Never ban the edge

All your incoming mail now comes from one address, so the automatic ban must never catch it. Add 203.0.113.10 under Settings › Security › Protection › Allowed IPs.

If you set Sending and receiving limits on the internal server, its limit on connections a minute from each outside server now applies to the edge, which carries all your incoming mail. Make it big enough for that, or leave that limit off on the internal server and keep it on the edge.

3. Don't judge the edge as the sender

SPF, DMARC and reverse IP checks look at the address mail came from. On the internal server that is always the edge, so the checks would fail every message. The edge has already checked the real sender.

Under Settings › Mail flow › Receiving › Sender checks (SPF, DKIM, DMARC), add this rule first to each of SPF Verification › EHLO, SPF Verification › MAIL FROM, DMARC Verification › Strategy and Reverse IP Verification › Reverse IP:

If	Then
remote_ip == '203.0.113.10'	disable

DKIM checks stay on: a signature still proves who signed, whichever server passed the message along.

Spam

The internal server decides what goes to Junk using its own spam check only. It doesn't read the edge's verdict from the message's headers. So choose one of these two, and set up both halves of it.

Option 1: the edge refuses spam

The edge checks every message, and refuses the ones it scores as spam. The internal server doesn't check them again.

• On the edge: under Settings › Spam filter › Protection › Filter settings, set Reject threshold to the same number as Spam threshold, 5 unless you changed it. Spam is then refused with 550 5.7.1 Message rejected due to excessive spam score.
• On the internal server: under Settings › Mail flow › Advanced › Message (DATA), add this rule first to Spam filtering:

  If	Then
  remote_ip == '203.0.113.10'	false

Spam never reaches anyone's mailbox, and whoever sent a message that was wrongly refused is told, by their own server, that it didn't arrive. The cost is that nothing lands in Junk for people to look through: a message the filter gets wrong is refused, not filed.

Turn off the internal server's check only if the edge refuses spam. With the check off and spam still accepted by the edge, spam lands in the inbox.

Option 2: both check

The internal server keeps its spam check, and files spam to Junk as it always did. The edge can still refuse the worst: give it a Reject threshold well above its Spam threshold, or leave it at 0, which refuses nothing.

The cost: with the sender checks off for the edge (step 3), the internal server has no SPF or DMARC result to go on, and scores each message a little higher, about two or three points in our tests. More good mail can land in Junk. If it does, raise the internal server's Spam threshold a little, and watch Junk for a week or two.

Check it works

1. Incoming. Send a message from an outside address to someone at your domain. On the edge it shows under Management › Emails › History › Outbound delivery, passed on to the internal server.
2. Outgoing. Send from the webmail to an outside address. The internal server's history shows it handed to the edge, and the edge's shows it delivered.
3. Not an open relay. From outside, try sending through the edge to a domain that isn't yours, without signing in. It must be refused with 550 5.1.2 Relay not allowed.
4. An address that doesn't exist. With a directory, it is refused at the door. Without one, expect the bounce described in step 3.

If the internal server is down, mail waits on the edge under Management › Emails › Queued, and goes through on the next retry once it is back. It waits three days by default before the sender is told it failed. For a longer outage, add a longer schedule under Settings › Mail flow › Sending › Retry schedules, and pick it for your domains in Scheduling under Delivery strategy, with the same condition as step 2.