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.
Vor ein paar Tagen habe ich hier im Blog nach einer neuen, empfehlenswerten Tastatur gefragt. Bei meiner Suche bin ich auf das Fujitsu LX901 Tastatur-Set gestoßen, das in diversen Online-Rezensionen als Tastatur-Maus-Set für den Office-Bereich sehr gelobt wurde. Das Set funktioniert kabellos und verfügt über eine 128 Bit AES Verschlüsselung, sodass eingetippte Daten wie z.B. Passwörter nicht über Funk abgefangen werden können. Das war für mich Voraussetzung: Ein Funk-Tastaturset mit Transportverschlüsselung.
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.
Mailserver betreibe ich zwar auch selbst, aber hin und wieder braucht man auch einen Account auf externer Infrastruktur. Beispielsweise, wenn man noch E-Mail Benachrichtigungen vom Monitoring bekommen will, wenn der eigene Mailserver nicht mehr funktioniert ;) Oder für den Kontakt zum Hosting-Unternehmen, über das die eigenen Mailserver laufen. Bisher habe ich für solche Zwecke meinen uralt-GMX-Account genutzt. Weil wir aber alle wissen, dass man die Seriosität von GMX stark anzweifeln kann und mich die fehlende IMAP-Synchronisierung meines „Free“-Accounts gestört hat, bin ich gestern zu Mailbox.org gewechselt.
Für 1 € / Monat bekommt man dort (ähnlich wie bei der Konkurrenz Posteo.de) allerhand geboten: 2 GB Speicher, alle IMAP-Features, Spamfilter, und sogar Browser-basierte Office-Software ist mit dabei. Die Benutzeroberfläche von Heinlein Support (dem Unternehmen hinter mailbox.org) basiert auf der OX App Suite. Ich spare mir an dieser Stelle, alle Funktionen aufzuzählen – wollte euch aber mailbox.org aber einfach nur mal empfehlen ;)
Übrigens: Wer eigene Mailserver betreibt, kann die offiziellen mailbox.org Spamassassin Filterregeln nutzen. Die werden vom Unternehmen kostenlos angeboten.
Übrigens 2: Es gäbe da ja auch noch openmailbox.org – das ist spendenfinanziert (steht übrigens mit Heinlein Support in keinem Zusammenhang)
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:
