Minimalistische Firewall-Regeln auf 1&1 Cloud Server

Beim Wechsel von meinem „alten“ 1&1 Dynamic Cloud Server auf einen neuen 1&1 Cloud Server (man beachte die Abwesenheit des Wortes „Dynamic“) habe ich mich gewundert, wieso Email-Versand und -Empfang nicht funktionieren wollte. Nach langer und vergeblicher Suche in Plesk fand ich die Ursache im 1&1 Cloud Panel.

Im Panel finden sich unter Netzwerk -> Firewall-Richtlinien zwei Default-Richtlinien. Die Richtlinie für Linux läßt gerade mal SSH (Port 22), HTTP(S) (Port 80 und 443) und Plesk (8443 und 8447) zu. Erst als ich hier noch SMTP (Port 25), Submission (Port 587) und IMAPS (Port 993) in die Richtlinie aufgenommen habe, funktionierten Emails wie gewohnt.

 

Mehr zu den Write-Only Mailboxen

Vielleicht erinnern sich einige noch an Write-Only Memory, doch meine Write-Only Mailboxen sind kein Witz. Die Idee dahinter ist folgende:

Ich möchte auf meinem Mailserver gemeinsame Mailboxen zum trainieren des Bayesschen-Filters in Spamassassin haben. Bei false positives (legitime Nachrichten, die fälschlicherweise als Spam erkannt wurden) soll der Anwender eine Kopie der Mail in die Ham-Mailbox ablegen, damit der Spamassassin daraus lernt. Da eine solche Nachricht sensible Daten enthalten könnte, will man natürlich nicht, daß alle Anwender auf dem Server diese Nachricht zu Gesicht bekommen. Dies widerspricht erstmal der Idee von gemeinsamen Mailboxen. Natürlich könnte ich für jeden Anwender seine privaten Spam/Ham-Mailboxen anlegen, doch dann wäre es umständlich den Spamassassin per IMAP zu trainieren, da ich mir erstmal alle Mailboxen zusammensuchen müßte. So kam ich auf die Idee von Write-Only Mailboxen. Die gemeinsamen Mailboxen (shared folders im Cyrus-Lingo) haben als ACL nur li für jederman. Damit sind die Mailboxen für die Anwender sichtbar und sie können Nachrichten darin ablegen. Einmal drin, kann man sie jedoch nicht mehr sehen.

An dieser Stelle muß ich gestehen, I did not have sexual relations with that woman…daß ich gelogen habe. Die Mailboxen sind nicht wirklich write-only. Einer darf sie lesen. Der Spamassassin-User, der die Mails automatisiert an den Spamassassin verfüttert. Seine ACL lautet lrwd. Er darf auch lesen und die Nachrichten hinterher aus der Mailbox löschen.

Ich denke, diese Lösung ist ein guter Kompromis zwischen Aufwand (Spam/Ham-Mailboxen finden und abgrasen) und Funktionalität (Spamassassin füttern). Ein Manko hat die Sache jedoch. Wenn ein Anwender sich mit den Mailboxen vertut und eine Ham-Nachricht in Spam ablegt (oder umgekehrt), hat er keine Möglichkeit, dies zu korrigieren.