Recently transitioned from 10.7.5 Server to 10.9.4 Server.  Apple dumped webmail in Mountain Lion Server so of course it’s gone in Mavericks Server too.  With webmail gone there’s no way to implement filtering with a GUI at the server level anymore.

With the combination of push email and loads of scripts emailing me at all hours, I found even configuring the rules in Mail.app on the server itself wasn’t fast enough to prevent my phone from buzzing before the message was filed away (in the next second or two.)

I found tidbits all over the place but no comprehensive guide to configuring sieve in OS X Server (on Mavericks or ML.)  I don’t know that this is comprehensive, but it’s more than I found.  This is written assuming you’re at least a little comfortable on the command line.

Find your unique mail ID.
I just headed to /Library/Server/Mail/Data/mail/ and looked for the most recently modified folder since I’m by far the most active user on my server.  You can also check the folder hierachy within it to see if those folders look like yours.

The safer way is to head to Server.app, open Directory Utility, switch to Directory Editor, make sure you’re in the right node (either /Local/Default for local users or /LDAPv3/127.0.0.1 for Open Directory users) and then select the user.  The GeneratedUID is the value you’re looking for and looks like this: 704751C3-6F9D-4A10-8CA9-04E34CBA5B3C.  I’m going to call this $USER_GUID.

Create Rules folder and sieve file

Fire up TextEdit.app, grab this text below, customize with your GUID value, then copy and paste the lines beginning with sudo into Terminal, one by one.  Make sure there are no line breaks for the four lines that begin with “sudo” or the commands will not work.  Here is a text version of it.
sudo mkdir -p /Library/Server/Mail/Data/rules/$USER_GUID
sudo chmod 775 /Library/Server/Mail/Data/rules/$USER_GUID
sudo nano /Library/Server/Mail/Data/rules/$USER_GUID/dovecot.sieve
(just type #replaceme for now, control+x, y, then return)
sudo chown -R _dovecot /Library/Server/Mail/Data/rules/$USER_GUID

Now comes the fun part, creating the rules. 

The link below contains several examples in a format that will work directly in dovecot.sieve, with modifications for your rules and mailboxes of course.

There are far more advanced ways to edit the dovecot.sieve file, but for really basic usage you can use the line beginning with “sudo nano …” above and then either edit directly, or edit in something with a friendly GUI like TextWrangler and then copy and paste into dovecot.sieve.  Just hold down control+K to delete the file line by line then paste from your editor.  Yes this will make your average command line geek cringe, but it’s quite straightforward.

Click on this text for dovecot sieve examples.
—
I provide all of these rules to provide examples of what you can do.  For what it’s worth I use one domain with a catch-all address, that way I can give companyname@mydomain.com email addresses out.  If/when the address gets compromised I can block that exact email address (which is sometimes buried in the headers instead of in the To field.)  This has happened at several small companies, and more recently Adobe, XM, and Toyota.

More examples can be found on the Dovecot LDA/Sieve page here: http://wiki1.dovecot.org/LDA/Sieve

As soon as you save the dovecot.sieve file the rules are in effect.  If you run a test and it’s not working (and I do recommend testing with just one rule before implementing everything!) you’ll see dovecot.sieve.log right next to dovecot.sieve in /Library/Server/Mail/Data/rules/$USER_GUID/ telling you in fairly plain english (at least for a program) what you did wrong.  Probably the easiest error to make would be leaving out a comma in one of the multiple rules, or adding an extra one on the last/only one.

If I’ve made an error or helped you out, I’d love to hear about it.  Please email me at dovecot@ this domain name (without the www.)  Thanks!

Applied Security Update 2014-001 recently to 10.7.5 Server (on this server I’m behind on purpose.)  First time through it stalled on reboot and killed the network user database.  Thought it wasn’t the update’s fault since I had a failing external backup drive I was replacing.  Restored from secondary backup and ran the update again.  This time it appeared to work – mail was coming in, sharepoints working, etc.

I found it actually had trashed the postgres db dealing with calendar and contacts.  The error messages received on the client side were “the server is not responding” and the old “CalDAVAccountRefreshQueueableOperation” error.  The port wasn’t open, which was because the service wasn’t starting.  Errors in the server logs were varied.  For example /Library/Logs/PostgreSQL/PostgreSQL.log was showing (date & time removed since it won’t match any search terms anyway):

LOG:  connection received: host=[local]
LOG:  connection authorized: user=caldav database=caldav
FATAL:  role “caldav” does not exist

In case you run into these errors first verify you have the same issue by checking for the caldav database in postgres:

sudo -u calendar psql -U _postgres caldav

If you receive

psql: FATAL:  database “caldav” does not exist

then you have the same problem.  If you are dropped into a caldav prompt after it lists the psql version, then this is not your exact problem.

– Verify there is a /var/pgsql.pre-restore-[something] folder in /var/.  Without it this guide is worthless.
– Open Server.app and shut down all services.
– Perform the following steps:
sudo serveradmin stop postgres
sudo mv /var/pgsql /var/pgsql.broken
—Use tab to autocomplete the part in brackets below.—
sudo cp -Rp /var/pgsql.pre-restore-[my .pre-restore file] /var/pgsql
sudo serveradmin start postgres

– Check permission to make sure _postgres is both the user and group.  If not run this:
chown -R _postgres:_postgres /var/pgsql

– Verify it works by running:
sudo -u _postgres psql -U caldav

– Open Server.app and start all previously running services.

I manage a healthy number of servers, and this does not happen on all of them.  However it does happen to other people as targeted searches indicate, so I’m inclined to believe certain OS versions shipped with a bug that causes this.  I’ve run into something similar with the 10.7.3 combo update, but none of the rest of my 10.7.x servers have this issue.  They also came with different versions of OS X, though that’s a guess based on timing and not hard data.  If you’ve had this bug occur, it will probably occur again and I urge you to make a bootable clone after shutting down services prior to running security updates (there will be no more combo updates for 10.7.5, obviously.)

When it’s time to upgrade I will be starting from scratch in order to avoid migrating this bug, and I suggest you do the same!

On an install of OS X Server 10.8.5 Mountain Lion where mail services had not been used, I received the error from clamd “can’t open file or directory.”  There was no more information available in the /Library/Logs/Mail/clamav.log.

After a bunch of dead ends I was looking at the setup script (/Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/CommonExtras/63-setup_clamav.sh) to find permissions for all items and stumbled across this:

# Set _clamav home to /var/clamav
`/usr/bin/dscl . -create /Users/_clamav NFSHomeDirectory /var/clamav`
`/usr/bin/dscl . -append /Groups/_amavisd GroupMembership _clamav`

Turns out /var/clamav didn’t exist!  Turned off Mail services and created the directory, set permissions, and fired it back up – no error.

I was root and already in /var so these commands are different from what I used, but they’re more universal and can be run directly after opening Terminal.

sudo mkdir /var/clamav

sudo chown _clamav:_clamav /var/clamav