Blog: Heinlein Support

Ist es Inkompetenz oder Ignoranz? Seit einigen Tagen häufen sich weltweit Beschwerden, weil Mails von Microsoft in den Spamfiltern versacken oder von Mailrelays geblockt werden. Achja: Die Beschwerden richten sich selbstverständlich gegen die blockenden Empfangssysteme, nicht jedoch gegen den Absender Microsoft. Dabei ist Microsoft an den Versandproblemen alleine schuld.

Vielleicht fühlt man sich auch einfach “gleicher als gleich” und meint, sich nicht an die ansonsten für alle Teilnehmer im Internet geltenden RFC-Spezifikationen halten zu müssen? Oder fehlt den Admins dort tatsächlich das Know-how? Man mag sichg überlegen, welche Antwort jetzt die bessere ist.

Banale und für jedermann gültige RFCs werden ignoriert

Ein konkretes Beispiel einer bei einem unserer Kunden geblocken Mails zeigt die ebenso einfachen, wie unnötigen Fehlkonfigurationen:

1. Die Mail kam von der IP 216.32.180.30, diese hat im DNS den Reverse-Lookup va3ehsobe010.messaging.microsoft.com. Im SMTP-Protokoll hat sie sich jedoch mit dem Namen VA3EHSOBE002.bigfish.com vorgestellt, also gelogen.
   Entweder grüßt das System im HELO mit dem, was im Reverse-Lookup gesetzt ist, oder man setzt den Reverse-Lookup auf den Namen, den das System seiner Meinung nach selbst hat und der für den HELO genutzt wird.
2. Das ganze wird auch nicht dadurch besser, daß die Namen noch nicht mal zur gleichen Domain gehören. Wenn wenigstens beide Namen microsoft ODER bigfish wären…
3. Microsoft MUSS nach RFC 2142 u.a. einen Postmaster-Mailaccount und auch einen Abuse-Mailaccount besitzen. Das ist keine Bitte, das ist Vorschrift. Microsoft ignoriert das geflissentlich, dabei müssten nur zwei simple Mailadressen eingerichtet werden.
   http://www.rfc-ignorant.org/tools/lookup.php?domain=microsoft.com

=> Die Kombination aus (1), (2) und (3) sorgt dann dafür, daß handelsübliche Anti-Spam-Systeme überall auf der Welt diese Mail (völlig zu recht) so verdächtig halten, daß diese Mails geblockt, getaggt oder sonst wie rausgefiltert werden.

Die Abhilfe wäre einfach und würde nur wenige Sekunden Zeit kosten

• HELO-Hostname und Reverse-Lookup müssen übereinstimmen, wie das bei Mailservern nunmal übereinstimmen muß. Also: Reverse-Lookup ändern. Easy.
• Micosoft muß eine Mailadresse postmaster@ und abuse@ einrichten, wie das nach RFC bei im Mailverkehr genutzten Domains nunmal vorgeschrieben ist. Also zwei Postfächer einrichten. Easy.

Doch das passiert nicht. Stattdessen wird zeitwaufwändig der Rest der Welt damit beschäftigt, mühsam die IP-Netze von Microsoft herauszufinden um diese manuell in den Spamfiltern der Welt zu whitelisten. Wenn man sich überlegt, was das die Provider, Partner , aber auch die (zahlenden!) Kunden von Microsoft betriebswirtschaftlich an Geld kostet…

Warum richten sich Beschwerden und Ursachenbehebung nicht an Microsoft?

Beschwerden über geblockte E-Mails sollten ausschließlich an den hausinternen IT-Support von Microsoft gehen. Stattdessen beschweren sich selbst Microsoft-Mitarbeiter bei deren unschuldigen Kunden darüber, daß angeblich geschäftskritische Microsoft-Mails nicht mehr versendet werden können — und die geben den Druck an die angeblich unverantwortlichen und schlampigen Anti-Spam-Dienstleister weiter. Dabei haben die gar keinen Fehler gemacht.

Doch wenn diese Mails so geschäftskritisch sind — warum versendet Microsoft diese dann nicht auch mit der für geschäftskritische Dinge notwendigen Sorgfalt?

 

Symptom und Whitelisting bei Postfix / policyd-weight

Bei Postfix schlägt der Dienst policyd-weight mit folgender Fehlermeldung zu:

Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; in postmaster.rfc-ignorant.org; in abuse.rfc-ignorant.org; from=<user@microsoft.com> to=<user@example.com> proto=ESMTP helo=<AM1EHSOBE001.bigfish.com>

Wer die betroffene IP-Ranges von Microsoft whitelisten möchten oder müssen: Wir haben bislang betroffene drei Netzbereiche ausfindig gemacht. Diese können bei Postfix per check_client_access wie folgt gefahrlos gewhitelistet werden:

213.199.154.0/24        permit_auth_destination 65.55.88.0/24           permit_auth_destination

Wer (wie ich derzeit) in Karlsruhe unterwegs ist, braucht starke Nerven. Und am besten trägt er auch einen handelsüblichen Helm aus dem Bergsteiger-, Motorrad oder Bauarbeiterfachgeschäft des persönlichen Vertrauens. Denn: In Karlsruhe regnet es flache Ratten!

Die Bürger von Karlsruhe wissen noch nicht, ob sie sich über dieses ungewöhnliche Phänomen freuen sollen (Touristenattraktion?) oder ärgern sollen (gefährlich!). In den Geschäften von Karlsruhe werden jedoch bereits deutliche Warnungen vor dem Rattenregen aufgehängt — so gesehen im Schaufenster eines E-Plus-Shops (pardon…: shop’s!) in der Karlsruher Innenstadt.

Ungeklärt jedoch ist noch, ob die Ratten bereits flach waren, als sie regneten, oder ob sie erst durch den unsanften Aufprall auf dem Karlsruher Kopfsteinpflaster flach wurden.

Amavis kann ab Version 2.7 direkt mit dem Sophos-Virenscanner per SSSP-Schnittstelle kommunuzieren und erreicht damit traumhafte Durchsatzraten. Dieses Howto klärt Installation und Konfiguration.

Dämonisierte Engines müssen sein

Das A und O eines performanten Anti-Viren-Filters auf einem Mailserver ist die Notwendigkeit, unbedingt einen dämonisierten Virenkiller einzusetzen. Leider bieten viele Hersteller jedoch keine eigenständig als Dämon laufenden Viren-Engines mehr an und möchten stattdessen gleich vollständige Komplettlösungen beim Kunden platzieren.

Unserer Ansicht nach kommen für eine enrsthafte Betrachung derzeit lediglich folgende Anbieter/Lösungen in Betracht:

• ClamAV
• Sophos
• Avira
• Kaspersky

Wobei Kaspersky anscheinend vom BSI eher ungerne für Behörden gesehen wird — Russland gehört nicht zur NATO und damit ist der Scanner wohl für die Verarbeitung von Dokumenten entsprechender Geheimhaltungsstufen nicht zugelassen.

Das SSSP-Protokoll ermöglicht den direkten Zugriff auf die Engine

Sophos bietet dankenswerterweise eine eigene Scan-Engine mit dokumentiertem Protokoll an: Über das SSSP-Protocol kann eine Drittsoftware die Scan-Engine performant und ohne Umwege über Hilfsprogramme ansprechen.

Für einen großen öffentlich-rechtlichen Kunden haben wir im Jahr 2009 zusammen mit Amavis-Autor Mark Martinec eine SSSP-Schnittstelle in Amavis gebracht. Seitdem kann Amavis mit der Scan-Engine von Sophos nativ und ohne Umwege über einen Unix-Socket oder einen TCP-Socket reden — genau wie Amavis das seit langem mit ClamAV bereits kann. Das macht den Einsatz von Sophos unter Amavis außerordentlich interessant — bei unseren Testaufbauten kamen wir damals auf phänomenale Durchsatzraten von 100 Mails pro Sekunde auf recht normaler Hardware.

Das Howto zu Installation

Ab Amavis 2.7.x ist die SSSP-Schnittstelle in Amavis enthalten.

Bei Sophos übernimmt die SSSP-Kommunikation der Dämon savdid — der ist nicht frei verfügbar, sondern nur für Systemintegratoren zu bekommen. im Normalen Download-Bereich wird man die notwendige Software (leider!) nicht finden können.

Notwendig sind die Pakete:

• Viren-Engine: linux.intel.libc6.tar.z (32 Bit), linux.amd64.glibc.2.3.tar.z (64 Bit)
• savdid: savdi-20-linux.tgz (32 Bit), savdi-20-linux-64bit.tgz (64 Bit)

Heinlein Support kann die Installationspakete dafür zur Verfügung stellen (=> Mail an support@heinlein-support.de). Und da wir aus den überzeugenden technischen Gründen bei vielen Kunden mittlerweile Sophos einsetzen, besorgen wir auf Wunsch die dafür passenden Lizenzen dazu…

Zunächst muß die eigentliche Viren-Engine installiert werden: tgz auspacken und Install-Script aufrufen. Anschließend finden sich unter /usr/local/sav die aktuellen Signature-Files und unter /usr/local/lib liegen die Dateien der libsavi.

Nun kann das Archiv vom savdid ausgepackt und das dortige Install-Script aufgerufen werden. Wenn das install_savdid.sh mit Verweis auf eine fehlende libsavi abbricht, so liegt das i.d.R. daran, daß unter 64 Bit eine 32-Bit-Version installiert worden ist (oder umgekehrt).

Am Ende muß nur noch der savdid-Dämon gestartet werden: Dessen Konfigurationsdatei liegt unter /usr/local/savdid/savdid.conf.  Dort kann einerseits eine unprivilegierte User-ID eingerichtet werden…

# User name and group for daemon to switch to for normal running # savdi must be running as root for this to be useful user: vscan group: vscan

…andererseits muß dort noch ein spezielles Kommando freigeschaltet werden, mit dem Amavis Subdirectorys scannen lassen darf. Diese folgende Einstellung muß für den savdid vorgenommen werden:

    scanprotocol {         type: SSSP         # Do we allow the client to use SCANFILE?         allowscanfile: SUBDIR

In der Amavis-Konfiguration sollte der Zugriff auf den savdid per TCP- statt per Unix-Socket vorgenommen werden, um Probleme mit Zugriffsrechten oder in chroot-Umgebungen zu vermeiden:

# ### http://www.sophos.com/  ['Sophos-SSSP',    \&ask_daemon, ["{}", 'sssp:[127.0.0.1]:4010'],    qr/^DONE OK\b/m, qr/^VIRUS\b/m, qr/^VIRUS\s*(\S*)/m ],

Nach dem Start vermeldet Amavis bei log_level=3 auch den Fund des savdid auf Port 4010:

Jan  6 16:55:31 booster amavis[3629]: Using primary internal av scanner code for Sophos-SSSP

Und eine Test-Mail sollte problemlos versandt und gescannt werden.

Leider stellt Sophis hier keinen Client zur Verfügung, um Sigantur-Files zu aktualisieren . Diese müssen regelmäßig von http://www.sophos.com/downloads/ide/ geladen werden und damit der Inhalt von /usr/local/sav ersetzt werden. Ein laufender savdid muß reloaded werden (“kill -HUP” läßt grüßen).