Connecting your own mail server: Postfix and others

Conbool sits as a gateway in the mail flow and speaks nothing but SMTP. That makes it possible to connect any self-operated mail server, without a connector, without API access and without an agent on the server. The examples on this page show Postfix, because the common server packages use Postfix as their MTA. For Microsoft 365 and Exchange the separate path through Exchange connectors applies.

The mailboxes stay on your own server. Conbool accepts incoming messages, checks them and delivers to your server. Outbound, Conbool accepts the messages of your server, applies signature, disclaimer or encryption and delivers on.

All examples use placeholders that are replaced with your own values. example.com is your own mail domain, 203.0.113.20 your own mail server, 203.0.113.10 the address Conbool delivers from and smtp.gateway.example the gateway host.

Where the real values come from:

• Delivering address and gateway host are shown in the portal under Settings, Domains, in the respective domain in the mail server field. In the setup wizard they appear at the mail server step as soon as manual setup is chosen. Partner and on-premises installations deliver from their own instance and show different values accordingly.
• MX, SPF, DKIM and the TXT verification are shown by the setup wizard under connecting a domain.

Inbound path

In the portal the MX is pointed at Conbool and your own server is entered as the relay host of the domain. Conbool then delivers to that host on port 25. Three rules are needed on your own server.

First: suspend connection protection for the gateway address. postscreen scores connections before acceptance and would treat the gateway like any foreign sender. In main.cf:

postscreen_access_list = permit_mynetworks,
    cidr:/etc/postfix/postscreen_access.cidr

In /etc/postfix/postscreen_access.cidr:

203.0.113.10/32   permit

Second: do not check SPF again. After forwarding, the connection comes from the gateway. A repeated SPF check therefore scores the wrong source and rejects correct messages. With postfix-policyd-spf-python the address belongs in the configuration under /etc/postfix-policyd-spf-python/policyd-spf.conf:

Whitelist = 203.0.113.10

If the check runs in Rspamd, a settings block in /etc/rspamd/local.d/settings.conf applies:

conbool_gateway {
  priority = high;
  ip = "203.0.113.10/32";
  apply {
    symbols_disabled = [
      "R_SPF_FAIL", "R_SPF_SOFTFAIL", "R_SPF_PERMFAIL", "R_SPF_NA",
      "DMARC_POLICY_REJECT", "DMARC_POLICY_QUARANTINE", "DMARC_POLICY_SOFTFAIL",
      "GREYLIST"
    ];
  }
}

Third: no second delay and no second rejection. Greylisting is switched off in the block above already. Block lists must not hit the gateway address, otherwise your own server discards messages that have already been checked. The check result from Conbool is written into the headers of every message and can be reused in your own rules.

Then postfix reload and, if Rspamd is involved, rspamadm configtest plus a restart of the service.

Outbound path

Outgoing messages go to the gateway instead of straight to the recipient. In main.cf:

relayhost = [smtp.gateway.example]:25
smtp_tls_security_level = may

The square brackets suppress the MX lookup and direct delivery to exactly this host. If only part of the senders is to run through Conbool, a sender-dependent mapping takes the place of the fixed value:

sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay

In /etc/postfix/sender_relay, followed by postmap /etc/postfix/sender_relay:

@example.com    [smtp.gateway.example]:25

There is no SMTP authentication. Permission follows from the SPF record of the domain. If a message does not pass the SPF check, Conbool rejects it, because an unauthorised system is then sending under the domain.

For the outbound DKIM signature a stricter rule applies: the address of your own server has to appear directly as ip4 or ip6 in SPF. An include is not enough here, because included ranges also cover many foreign systems and would be worthless as proof of origin. If the address only appears through an include, the message is delivered but not signed.

v=spf1 ip4:203.0.113.20 include:<value from the wizard> -all

The signature itself belongs at the last hop. If your own server signs and Conbool afterwards applies a disclaimer, subject marking or encryption, the existing signature breaks. Signing on your own server is therefore switched off for these domains, in Rspamd through /etc/rspamd/local.d/dkim_signing.conf:

enabled = false;

After processing, Conbool delivers directly to the recipient. If an existing downstream instance is to stay in the path, the mailer table and smart host routing controls that.

Archiving internal messages

Messages between two mailboxes of the same server are delivered locally and never reach the gateway. For a complete archive your own server therefore delivers a copy to a dedicated ingestion address.

The address is created in the archive under administration and sources. A source with the delivery path Copy by BCC is created there, after which the portal shows the full address in the form ingest-address@journal.conbool.com. The address cannot be guessed and acts as a secret. Optionally a sender IP allowlist can be stored.

Recommended rule: one copy per recipient with a marker. The recipient is appended to the ingestion address as an address extension. Only this way are Bcc recipients captured as well, since they appear in no header. In main.cf:

recipient_bcc_maps = regexp:/etc/postfix/archive_bcc

In /etc/postfix/archive_bcc, one line per domain:

/^(.*)@(example\.com)$/   ingest-address+${1}=${2}@journal.conbool.com

anna@example.com thereby becomes the copy to ingest-address+anna=example.com@journal.conbool.com. The archive reads the part after the plus sign as the real recipient and derives direction and mailbox from it, that is inbound, outbound or internal. Regexp lists need no postmap, a postfix reload is enough.

Simple rule without a marker. If you only want to set a single line, take a copy of the entire traffic:

always_bcc = ingest-address@journal.conbool.com

The archive then reads the recipients from To and Cc as well as from the headers X-Envelope-To, X-Original-To and Delivered-To. Bcc recipients are missing in that case.

Three rules apply to both variants:

• The marker belongs exclusively in recipient_bcc_maps. In sender_bcc_maps it would carry the sender, and the archive would determine the direction wrongly. Sender copies therefore always go to the address without an extension.
• The copy has to arrive over TLS. With smtp_tls_security_level = may that is satisfied, since the gateway offers STARTTLS.
• The original sender stays in the envelope. Postfix keeps it for BCC copies on its own, nothing needs to be configured here.

Duplicate copies are harmless. The archive detects them and creates exactly one entry per message and mailbox. The other archiving paths, capture at the gateway and import of legacy data, are described in the archive setup.

Verify the setup

• Inbound: send a test message from outside and look for the acceptance from 203.0.113.10 with status=sent in the mail log of your own server.
• Outbound: send a test message and check relay=smtp.gateway.example[...]:25 in the mail log. The message appears in the portal in message tracing.
• Archive: after the first copy the source under administration and sources counts the received messages and shows the time of the last delivery.

Limits

• Delivery to the relay host and to a smart host runs on port 25. A different port is not provided for.
• There is no SMTP authentication for the outbound path, permission runs through the SPF record.
• Copies without a marker do not capture Bcc recipients.

Continue with inbound protection under MailGuard and with archiving under Archive.