Using the Mail Server Panel

Receiving mail from other mail servers

If your server has a domain name, and is reachable via its domain name by other mail servers on the Internet, then, so long as the Postfix SMTP server is running, it is already able to receive mail sent by these other servers.

All you need to do is to tell Postfix is which domain it is supposed to receive mail for, on your behalf. You enter the domain name into MailServe's Domain Name field, as shown below, and Restart Postfix to make the setting "stick".

The Mail
Server Panel

Viewing the stored mail—using POP3 and IMAP servers

The Postfix SMTP server does the job of talking to other mail servers, sending mail to and receiving mail from these other servers. All incoming mail is stored in an Inbox—one for each mail user on the server.

The job of providing a view into these stored mail for every mail user is done by POP3 and IMAP servers.

IMAP additionally provides the user with a folder structure on the server to organise his stored messages.

MailServe Pro offers a choice of two IMAP flavours. With UW/IMAP, the folder structure is only a single-level deep. Dovecot is more powerful. It allows the user to create nested sub-folders, any level deep. Dovecot is also faster.

Choose one of the two—go to its relevant section (UW/IMAP or Dovecot)—and turn it on. The Port Status lights should look like that below. Then move to the next section.

Setting up—on the server machine, as well as on client machines on the local network

We assume that Postfix is running and the POP3 or IMAP server is also running, and the server is reachable via its domain name from running on the server machine, as well as from any client machine on the local network.

Assume that the domain name is "" and the mail user's account name is "bernard" (which is the OS X short name as created using the Accounts Pane in System Preferences).

Finally, assume also that the "Relay Mail from" parameter in MailServe is left at its default state, i.e., the server is set to relay mail from all machines on the local network. Machines outside the network are blocked from sending mail.

This is how you would set up on the server machine, as well as on any client machine on the local neiwork, assuming we are accessing the IMAP server as the Incoming Mail Server (the user name and password are the same as was created for an OS X user account on the server) :

Since the server, in this case, is set to relay mail from all machines on the local network, no authentication is necessary when we're setting up the Outgoing Mail Server.

At this point, you can test that you can send and receive mail from a mail client running on every machine on your local network, including the server.

Setting up—a general setup that will work for all client machines, either inside or outside the local network

The previous setup was useful for testing that the basic, most important, functionality of the mail server is working properly.

A more useful setup is shown below. It'll work for all machines, inside or outside the network, so you won't have to change settings on a MacBook, say, when it moves from one network to another.

This involves turning on SMTP Authentication in MailServe, so that the server will authenticate every mail client who seeks to relay mail through the server, both inside and outside the local network (with the exception of processes running on the server machine itself), like PHP scripts :

Use the OS X built-in user accounts method, where every OS X user account you create on the server machine is also a mail user who can send and receive mail.

The user name and password combination you need to set in the mail client corresponds to the OS X user account short name and password you set using the Accounts panel in System Preferences.

The OS X built-in user accounts method, together with SSL (which we will cover later) constitute a safe, simple, and effective mechanism for implementing security for the mail server.

This is how the Outgoing Mail Server is set up in to correspond to turning on SMTP Authentication for the Postfix mail server. Note that the authentication method must be "Password" and not Kerberos, etc. :

SMTP Auhentication via SASLDB

There is an alternative method for setting up SMTP Auhentication—using a mechanism called SASL and an SASLDB database to store the username:password combinations.

The situation in which this may be useful is when you're not running a full-fledged mail server with POP3 and IMAP services, but only for the outgoing SMTP services, in which case you can avoid creating OS X user accounts but just use a userID:password list.

This is how this is set up in MailServe:

SASLDB uses the MD5 Challenge-Response authentication mechanism and you need to set this in the Outgoing Mail Server setup in :

But, if you need to receive mail for your users, and especially if you need somewhere to store all your users' IMAP folders on the server, you're better off using SMTP authentication via the built-in OS X accounts method because you'll have just one password mechanism to deal with. This is secure enough when used in conjunction with SSL.

Turning on SSL

At this point, you have a safe and fully functioning mail server that relays for all legitimate, authenticated users but is secured against spammers.

You can improve its security by turning on SSL and encrypting the message streams between server and client, both for sending and receiving mail.

MailServe helps you create a test SSL certificate so you can turn on SSL mode for the server. Edit the SSL parameters in the MailServe interface to fit your needs (but keep to two characters wherever I've used two characters in the sample data entry fields). Then click on the "Create a Test Cert" button :

The MailServe interface will show that SSL is available for SMTP and you can turn it on by clicking on "Enable SSL over SMTP", as shown above. You can even require that SSL be turned on in the mail client.

This is how you set up the client to offer to negotiate the SMTP connection over SSL (click on the "Use Secure Sockets Layer (SSL)" button) :

With the SSL cert created by MailServe, you can even turn on SSL for IMAP and POP3, as shown for the case of IMAP, below :

MailServe create these SSL certs in /System/Library/OpenSSL/. They are in the .pem format. They can replaced by "real" certs you buy from a Certification Authority (CA).

Using the Other Features of the Mail Server Panel

Additional Domain Names

If your server hosts more than one domain, you can list the additional domains in this field (separated by commas, e.g.,, so that Postfix knows that it has to accept messages sent to these domains.

Make sure that these domain names work first and that they're also pointing correctly to your server machine.

There is no separation between users into particular domains. For example, on my server, mail for and mail for will both reach me in my single mail box on the server, under the user name bernard.

To get mail for and sent to two different mail boxes, you need to set up Virtual Domains.

Virtual Domains

Ordinarily, even if you receive mail for two domains - and - will use the same mailbox as But, using the Virtual Domains field, you can make things work a bit differently.

You need to create two separate user accounts on the server first, say, brendan and beekhim, respectively. Then make sure that the two domains, and, are listed in the Virtual Domains field. Then you can use the Virtual Domains Alias Mappings field to point to brendan's mailbox and to beekhim's mailbox, as shown below :

Note that you can also add an entry for sales for the primary domain (i.e.,, above) and point it to another mailbox (i.e. user account) on the server.

This is how you manage the account using :

The messages for will go to the mailbox of the real user, beekhim, on the server.

Alternate SMTP Port Numbers

This allows the server administrator to open more ports (beside port 25) for mail clients to contact it. For example, it may be useful to add port 2525 (and also 52525, separated by a comma). This way, if your users happen to be on a network that blocks outgoing mail from using port 25, your users would still be able to relay mail out your server by switching their mail clients to use either port 2525 or 52525.

You can also use this field to open more ports for other mail servers to contact your server, to deliver mail to it. For example, you may be attempting to set up a mail server on a network whose ISP blocks incoming port 25. This way, no other mail servers will be able to deliver mail to your server. There is a way around this, that people using's MailHop feature (for example) have expoited. But you need to open an alternate port that MailHop can use to contact your server (check the example). Set this port number in MailServe's Alternate SMTP Port Numbers field.

Real-time Black Lists

This field allows you to list RBL (Real-Time Black Lists) sites that you want your server to check against. If you have more than one, you should separate them by commas. Such sites include,,, etc... You can choose from among a lot more if you search Google.

Mailbox Size Limit

Set to 0 for no limit, which may be useful for people running Fetchmail. The default is about 50 MB.

Catch All Mail Box

You can choose who, among your users, gets to be swamped by mail that cannot find a valid user on your server. If you elect not to nominate anyone, all these messages will be bounced back to the sender.

Or sent into the black hole, if you choose /dev/null in the popup menu.

The Access Field

The Access field can be used to blacklist individual mail senders from sending mail to your site, or even entire domains. REJECT REJECT

It can also be used to stop mail from reaching a particular user account on your system, e.g., for a user that has since left the company :

brendan@ REJECT

Imagine that Brendan has left the company but he was subscribing to lots of mailing lists. The above setting in the Access field will bounce all mail for brendan back to the sender. Note : use brendan@ as a wild card setting, if you're receiving mail for more than one domain. If you want to specify that you want to block Brendan's mail for just one specific domain, use REJECT.

The Aliases Field

Some required entries for Aliases are already created for you. Each site needs to have a Postmaster and a Root user so that other ISPs and you own system processes can contact a responsible person when they find problems with your system. MAILER-DAEMON is the conventional name attached to bounced messages. When senders find that their messages have bounced, they may need to contact someone for clarification. Their replies to their bounced messages will go to MAILER-DAEMON, so you need someone to pick these up.

The first line in the example, below, shows that you can create e-mail groups quickly by entering a group name on the left-hand side of an Alias entry, and entering a series of user names, separated by commas, on the right-hand side, which can include users from other domains.

nightrunner: haihwee,beekhim,
postmaster: bernard
root: bernard
mailist: :include:/full/path/name/to/mailinglist.txt

The last line in the example, above, shows another way of creating e-mail groups - by pointing the mail server to a file that contains a list of e-mail addresses, with one address on each line.

You can also send all mail destined for a specific user into the black hole :

baduser: /dev/null

The Custom Postfix Settings field

This is meant to allow experienced Postfix users to add their own modifications to the Postfix configuration that have not been taken care of by the MailServe user interface. These will not be over-written when you do a Restart Postfix.