In der beliebten E-Mail-Software Outlook 2016 gibt es ein Problem beim Abruf von E-Mails per POP3, das zu gelöschten oder doppelt angezeigten E-Mails führen kann. Dieser Fehler tritt nur auf, wenn die Option “Kopie aller Nachrichten auf dem Server belassen” gewählt ist. Microsoft hat nun ein Update bereitgestellt, dass diesen Fehler behebt. Dieses Update kann über die automatische Updatefunktion von Outlook (bzw. Office 365) installiert werden.
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";
Schwere Sicherheitslücke in allen Joomla-Versionen
Am 14. Dezember wurde eine schwere Sicherheitslücke in allen Versionen des beliebten Content-Management-Systems Joomla bekanntgegeben, die es Angreifern ermöglicht, beliebigen PHP-Code auszuführen. Diese Sicherheitslücke wurde bereits 2 Tage zuvor ausgenutzt, um über automatisierte Scripte massenhaft Joomla-Installationen mit Schadcode zu infizieren.
Wir haben nach Veröffentlichung der Details am Abend des 14. Dezember unsere Webserver-Firewall angepasst, um die uns bekannten automatisieren Angriffe zu unterbinden, doch einen Schutz vor neuartigen Angriffen auf diese Sicherheitslücke gibt es nicht. Sofern Sie eine Joomla-Installation auf unseren Webservern nutzen, sollten Sie daher unverzüglich die bereitgestellten Updates installieren.
Joomla Version 3.x lässt sich über den integrierten Updater auf die neue Version 3.4.6 aktualisieren. Für die älteren Versionen 1.5 und 2.5 stehen Updates für die betroffene Datei “libraries/joomla/session/session.php” bereit, die manuell per (S)FTP bzw. SSH installiert werden müssen.
Update
Die Sicherheitslücke lässt sich nur in Zusammenhang mit einem Bug in älteren PHP-Versionen ausnutzen. Betroffen ist bei uns nur PHP 5.3, für das es seit längerer Zeit keine Sicherheitsupdates mehr gibt. Die für Ihre Webseite benutzte PHP-Version können Sie über eine PHP-Datei mit folgender Zeile ermitteln:
<?php phpinfo();?>
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.
Mögliche Probleme mit Apache 2.4.17 und mod_rewrite
Wir haben am 15.10. ein Update der Webserver-Software Apache von Version 2.4.16 auf 2.4.17 vorgenommen, dabei hat sich eine unerwartete Änderung im Modul mod_rewrite ergeben, die zu Problemen mit einigen PHP-Anwendungen (z.B. Concrete5) führen kann: Die Server-Variable “REDIRECT_URL” wurde von einer relativen URL (z.B. “/kapitel/2/”) auf eine vollständige URL (z.B. “http://www.domain.de/kapitel/2/”) umgestellt, daher könnten PHP-Scripte, die auf diese Variable zurückgreifen, unter Umständen nicht mehr korrekt funktionieren.
Falls Sie seit dem 15.10. Probleme mit Ihrer Webseite festgestellt haben, die zuvor nicht aufgetreten sind, wenden Sie sich bitte an unsere Kundenbetreuung.
Aktuelle Änderungen an unseren Anti-Spam-Regeln
Wir haben in den letzten Tagen einige Änderungen an unseren Mailservern vorgenommen, um die Zahl der nicht erkannten Spammails (False-Negatives) zu reduzieren. Zusätzlich zum bestehenden Spamfilter Expurgate nutzen wir nun DNS-basierte Blackhole-Listen (DNSBL) und werten SPF– (Sender Policy Framework), DKIM– (DomainKeys Identified Mail) sowie DMARC– (Domain-based Message Authentication, Reporting & Conformance) Einträge aus. Um fälschlicherweise als Spam klassifizierte E-Mails (False Positives) zu vermeiden, lehnen wir betroffene Mails nicht ab, sondern nutzen das Greylisting-Verfahren, um die Zustellung zu verzögern.
Was ist eine DNSBL?
Eine DNSBL ist eine laufend aktualisierte Liste verdächtiger IP-Adressen. Verdächtige IP-Adressen sind beispielsweise solche, über die kürzlich massenhaft Spam versendet wurde, oder dynamische IP-Adressen wie etwa von DSL-Anschlüssen von Privatkunden, die E-Mails ausschließlich über SMTP-Relays (z.B. smtp.variomedia.de) versenden sollten.
Was ist SPF?
Mittels SPF können Domaininhaber über spezielle DNS-Einträge festlegen, welche Mailserver E-Mails für diese Domain versenden dürfen.
Was ist DKIM?
Mittels einer DKIM-Signatur kann geprüft werden, ob eine E-Mail von der angegebenen Absenderadresse versendet und beim Transport nicht verändert wurde. Diese Signatur wird automatisch durch den Mail-Server des Absenders erzeugt.
Was ist DMARC?
DMARC nutzt eine Kombination aus SPF und DKIM, um zu prüfen, ob eine E-Mail von der angegebenen Absenderadresse versendet wurde. Weiterhin wird mittels DMARC festgelegt, ob E-Mails, die keine bzw. ungültige DKIM-Signaturen aufweisen oder die SPF-Regeln verletzen, abgelehnt oder angenommen werden sollen. Ähnlich wie bei SPF werden dazu spezielle DNS-Einträge genutzt, die vom Domaininhaber gesetzt werden können. DMARC wird von vielen bekannten Anbietern wie z.B. Google oder Facebook eingesetzt.
Was ist Greylisting?
Greylisting ist ein Verfahren zur Verzögerung der E-Mail-Zustellung. Verdächtige E-Mails werden dabei nicht sofort angenommen, sondern mit einem temporären Fehler abgelehnt, so dass der absendende Server später einen erneuten Zustellversuch unternimmt. Nach Ablauf der Verzögerung (meistens 5 Minuten) wird diese Mail dann angenommen. Erfolgt ein erneuter Zustellversuch, so wird der betroffene Mailserver permanent freigeschaltet, so dass weitere verdächtige E-Mails von diesem Server nicht mehr verzögert werden. Die Strategie dahinter ist, dass viele Spam-Programme keine erneuten Zustellversuche unternehmen und eine verzögerte E-Mail bei einer späteren Zustellung eventuell von unserem Spamfilter korrekt klassifiziert wird.
Wie funktionieren die neuen Anti-Spam-Regeln?
Falls die IP-Adresse des absendenden Servers auf einer DNSBL eingetragen ist, oder die SPF bzw. DMARC-Prüfung fehlschlägt, wird eine E-Mail gegreylistet (auch wenn die betroffene E-Mail nach SPF bzw. DMARC eigentlich abgelehnt werden sollte).
Eine Ausnahme sind E-Mails von PayPal (paypal.com, paypal.de), die bei fehlgeschlagener DMARC-Prüfung gemäß den Vorgaben von PayPal abgelehnt werden, da es sich mit sehr hoher Wahrscheinlichkeit um Phishing handelt.
Mögliche Probleme
Die SPF-Prüfung schlägt bei E-Mail-Weiterleitungen häufig fehl, da die weiterleitenden Server nicht zum Versenden vom E-Mails der Absenderdomain autorisiert sind. Eine Möglichkeit dieses Problem zu umgehen ist SRS (Sender Rewriting Scheme), das von uns und vielen anderen Anbietern für E-Mail-Weiterleitungen genutzt wird. Dabei wird die Absenderadresse anhand bestimmter Regeln umgeschrieben und die Absenderdomain durch die Empfänger-Domain des weiterleitenden Servers ersetzt.
PHP 7 RC 3 verfügbar
Ab sofort steht auf unseren Webservern der aktuelle Release Candidate 3 von PHP 7 zu Testzwecken zur Verfügung.
Wir haben dabei eine für viele Kunden interessante Neuerung hinzugefügt, und zwar einen Datei-basierten PHP-Beschleuniger.
Hintergründe zu PHP-Beschleunigern
PHP ist eine Script-Sprache, die vor der Ausführung auf unseren Webservern in für Computer verständlichen Mikroprozessor-Code übersetzt werden muss. PHP nutzt dabei (ähnlich wie Java) eine sogenannte Virtuelle Maschine, es wird also nicht direkt Mikroprozessor-Code erzeugt, sondern zunächst sogenannter Bytecode für eine Virtuelle Maschine (Zend Engine), die daraus dann im nächsten Schritt Mikroprozessor-Code erzeugt und diesen ausführt.
Dieser Bytecode wird jedoch nach der Ausführung eines PHP-Scripts verworfen, und muss jedes Mal zeitaufwändig neu generiert werden. Um dies zu vermeiden gibt es diverse PHP-Beschleuniger wie den PHP-eigenen OpCache, die den Bytecode für spätere Script-Aufrufe optimieren und zwischenspeichern. Allerdings wurde dieser Bytecode bisher immer im Arbeitsspeicher abgelegt, was auf unseren Shared-Hosting-Servern aus technischen Gründen nicht funktioniert, und nur in den Pro-Paketen (bzw. auf Dedicated-Servern) mit PHP-FPM möglich ist.
Seit PHP 7 kann der PHP OpCache den Bytecode optional auch in Dateien speichern, damit lässt er sich auf allen Shared-Hosting-Servern nutzen.
Wir haben anhand einer aktuellen WordPress-Installation die möglichen Performance-Verbesserungen durch OpCache getestet (Mittelwert über 100 Aufrufe):
Im Vergleich zu PHP 5.6 ohne OpCache verkürzt sich die PHP-Ausführungszeit für die WordPress-Startseite um Faktor 2, der Datei-OpCache lohnt sich also wirklich.
PHP 7 und OpCache aktivieren
Um PHP 7 mit OpCache zu nutzen, erstellen Sie zunächst ein Verzeichnis für die Bytecode-Dateien auf Ihrem Webserver. Dieses Verzeichnis können Sie beliebig benennen (z.B. “opcache”), und an beliebiger Stelle in Ihrem Benutzerverzeichnis anlegen, die Zugriffsrechte sollten jedoch aus Sicherheitsgründen auf Ihren Benutzeraccount beschränkt werden (chmod 700).
Legen Sie dann im gewünschten Webserver-Verzeichnis eine .htaccess-Datei mit folgendem Inhalt an (bzw. fügen Sie folgende Zeile zu einer bestehenden .htaccess-Datei hinzu):
AddHandler application/x-httpd-php70 .php
Anschließend legen Sie in diesem Verzeichnis eine php.ini-Datei mit folgendem Inhalt an (bzw. fügen die folgenden Zeilen zu einer bestehenden php.ini-Datei hinzu):
zend_extension=/vrmd/webserver/php70/lib/opcache.so
opcache.file_cache=/homepages/u12345/opcache
opcache.file_cache_only=1
Ersetzen Sie dabei “/homepages/u12345/opcache” durch den vollständigen Pfad zu Ihrem Bytecode-Verzeichnis. Beachten Sie bitte, dass php.ini-Dateien nur in dem Verzeichnis gelten, wo auch das aufgerufene PHP-Script liegt, eventuell müssen Sie diese Datei daher noch in weitere Unterverzeichnisse kopieren.
Hinweis
Bitte beachten Sie, dass sich PHP 7 noch in der Entwicklungsphase befindet, es können noch diverse kleinere Fehler und Probleme auftreten. Sie sollten PHP 7 daher besser noch nicht für kritische Webseiten einsetzen.