| Mac@Work The Ultimate Business Machine
DNS Enabler
DNS Enabler can set up a fully functional buzzword-compliant Domain Name Server on Mac OS X with just one click. It is able to handle multiple virtual domains, multiple sub-nets, aliases, MX records (including specifying back-up servers on other networks), multi-homing, and creating the right number of reverse pointer and CNAME records - all from one convenient single window.
WebMon helps you set up PHP, WebDAV, and SSL on OS X's built-in web server. For SSL, WebMon helps you generate test certs, as well as the certificate request needed to obtain a live cert. You can also use WebMon to monitor your web server logs remotely via remote login through SSH (the secure shell).
Luca
Luca is an accrual-based double-entry accounting system. Create unlimited levels for the Chart of Accounts. Real-time postings, Balance Sheet, and Profit & Loss reporting. Tracks receipts, disbursements, receivables, payables, and statement of accounts. Supports multiple currencies, calculates forex gain or loss. And more.
LDAP Enabler
Activate and configure the built-in LDAP server on Leopard with just one click. Once enabled, you can use the LDAP server to store contacts information that will show up on any Mac (and iPhone), and keep them all updated from one central point.
|
MailServe for Tiger Introducing MailServe MailServe helps Mac users set up a totally buzzword-compliant mail server in less than a minute, the Mac Way. It sets up SMTP, POP3, IMAP and Fetchmail services, including support for SSL and SMTP authentication. Mac OS X Leopard Update : I've released a new version that will work with Leopard, which you can buy. Configuration files saved, using the File menu, in Tiger will work in Leopard. If you're upgrading to Leopard, instead of doing a clean install, it'll help if you do a de-install of MailServe for Tiger first, if you can, using the Red Cross. Note : Some mail servers may reject mail coming from a dynamic IP address, on the (flawed) assumption that such mail must be from a spammer. But this is how I've set things up so that I can continue to send mail from anywhere I happen to be.
Using MailServe The picture, above, shows you how you'll start off using MailServe. There are three major tabs - Outgoing Mail, Monitor Mail, and Incoming Mail - each of which may contain its own sub-tabs. The idea is that you use the Outgoing Mail tab to turn on OS X's built-in SMTP server, use the Monitor Mail tab to check that you can indeed send mail out your Mac, and then use the Incoming Mail tab to turn on the rest of the services that will make your Mac a full-fledged standards-compliant mail server, including providing support for POP3, IMAP and Fetchmail services. The Outgoing Mail Tab The Outgoing Mail tab consists of two sub-panels : accessed via the Basic tab and the Smart Host List tab. The Basic sub-panel, below, is where you start off. It allows you to turn on the Postfix SMTP server built into Mac OS X, which will allow you to send mail out the command line, from PHP or Perl scripts, or from Mac OS X applications like Mail, Eudora or Entourage. Look for the Enable Postfix button. Hit it. And that's it. If the Enable Postfix button is not enabled, e.g., if you've just upgraded from Panther and had run Postfix Enabler on it before, you can get the Enable Postfix button back by hitting the Red Cross at the top left corner of the window. In most cases, this would be it. You don't have to type in anything else and you can move on to the Setting Up Mail.app section.
Problems? However, you may find yourself faced with a few more obstacles before you can send mail successfully. For example, you may find that the ISP of the network (that you're currently on) is blocking your ability to send mail, e.g., by blocking port 25, the smtp port. You can test this using Terminal. First, type in this command: telnet localhost 25 If you see a : Connected to localhost. it means MailServe has successfully set up your Mac to send mail. You can type 'quit' at this point to get out of the telnet session. Now, do a : telnet cutedgesystems.com 25 If you do not see the "220 ESMTP Postfix" service ready response from the remote server, cutedgesystems.com, but instead the session times out, then you can deduce that the outgoing port is being blocked by the ISP. The Basic sub-panel gives you a few options to get around that. Using the other fields in the Basic Outgoing Mail sub-panel If your ISP blocks port 25 and requires you to go through their own SMTP server (what is called a Smart Host), enter their SMTP server name into the Smart Host Name field (otherwise leave it blank). Your built-in Postfix SMTP server will then contact this Smart Host and relay mail through it. Note : if the Smart Host needs to be contacted on a port other than 25, add the port number after the Smart Host name, after a colon. Like this : mail.singnet.com.sg:587 In addition, if your ISP requires you authenticate against its Smart Host, turn the Enable Authentication check-box on and provide the userid and password combination given by your ISP, as shown in the example below :
If your ISP requires that you connect to their SMTP server over SSL, turn the Require SSL check box on. After you've made any of these changes, click the Restart Postfix button to effect the change. Then test that you can now send mail out your ISP network, by sending mail out via the command line, PHP or Perl script, or from a mail client like Mail or Eudora. If you do get a connection and can send mail out, you might like to add a couple of other refinements. If you want your message to look like it's being sent from a particular domain (and avoid the "May be forged" headers that some ISPs' servers tag onto it), enter that doman name into the Masquerade As field. The Masquerade As field is particularly important for PHP programmers using PHP's built-in mail function. Enter a domain name into the Masquerade As field that corresponds to to the e-mail address that you want all replies to come back to, and you will find that your messages will get to their destination safely from the PHP scripts. Without this, the messages will get rejected. The last field on this panel is the Message Size Limit. Set to 0 for no limit. New MailServe Feature : If you need to keep a list of Smart Hosts, for when you are on different networks or locations, now you can. Use the Smart Host List tab, store them in the list provided, and you can pick them up in the popup menu when you're setting the Smart Host. For developers - the benefits of having your own SMTP server For PHP programmers, web designers, and other software developers, it's often useful to set up a local SMTP server on the development machine and communicate with it through "localhost". This is because you can let the local SMTP server do the job of communicating with a Smart Host, or set up the SSL connections, if required, or work with the DNS System, without your having to figure out what to do to effect these in your code. In your code, you simply talk to "localhost" and leave it to the Postfix Enabled-SMTP server to do the rest. This is how you set up Mail.app to talk to the local SMTP server.
Set up the POP or IMAP account information the usual way, for the Incoming Mail Server. Set them to point to whichever mail server is providing the POP or IMAP services. You can use MailServe set up POP and IMAP services so you can become your own ISP - see MailServe's Incoming tab section, below. To use use your own built-in SMTP server, set the Outgoing Mail Server to localhost or 127.0.0.1, as shown above, and that's it. Make sure that the Authentication pop-up menu is set to none because you don't need to authenticate with your own built-in mail server. (... though the built-in mail server could, in turn, be made to authenticate with other mail servers, so it can relay mail out through them, as I had mentioned earlier.) If you use Eudora or Entourage, you can set them up in a similar way. In summary, this is what you're doing. You set up your POP or IMAP accounts so that replies coming back to you will reach you on your mail client. But the messages sent out your Mac via localhost will be despatched directly to the recipients. Note for PowerBook users : You may like to know if a large attachment has been sent out your machine, so you can close your PowerBook lid. Look into the Monitor Mail tab's Log sub-panel and check for a mail log entry that indicates Status=Sent for that particular message. Warning: If you're only going to send mail out and not trying to set up a full mail server (see next section), do not use the Incoming Mail tab because the settings for the two situations are slightly different. Specifically, do not enter a domain name into the Incoming Mail tab's Basic sub-panel because it'll cause Postfix to hold on to mail that are addressed to people on that domain, rather than sending them out. The Incoming Mail tab MailServe can be used to set up a fully functioning mail server, complete with POP3, IMAP, and Fetchmail services. Workstations on the local network can use this server to relay mail to each other, as well as to send them out to the rest of the world. This section describes how you would set this up. First, make sure that you've already been able to send mail out successfully to other mail servers. If not, please review the earlier Outgoing Mail tab.
Make sure you have a valid domain name and that it is pointing correctly to your server machine. If it is, enter it into the domain name field. In the example above, my domain name is cutedgesystems.com. Once you've done this, click on Restart Postfix, and that's it. I've set up a mail server for the domain cutedgesystems.com and all machines on the same network as the server can send mail through it. Multi-domains Note : If you're able to serve out more than one domain on your server, you can tell your mail server to receive mail from those other domains by adding their names into the Additional Domain Names field. Please note : When you're setting up a mail server that is accessible by the rest of the world, you must have a valid domain name. Check out this tutorial if you want to try this out using a free domain name. You need to check that the domain name works. The simplest way to do this is to turn on the web server on the same machine you are using to run your mail server (using OS X's Sharing Preferences). Then, fire up a web browser, like Safari, and see if you can hit the web pages that you know you have on this machine. Setting up POP3 and IMAP Services It's important to realise at this point that you need to set up user accounts on the mail server to collect (and act as distribution points) for the in-coming mail. To create an account for a mail user, simply create a New User on that server machine using the System Preferences -> Accounts panel. Once you've created your user accounts on the server, you can choose between two different mechanisms that will allow your mail users to download their in-coming mail to whatever machine they happen to be using as their workstation. POP3 is a simple mechanism for transferring mail to a mail client software like Eudora, Mail.app, or Entourage. IMAP is a "smarter" system because you can use more than one machine to read your mail and the state of your mail box is synchronised across all these machines (in terms of the messages last read, state of drafts, etc.) You can set up both POP3 and IMAP services using MailServe and have both running at the same time, allowing your users to choose which service they prefer. So, next, you will need to enable either POP3 or IMAP services (or both) so that all the machines and users on your network can retrieve their incoming mail. Leave all the other settings alone, for the moment, and click on the Enable POP3 button or the Enable IMAP button, depending on which mode of mail service you prefer to run. Then hit the Restart Postfix button. Check that it works Assuming that my domain name is cutedgesystems.com, this is how I'll set up the mail client, OS X's Mail.app, on each user's machine. Test it first on the local machine, i.e., the same machine you're using to run your server. Enter your domain name into your mail client's Incoming Mail Server and Outgoing Mail Server fields. The User Name and Password fields will correspond with the name and password of a user you had created using the Systems Preferences - Accounts Panel on the server machine. (If you've enabled the IMAP server, you can also use the Account Type: IMAP).
When you are ready, use Mail to send mail out to anybody you know and see if you can get a reply. The replies will come back to the same server. You can pick them up using Mail because MailServe has equipped your server with POP3 services. The next step is to share the mail server with all the other machines on your network. Share the Mail Server Via an Airport Base Station Mac users typically share an Internet connection in three ways. One way is to use an Airport Base Station to connect to the Internet and then share its connection. There's a tutorial (OS X, Broadband, and the Airport Base Station - but pay special attention to the section covering DNS) which will show you how to get a server running behind an Airport Base Station. In this case, if you've set up Mail for the other machines in the way shown above, you've really got nothing else to do. So long as you've got your DNS settings right (so that your other machines know where your mail server is), the other machines can now use your mail server to relay mail. Via Internet Sharing The second way to share an Internet connection is to turn on Internet Sharing on the mail server machine. If your mail server is equipped with an Airport card, this is really easy. The Airport card allows the server to create a secondary internal IP network which the rest of your machines can get up on, provided they're also equipped with Airport. In this case, besides setting Mail in the way shown above, you've also got one more thing to do on your server. By default, the Airport network created by the mail server will use a network in the range 10.0.2.x (please confirm that this is true before proceeding). Use MailServe, look for the Access field, and enter the following into a new line in the Access field : 10.0.2 OK This tells the mail server to allow all machines on the internal 10.0.2.x network to relay mail through the server. Via a Router The third way to share an Internet connection is via a router. The things you have to do here are a combination of steps from the first two methods described above. You have to enable port mapping on your router to make sure that ports 25 and 110 are mapped to the specific internal IP address you have reserved for your server (say, 192.168.2.18). Then, you have to ask Postfix to relay mail for your internal network, which should be 192.168.2, in the example above. Use MailServe, look for the Access field, and enter the following into a new line in the Access field: 192.168.2 OK This tells the mail server to allow all machines on the internal 192.168.2.x network to relay mail through the server. Please note : between the three ways, described above, for sharing an Internet connection, the ones with the router or Airport Base Station are the safer options. This is because you're situating the server on a private network behind the router or Base Station. Postfix is programmed, by default, to reject all attempts to relay mail through it by machines sitting outside its local network. In an Airport network, this network spans the private 10.0.1.x range. The mail server will relay mail only from its own 10.0.1.x network, rejecting all other attempts. The other way of sharing an Internet connection, through OS X Internet Sharing, though cheaper and more convenient, exposes your server to attempts to relay mail through it by other machines sitting on your ISP's network (because it is sitting directly on your ISP's network). Other uses for 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 Catch All Mail Box - mail addressed to no valid user 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 Additional Domain Names Field If your server hosts more than one domain, you can list the additional domains in this field (separated by commas) 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. Ordinarily, 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, see the Virtual Domains example, below. Relay Mail From - the server machine only or all machines on subnet This option allows you to prevent your Mac acting as an open relay if you've placed it directly on a broadband line. The default setting is to allow all machines on the same subnet as the server to relay mail through it without needing to authenticate, which is convenient for getting a shared server up quickly. But if you've placed the server directly on a broadband or dial-up line, then you will have all machines sitting on your ISP's network becoming your local network, inadvertently creating an open relay. Clicking on the "Relay Mail From : This server machine only" choice will close up the open relay. If you need to still allow mail relay from known users, turn on authentication. This will be the safest option. 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 stick in the Postfix config file at /etc/postfix/main.cf and will not be over-written when you do a Restart Postfix from MailServe. (In this way, MailServe works a little better than OS X Server's Mail Admin tool). The following fields are new to MailServe : The Mailbox Size Limit field Set to 0 for no limit, which may be useful for people running Fetchmail. The default is about 50 MB. The Alternate Port Numbers (for SMTP) field 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 Port Numbers (for SMTP) field. The Real-time Black List (RBL) Sites field 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 bl.spamcop.net, sbl-xbl.spamhaus.org, cbl.abuseat.org, etc... You can choose from among a lot more if you search Google. The Virtual Domains field & Virtual Domains Alias Mappings field 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 :
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 :
The messages for sales@domainB.com will go to the mailbox of the real user, beekhim, on the server. The Incoming Mail - Security sub-panel This allows the administrator to turn on SMTP authentication (SMTP-AUTH) for the mail server. This allows the mail server to be accessed remotely only by authorised users, whose name:password combinations have been registered with the server. By default, machines on the local network need not authenticate to send mail through the server. There is a radio button, below, to turn this off, so that you can force everybody to authenticate (by choosing the "Relay Mail from : This server machine only" option). This is especially important if you've placed your server directly on the broadband line, instead of behind a router or Airport Base Station, in which case all the other machines on your ISP's network becomes your "local" network! The safest practise is to turn on SMTP authentication and restrict mail relaying to just the server machine. This tab also allows the mail administrator to quickly create self-signed SSL certs for testing secured connections to and from the mail server.
If you need to turn on SMTP Authentication, you have two choices - use the built-in OS X user accounts or SASLDB. The first method is so simple to use. It authenticates against the Mac's built-in user account management - so you maintain just one set of passwords, using System Preferences. Turn it on and you're done. (But the downside is that passwords are sent in the clear, unless you turn on SSL encryption, as shown below and explained in the SSL section.) In Mail.app, under Outgoing Mail Server, click on Server Settings and set up the SMTP Server Options, as shown below. You need to make sure you enter the same User Name and Password combination that you gave to this user, using the server's OS X System Preferences panel :
The second method, SASLDB, is considered to be more secure because passwords are never sent down the wire, only tokens. If you choose to turn on SMTP Authentication via SASLDB, you will need to provide the server with a list of username:password combinations, for each user who will be needing to send mail remotely through the server. In Mail.app, under Outgoing Mail Server, click on Server Settings and set Authentication to "MD5 Challenge-Response". Enter the username:password combination that was registered for this user on the server.
You can turn on or off SSL mode to encrypt the communications between client and server, over SMTP, POP, and IMAP. However, you will need to have the appropriate SSL certs in /System/Library/OpenSSL/certs before you can enable SSL. You can use this panel to create test (self-signed) certs to test the SSL connection to and from the mail server. You can always replace them with "real" certs, of the same name, in the future. New in MailServe is the ability to require SSL be set in the mail client before your server will agree to relay mail for it. Just check the Require SSL option.
If you're testing the SSL connection, make sure you quit Mail.app and come back in again, when you switch the server from non-SSL to SSL mode. This is important, and had been the source of quite a few support calls. Mail.app seems to cache the information it keeps about a connection. If you switch modes, in mid-stream, it may get confused and you will see a connection error until you quit Mail.app and come back in. Also, if you're using the self-signed test certs, you will see the following dialog box thrown up by Mail.app, when you first send mail over SSL :
This is OK. It shows that the SSL mode is working. The cert used is a self-signed cert that hasn't been verified by any of the known certification services, e.g., Verisign. The cert can still be used to enable SSL encryption between client/server communications. If you click on "Show Certificate", it will show you the data you have set for this certificate (if you've updated the Country/State/Locality fields before clicking on the "Create SSL Test Certs" button. You can always replace the test certs with "real" certs of the same name. They are stored in /System//Library/OpenSSL/certs. There is one way to get rid of this dialog box. Click on the Show Certificate button. Drag the certficate icon that you'll see in the top left hand corner of the extended dialog to the Finder. This will create a file and you double-click on it. This will launch the Keychain Access application. Choose X509 Anchors when you're presented with a popup menu. Then import that certificate into the Keychain. The Incoming Mail - Fetchmail sub-panel Fetchmail is useful for people who have many other POP or IMAP servers that they read mail from. Fetchmail can be set up to check these other POP or IMAP servers periodically and download all that mail, consolidating them into one single mailbox on the local server. This is a good reference site for Fetchmail (the official man page) :-
To set up Fetchmail, go to the Fetchmail tab, click the + button to add a POP or IMAP server to fetch mail from, enter the server name, leave protocol as AUTO, enter your user ID and password at this server, and your user name on your local server. Leave the Keep column as NO to fetch all messages from the server and delete them after downloading. If you set Keep to YES, then they're left on the server, but Fetchmail attempts to figure out which messages are new and tries to download only the new ones. If this doesn't work well, leave Keep as NO. Leave SSL to NO, unless your ISP requires the connection to be over SSL. If you know that the ISP server is a POP3 server, it helps to set the protocol explicitly to POP3 rather than to leave it as AUTO. The Int column means "Interval". The default polling interval is one minute. You can set, in the Interval column, how many multiples of this polling interval you will make Fetchmail wait before contacting each individual ISP mail host. The Via field is optional. It can be made to contain the DNS name of the ISP POP or IMAP server. If set, this will override the Server Name field. Now why would you want to do that? You may have several accounts polling the same ISP mail server. If you enter the ISP server name into the Via field rather than the Server Name field, you can use the Server Name field merely as a label, a descriptive name for each account set-up. The Via field is optional. It's for people whose existing Fetchmail setup already uses a Via parameter. You can choose to ignore it if you want. Leave the Node and Aka fields empty, unless you want to set up Fetchmail to work in multi-drop mode whereby mail from one single mailbox at the ISP server is split by Fetchmail into multiple mailboxes at the local server. Fetchmail in Multi-Drop Mode Typically, multi-drop mode works this way. The ISP provides you with an account or node on the server, say node.isp.net. Your web server is at www.node.isp.net and you can get mail delivered to user1@node.isp.net, user2@node.isp.net, etc... When you need to read those mail, you log in to the ISP server as user name "node" and give your password. But user1 and user2's mail are all in the same mailbox. What you want to do is to get Fetchmail to do the logging on for you, and download all those mail, but split them into individual mailboxes that you have created on your own server for user1 and user2, etc. Then your users will log onto your local server and read their mail (coming down from isp.net) as if these had been sent to the local server all along. Fetchmail in multi-drop mode needs a couple of hints to help it on its way. First, you will need to enter the node name into the Node field. In Fetchmail parlance, this would be the localdomains parameter. In our example, we will enter "node.isp.net" into the Node field, i.e., the right hand side of the @ sign in the email addresses you've been given by the ISP. Then you may need to enter the other names that the ISP POP or IMAP server is known by into the Aka field. You can find this out by doing a "dig +short MX pop.isp.net" in the Terminal, where pop.isp.net is replaced by the POP or IMAP server you need Fetchmail to download the mail from. By giving more information about what likely names the ISP mail server may be known by, it can help Fetchmail figure out, from the mail headers, where each message should be delivered to on the local server. The Monitor Mail Log sub-panel You can use this panel to monitor the mail log. The Get button retrieves the last 200 (or so) records from the tail-end of the mail log, in reverse order. Because the table does not have enough width to show all the details of the connection, you can click on any line and the information will be re-displayed in the detail-fields below the table.
The mail log can be used to check if a large attachment has been sent out the mail server. Look into the mail log for a Status=Sent indicator for the specific message and destination. The Monitor Mail Queue sub-panel You can use this panel to monitor the mail queue. The Get button retrieves the mail queue. You can flush the queue or choose a particular message to delete - useful for when there are messages stuck in the queue.
The Monitor Fetchmail Log sub-panel You can use this panel to monitor the Fetchmail log, extracted from /var/log/fetchmail.log. It works just like the mail log.
Micellaneous There is also a Postfix Config Summary button at the bottom of the panel. When clicked it will show a summary of the active Postfix Configuration Parameters. If you know enough Postfix, this is useful for checking if the system is set up the way the GUI says it has been set up. Note that you can print out both the mail log and the Postfix configuration summary. (Actually, you can print any piece of information by just clicking on it, to give it the focus, before doing a Print from the File menu.)
The Mail Server and the OS X Firewall You should check your mail server machine to see if you have OS X's built-in firewall turned on. If so, you should learn how to set it so that information could still pass through to your mail server. Look here to see how this is done. In summary, you should open, at least, ports 25 (smtp), 110 (pop3) and 143 (imap) in the firewall. If you've turned on SSL, you should also make sure ports 995 (pop3 over SSL) and 993 (imap over SSL) are opened. Release Log 2.0. 29th December 2005. This is the first commercial release of MailServe. 2.0.1 1st January 2006. The Fetchmail launch daemon was re-spawning itself when launched on the faster machines due to some timing issues. This has been fixed in this release. (Thanks, Klaus Nielsen, for helping out and pointing the way to the solution. Really appreciate it). Also, Fetchmail could not deliver mail to machines that have been set up to receive mail for more than one domain. This has also been fixed. 2.0.2 2nd January 2006. Realised that I cannot depend on the characters in the mail queue report to be divided according to columns of fixed width. So I had to find another way to parse the mail queue report. This had resulted in the buttons and the table for the mail queue panel not working correctly on different machines. This has now been fixed. 2.0.3 13th January 2006. Includes a Danish localisation by Sebastian Adorján Dyhr. 2.0.4 19th January 2006. The application couldn't retrieve a password that is longer than eight characters from the Keychain. This bug has been fixed. 2.0.5 24th January 2006. There was a bug where the table of log records always left out the latest line. This has been fixed. 2.0.6 2nd February 2006. As requested, here it is the first Universal Binary version of MailServe. Nothing else has changed (besides fixing the user interface bug for the Mailbox Size Limit field, which didn't get anchored properly during resize). I've left the previous PowerPC-only version available, just in case. 2.0.7 16th February 2006. Improved the Fetchmail interface to include support for operating Fetchmail in multi-drop mode (where mail from one single ISP mailbox is split into many individual mailboxes in the local server). Also added the ability to save the current configuration, including the log records, into a double-clickable .msrv MailServe Config file. 2.0.8 21st February 2006. Fixed a bug when reading back the Fetchmail config file, when a Fetchmail keyword is found in the user's data. This update makes the Fetchmail config file parser a little bit smarter so that it won't make such silly mistakes next time. 2.0.9 21st February 2006. Added the ability to select SSL for a Fetchmail connection. Also, re-organised the Keep/Fetch/UIDL set of Fetchmail options to show a single Keep option because the values of the other two can be derived from the value chosen for Keep. There is now also a Fetchmail log monitor tab. Also, fixed a bug while reading back a saved config file that has the luser-relay parameter left in an indeterminate state. MailServe is a Universal Binary that will run truly native on Intel Macs 2.1 14th March 2006. It is 2.1 to indicate that it's a fully tested Universal Binary release. The application and the included POP and IMAP binaries, as well as the saslpasswd2 tool needed for sasldb password authentication, are now all Universal Binaries. (If you are running MailServe on an Intel Mac, just use the Red Cross to re-enable the Enable buttons and you will be able to replace the current POP and IMAP executables with Universal Binaries.) Also, new in 2.1, is a split screen view to separate the Aliases and Access pair of fields from the Virtual and Custom Postfix Settings fields. 2.1.1 19th March 2006. There was a user-interface bug. When the split view containing the Access, Aliases, Virtual and Custom Postfix Config fields was re-sized, the text in the fields may get corrupted when they're scrolled. This has been fixed with this release. 2.1.2 23rd March 2006. It contains support for the Via parameter for Fetchmail, a new Traditional and Simplifed Chinese Localisation, and a user interface bug fix for the log monitor table (an extraneous last column appears when the window is enlarged). 2.1.3 21st April 2006. This latest release adds a French localisation from Joselyne Rochaud and Corentin Cras-Méneur, who also did the DNS Enabler French localisation. Thanks ! Josy and Corentin. I really appreciate it. 2.1.4 5th May 2006. There were three changes : (1) The Access field now allows you to specify a user that you want to block email from reaching and bounce that back to the sender, e.g., for a user that has since left the company. (2) Added a Virtual Domains field to distinguish that from the Additional Domains field. The mail server will receive mail for all users for the primary or additional domains, but it will only receive mail for the specific e-mail addresses listed in the Virtual Domains Alias Mappings field, when you choose to use Virtual Domains. You can have some domains listed as "real" domains, and others as "virtual" domains, at the same time, with the difference being that you must specifically list the "virtual" email addresses you wish to receive mail for, and to whose "real" mailbox you want to direct the mail to, in the Virtual Domains Alias Mappings field, when you choose to use Virtual Domains. (3) Finally, I've changed the check box that allows the user to stop an open relay (in the Incoming /Security panel) into a radio button to more clearly convey its intent. 2.1.5 16th July 2006. Contains Fetchmail improvements. Added the ability to specify a global value for the Polling Interval (default 60 seconds) and the Time-out Interval (default 45 seconds but can be set to 0 for no time-out). Also the quotes around the * in the .fetchmailrc file (when Fetchmail is used in multi-drop mode) interfered with the multi-drop operations. This has been corrected in this release. 2.1.6 20th July 2006. Updated MailServe to handle a bug introduced by the OS X 10.4.7 update (that "Workaround Bonjour" thing) whereby the system would stall for about 30 to 60 seconds whenever a launchdaemon (like Fetchmail, BIND, etc) is launched by a call to /bin/launchctl. 2.1.7 17th November 2006. Added a new Norwegian localisation, by James Bjerkholt. Thanks, very much, James :-) It looked very nice. |
MailServe is the successor to Postfix Enabler. It does a lot more now, in terms of supporting mail server-type features than simply enabling Postfix.
Download : MailServe.zip The latest version is 2.1.7 MailServe & the POP/IMAP libraries are all Universal Binaries. Read the Release Notes. Localisation Credits : Danish- Sebastian Adorján Dyhr. French - Joselyne Rochaud and Corentin Cras-Méneur Norwegian - James Bjerkholt, Traditional & Simplified Chinese - Hai Hwee. MailServe Features :
Caveats - Things to Note :
|
||||||||||||||||||||||||||||||||||||||||
