Nachdem gestern Abend durch einen Bug in Prosody 0.10 Nightly keine Web-Registrierung mehr für meinen Server möglich war, habe ich den Bug bei den Entwicklern gemeldet. Weniger Stunden später wurde der Fehler behoben und seit heute morgen gibt es die gefixte Version auch im Debian Repo. Die Web-Registrierung ist damit wieder möglich.
Ich bin überrascht, wie schnell auf den Bug reagiert wurde. Das Dev-Team macht einen guten Eindruck :)
Obwohl ich das WordPress Plugin „Cachify“ schon seit langem auf meinem Blog einsetze, habe ich mich bisher noch nicht besonders damit beschäftigt. Bis vor einer halben Stunde war das Plugin auf die „Datenbank“-Caching-Methode gestellt. Zusätzlich war die HTML-Komprimierung aktiv. Jetzt läuft Cachify mit Memcached und bringt eine beachtenswerte Performancesteigerung mit sich (verarbeitete Seitenaufrufe pro Sekunde):
Etwas merkwürdig hat sich der Festplatten-Cache verhalten. Damit war der Blog sogar langsamer als ohne Cache. Da für mich ohnehin memcached als klarer Sieger feststand und eine Festplatte niemals gegen den RAM ankommt, wollte ich auch nicht lange nach der Ursache forschen. Die Memcached-Methode steht nur für Nginx-Webserver bereit. Der Grund ist u.A. hier erklärt: Cachify Caching-Methoden
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.
Einen sehr praktischen SPF-Record Generator gibt es hier: http://www.spf-record.de
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.
Ich habe meinen Beitrag zum Sammeln von Let’s Encrypt-Domainbestätigungen um einen Abschnitt erweitert: Mit einer einfachen Weiterleitung auf eine spezielle Subdomain kann man nicht nur alle Subdomains zusammenfassen, sondern auch alle Hosts. Setzt man mehrere Subdomains auf mehreren Hosts ein, ist es ganz praktisch, seine Bestätigungsdateien immer nur noch in einem Verzeichnis auf einem Hosts zu erstellen. Das erspart einem zwar leider auch nicht das Erstellen dieser Dateien, aber immerhin muss man dazu nicht auch noch auf sämtlichen Hosts eingeloggt sein.
DANE ist ein noch rar gesätes Protokoll, das Domainnamen mit einem oder mehreren TLS-/SSL-Zertifikaten verknüpft. Durch das DNS wird dem Client diktiert, welche Sicherheitszertifikate für eine Domain gültig sein sollen. Hintergrund ist, dass jede große, anerkannte CA der Welt (und davon gibt es hunderte) theoretisch für jede Domain gültige TLS-Zertifikate ausgeben kann. Dass das viel Spielraum für Manipulation und Missbrauch bietet, liegt auf der Hand. Indem man im DNS Informationen dazu ablegt, welche einzelnen Zertifikate oder Zertifizierungsstellen (CAs) für die Domain genutzt werden dürfen, kann man die Sicherheit signifikant verbessern. Normalerweise wird DANE in Kombination mit DNSSEC (Internetstandard zur Absicherung von DNS-Zonen) eingesetzt. Prinzipiell ist DNSSEC für die Nutzung von DANE nicht zwingend erforderlich. Es stellt sich jedoch die Frage, ob es sinnvoll ist, DANE Informationen in einer nicht manipulationssicheren Zonendatei unter zu bringen … besser ist es, DANE mit aktiviertem DNSSEC zu nutzen.
Im Manual Mode des Let’s Encrypt Referenzclients muss jede Domain über eine individuelle Datei im Unterverzeichnis /.well-known/acme-challenge/ derselben Domain bestätigt werden. Bei vielen Domains bremst das Wechseln zwischen den Verzeichnissen und das erstellen der notwendigen Verzeichnisstruktur den Arbeitsablauf. Damit die Domains schneller bestätigt werden können, sammle ich alle ACME Responses in einem gemeinsamen Verzeichnis /var/www/acme-challenges/. Egal, welche Domain gerade bestätigt werden soll: Die Datei zur Bestätigung wird hier abgelegt und steht dennoch unter der gewohnten URL bereit. Und so geht’s:
In mindestens zwei Anwendungsfällen ist die geringe Laufzeit von Let’s Encrypt Zertifikaten lästig: Bei der Nutzung von HPKP (Public Key Pinning) und DANE. Beide Verfahren sollen HTTPS-Verbindungen zusätzlich absichern, indem genau spezifiziert wird, welche TLS-Zertifikate für eine Domain gültig sein sollen. Da mindestens alle 90 Tage ein anderes Let’s Encrypt -Zertifikat eingerichtet werden muss, müssen in diesem Zyklus auch die HPKP- und DANE-Einstellungen mehr oder weniger aufwendig aktualisiert werden.
Der Aufwand lässt sich jedoch mit einem Trick reduzieren: Da beide Verfahren auf der Untersuchung des Public Keys im öffentlichen Zertifikat beruhen, kann man dafür sorgen, dass sich dieser bei der Umstellung auf ein neues Zertifikat nichts ändert. Man verwendet daher bei der Beantragung eines neuen LE-Zertifikats also keinen neuen Private Key, sondern einen alten. (Der Public Key basiert auf dem Private Key). Um einen alten Key nutzen zu können, muss der Referenzclient von Let’s Encrypt im Zusammenspiel mit einem eigenen, gleich bleibenden Private Key und einer eigenen Zertifikatsanfrage (CSR) verwendet werden.
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:
# crontab -e
Crontab Inhalt:
@hourly sa-update && systemctl reload spamassassin @hourly sa-update --nogpg --channel spamassassin.heinlein-support.de && systemctl reload spamassassin
(Falls kein systemctl (systemd) vorhanden, anpassen! service spamassassin reload)
Von Heinlein Support gibt es hier weitere Infos und eine Anleitung: https://www.heinlein-support.de/blog/news/aktuelle-spamassassin-regeln-von-heinlein-support/
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?