Neues Sieve-Plugin im Webmail (serverbasierte Filterregeln für E-Mails)

Ab sofort steht in unserem Webmail ein neues Sieve-Plugin für die serverbasierte Filterung und Sortierung von eingehenden E-Mails zur Verfügung.

Serverbasierte Mailfilter (“Sieve”) haben den Vorteil, dass sie unabhängig vom E-Mail-Client ausgeführt werden. Auf mobilen Clients stehen oft keine Filterfunktionen für E-Mails zur Verfügung. Es ist daher sinnvoll, eingehende E-Mails serverseitig zu sortieren, um im Posteingang den Überblick zu behalten. Auch wenn Sie E-Mails mit mehreren Geräten oder PCs lesen, müssen Sie dort die Filterregeln nicht mehrfach pflegen.

Das neue Sieve-Plugin im Webmail erlaubt feinste Abstufungen, die bisher nur deutlich komplizierter zu realisieren waren. So können Sie zum Beispiel E-Mails, mit einem bestimmten Dateityp im Anhang in einen bestimmten Ordner einsortieren, indem Sie folgende Regel anlegen – hier im Beispiel für gepackte ZIP-Dateien (siehe Bild oben):

Body –> Raw –> weitere Optionen –> trifft auf den regulären Ausdruck zu –> filename=”.+\.zip”

Bitte beachten Sie, dass die eingerichteten Filterregeln stets nur für neue, eingehende E-Mails funktionieren. E-Mails, die bereits im Posteingang liegen, lassen sich auf diese Weise nicht sortieren.

SSD-Webserver für alle Pro.Hosting-Pakete

Für unsere besonders leistungsfähigen Pro.Hosting-Pakete nutzen wir ab sofort nur noch Server mit SSDs anstelle normaler Festplatten. Bisher waren nur unsere MySQL- bzw. MariaDB-Datenbanken auf extrem schnellen PCIe-SSDs abgelegt; für Pro.Hosting-Webserver nutzen wir nun hochwertige SATA SSDs, die für den Einsatz in hochverfügbaren Server-Umgebungen ausgelegt sind.

Generell lässt sich durch den Einsatz von SSDs die Anzahl der gleichzeitig möglichen Anfragen an den Webserver deutlich erhöhen. In unseren Tests konnten wir insbesondere bei Magento-Shops eine spürbare Verbesserung der Performance feststellen; hier lässt sich die für das Suchmaschinen-Ranking wichtige Antwortzeit (Time To First Byte) um etwa 50% reduzieren.

Alle Bestandskunden wurden in den letzten Wochen auf die neuen Server umgezogen; dieses Upgrade ist für alle Kunden kostenlos.

Pro.Hosting-Pakete (ab 30,- Euro pro Monat) eigenen sich besonders für Webseiten mit komplexen PHP-Anwendungen und hohen Nutzerzahlen. Mit PHP-FPM und OpCache lassen sich viele Seiten spürbar beschleunigen, was die Nutzerzufriedenheit steigert und die Bewertung durch Suchmaschinen verbessert. Darüber hinaus gelten in den Pro.Hosting-Paketen höhere Limits für Scriptlaufzeiten, Arbeitsspeicher und der Zahl gleichzeitig laufender Prozesse. In den Paketen Pro.B und Pro.C mit eigenem Webserver können Kunden mittels Phusion Passenger auch Ruby on Rails, Python (WSGI) und Node.js Anwendungen auf dem Webserver nutzen.

Beginn der Let’s Encrypt Testphase

Wie angekündigt beginnt ab heute (23.05.2016) die Testphase für Let’s Encrypt-Zertifikate auf unseren Webservern.

Während der Testphase kann in jedem Webhosting-Paket ein Let’s Encrypt-Zertifikat (gültig für eine Domain sowie auf Wunsch eine zusätzliche Subdomain wie z.B. www) kostenfrei genutzt werden. Reseller können in der Testphase für ihre Hosting-Kunden insgesamt bis zu 10 Let’s Encrypt-Zertifikate erhalten. Die Einrichtung der Zertifikate ist während der Testphase noch nicht über unser Kundenmenü möglich, bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Nach Ablauf der Testphase bleiben Ihre Zertifikate erhalten, wir planen in jedem Webhosting-Paket für unsere Endkunden mindestens ein Let’s Encrypt-Zertifikat ohne Mehrkosten anbieten, die dann einfach über unser Kundenmenü eingerichtet werden können. Reseller werden je nach Paket eine bestimmte Anzahl an Inklusiv-Zertifikaten erhalten.

Voraussetzung für die Ausstellung von Let’s Encrypt-Zertifikaten ist die Nutzung unserer Nameserver. Die Zertifikate gelten weiterhin nur auf unseren Webservern, falls Sie eine Domain per DNS A-Record auf Webserver von einem anderen Anbieter weiterleiten, müssen Sie ein SSL-Zertifikat bei diesem Anbieter beauftragen.

Weiterhin unterstützt Let’s Encrypt gegenwärtig keine Domain-Namen mit Sonderzeichen (IDN).

Tipp: In unseren FAQ finden Sie eine Anleitung, wie Sie nach Einrichtung des Zertifikats alle unverschlüsselten HTTP-Aufrufe auf HTTPS umleiten können.

Unterschiede zwischen Let’s Encrypt- und Comodo-Zertifikaten

Wir haben auf unseren Webservern bisher ausschließlich SSL-Zertifikate der Firma Comodo genutzt. SSL-Zertifikate dienen nicht nur zur Verschlüsselung, sondern weisen auch den Inhaber einer Domain verbindlich aus. Zur Überprüfung der Inhaberschaft gibt es unterschiedliche Verfahren:

  • Das einfachste Verfahren ist die Domain-Validierung, dabei prüft die Zertifizierungstelle mittels automatisierter technischer Vefahren, ob der Inhaber der Domain mit dem des Zertifikats übereinstimmt. Dies kann beispielsweise über spezielle DNS-Einträge erfolgen, die nach Vorgabe der Zertifizierungstelle angelegt werden müssen, und dann von dieser automatisch überprüft werden. Bei Domain-validierten Comodo-Zertifikaten übernehmen wir selbst die Prüfung der Inhaberangaben.
  • Ein besseres Verfahren ist die Inhaber- bzw. Organisations-Validierung, dazu muss der Besitzer einer Domain sich bei der Zertifizierungstelle (z.B. mittels Personalausweiskopie bei Privatpersonen oder Handelsregisterauszug bei Firmen) ausweisen, und diese Daten werden dann mit den im Whois der Domain hinterlegten Inhaberdaten verglichen. Im Zertifikat wird der Inhaber dann im Feld Organisation hinterlegt, während dieses Feld bei Domain-validierten Zertifikaten leer bleibt. Zusätzlich erfolgt eine telefonische Validierung des Inhabers durch die Zertifizierungsstelle.
    Wir empfehlen Unternehmen, Inhaber-validierte Zertifikate zu nutzen, da bei Domain-validierten Zertifikaten ein Missbrauch durch Angabe falscher Inhaber-Informationen viel einfacher möglich ist. Inhaber-validierte Zertifikate sind in der Wahrnehmung der meisten Nutzer seriöser und vertrauenswürdiger.
  • Eine besonders strenge Prüfung erfolgt bei sogenannten Extended Validation Zertifikaten, die sich für hohe Sicherheitsanforderungen empfehlen. Bei diesen wird der Inhaber des Zertifikats in der Bowser-Adresszeile grün hinterlegt angezeigt (vgl. www.variomedia.de), allerdings sind diese Zertifikate auch besonders teuer.

Let’s Encrypt Zertifikate sind ausschließlich Domain-validiert, eine Inhaber-Validierung ist nicht möglich.

Ein weiterer Unterschied besteht bei der Einbindung der Zertifikate auf den Webservern: Auf unseren Webservern verwenden wir (wie alle Shared-Hosting-Anbieter) das sogenannte namensbasierte Virtual Hosting, dabei nutzen alle Domains auf einem Webserver die gleiche IPv4-Adresse, und der Webserver ordnet einer Domain anhand des vom Browser gesendeten HTTP Host-Headers eine Webseite zu. Bei Domains mit SSL-Zertifikaten war es jedoch bis vor wenigen Jahren noch nicht möglich, mehrere Zertifikate unter der gleichen IP-Adresse zu nutzen, daher erhält jedes Comodo-Zertifikat aus technischen Gründen immer eine eigene IPv4-Adresse, die dann zusätzlich auf dem Webserver eingerichtet wird.

Für Let’s Encrypt-Zertifikate können wir jedoch keine eigenen IPv4-Adressen mehr vergeben, denn dafür stehen uns nicht genügend ungenutzte IPv4-Adressen zur Verfügung. Mittlerweile gibt es jedoch mittels SNI die Möglichkeit, beliebig viele SSL-Zertifikate unter einer IP-Adresse zu nutzen, allerdings wird dieses Verfahren von älteren Browsern (z.B. Internet Explorer 6) und Betriebssystemen (z.B. Windows XP, Android 2.4) nicht unterstützt. Es kann daher mit Let’s Encrypt-Zertifikaten bei älteren PCs, Smartphones oder Tablets zu Problemen kommen.

Hinsichtlich der Verschlüsselung gibt es jedoch keine Unterschiede zwischen Let’s Encrypt- und Comodo-Zertifikaten, unsere Webserver erfüllen alle modernen Standards wie TLS Version 1.2, (EC)DHE-Schlüsselaustausch (Perfect Forward Secrecy) und AES-Verschüsselung (SSL Labs Note A+ bei gesetztem HSTS-Header).

Update vom 01.02.2017: Die Testphase ist jetzt beendet. Bitte beachten Sie folgenden Blog-Beitrag: Let’s Encrypt-Zertifikate jetzt offiziell erhältlich

Kostenlose Let’s Encrypt Zertifikate bei Variomedia

Wie bereits angekündigt, wird es bald möglich sein, über uns kostenlose SSL-Zertifikate von Let’s Encrypt auf den Webservern zu beauftragen.

Wir haben die dafür nötigen Technologien und Methoden implementiert und werden voraussichtlich ab dem 23.05. zunächst eine Testphase für interessierte Kunden anbieten, um eventuell noch auftretende Probleme bei der automatischen Erstellung und Validierung von Zertifikaten zu beseitigen.

In der Testphase können SSL-Zertifikate auf Wunsch durch unsere Kundenbetreuung installiert werden, genauere Details zum Ablauf werden wir nächste Woche bekannt geben. Sobald alles zuverlässig funktioniert, können SSL-Zertifikate später einfach per Mausklick im Kundenmenü eingerichtet werden.

Wir planen, in jedem unserer Webhosting-Pakete zukünftig mindestens ein kostenloses SSL-Zertifikat anzubieten, das für eine Domain sowie die zugehörige www-Subdomain gilt.

Absenderverifizierung auf unseren Mail-Servern

Das Versenden von E-Mails mit einer ungültigen Absenderadresse (Envelope Sender) ist nicht zulässig und führt bei vielen Mail-Servern zu einer sofortigen Ablehnung. In diesem Fall besteht der begründete Verdacht, dass es sich um unerwünschte E-Mails (SPAM) handelt. Manchmal handelt es sich jedoch auch um legitime E-Mails, die versehentlich mit ungültigen Absenderadressen gesendet werden. Unsere Mail-Server haben bisher keine genauere Prüfung der Absenderadresse vorgenommen, wir haben uns nun jedoch dazu entschieden, ungültige Absenderadressen als zusätzliches Kriterium für unser bestehendes Greylisting zu nutzen, um weitere bisher nicht als SPAM erkannte E-Mails abzuweisen:

E-Mails mit einer Absenderadresse von einer nicht existierenden Domain oder einer Domain ohne gültigen A- bzw. MX-Eintrag führen jetzt ebenfalls zum Greylisting. Bei Absenderadressen, die auf unsere Mail-Server verweisen, wird zusätzlich geprüft, ob dieses Postfach auf unseren Mail-Servern existiert (bzw. ob es ein passendes Catch-All-Postfach gibt).

Durch das Greylisting werden diese E-Mails nicht abgelehnt, sondern erst nach einem zweiten Zustellversuch mit einer Verzögerung von mindestens 5 Minuten angenommen, es können also keine legitimen E-Mails verloren gehen.

MariaDB 10.1 verfügbar

Ab sofort können Sie im Kundenmenü für neue Datenbanken auch MariaDB in der aktuellen Version 10.1 nutzen. MariaDB ist eine Abspaltung von MySQL, die nach der Übernahme von MySQL durch Oracle von einigen früheren Entwicklern aus Unzufriedenheit mit dem neuen Eigentümer initiiert wurde. MariaDB nutzt die gleichen Schnittstellen und SQL-Befehle wie MySQL, die Version 10.1 ist weitgehend kompatibel zu MySQL Version 5.7. In den meisten Anwendungen (z.B. WordPress, Joomla, OwnCloud) können Sie einfach statt einer MySQL-Datenbank MariaDB nutzen (falls die Anwendung MariaDB nicht als eigenen Datenbank-Typ unterstützt, wählen Sie als Datenbank-Typ einfach MySQL).

MySQL 5.7 als Standard

Weiterhin haben wir die Standard-MySQL-Version für neue Datenbanken von MySQL Version 5.6 auf Version 5.7 umgestellt. Wenn Sie eine neue Datenbank anlegen, und keine andere MySQL-Version auswählen, wird standardmäßig Version 5.7 genutzt.

Mögliche Probleme mit MySQL 5.7

Seit MySQL Version 5.6 sind standardmäßig die Optionen STRICT_TRANS_TABLES und NO_ENGINE_SUBSTITUTION gesetzt, die Option STRICT_TRANS_TABLES  kann allerdings bei älteren Anwendungen manchmal zu Problemen führen. Alternativ können Sie auch weiterhin MySQL Version 5.5 oder das neue MariaDB nutzen, oder Sie deaktivieren diese Option für eine MySQL-Session über folgenden Befehl:

SET SESSION sql_mode = "NO_ENGINE_SUBSTITUTION";

MySQL 5.7 und TRIGGER-Rechte für Datenbanken

Ab sofort lassen sich im Kundenmenü neue Datenbanken mit der aktuellsten MySQL-Version 5.7 einrichten. Für neu angelegte Datenbanken sind nun außerdem standardmäßig EVENT- und TRIGGER-Rechte freigeschaltet, die beispielsweise für Magento 2 benötigt werden.

Mittelfristig werden wir auch die bestehenden MySQL-Datenbanken auf die Version 5.7 aktualisieren, dabei aber die Abwärtskompatibilität zu der Version gewährleisten, in der die jeweilige MySQL-Datenbank eingerichtet wurde.

Hinweis zum Umstieg von MySQL 5.5

Seit MySQL Version 5.6 sind standardmäßig die Optionen STRICT_TRANS_TABLES und NO_ENGINE_SUBSTITUTION gesetzt, die Option STRICT_TRANS_TABLES  kann allerdings manchmal zu Problemen führen. Diese Option kann jedoch in einer MySQL-Session über folgenden Befehl deaktiviert werden:

SET SESSION sql_mode = "NO_ENGINE_SUBSTITUTION";

Weiterhin unterscheidet sich der serverseitige Standard-Zeichensatz zwischen MySQL Version 5.5 und den neueren Versionen 5.6 und 5.7. Unsere MySQL-5.5-Datenbanken nutzen aus Gründen der Abwärtskompatibilität zu MySQL 4 standardmäßig den Latin1-Zeichensatz, MySQL 5.6/5.7 nutzen UTF-8. Falls Sie eine bestehende MySQL-5.5-Datenbank auf MySQL 5.6/5.7 migrieren, kann es dadurch unter Umständen zu Problemen bei der Darstellung von Umlauten und Sonderzeichen kommen. Diese Probleme treten meistens bei selbst entwickelten PHP-Scripten auf, wenn der der gewünschte Datenbank-Zeichensatz nicht ausdrücklich vorgegeben wird. Die meisten bekannten PHP-Anwendungen nutzen seit längerem UTF-8 als Standard-Zeichensatz und sind daher von diesen Problemen nicht betroffen, Sie können bei Problemen den alten Standard-Zeichensatz durch folgenden SQL-Befehl setzen:

SET NAMES 'latin1';

PHP 7.0 verfügbar

Seit heute steht auf unseren Webservern die neue Version 7.0 von PHP zur Verfügung. Der Versionssprung von 5.6 auf 7 liegt daran, dass die Entwicklung von PHP 6 aus verschiedenen Gründen eingestellt wurde.

Vorteile von PHP 7

Die Hauptverbesserungen bei PHP 7 wurden an den internen Datenstrukturen vorgenommen, dort konnte der Speicherbedarf stark reduziert werden. Dies führt zu einer deutlichen Erhöhung der Ausführungsgeschwindigkeit von PHP-Scripten, in der Praxis laufen viele Anwendungen wie z.B. WordPress unter PHP 7.0 doppelt so schnell wie unter PHP 5.6, der Umstieg auf PHP 7 lohnt sich also.

Mögliche Probleme beim Wechsel auf PHP 7

Bei PHP 7 wurden einige bisher nur als veraltet markierte Extensions endgültig entfernt, darunter auch die häufig eingesetzte originale MySQL-Extension. Als Alternativen können die MySQL-Improved-Extension (MySQLi) oder PDO genutzt werden.

Weiterhin sind einige Begriffe wie int, float, bool, string, true, false und null nun reserviert und dürfen nicht mehr für Klassennamen oder Ähnliches genutzt werden, dies führt bei einigen PHP-Anwendungen wie beispielsweise Joomla zu Problemen.

Eine vollständige Übersicht der nicht abwärtskompatiblen Änderungen finden Sie hier.

Aufgrund dieser Änderungen sind viele bekannte PHP-Anwendungen nicht kompatibel mit PHP 7. Für die meisten betroffenen Anwendungen sollten jedoch in Kürze Updates erscheinen, die diese Probleme beheben. Die bei uns am häufigsten genutzte PHP-Anwendung WordPress ist in der aktuellen Version vollständig kompatibel mit PHP 7, es kann jedoch unter Umständen Probleme mit älteren WordPress-Plugins geben.

PHP 7 aktivieren

PHP 7 wird nicht automatisch für alle PHP-Scripte auf unseren Webservern genutzt, da bei einer Änderung der Standard-PHP-Version viele Webseiten nicht mehr korrekt funktionieren würden. Sie können jedoch die gewünschte PHP-Version für Ihre Webseiten über eine Konfigurationsdatei vorgeben, eine Anleitung dazu finden Sie hier.

Let’s Encrypt Zertifikate bei Variomedia

Ab dem 3. Dezember wird die Zertifizierungsstelle Let’s Encrypt kostenlose SSL-Zertifikate für Webserver ausstellen, die von sämtlichen Web-Browsern akzeptiert werden. Wir erhalten derzeit viele Anfragen von Kunden, ob wir diese ebenfalls unterstützen werden. Grundsätzlich planen wir, Let’s Encrypt Zertifikate anzubieten. Es gibt allerdings noch einige bisher ungelöste technische Probleme bei der Domain-Validierung durch Let’s Encrypt, so dass wir derzeit noch nicht genauer sagen können, wann und in welcher Form wir diese Zertifikate anbieten können.

Um ein SSL-Zertifikat zu erhalten, muss zuvor bei der Zertifizierungsstelle der Besitz der Domain nachgewiesen werden. Let’s Ecrypt nutzt hierzu einen Mechanismus, der eine Datei mit einem verschlüsselten Token per HTTP von der gewünschten Domain herunterlädt, die nur vom Inhaber der Domain angelegt werden kann. Alternativ kann auch eine Validierung mittels spezieller DNS-Einträge erfolgen, dieses Verfahren wird jedoch zum Start von Let’s Encrypt am 3. Dezember noch nicht unterstützt, sondern erst später nachgereicht.

Um den gesamten Vorgang zu automatisieren stellt Let’s Encypt eine eigene Software bereit, die jedoch auf unseren Webservern nicht funktioniert. Wir müssen daher das von Let’s Encrypt genutzte ACME-Protokoll selbst implementieren. Weiterhin gelten die Let’s Encrypt-Zertifikate nur 90 Tage, so dass wir auch eine automatische Verlängerung implementieren müssen. Eine automatisierte Validierung ist in unserem Webserver-Verwaltungssystem praktisch nur mittels DNS-Validierung umsetzbar, daher müssen wir noch warten, bis dies von Let’s Encrypt unterstützt wird.

Bitte beachten Sie, dass es bei uns grundsätzlich nicht möglich ist, selbst erstellte oder von regulären Zertifizierungsstellen direkt erworbene SSL-Zertifikate einzubinden, da wir ein automatisiertes System zur Verwaltung von SSL-Zerfikaten nutzen, das nicht mit Zertifikaten anderer Anbieter funktioniert.

Phusion Passenger für Ruby, Python und Node.js

Wir erhalten regelmäßig Anfragen, ob wir auch Hosting für Ruby on Rails, Python WSGI oder Node.js anbieten können. Daher planen wir, in unseren Pro-Paketen und auf Dedicated-Servern zukünftig auch Ruby Rack (z.B. Ruby on Rails, Sinatra), Python WSGI (z.B. Django, Flask, Pyramid) und Node.js mittels Phusion Passenger (als Apache-Modul) zu unterstützen. Passenger, auch als mod_rails bekannt, ist der Standard-Application-Server für Ruby on Rails, unterstützt jedoch auch andere Sprachen wie Python (WSGI) und Node.js.

Um eine Web-Anwendung mittels Passenger zu nutzen, muss sich diese an die typische Rack-Verzeichnisstuktur halten. Python- und Node.js-Anwendungen lassen sich sehr einfach anpassen:

  • Im Hauptverzeichnis der Web-Anwendung muss ein Unterverzeichnis “public” für statische HTML-Dateien, Bilder und CGI-Scripte angelegt werden.
  • Der Webserver-Pfad für die gewünschten Domains sollte auf dieses Verzeichnis zeigen.
  • Im Hauptverzeichnis der Web-Anwendung muss Passenger per .htaccess-Datei aktiviert und ein Startup-Script angelegt werden, dass die Anwendung lädt (z.B. config.ru, passenger_wsgi.py, app.js).
  • Wenn im Public-Verzeichnis keine Indexdatei (index.html, index.php, usw.) hinterlegt ist, wird die Anfrage vom Webserver an Passenger weitergeleitet.
  • Passenger lädt beim ersten Seitenaufruf das Startup-Script der Anwendung und leitet dann alle Anfragen an diese weiter.

Für interessierte Kunden bieten wir ab sofort eine kostenlose Testphase unserer Pro-Pakete an, bitte wenden Sie sich dazu an unsere Kundenbetreuung.