Mail Services on Mountain Lion Server

With a few simple modifications, you can clear some of the errors generated by the Mail service on OS X Server, as well as eliminating logging detail that will be unnecessary during routine use.

If you’ve followed along with the earlier articles in this series, by now you’ve taken the first steps in setting up your server, have DNS fully operational, and have enabled the web server itself. You’ve completed several important performance tweaks to help get the most out of your server, you’ve improved security, and you’ve probably installed several extras like MySQL, phpMyAdmin, etc.

Now let’s take a look at the mail service. Provided you’ve configured MX records at your DNS provider, you should now be able to click on “Mail” in Server.app and switch on the service. In my experience, soon after enabling mail and sending a test message or two to a user account, Console begins filling up with with clamd and freshclam error messages screaming about the installation being outdated and being unable to update the ClamAV database from a remote server. (Problems with ClamAV are very much not restricted to OS X Server, by the way!)

In addition, I’ve encountered postfix/postdrop errors along the following lines:

Restarting the server clears up some of the ClamAV complaints but has no effect on the postfix config error. However, doing exactly what it says and restarting the mail service does seem to work. Oddly, there’s already a line at the end of the /etc/postfix/main.cf file which is almost what the error is demanding:

config_directory = /Library/Server/Mail/Config/postfix

Just adding another below it with the line from the error message does seem to do the trick, followed by a postfix reload and toggling the mail service off and on again from Server.app:

In my experience, repeated ClamAV error messages are a recipe for delayed and/or lost mail, so unless you’re especially keen to run anti-virus filtering at the server level, you may want to consider just shutting it down.

In addition, for some reason when first enabling the mail service, Server.app defaults to a “Custom” setting for authentication methods. If you have difficulty connecting with an email client, it may be worth changing this back to “Automatic”:

Alternatively, if you’d specifically like to disallow “Cleartext”, stick with “Custom” but get rid of the cleartext option.

You can get a list of all settings currently active for the mail service by checking from the command line:

One of those which you particularly might want to tweak is the default message size of 10 MB, which starts off like this:

mail:postfix:message_size_limit = 10485760

You can alter that limit (upping it to, say, 25 MB) like this:

If you’d like, you can also disable greylisting — which can be a royal pain when you’re first setting up a server and doing lots of testing — with the following:

And to set the subject line modification which the server will make when it detects possible spam:

By default, the mail service is set up to write quite a bit to the logs — probably more than is necessary, unless you’re specifically trying to troubleshoot something:

mail:postfix:log_level = "info"
mail:imap:log_level = "info"

You can reduce the amount written to the logs like so:

However, altering the log rolling interval for postfix alone has no effect on mail access logging, and at first glance anyway, it looks like you’re stuck with daily logs for mail access, clamav and amavis unless you edit their configuration files:

mail:postfix:log_rolling_days = 1

Note that postfix logs will still roll automatically when they hit 1 MB in size, but hopefully that won’t happen anyway if you’ve changed the logging level from “info” to “warn”. (Also, I haven’t explored in more detail how to change the rolling interval for mail access, etc., so it may well be possible to alter the log rolling interval for these services too using serveradmin.)

You may notice in checking the various settings visible only from the command line that the postmaster address has already been filled in, and this serves as a reminder that it’s good practice to ensure you have an account in place to catch email sent to standard accounts like ‘abuse@servername’, ‘postmaster@servername’, ‘webmaster@servername’, and last but certainly not least, ‘root@servername’. You can do this by replacing ‘servername’ with your real server name and using Server.app to add an alias for each to one of your standard accounts.

Incidentally, during the course of starting and stopping the mail service as you complete your configuration, you may also encounter errors like this in the log:

Since the error doesn’t tell us what keys are missing from the plist, I don’t have the foggiest idea what to do about this one.

Finally, if you happen to require server-side processing of email via PHP script, I’ll cover that in a separate article.

• macOS