 |
|||
|
Step 2 • Receiving Mail from other Mail Servers The Mail Server Panel 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 which domain it is supposed to receive mail for. You enter the domain name into MailServe's Domain Name field, as shown below, and Restart Postfix to make the setting "stick".
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 Dovecot, which provides both a POP3 and an IMAP server, and which you can turn on at the Dovecot panel. (IMAP is recommended because it provides the user with a user-definable folder/sub-folder structure). If you turn on POP3 and IMAP on Dovecot (ignoring their SSL variants for the moment), the Port Status lights on MailServer should look like that below :
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 Mail.app running on the server machine, as well as from any client machine on the local network. Assume that the domain name is "cutedgesystems.com" 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 Mail.app 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 required 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 Mail.app—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 Mail.app to correspond to turning on SMTP Authentication for the Postfix mail server. Note that the authentication method must be "Password" and not Kerberos, etc. :
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 Mail.app :
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/. The cert is in the certs folder and the private key can be found in the private folder. You can replace the test cert with a "real" cert that you buy from a Certification Authority (CA). MailServe includes a streamlined interface that can help you request for a cert from a Cert Authority and then help you pair the returned cert with its original private key (that was created at the cert request stage). You access this facility by clicking the "Use a Real Cert" button and this what you will see, a 4-stage process to acquire an authentic certificate from a Cert Authority:
You can also use this panel to save a pre-existing cert for use by your mail server (and your web server if you use WebMon to set up the web services). Just drag the certificate and key portions (either from text files on the Finder or text blocks copied from another application or the web browser) and place them into their respective fields. Then hit the Save Cert button. New in MailServe for Lion : the user interface now allows you to insert an Intermediate CA cert, if that is required by your Certification Authority. When you close the cert management dialog box, MailServe will be able to detect that a "real" cert is available for use and so allow you to turn on the SSL-related controls.
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., lifeassets.com, roadstead.com) 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 bernard@cutedgesystems.com and mail for bernard@roadstead.com will both reach me in my single mail box on the server, under the user name bernard. To get mail for sales@cutedgesystems.com and sales@roadstead.com sent to two different mail boxes, you need to set up Virtual Domains. Virtual Domains Ordinarily, even if you receive mail for two domains - domainA.com and domainB.com - sales@domainA.com will use the same mailbox as sales@domainB.com. 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, domainA.com and domainB.com, are listed in the Virtual Domains field. Then you can use the Virtual Domains Alias Mappings field to point sales@domainA.com to brendan's mailbox and sales@domainB.com to beekhim's mailbox, as shown below :
The messages for sales@domainB.com 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 DynDNS.org'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 dyndns.org example). Set this port number in MailServe's Alternate SMTP Port Numbers field. The Access Field The Access field can be used to blacklist individual mail senders from sending mail to your site, or even entire domains. spammer@yahoo.com 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 brendan@cutedgesystems.com 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,brendan@sky.com 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. |
MailServe for Lion
|
||
Note that you can also add an entry for sales for the primary domain (i.e., sales@cutedgesystems.com, above) and point it to another mailbox (i.e. user account) on the server.
This is how you manage the sales@domainB.com account using Mail.app :