Recently, I gained some insight on the intended nature and its implications of the interaction of DNS with mail services.

It seamed that rather suddenly, my mail server was no longer able to receive mails from certain mail service providers like web.de. Those sending mail servers were only little verbose about what the source of the problem was:

domain has no mail exchangers

That was rather strange to me as I had some good experiences so far regarding the reliability of the DNS servers I was using. The original configuration I used was the following:

$ dig mx grosseosterhues.com
[...]
;; ANSWER SECTION:
grosseosterhues.com.    120     IN      MX      10 mx.grosseosterhues.com.

and

$ dig mx.grosseosterhues.com
[...]
;; ANSWER SECTION:
mx.grosseosterhues.com. 119     IN      CNAME   mail.grosseosterhues.com.
mail.grosseosterhues.com. 120   IN      A       46.4.78.23

So my MX record was a CNAME pointing to an A resource record. No problem with that -- I thought. Doing some web research I learned from RFC 2181, Section 10.3 that there is a certain regulation prohibiting an MX resource record from being an alias (CNAME):

10.3. MX and NS records:

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

I don't know if some providers just adjusted their MTA to use more restrictive policies on sending mails to foreign mail servers of if I just never realized a problem. Anyway: after changing the MX record over to an A resource record everything works flawless (again).

*[IMAP IDLE]: The IDLE feature allows IMAP e-mail users to immediately receive any mailbox changes.

Regular desktop mail clients support push notifications when communicating with IMAP servers. In order to achieve this, IMAP IDLE is being using. Unfortunately though, the current generations of smart phones such as Apple's iPhone or Android-based phones do not support the IMAP IDLE feature but prefer ActiveSync to achieve Push services.

One way to make use of IMAP IDLE e.g. on Android is to use a different mail client like K9 Mail. Yet, that may not be an option to everyone due to software installation policies.

In case modifying the phone's software setup is not an option, it is possible to insert an emulation layer from IMAP to ActiveSync on the mail server. This layer is provided by Z-Push, an open source implementation of the ActiveSync protocol, developed by the Zarafa team.

Z-Push is run by an Apache webserver using PHP and the php-imap module in order to provide the bridge between mobile device and IMAP server. This article documents how to set up a running ActiveSync emulation using Ubuntu Linux, Apache webserver, and Cyrus IMAP-daemon. A running Apache with working PHP and SSL configuration on an Ubuntu Linux is presumed.

This article assumes all Z-Push files to be places in /var/www/z-push. First, the according sources are to be downloaded. They can be found either here http://z-push.sourceforge.net/ or here http://zarafa-deutschland.de/z-push-download/final/.

In the file /var/www/z-push/config.php the BACKEND_PROVIDER has to be changed:

define('BACKEND_PROVIDER', "BackendIMAP");

For syncing problems in previous versions of Z-Push, it helps to increase the value of MAX_EMBEDDED_SIZE as follows:

// define('MAX_EMBEDDED_SIZE', 1048576);
define('MAX_EMBEDDED_SIZE', 10485760);

By default Z-Push expects the directories /var/log/z-push and /var/lib/z-push to exist. In Ubuntu, this is not the case. Therefore, they have to be created and the according ownership needs to be set:

mkdir /var/log/z-push /var/lib-z-push
chown -R www-data:www-data /var/log/z-push /var/lib/z-push

If not already present, the proper php5-imap module needs to be installed:

aptitude install php5-imap

Now in Apache config, the file /etc/apache2/sites-enabled/default-ssl gets some addition:

Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php

     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Order allow,deny
     allow from all
     php_flag magic_quotes_gpc off
     php_flag register_globals off
     php_flag magic_quotes_runtime off
     php_flag short_open_tag on

If the Suhosin patch for PHP is used, the following setting has to be changed to off in /etc/php5/conf.d/suhosin.ini:

suhosin.executor.disable_emodifier = off

The mobile device should address the emulated ActiveSync server just by it's hostname. It is not neccessary to add the Apache alias into the address.

On Android phones, the user might have to accept certain security policy warnings before the actual sync starts.

Useful debugging information can be found in Apache's logs in /var/log/apache2 and in Z-Push's logs in /var/log/z-push. Cyrus IMAP logs its information into the mail system's log in /var/log/mail.log.

In order to mix different sound channels, the Asterisk MeetMe-extension relies on the dahdi-Module that take care of the necessary timing. This module is not a stock module in Ubuntu, so it has to be build from stock. Fortunately, Ubuntu delivers packages that take care of the framework used to build that module from source. The following line will install all those packages:

aptitude install asterisk-dahdi

Now, the dahdi module needs compilation. :

 aptitude install linux-headers-3.0.0-12-virtual

*[PyPI]: Python Package Index

This is an update to my previous article on how to set up FlexGet in Ubuntu. In this post, FlexGet v.1.0r2733 will be used on Ubuntu 11.10.

The reason for this new post is that the install and update processes have changed from using easy_install to pip, an alternative Python package installer. Both installation as also upgrading can be done with this tool.

Still, there have to be certain packages around:

aptitude install python2.6 python-setuptools python-pip

Now, the installation can easily take place:

pip install flexget

In case of an upgrade, the according line would be:

pip install --upgrade flexget

The following step is optional. In case an interface to transmission-daemon is of use, the according FlexGet-plugin is installed like this:

pip install transmissionrpc

Spamassassin already ships with the nice feature of running automatic updates to its core rules by using sa-update. Customisation of this update process is not well documented though. So it will be described in this article.

At http://wiki.apache.org/spamassassin/CustomRulesets quite some additional channels are listed. As an example the configuration of the German Language Ruleset will be outlined.

The Spamassassin Channel is documented on that website and says:

Available at: SpamAssassin Channel: 70_zmi_german.cf.zmi.sa-update.dostech.net

In your local Spamassassin's setup the update rules reside at /var/lib/spamassassin/{SA_VERSION_NUMBER}. There, you may want to add the new channel definition by introducing the according gpg-key as follows:

wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY
sa-update --import GPG.KEY

Now, a manual channel update for that particular channel can be run:

sa-update --channel 70_zmi_german.cf.zmi.sa-update.dostech.net  --gpgkey 856AA88A

In order to have the cron-triggered nightly sa-update-run also update the new channel, a hook for sa-update has to be defined in /etc/spamassassin/sa-update-hooks.d/. There, create a file called german-rules-updates with the following content:

#!/bin/sh
sa-update --channel 70_zmi_german.cf.zmi.sa-update.dostech.net  --gpgkey 856AA88A

The German rules should now be updated each day and become active thereafter.

*[NCSA]: National Center for Supercomputing Applications

This article is deprecated. For the recent version check the following article: https://www.grosseosterhues.com/2011/12/squid-config-with-ncsa-authentication/

This article describes a quick and easy way to implement a web proxy with most basic user authentication. The authentication mechanism uses an NCSA-style htpasswd file, well known also for other basic authentication purposes. The proxy server in use will be Squid proxy.

To install the necessary software, this line will do:

aptitude install squid

Now, a new file containing usernames and password hashes needs to be created:

htpasswd -c /etc/squid/passwd USERNAME
chmod 400 /etc/squid/passwd && chown proxy /etc/squid/passwd

The file /etc/squid/squid.conf has to be modified. The following lines have to be uncommented while the first of them needs adjustment as to the whereabouts of the passwd file. By default it points to usr/etc/passwd but we want it to be /etc/squid/passwd:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic casesensitive off

In the ACL section two lines have to be inserted. The ACL section can be found by searching for "# ACCESS CONTROLS".

acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

In case you want Squid to not reveal your client's real IP address in HTTP requests it forwards, the follow option has to be disabled:

forwarded_for off 

A restart of Squid's daemon will activate the recent changes:

service squid restart 

*[MTA]: Mail Transfer Agent
Although virus scanners are installed on virtually all regular client systems nowadays, it's nice to have the mailserver pre-scanning mails for malware. This article describes the configuration of ClamAV in conjunction with Exim 4 in Ubuntu Linux.

Assuming a working Exim 4 environment, the fist step is to install the necessary ClamAV package:

aptitude install clamav-daemon

To tell Exim which anti-virus scanner to use, the file /etc/exim4/exim4.conf.template needs to be customized. The default config already brings the necessary lines. They just need to be adjusted and uncommented:

av_scanner = clamd:/var/run/clamav/clamd.ctl
[...]
deny
  malware = *
  message = This message was detected as possible malware ($malware_name).
warn
  message = X-Virus-Scanned: (${readsocket{/var/run/clamav/clamd.ctl}{VERSION}{2s}{}{AV Not running}})

In order for ClamAV to access the mail spool it has to become a member of Exim's group:

usermod -a -G Debian-exim clamav && service clamav-daemon restart

Now, sending a testmail like the one from EICAR should give you the appropriate malware rejection.

*[MTA]: Mail Transfer Agent
In this article the approach of greylisting as a protection against spam in Exim 4 is being described. The concepts of greylisting temporarily rejects mails at SMTP time. A regular MTA without spamming intent will try to send mail again after a certain period of time. The average trojan or worm on the other hand usually sends spam in waves. It will try to send its load only once and won't try again later. This concept facilitates spam reduction to a huge extent.

Setting up greylisting in Ubuntu Linux using Exim 4 is a breeze. To work, it simply needs the following lines.

Firstly, the installation of the package greylistd:

aptitude install greylistd

To activate the new package in Exim's configuration, the following command will do some magic:

greylistd-setup-exim4 add

The default configuration of greylistd is a bit too paranoid from my point of view. Therefore I adjust /etc/greylistd/config as follows (usually the last two existing entries in that file):

singlecheck = true
singleupdate = true

This has the effect that a domain that has already been verified won't become greylisted again if a different user sends from that particular domain. Also, it enables for manual manipulation of the whitelist by just adding IPs of "good" MTAs.

The whitelist file that is supposed to be edited by admins resides at /etc/greylistd/whitelist-hosts. The predifined whitelist can be found at /var/lib/greylistd/whitelist-hosts.