Posts

Why do postconf -n and postfix reload produce unexpected output on OS X Server 5?

If you’ve been a long-time OS X Server user, especially from the days prior to OS X Server 5, then you’ll find that commands that used to work fine, suddenly produce unexpected output.

For example:

postconf -n

may show you Postfix parameters which are completely different from what you would expect them to be.

While:

postfix reload

may show you errors that shouldn’t be there.

The reason for this is quickly found. In recent years, and especially so in OS X Server 5, Apple has been moving server related binaries to:

/Applications/Server.app/Contents/ServerRoot/

and server related configuration files to:

/Library/Server/
/Library/Server/Mail/Config/postfix/

Thus, when you call postconf -n you are actually using /usr/sbin/postconf -n and displaying the contents of /etc/postfix/main.cf instead of using /Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf -n and displaying the contents of /Library/Server/Mail/Config/postfix/main.cf.

While it makes lots of sense and allows for unbundling OS X Server from the underlying OS (OS X Server 5 works on both, Yosemite and El Capitan) it is a transition which is still not complete and has its inconsistencies. Some commands (e.g. mailq) are still in their old locations due to compatibility issues with older software (sendmail in this case).

Tip: Use postqueue -p instead of mailq

Although it can drive you mad at times, overall, it is a welcome change made for good reasons.

That said, let’s see how we can make sure we use the correct binaries and configuration files.

As mentioned, binaries (applications) for Postfix are now to be found under /Applications/Server.app/Contents/ServerRoot/. So the first thing we need to do, is to use those binaries, instead of the ones under our main root /.

There are multiple ways of achieving this.

1. Use the full path to the binary:

Instead of simply typing:

postconf -n 

we would need to type:

/Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf -n

Not exactly elegant, but it works.

2. Modify the PATH environment variable:

While this requires a little bit of work upfront, it will save you lots of time in the long run.

If you look inside /private/etc/paths.d/ you will find a file called com.apple.server. This in turn contains the following two paths:
/Applications/Server.app/Contents/ServerRoot/usr/bin
/Applications/Server.app/Contents/ServerRoot/usr/sbin

Unfortunately, paths added inside paths.d will be added to the end of $PATH. So if you issue for example postfix reload, you will still use /usr/sbin/postfix instead of /Applications/Server.app/Contents/ServerRoot/usr/sbin/postfix

Note: There are many ways of modifying the PATH environment variable. Choose the one you prefer or use the method outlined below.

In your users home directory (e.g. /Users/myadminaccount/) create a file called .profile.1

Inside it, add:

export PATH="Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/mysql/bin"

Note: If you already have other custom paths set up, you will need to adapt above instructions to reflect those paths as well.

Save the file, close and re-open your terminal window (or exit and re-connect via SSH) and you should be good to go.

If in doubt, issue:

which postfix

and it will show you which command is going to be used.

The steps outlined in this article are not only valid for Postfix, but pretty much for any server related binary that has been moved under /Applications/Server.app/Contents/ServerRoot/.


  1. If you are unsure about how to edit a configuration file, have a look at our tutorial on how to edit text files 

Setting Logging Levels for Mail Services on OS X Server 5

With OS X Server 5, Apple has further modified logging level and files for mail services. This setup is well thought out for occasional log peeking through Server.app, but can make it a bit cumbersome for troubleshooting since different log levels are written into separate log files, rather than a single one.

The most important logs for a mail server are:

/var/log/mail.log
/var/log/system.log
/Library/Logs/Mail/mail-info.log
/Library/Logs/Mail/mail-debug.log
/Library/Logs/Mail/amavis.log

These logs cover the SMTP, IMAP and SPAM Filter parts of mail services.

If you are curious, there are more logs here:

/Library/Logs/Mail/

When troubleshooting, most of the time we have to focus on SMTP and SPAM Filters. IMAP, which is provided by Dovecot, tends to give very few issues nowadays (while this wasn’t true in the pre 10.6 era where Cyrus was used).

So let’s focus on SMTP and SPAM Filters.

The SMTP logs are written into /var/log/mail.log while the SPAM Filter logs we usually need are written into /Library/Logs/Mail/amavis.log

The amount of information written into these logs depends on the logging level. The ones we care about are typically notice, info and debug

Most of the time you want your log levels to be at info. This gives you plenty of information for troubleshooting the most common issues. When running into real trouble, you might need even more detail which you get by setting the level to debug. Some object to keeping info on all the time as they claim that this generates lots of log entries and load on your server. Truth is, unless you are running mail services with hundreds of thousands of messages a day, this will never be an issue. Should you want to reduce the number of entries, you can set the log level to notice, but will have to compromise on the log detail you get.

Another factor is the time your log remains available before being rotated and archived or deleted. A good default setting is usually 1 day. However, most OS X Server mail servers aren’t so busy that you need to rotate daily, so setting it to 3-7 days gives you more detail to work with in the current log, rather than having to dig out archived logs. This is especially important if you suspect a breach and want to have a quick look at the past 48-72 hours.

Having said that, here is how to set what we discussed above:

sudo serveradmin settings mail:postfix:log_level = "info"
sudo serveradmin settings mail:postfix:spam_log_level = “info”
sudo serveradmin settings mail:imap:log_level = "info"
sudo serveradmin settings mail:postfix:log_rolling_days_enabled = yes 
sudo serveradmin settings mail:postfix:log_rolling_days = 3

To check your settings, you can for example issue:

sudo serveradmin settings mail:imap:log_level

Besides above log related commands, there are many more parameters that can be viewed or set via the command line. For an overview, issue:

sudo serveradmin settings mail

Be careful when unsure about changing a parameter and always make sure you have a working backup.

Another option is to merge SMTP and SPAM Filter information into one log. This of course comes down to personal preference. I like it, because I can follow the entire flow of an incoming or outgoing e-mail through SMTP and all connected filters, rather then having to peek into two separate log files.

To do so, edit1
/Library/Server/Mail/Config/amavisd/amavisd.conf

and make sure the necessary parameters are set as follows:

$log_level = 3;
$DO_SYSLOG = 1;              # log via syslogd (preferred)
$syslog_facility = 'mail';

From now on, all SPAM Filter log entries will be written into /var/log/mail.log rather than /Library/Logs/Mail/amavis.log for easy troubleshooting.


  1. If you are unsure about how to edit a configuration file, have a look at our tutorial on how to edit text configuration files on OS X Server 

Is My Server Running in Performance Mode?

In the earlier days (up to OS X Lion 10.7), Server Admin had an option to “Dedicate system resources for high performance services”.

This option is no longer available in the GUI, but it still exists on the command-line.

NOTE: If you are using OS X 10.11 El Capitan or greater, you will need to disable SIP (System Integrity Protection) first.

Check if your server is running in performance mode with

serverinfo --perfmode

If you find its NOT, its generally a good idea to enable it as performance mode tunes the system to run as a server.

You can do so by issuing:

serverinfo --setperfmode 1

When done, reboot.

How to Edit Text Configuration Files on OS X Server

Managing OS X Server, quite often requires one to manually edit text based configuration files. As do many of our tutorials and FAQs.

There are many ways of doing this. You can use a Terminal based editor or one with a fancy GUI. What is paramount though, is that you use a Plain Text Editor like TextWrangler, Textastic or BBEdit. Rich Text Editors like Microsoft Word or Pages can severely damage your configuration files. Keeping above in mind, the rest comes down to personal preference.

On OS X I prefer to either use PICO, a Terminal based editor or TextWrangler which has a simple but powerful GUI and good syntax highlighting.

On iOS, PICO – accessed through an SSH session with Prompt – or TextWrangler with its built in SFTP client are my tools of choice.

Whether I use a Terminal based editor or one with a GUI mainly depends on the task at hand. For quick edits of a few lines, PICO works well and is the fastest way to go. If I need to make lots of changes or need a good overview of the file I am editing, a GUI editor is way more comfortable.

Let’s have a quick look at how these work.

Assuming we want to modify Postfix’ main.cf, we would issue:

sudo pico /Library/Server/Mail/Config/postfix/main.cf

And be presented with a view like this:

Now we can use our cursor keys to move around, the backspace key to delete characters or simply type what we need. When we are done editing, we need to save and exit. The commands for this are at the bottom of the window.

In order to save and exit, we would hit CTRL-O (to write the file) and CTRL-X to exit PICO. Alternatively we can just hit CTRL-X and enter y when asked to save.

Have a good look at the available commands as there are more options like cutting text and page scrolling.

While it may need a bit of time to get adjusted to, mastering a Terminal based text editor can be a very useful item in your tool chest.

Using the GUI instead of Terminal

If you don’t like using Terminal, you can always use a Plain Text Editor like TextWrangler which would look something like this

and behave like any other GUI Plain Text Editor.
The choice is yours, just make sure you avoid Rich Text Editors like Microsoft Word or Pages. There are plenty to choose from, like TextWrangler, Textastic, BBEdit, SubEthaEdit, SublimeText and many more. The choice on iOS is equally large.

For this tutorial, let’s look at TextWrangler which is a powerful (yet free) plain text editor

TextWrangler allows you to navigate hidden directories (/etc /Library etc) and edit files even when they are owned by root.

IMPORTANT: Don’t use the App Store version
Due to app store rules, the version from the app store is not able to unlock/edit files.
Download the application directly from the publisher: http://www.barebones.com/products/textwrangler/

These steps walk you through editing a hidden/privileged (root) file. We’ll use /etc/php.ini as our example.

In TextWrangler, use the Open File by Name option in the File menu.
This allows you to simply paste the path/name: /etc/php.ini

OpenByName

Another way to open /etc/php.ini is with the more familiar Open Dialog from TextWrangler.
Be sure to choose the Show Hidden Files option.

open-dialog

ALWAYS backup a file before you make changes
Save a backup to your Desktop using the Save a Copy option from the File menu.
Because the file is owned by root, you’ll need to authenticate.

Screen Shot 2016-02-10 at 11.45.44 AM

We need to be careful editing this file, one out of place character could effect your system.
You did backup first, right ?

Let’s make a safe change.
In the php.ini file, comments start with a semi-colon.
Simply add a space at the end of one of the commented lines:

;;;;;;;;;;;;;;;;;;;
; About php.ini   ;  <<--- add a space at the end of this line
;;;;;;;;;;;;;;;;;;;

When you attempt to edit the file, you’ll be asked to authenticate again.
Once you authenticate, you can edit, then save the file.

That is all there is. Happy editing!

How to copy (bcc) all mail from specific senders to another address

Sender BCC Maps allow you to specify one or more senders along with a bcc_recipient address.
When an incoming or outgoing message matches sender_bcc_maps, the message is BCCd to the specified address

A few examples
  • BCC all mail sent from a fax or copier to a Fax/Copier archive
  • Bob wants all mail he sends from his 3 company addresses copied to his AOL account
  • Audit mail from a specific address

Create the sender_bcc file

Here is how I would create the file using pico.
note: when done editing with pico, hit ctrl-x to exit and y to save

sudo pico /Library/Server/Mail/Config/postfix/sender_bcc

Then you can start entering the following:

# sender-address [space(s)]  bcc-address
sender@example.com    archive@example.com
anothersender@example.com    archive@example.com

Alternatively you can use a plain text editor of your choice.

Run postmap anytime you edit the sender_bcc file

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/postmap /Library/Server/Mail/Config/postfix/sender_bcc

Tell postfix where to find your new sender_bcc file then reload postfix

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf -e sender_bcc_maps=hash:/Library/Server/Mail/Config/postfix/sender_bcc
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/postfix reload

To disable sender_bcc_maps

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf -e sender_bcc_maps=
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/postfix reload