Skip to content

Thunderbird with Exchange Server 2007

The university I am studying at recently migrated the mail system from Cyrus IMAP to Exchange Server 2007.

Unfortunately Mozilla Thunderbird does not work well with Exchange's IMAP server, unless you do some manual configuration:

First in order to make Thunderbird delete e-mails on the IMAP server correctly, you have to set the mail.imap.expunge_after_delete option to true (see KB article).

Besides, you want to set the mail.server.server#.trash_folder_name property to the name of the "deleted items" folder on the server (see KB article).

With this options changed, Thunderbird will interact with Exchange's IMAP server quite well.

Fighting SPAM Bounces with Exim (Part II)

In the previous article I described how you can reduce the number of bounce mails generated by your mail server. In this article, I will describe a method to automatically distinguish between legitimate and unsolicited bounce mails, thus reducing the number of bounce mails you receive.

Bounce mails should always be sent to the envelope sender (aka "return path") and the bounce mail itself should use an empty envelope sender (some misconfgured systems however use "postmaster@...").

As the user usually does not see the envelope sender, we can set it to anything different from the true sender's address. In fact we can append some kind of signature to the local part of the address, which proves that the mail has really been sent by our mail server. The spammer does not now this signature (which contains a timestamp), unless he has received a mail from us very recently, and therefore will use the normal address (which might have been collected from some webpage or whois information).

Then our mail server can just reject any bounce mails to an address with an invalid signature, because it is probably not a reaction to a mail from our server. This mechanism is called Bounce Address Tag Validation (BATV) and supported by newer Exim versions.

In the first section of our Exim configuration, we define a macro containing the secret signing key and the list of addresses, we want to enable BATV for:

PRVS_SECRET=VerySecretKeyThatYouHaveToChange
addresslist prvs_senders = an-address@example.com : another-address@example.com

If you want to enable BATV for all addresses, you could skip this step and enable BATV for a list of whole domains. However, usually only a few addresses are affected by spam bounces and enabling BATV only for them reduces the risk of breaking something.

Then you have to extend the acl_smtp_rcpt ACL with the following rules:

  deny    message     = This address does not send an unsigned return path
          senders     = : postmaster@*
          recipients  = +prvs_senders

  deny    message     = Invalid return path signature
          senders     = : postmaster@*
          condition   = ${prvscheck {$local_part@$domain}{PRVS_SECRET}{1}}
         !condition   = $prvscheck_result

The first rule will deny bounce mails (actually any mails with an empty envelope sender or postmaster@ in the envelope sender) which are targeted at a BATV enabled address and do not have a signature. The second rule checks any bounce mails that have a signature for the correctness of this signature.

In the next step we have to add a router that rewrites a BATV address to the original address:

prvs_redirect:
  driver = redirect
  data = ${prvscheck {$local_part@$domain}{PRVS_SECRET}}

This router should be placed following any remote but preceding any local routers.

Finally, we have to add the signing configuration to the SMTP transport:

remote_smtp:
  driver = smtp
  return_path = ${if match_address{$return_path}{+prvs_senders} \
{${prvs {$return_path}{PRVS_SECRET}}}{$return_path}}

This will cause the sender address to be signed, if it is listed in prvs_senders.

Since enabling this, I receive virtually no spam bounces any longer.

Fighting SPAM Bounces with Exim (Part I)

In a perfect world there would be no spam and no bounce mails generated by spam. However, in the real world there is spam and there are badly configured mail servers, which generate bounce mails for invalid addresses.

Fighting spam is a complex task and there are many different approaches but no real solution. However, there are two simple and effective measures to fight bounce mails generated by spam:

First, you should take care to adjust your Exim configuration in order to minimize the number of bounce mails generated by your mail server. This will not reduce the amount of unsolicited bounce mails you receive, but it will dramatically reduce the number of bounce mails your mail server sends to the poor guy, whose address is abused by spammers for the "return path" (aka "envelope sender").

The solution is very simple: Just tell your mailserver to verify a recipient's address before accepting mail for it. The mailserver usually does this for local mail addresses, but you have to tell the server to do it for remote addresses, too. You do this by adding the line

require verify = recipient/callout=10s,defer_ok

to your Exim configuration. This way the mailserver will connect to the destination mail server and check the address before accepting a mail. If the destination mail server does not accept the local part, Exim will decide that the address is invalid and reject the mail without generating a bounce mail. If the destination mail server is down, Exim will still accept any local part. In fact this will cause bounce mails for invalid addresses again, however this will happen much more infrequently, because the destination mail server is up most of the time.

Now this article is longer than I expected, so I will describe the second measure (which will dramatically reduce the number of bounce mails you receive) in a second article.

Fun with Xen, Ubuntu and ethtool

During the last days I had some fun with a Xen DomU: The virtual machine had a very bad network performance, although the well-known ethtool line was present in /etc/network/interfaces like in any other DomU on the same host. But only this single DomU had these problems.

After some time, I found out that although the line was present, tx checksumming was not disabled in this DomU. Then I found some other strange problems, when I tried to restart networking. I had to perform a lot of debugging of the startup process before I discovered that udev tried to bring up the interface, failed and then left the interface configuration in an inconsistent state. This problem only occurred in this DomU as in contrast to the other DomUs /usr has its own partition in this DomU, which is not yet mouted when udev tries to startup the interface.

Now I have found a workaround (documented in my wiki) and filed a bug in Launchpad, so that ethtool is moved from /usr/sbin to /sbin.

Task-focused UI with Mylyn

I just found a very interesting video demonstrating the Mylyn feature for the Eclipse platform.

Even if you are not a Eclipse user, the video is still interesting, as it shows why the human brain conflicts with the way most traditional user interfaces are build and how a task-focused user interface can support our brain and boost our productivity.

Eclipse unter Linux (x86_64)

Es scheint einen Bug in Eclipse (oder wahrscheinlich eher der JVM) zu geben, der dazu führt, dass Eclipse unter Linux auf x86_64 ziemlich häufig mit etwa folgender Meldung abstürzt:

#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fa594b7025a, pid=471, tid=1109551440
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b22 mixed mode linux-amd64)
# Problematic frame:
# V [libjvm.so+0x1f125a]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Der Bug scheint bekannt zu sein und zum Glück gibt es einen Workaround, der zumindest bei mir ganz gut funktioniert: Wenn man die eclipse.ini um den Eintrag -Xint erweitert, läuft Eclipse stabil. Diese Option bewirkt, dass der JIT-Compiler deaktiviert wird, der für die Abstürze verantwortlich zu sein scheint. Natürlich läuft der Code dadurch langsamer, aber ich finde den Unterschied zumindest auf meinem Rechner zu Hause (Core 2 Quad @ 2.4 GHz) kaum spürbar.

Ubuntu 8.04 Hardy Heron breaks Xen

Yesterday I upgraded the Xen Dom0 hosting various DomUs (for example my Jabber server) from Ubuntu 7.10 to 8.04.  However, after upgrading Xen stopped working.

I tried to use the old 2.6.22 kernel instead of the new 2.6.24 one, but no chance. Xen did not show any error messages and started the DomUs, however neither networking nor "xm console" were working. In fact "xm console" did not show anything and did not react on keyboard input and even a SIGTERM caused no effect. I had to kill the instance with a SIGKILL or SIGHUP.

Now, after I have restored a backup of the old system, everything is working fine again. Therefore I advise everyone using Xen on Ubuntu not to upgrade to 8.04. Upgrading the DomUs however did not cause any problems, Ubuntu Hardy Heron seems to be broken for Dom0 only.

FreePBX: Adding Extensions does not work

After installing trixbox and updating the system I could not add new extensions using FreePBX.

Although the solution is quite easy, it took some time to find out. So here it is (I found it in the FreePBX-Forum):

Simply delete all contents in the files /etc/asterisk/vm_general.inc and /etc/asterisk/vm_email.inc. Then perform an amportal restart and everything works fine again.

Installing trixbox 2.4 on an IBM Netfinity 5000

I wanted to give Asterisk a second chance and thus decided to install trixbox 2.4 on a test machine. This machine is an old IBM Netfinity 5000 (dual Pentium II, only 128 MB memory but a nice SCSI RAID). Unfortunately the installation failed because the system got locked, when the driver for the Adaptec SCSI controller (not the RAID controller) was loaded.

Surprisingly, when I used the "linux" boot command instead of "default", the installation went fine. However, trixbox did not work (freePBX was not installed correctly). So it took me some extra time to find out, that using the "linux" boot mode the wrong installation script was used.

So finally I figured out, that actually trixbox can be installed correctly by using the boot command "linux ks=cdrom:/ks.cfg skipddc". Basically this is the same as using "default", but "default" also includes the "acpi=off" option which causes the problems with the SCSI driver mentioned above.

Sometimes small problems like a wrong boot option can literally take hours to be solved...

Now I am looking forward to get a working Asterisk installation, however there are probably more problems to come as I want to use an ISDN card with mISDN. So it looks that I will be busy with Asterisk for some more hours :-)

Kaputtes Paket-Management unter Ubuntu

Am Sonntag und auch noch gestern hatte ich ein kritisches Problem mit dem Ubuntu auf meinem Rechner: Der Paket-Manager funktionierte plötzlich nicht mehr und meldete hunderte nicht auflösbare Abhängigkeiten (meistens im Zusammenhang mit der glibc). Auch ein "aptitude -f install" half nicht: Wenn der Konflikt aufgelöst werden konnte, dann nur durch Entfernung von mehreren hundert Paketen, darunter auch solche, die zum Betrieb des System zwingend notwendig sind.

Heute jetzt die Erleichterung: Nach einem "aptitude update", funktioniert wieder alles wie gewohnt. Anscheinend gab es also tatsächlich einen Fehler im Ubuntu-Repository, durch den die Abhängigkeiten zerstört wurden, den jetzt aber die Ubuntu-Leute gefunden und behoben haben.

Eclipse CDT with autotools support

The guys from Fedora Eclipse have developed a plugin for GNU autotools support:

When using Eclipse CDT without this plugin, you have to choose between a "managed make" and a "standard make" project type. The first one causes severe restrictions on the build system of your project and will usually not be sufficient for larger projects as you cannot provide your own Makefile. The second one does not have this restriction but has a less sophisticated integration with the Eclipse build system.

The autotools plugin combines the advantages of both modes in one new mode: You can use your own Makefiles created by GNU autoconf and automake but Eclipse will still take care of automatically building the project.

This mode works just fine for existing projects: I checked out the source code of suPHP from the repository and converted the project to an autotools C project (this can be done using the File -> New -> Other... menu). Without much need for configuration Eclipse ran the configure script and built the project. After the automatic build process completed the autocompletion feature worked like a charm: It provides autocompletion for methods and attributes of an object making C++ development nearly as much fun as Java development.

By the way, have a look at the ChangeLog plugin also provided by Fedora Eclipse. It is only a small plugin but can be very handy when documenting changes.

5.1 surround sound with Xine

Today I had a very strange problem: While Totem (with gstreamer backend) was playing a VOB test file with correct 5.1 surround sound output, Kaffeine (with Xine backend) mixed up the channels incorrectly.

After looking some time around and trying different hints found on the web, I finally got the right hint in a bugreport: Some magic settings in the ~/.asoundrc or /etc/asound.conf solve the problem:

pcm.!default {
type plug
slave.pcm "surround51"
slave.channels 6
route_policy duplicate
}

Of course you have to make sure this settings do not collide with other settings (which might have been created automatically by some tool).

Update (2007-03-12):

Forget what I have written above: This solution works for Kaffeine, however it creates other problems. The right solution is to set the setting "audio.device.alsa_default_device" to "plug:surround51:0". The reason is that Xine does all checks (like how many channels are supported) on this device, even if configured for 5.1 surround mode. However I had to read the corresponding Xine source code to find out. This behaviour seems to be documented nowhere and one would usually expect Xine to use the device defined in "audio.device.alsa_surround51_device" for 5.1 sound output.

Ubuntu 6.10 and X11 radeon driver

Today I replaced the totally outdated Gentoo system on my desktop PC with Ubuntu "Edgy Eft".

When I tried to switch from the "vesa" to the "radeon" driver, the PC crashed on startup of the X server. After some internet search I found a corresponding bug report: This is actually a bug in the radeon driver. However there is a workaround: By setting the "AGPMode" option to "8" in the /etc/X11/xorg.conf the problem can be fixed. At least this perfectly worked for my ATI Radeon 9600 XT.