There are several ways to set up the synchronization feature:
* **[MobileMe](http://me.com)** This is probably the most convenient way but it requires you to have a MobileMe account.
* **Bonjour** Synchronizing via Bonjour requires to make one Mac to function as a "database server" (which has to be up and running if you want to sync) and synchronizing is only possible over the local network.
* **Disk** If you have NAS system or a USB hard drive connected to your AirPort you could use this option. But unfortunately the iPhone does not support this way.
* **WebDAV** If you have access to a web server you could use that one as an OmniFocus database server. This way you have access to your tasks from all over the world.

In this tutorial I want to show you how you can configure an apache web server to support WebDAV and what you have to do to make OmniFocus use your very own "cloud".

I'll use Gentoo Linux to explain the single steps but it should be similar on different platforms. There is also a tutorial on how to configure [Leopard to speak WebDAV](http://manas.tungare.name/blog/howto-setup-webdav-on-mac-os-x-leopard-for-syncing-omnifocus-to-iphone/).

## What is WebDAV?
The first question may be: What the heck is WebDAV?

Most parts of the web is read-only, right? You can't go to apple.com and change their front page by putting some Dell products on it. The standard HTTP protocol doesn't allow such operations.
But what if you want to *allow* other people to change your data (without using content management systems)?
To extend the standard HTTP functionality a working group of the [Internet Engineering Task Force](http://www.ietf.org/) developed a protocol called WebDAV which means *Web-based Distributed Authoring and Versioning*. This extension to HTTP allows a web page to become both a readable and writable medium.

OmniFocus is using this protocol not to modify a web page but to keep your "task database" up to date.

## Convincing the apache web server to speak WebDAV
The first thing we have to do is to make apache speak WebDAV.

Support for WebDAV can be added to apache by loading two modules:
* [mod\_dav](http://httpd.apache.org/docs/2.0/mod/mod_dav.html): Enables WebDAV functionality
* [mod\_dav\_fs](http://httpd.apache.org/docs/2.0/mod/mod_dav_fs.html): Provides access to resources on the server's filesystem

### Check WebDAV modules

To see if you've already compiled these two modules, you can have a look in */usr/lib64/apache2/modules* (or */usr/lib/apache2/modules* if you have a 32-bit system). There should be a *mod_dav.so* and a *mod_dav_fs.so* file.

### Compile WebDAV modules
If you can't find your WebDAV modules you'll have to compile them.
To do this, edit your */etc/make.conf* file and add *dav* and *dav_fs* to the *APACHE2_MODULES* variable.

APACHE2_MODULES="dav dav_fs [...]"

If you do an

emerge -vp apache

you should see that the *dav* and *dav_fs* modules will be compiled the next time you compile apache.
To compile apache, simply type

emerge apache

This may take some time but once it is finished you should see the compiled modules in your apache modules directory.

### Activating the WebDAV modules
To activate your WebDAV modules you have to edit your */etc/conf.d/apache* file and change the *APACHE2_OPTS* variable by appending *-D DAV*.

APACHE2_OPTS="-D DAV [...]"

## Enabling WebDAV for Virtual Host
Assuming that you've already set up a virtual host for your webpage, we only have to modify this virtual host configuration.
All we need is to define a directory within your DocumentRoot which should be used for OmniFocus and enable WebDAV for it. Also, we want to set up a password protection so nobody else has access to your data. Enabling SSL for this domain is probably not the baddest idea but that is not topic of this tutorial.

DAV On
AuthType Basic
AuthName "OmniFocusLogin"
AuthUserFile /var/www/sub.domain.com/omnifocuslogins
Require valid-user

This defines that your OmniFocus database is reachable at *http://your.domain.com/omnifocus*.

Don't forget to create the *omnifocus* directory in your *htdocs* directory and change the owner to *apache*:

mkdir /var/www/your.domain.com/htdocs/omnifocus
chown -R apache:apache /var/www/your.domain.com/htdocs/omnifocus

## Password protection
As you can see we already configured password protection for this URL.
All we need to do is to create the *omnifocuslogins* file in which we will define the username and passwords.
To create this file you can simply run this command:

htpasswd2 -c /var/www/sub.domain.com/omnifocuslogins myuser

## Restart Apache
To make all your changes active you have to restart apache.

/etc/init.d/apache2 restart

Apache now allows read and write access to the */omnifocus* directory via WebDAV.

## Configuring OmniFocus
Telling OmniFocus to use your newly configured WebDAV server for synchronization is very easy.
All you have to do is to open the application's preferences, select the *sync* tab, select *Sync with: Advanced* and enter the URL of your server. By clicking on *sync now* you start the synchronization process.

The first time you are doing this you have to enter the username and password you have defined above.
If everything worked fine you should see something like *LastSync: Today, 3:26pm". Congratulations!

## Requirements
This short tutorial requires you to have Mac OS X Leopard (it also may work with Tiger) installed on your system along with the [Xcode tools](http://developer.apple.com/tools/xcode/).

## Getting the sources
The sources of PostgreSQL are free available from one of the mirrors listed [here](http://wwwmaster.postgresql.org/download/mirrors-ftp). Download the current beta from the *source* directory and unpack it.

## Configuring
Before you can start the actual build process, you have to generate the Makefiles. This is done by running the included **configure** script with optional parameters. Available parameters can be listed with the following command:

$ ./configure --help

I decided to build my installation with the following parameters:

$ ./configure --prefix=/opt/local/postgresql83b3
--enable-thread-safety
--without-docdir
--with-perl
--with-gssapi
--with-pam
--with-bonjour
--with-openssl

There is no need to install 3rd party libraries when you use these parameters, but feel free to change them. For a full description of all the parameters have a look at this [website](http://www.postgresql.org/docs/8.3/static/install-procedure.html). The **configure** script now does some checks and creates the Makefiles needed for the build process.

## Building PostgreSQL
The actual build process is started by running the **make** command. The created Makefiles are used to tell the **make** program which files have to be compiled and how the whole application has to build together.

$ make

Depending on your machine the build process takes a few minutes. If **make** succeeds you should see this line:

All of PostgreSQL successfully made. Ready to install.

Great!

## Installing PostgreSQL
The install process is as easy as the build process. The only thing we do is telling **make** to start the installation:

$ make install

A few seconds later you should see this:

PostgreSQL installation complete.

## Creating the database cluster
Before we can use PostgreSQL we have to create at least one database cluster. That is the location where all the data will be stored (here in the directory *data*).

$ cd /opt/local/postgresql83b3
$ bin/initdb ./data

## Starting the server process
Starting the PostgreSQL server process is done via the **pg_ctl** program located in the *bin* directory.

$ bin/pg_ctl -D ./data start

To stop it, use

$ bin/pg_ctl -D ./data stop

## Using launchd to start automatically
If you plan to use PostgreSQL frequently you might be interested in starting PostgreSQL automatically when you log into your system. To do this, download [this file](http://www.stiefels.net/wp-content/uploads/2007/11/net.stiefels.postgresql.starter.plist) and copy it into *~/Library/LaunchAgents* (you may create the *LaunchAgents* directory if it doesn’t already exist). Next time you log in, the PostgreSQL server process is started automatically. The file expects to find your PostgreSQL installation in */opt/local/postgresql83b3*. Feel free to change it, if you installed it somewhere else.

## Connecting to the database
To test if your installation is actually working you can use **psql** to make a local connection to your server. Please note, that PostgreSQL doesn’t allow any network connections using the default configuration. Have a look at the [manual](http://www.postgresql.org/docs/8.3/static/index.html) for further information.

$ cd /opt/local/postgresql83b3$ bin/psql -d postgres
Welcome to psql 8.3beta3, the PostgreSQL interactive terminal.

## Congratulations
The purpose of this little tutorial is to show you how source packages can be compiled on Mac OS X (and other Unices). This way of building applications (configure/make/make install) is a common way in the Unix world and you'll come across these tools very often if you build applications from source packages.

To do that we first have to store the e-mail address of the sender in a database. This allows us to make changes to our blacklist without having to restart the mail server. As my [greylisting implementation](http://www.stiefels.net/2006/12/10/implementing-greylisting-with-exim/) already uses [MySQL](http://www.mysql.com) I will use that for blacklisting too.

CREATE TABLE blacklist (
id int(11) PRIMARY KEY auto_increment,
from_local_part varchar(100),
from_domain varchar(100)
);

This creates a new table in the database in which an ID (just for administration purposes), a local part (the part before the @) and the domain of the sender can be stored.

A new entry in the blacklist can be inserted with:

INSERT INTO blacklist
VALUES (NULL, 'someone', 'somedomain.com');

In the exim configuration file (exim.conf) we first create a macro which contains the controlling SQL statement:

# blacklist macro
BLACKLIST_TEST = SELECT CASE \
WHEN COUNT(*) > 0 THEN 1 \
ELSE 0 \
END \
FROM blacklist \
WHERE from_domain ='${quote_mysql:$sender_address_domain}' \
AND (from_local_part = '${quote_mysql:$sender_address_local_part}' \
OR from_local_part = '*')

As you can see we want to be able to block complete domains by inserting a asterisk in the *from_local_part* column. The statement can return two different values. A *1* is returned if a entry is found and the mail should be blocked. A *0* is returned if the mail should not be blocked by the blacklist mechanism.

If you haven't configured exim to use MySQL yet be sure it is compiled with MySQL support and add the following line to *exim.conf* in order to set the connection parameters:

hide mysql_servers = server/database/username/password

The last thing we have to do is to run the SQL statement every time a mail comes in. A Exim mail server normally uses access control lists in its configuration. We will build our blacklist mechanism in the *acl_check_rcpt* control list:

# access control lists
begin acl

acl_check_rcpt:
...
warn set acl_m3 = ${lookup mysql{BLACKLIST_TEST}{$value}}
...
deny message = Blacklisted. Your mail has been blocked.
condition = ${if eq{$acl_m3}{1}}
...

The ACL configuration consists of two entries.
The first (beginning with *warn*) just runs the SQL statement and saves the result (*1* or *0*) in a variable called *acl_m3*.
Below the second entry (beginning with *deny*) uses that variable to decide whether to deny the mail or not. If denied the mail server of the sender gets the error message *Blacklisted. Your mail has been blocked.*
Don't forget to restart Exim to make the changes work.

Amit Singh (author of the book [Mac OS X Internals](http://www.osxbook.com)) ported this great technology to the Mac: MacFUSE.

You now may think "Wow. And what can I actually do with that?".
MacFUSE itself is less interesting for the end-user but its filesystem implementations are stunning.
Think about your [picasa](http://picasa.google.com)-account (Picasa is Google's online photo album service). Wouldn't it be nice if you could manage your published photos as if they were on your local hard-drive, move them via drag-n-drop, or delete them like normal files? Well, with MacFUSE you can.

Have a look at [Amit's Tech Demo Video](http://video.google.de/videoplay?docid=3138515991250095768) and see what's possible with MacFUSE. It's really great.

But what's really important for me is the sshfs filesystem implementation. Every day I have to connect to several servers via ssh and move files from one machine to another. While this isn't really a problem (thanks to [Transmit](http://www.panic.com/transmit)) it would be more convenient if all those machines were mounted locally on my MacBook.

So, let's install MacFUSE and sshfs and see what happens. Proceed at you own risk. This technology is still under development and I don't know how stable it is.
You can find all the needed files [here](http://code.google.com/p/macfuse/downloads/list).

Let's begin with the MacFUSE-Core kernel extensions.
Download the MacFUSE-Core-0.2.2.dmg, mount it and run the installer. After the installer finished reboot the system so the new kernel extensions are loaded.
To mount remote computers via ssh the sshfs implementation is also needed.
Download the file sshfs-0.1.0.dmg and mount it. You'll see a normal Mac OS X Application called *sshfs*. Copy it to your *Applications*-Folder, run it and a small window will pop up where you have to type in your server address and your user name. A few seconds later another window will pop up where you have to type in your password.
If all worked right a new volume will show up in Finder. Voila.

You can close the *sshfs*-Application if you don't want to connect to additional servers. The mounted Volume won't disappear.
To unmount simply click on the eject button in the Finder.

Wow, that is really easy.

For the more experienced users there is also a command-line binary which allows a finer configuration.
The binary is located in the *sshfs.app/Contents/Resources*-Directory and is called *sshfs-static*. If you plan to use it regularly you should link it into */usr/local/bin*:

$ sudo ln -s /Applications/sshfs.app/Contents/Resources/sshfs-static \
/usr/local/bin/

To mount a remote server you first have to create a directory which will be an alias to the volume:

$ mkdir /some/directory

After that you can run sshfs-static with following parameters to mount:

$ sshfs-static user@remote.server:/remote/directory /some/directory \
-oreconnect,ping_diskarb,volname=volumename

The *reconnect*-option allows sshfs to reconnect if your network was down.
*ping_diskarb* allows the newly mounted volume to play better with the Finder.
*volname=* can be used to name the new volume.
There are a lot more paramteres. *sshfs-static -h* shows you a list.

To unmount the volume at the command-line use:

$ umount /some/directory

Really great. A big **thank you** to Amit!

Uli completed this tutorial a few days ago and it is a good point for everyone who wants to get started in programming C. While it is aimed at Mac users it is also very useful for Linux and Windows users.
And if you are already there you should also take a look at '[How Memory Management Works](http://www.zathras.de/angelweb/howmemorymanagementworks.htm)'.
Thank you, Uli!

The basic idea behind it is to deny an incoming mail with a temporary error code in the first place.
But at the same time the mail server ([MTA](http://en.wikipedia.org/wiki/Mail_transfer_agent)) saves the ip address and sender domain of the incoming mail.

Every ordinary (non-spammmer) mail server will try to resend the deferred mail after some minutes.
This time the mail (and all the following) will be accepted as the MTA knows that this server already tried to deliver this mail.
A spammer often does not try to resend a mail after it was not accepted. The time and resources needed for this would
not be very economic for a spammer.

Unfortunately, there are also some disadvantages:
One mayor tradeoff is that some mails will be delayed a few minutes (dependend of configuration) but this should not be a very big problem for most people.
Another problem are servers which aren't correctly configured and won't try to resend a mail. So the sender gets an error that the mail could not be delivered. Fortunately most servers are set up correctly.

A full design whitepaper of Greylisting can be found [here](http://projects.puremagic.com/greylisting/whitepaper.html).

There are [many implementations](http://www.greylisting.org/implementations/) for most MTAs and also for [Exim](http://www.exim.org) which I use on my server. All you need is a database Exim can use to store its Greylisting information.
A simple implementation with Exim and MySQL can be found [here](http://theinternetco.net/projects/exim/greylist). If you prefer PostgreSQL take a look at this [website](http://raw.no/personal/blog/tech/Debian/2004-03-14-15-55_greylisting).

I reconfigured my Exim installation a few days ago and - yes, email is fun again.