Tag Archives: Kommunikation

SpamAssassin: Von der Zeit eingeholt

Heute kam die berechtigte Beschwerde eines Webserver-Mitnutzers, dass viele E-Mails neuerdings fehlerhaft als Spam klassifiziert würden. Als fähiger Informatiker hat er auch gleich noch ein Beispiel mitgeliefert. Darin wurde eine Regel sichtbar, die ich bislang noch gar nicht weiter beachtet habe und die bis zum Beginn dieses Jahres durchaus sinnvoll war:

FH_DATE_PAST_20XX

Diese Regel vergibt Punkte fuer alle E-Mails die ab dem 01.01.2010 datiert sind. Und nicht nur ein paar Zehntel, sondern bis zu 3.5 Punkte — bei insgesamt 5 nötigen Punkten für eine Spam-Klassifizierung macht das sehr viel aus. Effektiv wurde damit die Grenze für Spam auf 1.5 Punkte herabgesetzt.

Die Lösung ist im Apache-Wiki zu finden und wurde gleich noch mitgeliefert: In der lokalen Konfiguration muss diese Regel manuell deaktiviert werden, indem man die vergebenen Punkte auf 0.0 setzt. (Ein sa-update hatte bei mir keinen Effekt.)

Das ist mal ein schönes Beispiel dafür, dass insbesondere Regeln, die nicht global gültig sind und bleiben, regelmäßig begutachtet und gegebenenfalls überarbeitet werden müssen.

Verlorene Nachrichten im OnlineChat von GMX und web.de

GMX und web.de, neben 1&1 die beiden großen Marken der United Internet AG, bieten seit etwas über zwei Jahren nun den sogenannten MultiMessenger an, ein Programm mit dem man gleichzeitig in verschiedenen Instant-Messenger-Netzwerken online sein kann. Das ganze basiert auf Jabber beziehungsweise XMPP. Ein willkommener Nebeneffekt ist, dass man mit den Zugangsdaten vom Mail-Konto eines der beiden Provider prinzipiell direkt einen Jabber-Account hat, den man mit beliebigen Clients nutzen kann. In unserem Freundeskreis machen von dieser Möglichkeit (also Jabber-Account am MultiMessenger vorbei) etwa ein halbes Dutzend Leute Gebrauch und haben so einen Jabber-Account mit leicht zu merkendem Nutzernamen und Passwort – die selben wie beim Mail-Account halt.

Heute mittag war ich etwas verwundert, jemanden aus dieser Runde im Jabber online zu sehen, der um diese Zeit während der Arbeit üblicherweise keinen Jabber-Client benutzt, sondern maximal im Browser die E-Mails abruft. Die verwendete Ressource lautete webmessenger, was mich vermuten ließ, dass GMX und web.de da jetzt ein wenig wie GoogleMail arbeiten. Dort kann man GoogleTalk, also Google’s Form von Jabber, auch nutzen, während man über das WebFrontend seine Mails liest. Also hab ich mich mal bei den beiden Portalen eingeloggt und siehe da:

Am oberen Rand des Browserfensters (naja also des sog. Viewports, vom Inhalt oder sagen wir mal der Seite selbst eben) sind neuerdings verschiedene Symbole. Von links nach rechts sind das das Logo von GMX bzw. web.de, ein Briefumschlag für den Posteingang und dann eine bunte Sprechblase. Hinter dieser verbirgt sich sozusagen das Webfrontend des Multimessengers. Wer diesen oder einen anderen Jabber-Client mit diesen Zugangsdaten schon benutzt hat, sieht auf der linken Seite zunächst mal seine Kontaktliste, wahrscheinlich sind sogar ein paar Leute online. Mit den kann man dann ganz normal chatten, soweit so gut.

Jetzt sehe ich aber bei dieser Geschichte ein paar Probleme. Wie eingangs erwähnt, wird man automatisch im Jabber-Netzwerk angemeldet, wenn man bei GMX oder web.de nun seine Mails liest. Für alle, die den MultiMessenger oder den Account mit einem alternativen Jabber-Client sowieso nicht nutzen, ist das relativ egal, weil da auch die Kontaktliste leer ist. Diese Leute empfangen dann sowieso keine Nachrichten.

Alle anderen haben nun zunächst folgendes Problem: für die Kontakte sieht das so aus, als wären sie online und quasi bereit zu chatten. Die entsprechenden Nachrichten schlagen dann in diesem Webinterface auf. Da erscheint dann eine unscheinbare rote Nummer mit der Anzahl der neuen Nachrichten über dem Sprechblasensymbol. Wenn ich jetzt nicht in diesen OnlineChat klicke, dann ignoriere ich damit nicht nur diese Nachricht, ich bekomme die auch nirgends wieder zu sehen: nicht im normalen Jabber-Client beim nächsten Einloggen und auch nicht im Webinterface beim nächsten Einloggen!

Die Konsequenzen dürften abgesehen von der fehlenden History vielfältige soziale Probleme folgender Art sein:

»Wieso hast Du meine Nachricht heute mittag nicht beantwortet?«
»Ich war heute mittag gar nicht online.«
»Doch, im Jabber, ich hab Dich doch gesehen.

Das wäre nicht so schlimm, wenn die ungelesenen Nachrichten später nochmal auftauchen würden, tun sie aber nicht! Wenn sowas wiederholt passiert, wird das bei technisch nicht versierten Nutzern zu Frustration, Missverständnissen und was weiß ich nicht führen. Das mag sich bitte mal jeder selbst ausmalen.

Was kann man nun dagegen tun? Gute Frage. Nach meinen bisherigen Erkenntnissen, kann man das Einloggen beim Jabber-Server nicht einfach abschalten, so wie das, wenn ich mich recht entsinne, bei Google der Fall ist. Was man derzeit machen kann: man klickt in diesem Messenger-Interface auf »Hauptmenü« und dann auf »Einstellungen«. Dort gibt es derzeit nur eine mögliche Einstellung, nämlich zu eben dieser Anmeldung, wo man auswählen kann, welchen Status man bei der Anmeldung haben möchte. Hier sollte man, um den zuvor geschilderten Missverständnissen vorzubeugen, unbedingt »unsichtbar« auswählen! Das verhindert zumindest, dass die Kumpels einen online sehen und dann Nachrichten an einen schreiben, die nie gelesen werden.

Für den weiteren Verlauf wäre es wünschenswert, wenn GMX und web.de den Nutzer deutlich auf dieses Verhalten hinweisen und das ganze abschaltbar machen würden. Ich werde mal versuchen, diese Betreiber zu kontaktieren, mache mir da aber keine großen Hoffnungen.

Bis dahin schlage ich vor: wenn Ihr Nutzer kennt, die Jabber über GMX oder web.de nutzen und ihre Mail auf der Webseite lesen, weist diese Nutzer deutlich auf diesen technischen Missstand hin und wie sie in zumindest umgehen können!

Technisch ein wenig versierte Nutzer: wenn Ihr in Eurem Jabber-Client seht, dass der Gegenüber gerade nur auf der Ressource »webmessenger« online ist, verzichtet auf das Senden der Nachricht!

Für weitere Vorschläge bin ich offen, könnt Ihr gern hier in den Kommentaren oder per Mail abladen.

Davon abgesehen, habe ich noch ein weiteres Problem festgestellt. Wenn ich aus dem Webinterface heraus Kontakte einlade, die ihren Account auf einem anderen Jabber-Server haben, kann ich mit denen nicht das normale Autorisierungs-Spielchen durchspielen. Die Kontakte verbleiben als unbestätigt in der Liste. Für den Fall, dass die andere Jabber-ID auch als Mail-Adresse funktioniert, kommt dort eine Mail mit einem entsprechenden Hinweis an. Man kann die Autorisierung aber nicht direkt über Antwort auf die Mail oder Anklicken eines Links abschließen, sondern muss von der Gegenseite aus seinem Jabber-Client heraus den GMX/web.de-Kontakt hinzufügen. Danach hat der dann aber den Eintrag doppelt in der Kontaktliste. Kurz und gut: wo »beta« drauf steht, ist in dem Fall auch »beta« drin. :-(

Nachtrag: Zum Glück werden Offline-Nachrichten nicht von diesem OnlineChat abgeholt sondern landen im normalen Jabber-Client, wenn der wieder online geht.

Cloud Messaging

Moderne Instant-Messaging-Protokolle, wie zum Beispiel Jabber, erlauben es bereits mit mehreren Clients gleichzeitig online zu sein. Auch das Problem der durch mehrere Rechner verteilten Nachrichtenhistorie kann mit Tools wie IMPULS, über das wir auch schon berichtet haben, gelöst werden.

Übrig bleibt das Problem, dass eingehende Nachrichten nur bei einem der angemeldeten Clients erscheinen. Bei Jabber ist das der Client mit der höchsten Priorität. Sitzt man gerade an einem der anderen Rechner, hat man Pech und wird über die Nachricht nicht informiert. Auch, wenn man den Rechner wechselt oder der Gesprächspartner an eine bestimmte Ressource schreibt, erfährt man von der Nachricht erst, wenn man genau den Zielclient öffnet.

Es fehlt ein System, bei dem man auf allen angemeldeten Clients jederzeit denselben Zustand vorfindet. Inklusive der aktuellen Nachrichten. Das entspräche auch der Vorstellung des Geprächspartners, der oft gar nicht weiß, welche Infrastruktur man selbst hat und welche Nachricht wo empfangen wird.

Der Begriff “Cloud Messaging” für dieses Konzept ist vom Cloud Computing abgeleitet, bei dem es ja auch darum geht, an jedem beliebigen Ort seine Daten und Applikationen vorfinden zu können. In diesem Fall geht es nicht allgemein um die Berechnung, sondern um Kommunikation, also eine Unterkategorie des Computings.

Es gibt eine einfache Lösung, die ich für ICQ schon lange anwende: Der Client (licq) läuft als Konsolen-Applikation in einer virtuellen Konsole mit screen. Über ssh kann ich mich mit meinem Server verbinden und dann auch auf mein ICQ zugreifen. Die Lösung erfüllt alle oben gemachten Forderungen. Sie hat aber drei Nachteile:

  1. Ich brauche dafür einen Server, auf dem meine Software laufen kann.
  2. Die Hardware, mit der ich zugreife, muss eine entsprechende Konsole darstellen können. Bei einem Handy wird das schon schwierig. Das Benutzerinterface lässt sich nicht an das jeweilige Gerät anpassen.
  3. Da die Kopplung zwischen Applikation und Betriebssystem durch ssh und screen sehr lose ist, können spezielle Mechanismen des Zielgeräts – zum Beispiel das Abspielen eines Sounds bei eingehenden Nachrichten – nicht genutzt werden. Die Integration ist sehr schlecht.

Gerade offene Protokolle mit entsprechenden Client-Bibliotheken laden dazu ein, auf das jeweilige Gerät angepasste Applikationen zu schreiben. Deshalb muss das Cloud Messaging über das Protokoll realisiert werden.

Möglich ist zum Beispiel folgende Lösung: Der Server versendet nicht sofort die Nachrichten, sondern informiert alle Clients über die anstehende Nachricht. Falls sich Clients anmelden, wenn noch wartende Nachrichten vorhanden sind, werden diese ebenfalls informiert. Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde. Effektiv werden damit keine Nachrichten mehr verschickt, sondern Informationen über eine Änderung des Messaging-Zustandes des betroffenen Nutzers. Dieser liegt auf dem Server, wie das auch derzeit mit nicht abgerufenen Nachrichten der Fall ist.

Wenn dieses Konzept auf den Status erweitert wird, ist es außerdem möglich, transparent mit nur einem Gerät zu erscheinen, während man gleichzeitig mit dem Desktop-PC, dem Notebook und dem Handy online ist und die Wahl hat, auf welchem der Geräte man die Nachricht empfangen und die Antwort verfassen möchte.

eisfair-HowTo: richtig krasse Spam-Mails automatisch löschen

Spam, Spam, Spam, Spam und das jeden Tag. Mein Setup sieht derzeit so aus, dass auf meinem eisfair-Server das Paket mail installiert ist. Dies sammelt via fetchmail die Mails von meinen Mailkonten ein, jagt die durch ClamAV und durch SpamAssassin und verteilt die dann wahlweise auf mein IMAP-Konto oder zum User spam. Das funktioniert sehr gut, auch die false positive Rate des Spam-Filters ist traumhaft, ich kann mich an keinen einzigen in den letzten drei Jahren erinnern.

Nichtsdestotrotz kommen immernoch zu viele Spam-Mails durch. Peter vom Fli4l-Team wurde das bei derselben Software zu viel und kam im IRC mit folgender Lösung um die Ecke: alle Spam-Mails, die von SpamAssassin einen Score größer als 10 bekommen, werden direkt nach /dev/null verschoben, also unwiderruflich gelöscht. Als ich gestern die aktuelle Welle in meinem Spam-Ordner anrollen sah, hab ich beschlossen, das auch umzusetzen.

Mit eisfair ist das zum Glück spielend leicht. Man erstellt als root einfach eine Datei namens custom-systemfilter.rm_spam_mail im Ordner /var/spool/exim und übergibt die dann mit

chown exim:trusted /var/spool/exim/custom-systemfilter.rm_spam_mail

dem passenden Systemnutzer. Der Inhalt muss wie folgt aussehen:

# Exim custom filter
#------------------------------------------------------------------------------
if $h_X-Spam-Score: contains "++++++++++++"
then
    logfile /tmp/exim_filter_rm_spam.log
    logwrite "$tod_log To=$h_to Subject=$h_subject From=$h_from Id=$message_id"
    save /dev/null
endif

(Bei neueren Versionen des Pakets mail kann man die Datei direkt aus /usr/local/exim/examples kopieren.)

Dann geht man ins Setup-Menü, dort in die Konfiguration vom Paket mail und lässt die einmal neu durchlaufen. Das Paket erkennt die zuvor erstellte Datei und meldet folgendes:

adding custom system filter /var/spool/exim/custom-systemfilter.rm_spam_mail ...

Fertig, naja fast. Wer den Filter aufmerksam angesehen hat, erkennt, dass das Log erstmal provisorisch in /tmp/exim_filter_rm_spam.log landet. Eleganter ist es, das Logfile dahin schreiben zu lassen, wo die anderen Logfiles von exim landen, nämlich nach /var/spool/exim/log. Dazu ändert man den Pfad im obigen Beispiel entsprechend ab. Jetzt fehlt noch das logrotate dafür. Dazu kopiert man am besten /etc/logrotate.d/mail in eine neue Datei, beispielsweise /etc/logrotate.de/exim_filter_rm_spam. Diese Datei passt man nun an seine Bedürfnisse an, d.h. man schmeißt den Abschnitt für fetchmail raus, ändert die Pfadangabe für das Logfile und spielt dann noch bisschen mit den eigentlichen Einstellungen. Bei mir sieht das Ergebnis so aus:

#------------------------------------------------------------------
# Creation: 2009-07-07 alex
#------------------------------------------------------------------
/var/spool/exim/log/exim_filter_rm_spam.log {
    rotate 53
    weekly
#    compress
    missingok
    notifempty
    sharedscripts
    create 640 exim trusted
    postrotate
        /etc/init.d/mail -quiet reload exim
    endscript
}

Ich lasse in dem Fall recht viele wöchentliche Logfiles übrig und lasse die nicht komprimieren. Das ermöglicht eine einfache statistische Auswertung, wieviel Spam tatsächlich gelöscht wurde (auch wenn ich das noch nicht umgesetzt habe).

Mehr Infos über das eisfair-Paket gibt’s in der eisfair-Dokumentation im Abschnitt Mail-Package. Die Filter vom Mailserver Exim sind detailliert auf exim.org beschrieben.

Ach und wer erkannt hat, dass ich in meinem Filter die Mails erst ab einen Score von 12 wegwerfe und nicht wie Peter schon bei 10, bekommt ein Bienchen!

Kein Usenet bei O₂

Wir haben in unserer WG einen DSL-Anschluss, der Provider ist O2. Auch wenn da öfter als mir lieb ist die Verbindung neu aufgebaut wird und der von denen gestellte Router besser funktionieren könnte, läuft das ganze doch recht zufriedenstellend.

Soweit so gut, nun bin ich von Fli4l und eisfair gewohnt das Usenet zu nutzen, dort laufen die Diskussionen zwischen Nutzern in Newsgroups ab, die auf einem freien Newsserver verfügbar sind und die ich auch regelmäßig nutze. Dieser Server hat allerdings nur diese Gruppen gelistet. Andere Gruppen aus den Weiten das Usenet wie z.B. de.comp.text.tex oder de.comp.lang.perl.misc habe ich vor unserem Umzug 2007 auf dem Newsserver von T-Online abgerufen, aber nur gelegentlich gelesen, so dass ich hier bisher darauf verzichtet habe.

Heute nun hatte ich eine Frage bezüglich Perl und hab die reflexartig erstmal über Google Groups in de.comp.lang.perl.misc abgesetzt. Grundsätzlich würde ich die Gruppe aber schon gern in einem normalen Newsreader lesen. Ich dachte mir, dass O2 wohl auch einen Newsserver bereitstellt und suchte nach der entsprechenden Information. Auf der Homepage von denen war leider nichts zu finden, also rief ich die Hotline an.

Das Telefonat dauerte sechseinhalb Minuten wovon gefühlt fünf Minuten Ansagen und Melodien vom Band kamen. Die Mitarbeiter dort waren alle ganz freundlich, nur leider kam derjenige, der dann bescheid wusste mit der enttäuschenden Nachricht um die Ecke: »Newsserver gibt’s nicht bei O2.« Schade! :-(

Organisiertes Vertrauen

Eine Idee, die ich heute Nachmittag schon hatte, nachdem Keysigning, GeoCaching und verwandte Dinge gerade mehr oder weniger unsere Gesprächsthemen sind:

Es wäre doch nett, ein Portal zu haben, mit dessen Hilfe man Keysigning-Parties (KSPs) jeglicher Größenordnung organisieren könnte.

Ich stelle mir das so vor:

Man meldet sich dort an und bekommt dann die Möglichkeit, neben seinen aktuellen Schlüsseln auch seinen Aufenthaltsort anzugeben. Damit ist es schonmal leicht, herauszufinden, wer in der Umgebung noch einen PGP-Schlüssel besitzt.

Wer eine KSP organisieren möchte, legt ein entsprechendes Event mit Termin und Austragungsort an. Anschließend können andere Nutzer sich dafür anmelden, wobei sie gegebenenfalls sogar automatisch auf die KSP in ihrer Nähe hingewiesen wurden.

Eine dritte Funktion könnte eine Art Marktplatz sein, auf dem man sich zum Key-Signing verabreden könnte. Wer kein Problem damit hat, mal einen Schlüssel zu verifizieren, gibt das entsprechend bekannt (z.B. durch ein Häkchen im Profil und eine Angabe von Orten, an denen man ihn leicht treffen kann) und wenn man Leute sucht, die einen neuen Key verifizieren, kann man dort einfach auflisten lassen, wer denn in Frage kommt oder eine entsprechende Anfrage stellen und hoffen, dass sich jemand anbietet (auf diese Art lässt sich vermeiden, dass sinnlos Daten ausgespäht werden).

Nebenbei gibt es natürlich Informationen und Tools für KSPs, zum Beispiel eine Möglichkeit, sich ein nett designtes Formular mit allen Fingerprints der KSP-Teilnehmer herunterzuladen oder eine Liste mit Schlüsselschnipseln zum Ausschneiden und Weiterverteilen.

Wenn viel Serverlast ürbrig ist, kann man sogar Vertrauensnetzwerke berechnen und visualisieren. Der Kreativität sind da keine Grenzen gesetzt.

Falls es eine solche Plattform schon gibt oder jemand Lust hat, das umzusetzen: Lasst es mich wissen! Ich habe im Moment leider keine Zeit dazu.

Keysigning auf dem ersten Magdeburger Open-Source-Tag

Das sind ja gleich zwei Themen auf einmal… nun ich fang mit dem kürzeren an. Auf dem Magdeburger Open-Source-Tag 2008 wird es ein Keysigning-Event geben, leider ist die Ankündigung sehr versteckt ganz unten im Programm. Das ganze wird von Jens Kubieziel organisiert und der gute Mann bittet um Anmeldung für den Spaß bis zum 8.10. – also bis Mittwoch. Einfach eine (signierte ;-) ) Mail mit dem eigenen Fingerprint an Jens schicken, schon ist man angemeldet. Alles weitere auf der zuvor genannten Seite.

Der Open-Source-Tag selbst findet zum ersten Mal statt und wird von Stefan Schumacher organisiert. Unterschrieben ist das mit »Entwicklung trifft Anwendung«, die Themenschwerpunkte gehen in Richtung Erziehung, Bildung, Publishing. Natürlich sind auch ein paar thematisch anders gelagerte Vorträge im Programm. Jenes liest sich übrigens sehr interessant, man kann sich kaum zwischen den vier Tracks entscheiden.

Ich persönlich werde mir wohl die Vorträge anhören, die in Richtung LaTeX gehen und ich werde natürlich selbst auch auf der Keysigningparty zugegen sein. Dort sind übrigens auch ein paar Leute anwesend, die Punkte für CAcert vergeben können und wollen. ;-)

irssi-Hilight mit Jabber

Seit einigen Jahren läuft in meiner Screen-Session neben ICQ und anderen Tools auch ein irssi, um mich mit der Welt des IRC zu verbinden. In den meisten Channels bin ich einfach nur anwesend, gelegentlich spricht mich dann aber doch jemand an. Dank hilight im irssi wird man darüber ja eigentlich informiert. Nur leider schaue ich viel zu selten in das irssi-Fenster, um das dann letztendlich auch zu sehen. (Ja, screen informiert ueber Pings in anderen Fenstern, aber da guck ich doch erst Recht nicht hin …)

Da irssi eine schicke Perl-API hat, liegt es doch nahe, ein Perl-Script zu schreiben, mit dessen Hilfe ich mich anderweitig informieren lassen kann. Sehr nahe liegt da der Instant Messenger, der sowieso immer läuft, wenn ich am Rechner sitze – konkret Jabber.

Mit dem Perl-Modul Net::Jabber ist das alles kein Problem (abgesehen von den lückenhaften Dokumentationen, insbesondere in der irssi API) und so gibt es nun das Script irssi2jabber.pl, das als irssi-Script geladen werden kann und mir nun bei jedem Hilight oder jeder privaten Nachricht, die auftreten, während ich /away bin, eine Nachricht an meinen Jabber-Account schicken.

Das Script ist etwas kommentiert, die notwendigen Einstellungen stehen ganz am Anfang und müssen in die irssi-Config. Unter der GPLv3 darf es jeder weiterverwenden, natürlich nehme ich auch Patches an, die, wenn sie nützlich sind, eingepflegt werden.

Indirekter SPAM

Das Antiblau-Blog war heute zeitweise nicht erreichbar, gemeinsam mit einigen anderen Diensten, die auf diesem Server laufen.

Grund ist eine indirekte SPAM-Attacke: Irgend jemand hat heute morgen eine meiner E-Mail-Adressen als Absender für eine größere Menge von SPAM-E-Mails missbraucht. Der Effekt war, dass der Server mit failure notice-Nachrichten bombardiert wurde – insgesamt ca. 8000 Stück.

Das fiese an so einer Attacke: Das findet wohl kein SPAM-Filter. Die Fehlerbenachrichtigungen sind korrekte und unverdächtige E-Mails, lediglich ihre Anzahl ist ungewöhnlich. Hier kann wohl nur eine konsequente Umsetzung diverser Anti-Spam-Maßnahmen wie z.B. Absenderverifikation helfen.

Aber bis es soweit ist, kann ich wohl nur versuchen, die Erkennungsmaßnahmen zu optimieren und einzelne Parameter so zu tunen, dass viele E-Mails den Server nicht mehr in die Knie zwingen.

Ideen sind an dieser Stelle oder direkt an mich natürlich immer willkommen!

Flock – Social Browsing

Eigentlich war ich auf der Suche nach einer Firefox-Integration für Bibsonomy. Aber wie das so ist, bin ich dabei über einige andere Dinge gestolpert. Zum Beispiel Flock.

Flock ist ein sogenannter Social Web Browser, das heisst, neben den üblichen Browser-Features (Flock ist ein Firefox-Abkömmling) gibt es eine Vielzahl von Integrationen für Web 2.0-Dienste, z.B. del.icio.us, Flickr, WordPress (tatsächlich schreibe ich gerade mit der WordPress-Integration von Flock).

Das Interface ist gewöhnungsbedürftig, weil es eine Menge neuer Optionen gibt. Wer aber sowieso viele Web 2.0-Dienste nutzt, wird sich damit wohlfühlen.