FacebookTwitterFlickrYoutuberss

Mail Split Domain

From Zentyal Linux Small Business Server
Revision as of 10:04, 19 August 2014 by Admin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
  • Tittle: Split Domain setup
  • Author(s): Nathanael Rebsch (dihedral)
  • Date: 25 Oct 2011
  • Version(s): >=2.2
  • Zentyal profiles:

Contents

Split Domain Setup

We talk of a split domain as soon as 2 or more mail servers are responsible for the delivery of a single domain. This does not refer to having a master and slave MX, but rather having different recipients stored on different servers.

Throughout this article I shall be referring to the domain example.org - I shall work with the concept of the following: recipient a@example.org shall reside on this Zentyal server, which for the purpose of this article I shall call mail-a.example.org, while the recipient b@example.org will need to be delivered to mail-b.example.org.

Further I shall imagine not being in charge of mail-b.example.org, and therefore not being able to influence any configuration on that server.

Zentyal Modules

These are the modules I chose for my setup. Of course you can stick in there as many modules as you want or even leave out some - however, these are the ones being used for this article.

- Antivirus
- Logs
- Mail Service
- Mail Filter
- Users and Groups

Zentyal Configuration

Just to keep this fresh in your mind, this Zentyal server is named, mail-a.example.org

As we want this server to be the master mx for all email to example.org we need to configure this domain as one of Zentyal's virtual domains (Mail ‣ Virtual Domains)

Now we need a user with either a mailbox or an alias of a@example.org - this will bring us to the stage of the system delivering mail for this recipient to the locally.

Last, but very important, we need to define an external accounts alias (Mail ‣ Virtual Domains ‣ External accounts aliases). Here we create an alias named b pointing to the external address b@example.org. Creating this alias may seem strange at the time, however once you reach the end of this article, it will actually make sense.

Work on the Command-Line

Changing A Template

Following the instructions at [Documentation/Community/HowTo/CustomizeConfigFiles CustomizeConfigFiles] the template mail/main.cf.mas is asking for our attention (this is mainly needed if you are not using zarafa for any other virtual domain)

What needs doing here is quite simple, yet very important - postfix needs the transport map, regardless of zentyal being used or not. We archive this by making the following change:

somewhere around line 91 of the original main.cf.mas file (Zentyal 2.2) you will find this snippet:

% if ($zarafa) {
transport_maps = hash:/etc/postfix/transport
zarafa_destination_recipient_limit = 1
% }

We simply change this to:

transport_maps = hash:/etc/postfix/transport

% if ($zarafa) {
zarafa_destination_recipient_limit = 1
% }

This modified file is then saved to /etc/zentyal/stubs/mail/main.cf.mas

Zentyal Hook Scripts

We shall now make use of the Hook System made available to us. We want to archive that our additions to the transport map are only added once each time Zentyal touches the postfix configuration files. (I am not sure if the .presetconf and .postsetconf files need to be executable, just to be on the safe side, chmod +x them)

/etc/zentyal/hooks/mail.presetconf

#!/bin/bash

test -f /etc/postfix/transport && rm /etc/postfix/transport

exit 0

/etc/zentyal/hooks/mail.postsetconf

#!/bin/bash

cat /etc/zentyal/hooks/postfix/transport >> /etc/postfix/transport
postmap /etc/postfix/transport

exit 0

/etc/zentyal/hooks/postfix/transport

b@example.org    smtp:mail-b.example.org    # only this recipient is affected
example.org      smtp:mail-b.example.org    # any recipient (local delivery has priority, however)
.example.org     smtp:mail-b.example.org    # all sub domains are affected (e.g. lists.example.org)

I myself work with the first entry, in order to have greatest control. The second entry is also an option, though only useful if you are working with exactly 2 mail servers, or the further mail servers are addressed from mail-b.example.org - though I would suggest doing the split right here (on mail-a.example.org), unless of course there is a firewall / routing issue avoiding you to contract any further mail server. The third entry is merely listed for the sake of documentation.

Now to explain what this will do: In the case of Zentyal not deleting our transport file (which is the case when zarafa is not used) we will remove the file with our mail.presetconf hook script. Our mail.postsetconf script will in turn append the contents for /etc/zentyal/hooks/postfix/transport and make the new database readable to postfix right away. The 'transport' file contains details on how to process the recipient b@example.org, namely by using sending the mail on to the server mail-b.example.org via the SMTP protocol.

Outcome

As postfix does a recipient check, the recipient must be known to postfix, either by there being a local mailbox or a defined alias. The transport map merely tells postfix how a certain address is to be delivered, however does not satisfy a recipient check - this is where the external accounts alias has its role to play: this tells postfix that the recipient is actually valid, and where to forward the mail to. Once postfix wants to deliver the email, it will have a look in its transport map, which tells postfix to send all email for b@example.org to the host mail-b.example.org through SMTP.

The only difference users located on our fictional server mail-b.example.org is the lesser amount of spam, as this is now totally in your control, especially if grey-listing is enabled, the amount of spam seen on mail-b.example.org will drop significantly. During the first few days I would advise keeping an eye on the logs for Mail and the SMTP Filter (Maintenance ‣ Logs ‣ Full Report) just to make sure things are going well and as expected.

In the case of my own setup, I am free to move individual users across to the new server when it suits them (and me) best. Until then the users residing on the "old" server (with regards to this article that would be mail-b.example.org) without really noticing a difference. Nor do they need new connection credentials in order to fetch their mail, or access web-mail.

Personal tools
Namespaces

Variants
Actions

Zentyal Wiki

Zentyal Doc
Navigation
Toolbox