In den Kommentaren zu meinen Mailserver-Beiträgen wurde ich schon mehrmals darauf hingewiesen, dass man sich den Aufwand mit Spamassassin, Amavis und Co eigentlich sparen könne, weil Postscreen alleine schon mehr als ausreichend wäre. Spammails würden das System gar nicht mehr oder nur in seltenen Fällen erreichen. Kürzlich habe ich mein privates Mailsystem neu aufgesetzt und es einfach mal ausprobiert: Spamabwehr nur durch Postscreen alleine.
… das hat leider nicht wie erhofft funktioniert. Schon in der ersten Nacht sind auf einem einzigen Account 2 Spammails durch den Filter gegangen. Das war für mich schon Grund genug, wieder meinen Spamassassin zu aktivieren. Seitdem ist auch wieder Ruhe. Offenbar reicht ein Postscreen leider nicht in allen Fällen aus. Schade. Ich hätte gerne auf den Amavis-Apparat verzichtet und nur die schlanke Postscreen-Lösung genutzt.
Wie wehr ihr Spammails ab? Nutzt ihr Postscreen zusammen mit Spamassassin, oder reicht ersteres bei euch alleine aus? Welche Postscreen-Einstellungen funktionieren bei euch zuverlässig?
Manchmal ist es sinnvoll, E-Mails von einem Server aus nicht direkt in das Internet zu verschicken, sondern ein E-Mail Gateway / einen Postfix-Relayserver zu nutzen. Der absendende Server funktioniert dann wie ein normaler E-Mail Client und schickt seine E-Mail zuerst an einen zentralen Mailserver, der diese dann an das Ziel weiterleitet. Das kann z.B. aus folgenden Gründen sinnvoll sein:
Ein Server an einem DSL-Anschluss soll E-Mails versenden. Ein direkter Versand wird aus verschiedenen Gründen nicht empfohlen (Dynamische IP-Adresse, kein passendes Reverse DNS, …)
Mehrere Server werden betrieben. Um nur einen einzigen Mailserver mit seinen Komponenten warten zu müssen, soll ein zentrales E-Mail Gateway genutzt werden. DKIM müsste dann z.B. nur für das Gateway eingerichtet werden, und nicht für jeden sendenden Server einzeln.
Ich beschreibe hier im folgenden, wie ihr einen bereits bestehenden Postfix-Mailserver zu einem Gateway erweitern könnt, und wie ihr Postfix auf allen anderen Servern einrichtet. Den bereits eingerichteten Postfix-Server nenne ich „Gateway“; alle anderen Server werden „Clients“ genannt (da sie hier nur eine Rolle als Mailclients spielen“).
Gestern Nachmittag war die Infrastruktur meines Serverhosters wegen eines DDoS-Angriffs für ~ 3 Stunden nicht mehr erreichbar. Von dem Ausfall waren alle Dienste betroffen, auch XMPP und meine Mailserver. Ein besorgter XMPP-Nutzer (*wink* @Phil ;-) ) hat mir an meine Admin-Mailadresse eine Mail geschrieben – die konnte ich aber erst empfangen, nachdem meine Server wieder liefen. Besser wäre es gewesen, noch während der Downtime auf die Mail reagieren zu können. Für solche Zwecke richtet man üblicherweise einen einen sog. Backup-MX im DNS ein: Einen Backup-Mailserver, der den Empfang übernimmt, falls der primäre Mailserver nicht erreichbar ist. Im Moment will ich mir allerdings das Geld für einen separaten Backup-Mailserver bei einem anderen Hoster sparen, deshalb habe ich mir eine andere Lösung überlegt:
Um kommunikationsfähig zu bleiben, wenn mein Mailserver ausfällt, habe ich sowieso einen Mailaccount bei mailbox.org. Im 1 € / Monat -Tarif sind bis zu 3 Alias-Adressen enthalten. Als Aliase können nicht nur @mailbox.org-Adressen genutzt werden, sondern auch Adressen aus eigenen Domains. Also habe ich mir die beiden wichtigsten Mailadressen meiner eigenen Mailserver dort als externe Aliase eingerichtet, und die Mailbox.org-Server als Backup-MX im DNS vermerkt.
Zum Test habe ich meinen eigenen Mailserver kurz abgeschaltet und an eine der abgesicherten Adressen eine Mail verschickt. Wie erwartet, hat mailbox.org dem Empfang übernommen, sodass mich die Mail trotzdem erreicht hat. Zumindest die wichtigsten beiden Mailadressen sind nun katastrophensicher erreichbar ;-)
Update am 27.10.2016: Wie sich herausgestellt hat, gibt es bei der ganzen Sache einen Haken: Wenn man von einem Mailbox.org User eine Mail an eine der abgesicherten Adressen geschickt bekommt, übernimmt Mailbox.org trotz seiner Rolle als Backup-MX in jedem Fall den Empfang, weil die E-Mail gleich intern geroutet wird. Daran lässt sich auch nichts ändern.
Im Frühjahr 2014 habe ich meine erste ausführliche Anleitung zur Einrichtung eines einfachen Mailservers mit Postfix und Dovecot auf diesem Blog veröffentlicht. Viele Leser sind so erfolgreich zu ihrem privaten oder geschäftlichen Mailserver gekommen. Nachdem nun zwei Jahre vergangen sind und sich mittlerweile auch mein eigenes Setup geändert hat, will ich euch mit diesem Beitrag eine neue, aktualisierte Anleitung für einen Mailserver mit erweiterten Funktionen vorstellen.
Diese Anleitung wurde mehrmals im Ganzen auf einem neu installierten Ubuntu Server getestet und für funktionierend befunden. Solltest du dennoch einen Fehler finden oder einen Verbesserungsvorschlag haben, schreib‘ mir an: mailserver [ett] thomas-leister.de
Am Ende dieser Anleitung werdet ihr einen robusten Mailserver mit Spam-Abwehrmechanismen und weiteren Extras vor euch haben, den ihr so direkt verwenden und auf das Internet loslassen könnt. Außerdem liegt mir etwas daran, die grundlegende Funktionsweise des Mailsystems zu erklären, sodass ihr versteht, was Schritt für Schritt eingestellt wird. Ich betreibe selbst erst seit wenigen Jahren einen eigenen Mailserver und hätte mir zu Anfangszeiten gewünscht, zu verstehen, was ich da eigentlich konfiguriere. Wer einfach nur schnell zu einem Ergebnis kommen will, kann die Erklärungen natürlich überspringen und einfach nur Schritt für Schritt die Anweisungen befolgen. Ich rate aber trotzdem, sich mit dem Thema zumindest grundlegend auseinanderzusetzen: Wenn ein gewisses Verständnis vorhanden ist, können künftige Erweiterungen und Änderungen an der Software einfacher durchgeführt werden.
Tipp: Wer statt auf Handarbeit lieber auf eine fertige Lösung setzt, sollte sich einmal Mailcow ansehen.
Wer erst seit kurzem einen eigenen Mailserver betreibt, wird vielleicht schon festgestellt haben, dass die eigenen E-Mails von anderen Server nicht immer akzeptiert werden und schnell im Spamverdachts-Ordner landen. Tatsächlich gibt es einige Dinge zu beachten, wenn man in die Liga der seriösen Mailprovider aufgenommen werden will. Um bei fremden System einen guten Ruf zu erreichen, sollten die folgenden Merkmale erfüllt sein:
Der ein oder andere überlegt sich vielleicht, auch seinen eigenen Mailserver zu betreiben. Wann ist das überhaupt sinnvoll? Was spricht dagegen? In diesem Beitrag will ich auf diese Fragen eingehen und erklären, warum ich hauptsächlich, aber nicht nur auf eigene Mailserver setze.
Der ein oder andere schüttelt jetzt vielleicht den Kopf: „SPF? Den Mist braucht doch keiner! Macht nur Ärger!“ – Richtig, SPF ist doof. Und trotzdem verwenden große E-Mail Privider SPF, um die Herkunft von E-Mails zu überprüfen und so festzustellen, ob es sich um Spam handelt oder nicht. Mehr Informationen dazu, wieso SPF doof ist, könnt ihr euch auf der Blog-Seite von Heinlein-Support einholen: https://www.heinlein-support.de/vortrag/spf-dkim-greylisting-der-neue-spamschutz (Empfehlung!)
Für jene unter euch, die ganz einfache, simple Mailserver verwenden, kann so ein SPF-Eintrag im DNS aber trotzdem sinnvoll sein: Nicht, weil ihr SPF selbst nutzen sollt, um Spammer zu identifizieren (dafür gibt es wesentlich bessere Technik), sondern um besonders schlechte Provider wie Microsoft (Hotmail, Outlook.com) oder GMX dazu zu bringen, eure E-Mails nicht als Spam zu klassifizieren ;) Fehlt ein SPF Record in der Absenderdomain, sind sich diese Provider nicht sicher, ob sie die Mail als harmlos einstufen sollen oder nicht. In einigen Fällen landen eure E-Mails dann schnell im Spam oder werden erst gar nicht akzeptiert. Habt ihr hingegen einen einen SPF Record in eurem Zonefile, kann derjenige Provider nachsehen und wird feststellen, dass der sendende Server tatsächlich legitimiert ist, die E-Mail zu verschicken. Alles ist gut und euch wird vertraut.
Wie in den Vortragsfolien von Peer Heinlein schon steht: Ausgehend SPF zu nutzen, schadet nicht und hilft in einigen Fällen. Nur selbst danach filtern sollte man nicht.
Wie bereits bekannt sein dürfte, kann man die Erkennungsrate von Spamassassin verbessern, indem man die Software von bereits als Spam markieren E-Mails mittels sa-learn lernen lässt.
Seit einigen Monaten binde ich in mein Spamassassin zusätzlich die Filterregeln von Heinlein Support ein, die täglich aktualisiert werden und vom Betreiber so 1:1 auch für mailbox.org verwendet werden. Seitdem hat sich die Erkennungsrate für Spam signifikant verbessert. Zu meinem bestehenden Cronjob zur Aktualisierung der allgemeinen Filterregeln habe ich einfach einen zweiten Cronjob für die Heinlein Support-Filterregeln hinzugefügt:
Dass das Unternehmen seine Filterregeln frei für alle Admins zur Verfügung stellt, macht es durchaus sympathisch, finde ich. Vielleicht stellt in Zukunft ja auch der Mailprovider Posteo seine Filter zur Verfügung?
