Best Practice für stressfreie Mailserver

Transkript

1 Best Practice für stressfreie Mailserver Peer Heinlein Heinlein Professional Linux Support GmbH Abstract: Mailserver sind hochkomplexe Systeme, da sie selbst aktiv werden, Entscheidungen treffen und mit anderen Systemen Kontakt aufnehmen. Aus diesem Grund stellen sie deutlich höhere Anforderungen an eine fachlich korrekte Konfiguration als viele andere IP-basierte Dienste. Nach Trial-and-Error konfigurierte Mailserver verstoßen oft gegen viele kleine Details und Vorschriften und sorgen damit dafür, dass ihre s unnötig oft in den Spamfiltern anderer Mailserver hängen bleiben. 1 Das Backscatter -Problem: Zu späte Bounces Oft nehmen Mailrelays alle s zuerst ganz normal an, um sie dann später von Spamund Virenfiltern begutachten zu lassen ( store+foreward ). In diesem Setup ist es nicht mehr möglich, Spam und Viren direkt bei der Einlieferung abzulehnen. Werden diese s später nicht getaggt, sondern an den Absender zurückgebounct, tritt die sogenannte Backscatter -Problematik auf: Da Spammer gezielt Absender fälschen und dabei auch existierende Domains und Mailadressen mißbrauchen, werden plötzlich am Spamversand unbeteiligte Dritte mit großen Mengen gebouncter s überschüttet [BACKSCA]. Eine sechsstellige Anzahl derartiger Bounces kann jedes Mailsystem eines durchschnittlichen Unternehmens zusammenbrechen lassen und große Schäden anrichten. Gerade wenn Spam nicht getaggt, sondern gebounct wird, ist es geradezu die Pflicht eines jeden Postmasters dafür Sorge zu tragen, dass Spam und Viren in Echtzeit geprüft und abgelehnt werden. Gute Anti-Spam-Systeme beherrschen dies auch und gerade im Open Source Bereich [AMAVISD]. Da auch Spam-Bounces weit verbreitet als Spam gewertet werden, landen diese spambouncenden Systeme nach kurzer Zeit zurecht auf einschlägigen Sperrlisten, so dass sie ihrerseits nicht mehr zuverlässig versenden können. 2 Mailrelays und Backup-Mailserver ohne Empfängerliste Ursache für die Backscatter-Problematik sind oft auch vorgeschaltete Mailrelays, die keine Kenntnis der real existierenden Mailadressen haben. Diese Mailrelays nehmen dabei grundsätzlich jeden Empfänger an und erzeugen erst später bei nicht-existenten Empfängeradressen entsprechende Bounces an den Absender.

2 Auch hier stellt sich die Problematik der Backscatter- s und derartige Mailrelays landen ebenso über kurz oder lang auf den einschlägigen Sperrlisten. Mit wenigen Handgriffen kann der automatisierte Export einer gültigen Empfängerliste auf die annehmenden Mailrelays eingerichtet werden. Gute Mailserver wie beispielsweise Postfix sind seit längerer Zeit sogar in der Lage, die Existenz von Empfängern in Echtzeit auf nachgelagerten Systemen mittels SMTP-Dialog zu verifizieren und gültige wie ungültige Adressen automatisch zu lernen [HEINL04]. Mit dieser Technik können auch IT-Dienstleister Kundenadressen verifizieren, wenn ihre Kunden dem Export ihrer Empfängerliste nicht zustimmen wollen. 3 Kein Spamschutz auf dem Backup-Mailserver Häufig weisen Backup-Mailserver einen schlechten bis nicht vorhandenen Spamschutz auf. Spam-Versender liefern Spam darum gezielt auf den Backup-Mailservern einer Domain ein. Werden diese s dann an den eigentlich zuständigen Mailserver weitergeleitet, können die dortigen Spamfilter nur noch eine inhaltliche Bewertung der vornehmen. Alle Mechanismen, die den Spammer an seinem Verhalten und Fehlern im SMTP-Dialog erkennen, können nicht mehr greifen obwohl sich genau diese Methoden als sehr effektiv, sehr einfach und sehr zuverlässig erwiesen haben [EGGEN01], [HEINL04b]. Eine mangelhafte Filterrate ist damit vorprogrammiert und hausgemacht. Der Backup- Mailserver wird damit zum Königsmörder; zum Handlanger des Spammers. 4 Kein oder falsche Reverse-Lookups und HELO-Hostnamen Viele Spammer wollen nicht nur den Absender der Mail fälschen, sondern geben sich zugleich noch als fremder Mailserver aus. Sie lügen im SMTP-Dialog und geben nach dem HELO-Kommando des SMTP-Dialoges einen gefälschten/fremden Hostnamen an was auch dazu führt, dass der Reverse-Lookup der Client-IP nicht mehr stimmt [RFC2822]. Grundsätzlich könnte einem annehmenden Mailserver der Hostname und Reverse-Lookup des Clients egal sein. Doch der häufige Mißbrauch durch Spammer macht die Echtheit der HELO-Angabe auf vielen Filter-Systemen zu einem kleinen, aber wichtigen Prüfbaustein, der sich zu einem Gesamtbild zusammenfügt. Falsche oder nicht-existente Hostnamen im HELO führen darum regelmäßig zur Ablehnung von s, bzw. zur latent schlechteren Bewertung der eingelieferten , so dass diese häufiger als nötig im Spamverdachts-Ordner landen. Postmaster sollten darum stets darauf achten, dass sich der Server einerseits mit einem im DNS richtig auflösbaren Hostnamen meldet (Richtig: mail.example.com; Falsch: example.local oder mailtest.example.intra). Außerdem sollte dieser Host-

3 name auch im Reverse-Lookup der IP-Adresse stehen (Richtig: mail.example.com; Falsch: port static.qsc.de oder Zu guter Letzt muß auch der im Reverse Lookup zurückgegebene Hostname seinerseits wieder auf die korrekte IP des Servers zeigen und nicht etwa selbst im DNS unbekannt sein. 5 s ohne Zeichensatzdefinition Oft erzeugen Webformulare, Autoresponder, CRM-Systeme etc. einfache s ohne auf die grundlegend notwendigen Mailheader zu achten. Programmierer ohne Kenntnisse der -RFCs arbeiten oft nach Trial-and-Error solange bis die ihrer Ansicht nach richtig aussieht. Dabei programmieren sie jedoch in der Sprachumgebung unter der sie die Test- s auch lesen. Wird eine ohne Angabe eines charset:-headers mit UTF8-Umlauten erzeugt, so wird sie der UTF8-Desktop des Programmiers tadellos darstellen der Kunde mit ISO sieht jedoch nur Schmutzzeichen anstelle aller Sonderzeichen [RFC2822]. Dies ist nicht nur eine peinliche Außendarstellung gegenüber Kunden und Geschäftspartnern, sondern wird auch entsprechend kritisch von Anti-Spam-Systemen bewertet. Schließlich deuten solche Fehler doch darauf hin, dass diese nicht von einem normalen fehlerfreien Mailclient versandt wurde. Postmaster und Programmierer müssen darum einen fehlerfreien charset:-header erzeugen: Content-Type: text/plain; charset="iso " 6 8-Bit-Umlaute im Subject Der Betreff einer steht im Header-Feld Subject: und ist damit Bestandteil des Mailheaders. Hier gilt die eben erwähnte charset-definition der noch nicht, so dass der Subject einer wahlweise nur aus 7-Bit-ASCII oder individuell codierten Umlauten bestehen darf [RFC2822]. Falsch: Schöne Grüße Richtig: =?iso ?b?u2no9m5l?= =?iso ?b?iedy/n9l?= Auch diese Codierungsfehler sorgen nicht nur für eine unprofessionelle Außendarstellung, sondern auch für entsprechende Spam-Punkte bei allen bekannten Filter-Systemen. Die Buchungsbestätigung einer Fluggesellschaft muß beispielsweise codiert werden sonst landet das E-Ticket latent häufiger im Spamverdachtsordner oder wird direkt abgelehnt.

4 7 HTML ohne MIME-Struktur Die normale einfache besteht aus blanken 8-Bit ASCII-Text, nichts sonst. Erzeugen Programmierer und Webdesigner s mit HTML-Inhalt, so muß dieser HTML- Content sauber in eine entsprechende MIME-Struktur gekapselt werden und darf keinesfalls einfach so in den Mailbody geschrieben werden. Einige Mailclients zeigen derart falsch ausgezeichnete s zwar automatisch trotzdem als HTML an restriktiv eingestellte Mailclients präsentieren die zutreffenderweise jedoch als puren unleserlichen HTML-Text, auf den auch kaum zitierbar zu antworten ist. Selten sind sogar HTML-Tags in den Betreff-Zeilen der s zu finden, was absolut unzulässig ist und auch durch keine wie auch immer geartete Codierung realisierbar ist. 8 Webserver erzeugen kaputte Absender Sorgen PHP-Programmierer beim Erzeugen von s nicht für klar definierte Absender der s, versenden die üblichen Apache/PHP-Webserver die s unter der User- ID des Apache-Prozesses: wwwrun@ Diese Absender sind oft unzustellbar, so dass Bounces an diese Adresse verloren gehen zudem sind auch diese Adressen entsprechend anfälliger für eine Spam-Bewertung. Mit wenigen Handgriffen kann der Webmaster für jede gehostete Domain einen individuellen Default-Absender festlegen, wenn er die nachfolgende Konfiguration in jeden VirtualHost-Container des Apache-Webservers übernimmt: php admin value sendmail from user@example.com php admin value sendmail path "sendmail -t -i -f user@example.com" 9 Webformulare ohne Eingabevalidierung Viele Programmierer von Gästebüchern, Kontaktformularen und Webshops übernehmen die vom User eingesandten Daten ungeprüft in die Header From:, To: oder Subject: einer damit erzeugten . Spammer nutzen diese fehlende Eingabevalidierung im großen Stil aus, indem sie Zeilenumbrüche einfügen und so beliebige eigene Mailheader schreiben können. Ohne Probleme kann so ein einfaches Kontaktformular zum Spamversand an Empfänger mißbraucht werden. Webserver mit anfälligen Formularen sind mittlerweile so verbreitet, dass sogar schon eigene Blacklisten für diesen Typ Spamschleuder eingerichtet wurden.

5 Programmier müssen eine effektive Eingabevalidierung also nicht nur zur eigenen Sicherheit (PHP/MySQL-Code-Injection!), sondern auch aus Spamschutz-Gründen vornehmen. Grundsätzlich sollten sich Empfänger in Webformularen möglichst nie frei definieren lassen, sondern wann immer möglich hardcodiert fest vorgegeben werden. Dabei reicht es nicht aus, die Empfänger-Adresse als hidden field im HTML-Formular zu definieren, da diese Daten vom Nutzer ausgetauscht werden können und Daten, die vom Nutzer zurückgesandt werden, deshalb immer ebenso validiert werden müssen. 10 Spam-Tagging kann zu Mailverlust führen Aus Angst vor falsch gefilterten echten s ( false positives ) wird erkannter Spam vielerorts nur im Betreff getaggt oder in Spamverdachts-Ordner gefiltert. In der Praxis werden derart getaggte Mails jedoch sehr, sehr häufig ignoriert, nicht manuell kontrolliert oder ggf. im großen Stil gruppenweise durch den Anwender ungelesen gelöscht. Die eigentlich vorgesehene Nachkontrolle der verdächtigen s findet oft nicht statt. Im Ergebnis glaubt der Absender an einen erfolgreichen Versand der und kann auch einen SMTP-Dialog mit einem 250 OK als Zeichen einer erfolgreichen Mailannahme vorweisen. Der Empfänger jedoch hat die oft nicht gelesen, bzw. bereits gelöscht. Besser ist es, s in Echtzeit zu filtern und hart im SMTP-Dialog abzulehnen. Das false-positives-risiko besteht dabei weiterhin, doch erhält der Absender dann wenige Sekunden nach dem Versand seiner eine entsprechende Bounce-Nachricht, die ihn über den Filterfehler informiert. An die Stelle eines spurlosen Verlustes der (mit allen daraus entstehenden Problemen) tritt nun wenigstens die Kenntnis des Absenders über den Fehler. Im Endeffekt ist also nicht Tagging, sondern das sofortige Ablehnen der s noch während der -Annahme im Interesse aller Beteiligten und vermeidet für Firmen darüber hinaus die unangenehme Frage, wer für entstehende Schäden aus angenommenen, aber von Mitarbeitern unbearbeiteten oder gelöschten s haftet. 11 Ausfälle entstehen vor der Tastatur Unternehmen stecken oft viel Geld und Aufwand in die Absicherung der Hardware. Selbst redundant vorgehaltene Systeme werden oft noch mit teuren herstellerseitigen kurzen Entstörfristen abgesichert. Dabei wird erkannt, dass Ausfälle häufiger durch Fehlkonfigurationen, als durch Hardwareausfall entstehen. Bereits geringe Investitionen in die Fortbildung der eigenen Administratoren heben die Ausfallsicherheit oft mehr an, als es jede erheblich teurere Hardwareabsicherung zu leisten vermag [HEINL04], [HEINL04a].

6 Der Fehler entsteht oft genug vor der Tastatur und jedes System ist nur so gut, wie es auch administriert wird. Häufig ist der kompetente Administrator alleine im Unternehmen. Redundanz in der Administration? Fehlanzeige. 12 Literatur [RFC2822] [BACKSCA] README.html [AMAVISD] [HEINL04] Peer Heinlein, Das Postfix-Buch, Open Source Press, München 2004 [HEINL04a] Peer Heinlein, POP3 und IMAP, Open Source Press, München 2007 [HEINL04b] Peer Heinlein, Verzögerungstaktik, Linux-Magazin 09/04, Linux New Media, München 2004 [EGGEN01] Tobias Eggendorfer, Schneckenpost, Linux-Magazin 02/08, Linux New Media, München 2008