Sicher kennen Sie die Situation: Ein Benutzer möchte in seinen verdienten Erholungsurlaub und kann seine Abwesenheitsnachricht nicht selbst setzen oder ein Benutzer kommt aus dem Urlaub zurück und vergisst seine Nachricht zu deaktivieren. Mit dem WinGroupware Out-of-Office Plugin gehören diese Probleme der Vergangenheit an. Das Plugin erstellt einen Menüpunkt “Out-of-Office Settings” in Outlook 2003, 2007 und 2010, über welches Ihre Benutzer selbstständig Ihre Abwesenheitsnachricht setzen können.

Soweit eigentlich nicht wirklich spektakulär, aber es gibt natürlich wieder ein paar “Specialfeatures”: Die Nachricht wird automatisch an dem angegebenen Endzeitpunkt deaktiviert, der Benutzer kann eigehende Nachrichten an seine Kollegen weiterleiten und selbst entscheiden, ob die Mails weiterhin in sein Konto zugestellt werden sollen. Ausserdem ist es mit WinGroupware möglich nur einmalige Abwesenheitsnachrichten zu versenden. Dies ist besonders wichtig, um sich selbst vor einer Eintragung in einer Anti-Spam-Liste zu vermeiden.

Schauen Sie sich doch einfach das Plugin im Echtbetrieb an – in unserem Video:

Heute haben wir fast einen ganzen Tag lang damit verbracht, einen Fehler in unserem SSL Code zu finden. Während unser IMAP-Server prima funktionierte und alles reibungslos bis zum Umschalten per STARTTLS auf den verschlüsselten SSL-Modus funktionierte, wollte dies einfach nicht gelingen.

Nachdem wir ca. acht Stunden lang den Code durchgeschaut und ca. 50 neue Builds versucht hatten, mittlerweile auch andere Mailclients wie Pegasus Mail und den neuen 3er Thunderbird versucht hatten, kamen wir zu der Erkenntnis, dass das Problem von etwas anderem ausgelöst werden musste. Nach einer netten Google-Suche kamen wir dann dem Problem auf die Schliche: Kaspersky Antivirus. Dieser scheint bei IMAP in Verbindung mit dem Umschalten von einer unverschlüsselten zu einer verschlüsselten Verbindung Probleme zu haben und der SSL Parameteraustausch wird dabei abgebrochen. Prima!

Übrigens funktionieren SSL-Verbindungen, die direkt über den Port 993 mit SSL Version 3 aufgebaut werden, ohne Probleme. Lediglich beim Umschalten mittels STARTTLS kommt es zu dem oben beschriebenen Problem und das NUR bei dem IMAP Server. Bei SMTP und POP3 funktioniert STARTTLS bzw. STLS ohne Probleme, daher haben wir den Kaspersky auch nicht in den Problemkreis mit einbezogen. Das mit dem IMAP Server scheint nicht der einzige Fall zu sein, wie wir bei der Google-Suche feststellten. Daher könnte diese Information ggf. jemandem nochmal helfen, deswegen dieser Blogeintrag.

Ansonsten gibt es hier an der WinGroupware-Front jede Menge Neuigkeiten, aber leider nichts, was wir jetzt schon verraten können. Es dauert ja nicht mehr lange… einen guten Wochenstart aus Rödermark!

Wir haben auf unserem Mailserver drei RBL (Realtime Behaviour/Realtime Black List)-Listen im Einsatz, zwei von Spamhaus und eine von IX/Manitu. Von allen eingehenden Verbindungen sind wirklich 80% der eingehenden IP Adressen in diesen Listen zu finden:

Leider kann man nicht davon ausgehen, dass alle RBL Einträge auch wirklich einen Spammer dahinterstehen haben, daher ist ein Einsatz einer Ablehnung nur aufgrund dieser Datenbasis meistens “Selbstmord”. Listen, bei denen es wahrscheinlicher ist, dass ein Spammer diese IP missbraucht, erzeugen in der Regel deutlich geringere Trefferraten.

Anyway, es ist eine Schande, was mit dem Medium EMail passiert bzw. schon passiert ist…

Heute arbeiten wir weiter an der SpamPain v5 Engine und der Integration in WinGroupware. Die Ergebnisse heute morgen sahen sehr vielversprechend aus. Nicht zuletzt, da die Engine jetzt endlich viel tiefer integriert werden kann, als zuvor. Das gibt dem Begriff Realtime eine völlig neue Dimension

Über das Wochenende stellen wir jetzt endgültig auf Subversion als Versionskontrolle um. Wir haben vor geraumer Zeit zwar schonmal einen Subversionserver mit Linux in Betrieb genommen, hatten aber mit der Integration in Visual Studio 2008 Probleme, daher haben wir den Umstieg immer wieder verschoben. Nun ist der Vorgang allerdings überfällig und da wir alles unter Windows selbst benutzen möchten, war die Konfiguration des Servers (für bislang-nicht-Subversion-Leute wie uns) nicht ganz so einfach, da gerade das Anlegen des ersten Repository einfach nicht gelingen wollte. Für alle Personen, die auch Schwierigkeiten mit der (Erst-)Konfiguration haben, haben wir hier die bislang beste Website mit einem einfachen Tutorial (englisch) für die Nachwelt in einem PDF festgehalten (nur falls sich die Links einmal ändern sollten, die Originalquelle ist hier verlinkt).

…das ist hier die Frage.

SPF (siehe www.openspf.org) sollte es dem Empfänger-Mailserver ermöglichen, den Absender zu identifizieren, also sicherzustellen, dass das verbundene System (über die IP Adresse und den Hostnamen) explizit berechtigt ist, für eine bestimmte Domain eMails abzuliefern. Bei berechtigten Anfragen soll die Mail akzeptiert, bei unberechtigten Zustellversuchen soll die Nachricht als Spam markiert werden. Soweit die Theorie. In der Praxis sieht das jedoch etwas anders aus…

Einige große Provider haben bis heute keinen SPF Eintrag in Ihrem DNS vorgenommen (dies ist nun wirklich nicht so schwierig), so dass ein gerade in Deutschland ein grosser Anteil der Nachrichten nicht geprüft werden kann, da die Spammer natürlich eben diese Adressen gerne als Absender benutzen.

Die “besseren” Spammer sind durchaus in der Lage Ihre SPF-Einträge entsprechend anzulegen. Da es sich sehr oft um “Wegwerf-Domains” handelt, ist selbst das “Verbrennen” der Domain uninteressant. Da wir seit ca. drei Jahren intensiv über unseren SpamPain Dienst das Verhalten von Spammern untersuchen, zeigt sich deutlich, dass professionelle Spammer kein Problem mit SPF haben.

Stellt sich also im Endeffekt die Frage, ob es sich lohnt, SPF überhaupt zu nutzen. Diese Entscheidung muss jeder Administrator selbst treffen. Sicherlich ist SPF als ein Teil des Bewertungssystems sinnvoll, als alleiniges Merkmal jedoch absolut unbrauchbar. Wir haben es trotzdem implementiert.

[Irgendwie erinnert der Text an die ehemals so heftig genutzten Reverse-DNS-Einträge von Mailservern. Auch heute ist das noch beliebt, aber die Mails werden in der Regel nicht einfach abgelehnt, sondern in die Spambox des Benutzers verschoben. Da Spammer häufig den richtigen Reverse-DNS eines Zombi-Systems nutzen, ist dieser Test sowieso nicht mehr das, was er mal um 2000 war... ]

Heute haben wir die Tests des IMAP Servers gegen alle uns bekannten Mailclients abgeschlossen. Im Test waren unter anderem Thunderbird, Outlook 2003, 2007, sowie auch die Office 2010 TP-Version, also inklusive Outlook 2010. Dank einiger kleineren Änderungen sind wir schon jetzt für den erfolgreichen Einsatz von Outlook 2010 mit allen IMAP Features gerüstet. Selbstverständlich auch zuverlässig mit Multiaccess (Gruppenzugriff) auf ein einzelnes IMAP-Konto als “Sammelpostfach für Benutzergruppen” inkl. der Synchronisierung der Clients ohne Wartezeit.

Wir haben heute noch ein paar kleienere Änderungen an unserem IMAP Server vorgenommen, daher möchten wir Ihnen ein kleines Sp0ntan-Video präsentieren (bitte entschuldigen Sie die Qualität). Hier zeigen wir im ersten Teil die Funktionalität von IMAP Push, d.h. drei verschiedene Clients (Outlook Express, Thunderbird und Outlook 2003) sind auf ein einziges Benutzerkonto verbunden und erhalten eingehende Nachrichten direkt vom Server übermittelt. Gleichzeitig werden die Nachrichten in allen Clients synchron gehalten, um ein Arbeiten im Team auf Sammelpostfächern zu ermöglichen.

Im zweiten Teil sehen Sie das Verhalten des IMAP Servers bei der automatischen Spamerkennung unter Outlook 2003. Nachrichten, die als Spam erkannt werden, werden automatisch in den Junk-E-Mail-Ordner verschoben. Dieses Verhalten lässt sich auch an den anderen Clients beobachten.

Viel Vergnügen!

Im September werden wir die erste öffentlich verfügbare Betaversion zur Verfügung stellen. Seien auch Sie dabei uns werden Sie zu einem unserer Betatester! 

Die Beta-Version wird ca. 25-50 MB als Downloadgrösse besitzen. Gegebenenfalls sind weitere Downloads notwendig, die während der Installation selbstständig ausgeführt werden, um Ihr System auf die Installation von WinGroupware vorzubereiten. Für den finalen Betatest sind 60 Tage vorgesehen, die veröffentlichte Version ermöglicht daher eine Laufzeit von 90 Tagen ab Betatestbeginn.

Vielen Dank für Ihr Interesse und Ihrer Hilfe.

Wenn auch Sie dabei sein möchten, senden Sie bitte einfach eine kurze eMail an beta@wingroupware.com, wir setzen uns dann umgehend mit Ihnen in Verbindung.

Jeden Tag nervt Spam (mal mehr, mal weniger), aktuell ist gerade wieder ein Urteil gegen einen Spammer in den Niederlanden ergangen.

Dieser soll mindestens 21 Millionen Spams versendet haben und wurde jetzt zu einer 250000,- € Strafe verurteilt. Für jeden weiteren Tag, an dem er Spam verschicken wird, werden nochmals 5000,- € fällig. Damit dürfte dieser Spammer sich wohl erledigt haben oder aber er wird es in Zukunft geschickter anstellen. Der Originalbericht ist auf Heise abrufbar.