Probleme mit der Autodiscover-Funktion von Outlook und Exchange (ActiveSync)

Microsoft Outlook und andere Exchange-kompatible E-Mail-Programme nutzen einen sogenannten Autodiscover-Mechanismus, um die Einstellungen (z.B. Posteingangsserver, Postausgangsserver, Authentifizierungsmethode) zu einem E-Mail-Postfach automatisch zu erkennen. Leider hat dieser Mechanismus einen grundlegenden Konstruktionsfehler, der seit der Einführung von Let’s Encrypt-Zertifikaten auf unseren Webservern zu unerwarteten Problemen führt:

Bei der Einrichtung eines neuen Postfachs sucht Outlook zuerst unter der Domain der E-Mail-Adresse per HTTPS nach einer passenden Konfigurationsdatei (z.B. “https://variomedia.de/autodiscover/autodiscover.xml”). Wenn die Verbindung zum HTTPS Port 443 abgelehnt wird, oder die Konfigurationsdatei nicht exisitiert, wird im nächsten Schritt die Subdomain autodiscover probiert (z.B. “https://autodiscover.variomedia.de/autodiscover/autodiscover.xml”). Wenn auch dies fehlschlägt, wird im letzten Schritt nach einem Autodiscover-SRV-Eintrag im DNS gesucht. Wenn jedoch ein ungültiges SSL-Zertifikat für die (Sub-)Domain hinterlegt ist, so wird eine entsprechende Warnung angezeigt.

Leider hat Microsoft dabei nicht bedacht, dass es auch Webserver gibt, die Server Name Identification (SNI) für SSL-Zertifikate nutzen, um mehrere Zertifikate unter einer IP-Adresse zu ermöglichen. In diesem Fall ist für manche Domains ein SSL-Zertifikat hinterlegt, und für andere Domains nicht. Wenn auf eine Domain, für die kein gültiges SSL-Zertifikat hinterlegt ist, per HTTPS zugegriffen wird, so liefert der Webserver standardmäßig das erste vorhandene SSL-Zertifikat aus. Da dieses Zertifikat aber nicht für die angefragte Domain gilt, wird nun eine entsprechende Warnung angezeigt.

Falls Sie einen neuen E-Mail-Account in Outlook einrichten, und für Ihre Domain kein SSL-Zertifikat hinterlegt ist, kommt es daher nun immer zu einer Fehlermeldung. Ihnen wird dann das SSL-Zertifikat für “ws0.web.vrmd.de” angezeigt. Sie können dieses Zertifikat entweder akzeptieren, oder die automatische Einrichtung mittels Autodiscover abbrechen.

Wir bieten einen Autodiscover-Dienst für Outlook und andere Exchange-kompatible E-Mail-Programme unter autodiscover.variomedia.de (bzw. autodiscover.securehost.de) an, der über einen SRV-Eintrag im DNS-Bereich genutzt werden kann. Diese SRV-Einträge wurden im Zuge der Einführung von Open-Xchange für alle Domains automatisch gesetzt.

Update vom 16.06.:

Wir werden für Let’s Encrypt Zertifikate zukünftig eine zusätzliche IP auf jedem Webserver einrichten, so dass die normale Webserver-IP keine HTTPS-Verbindungen mehr annimmt. Damit kann dieses Problem nicht mehr auftreten.

Probleme mit ownCloud und PHP 7

Gegenwärtig gibt es ein Problem mit ownCloud und der aktuellen PHP-Version 7.0.6, die wir am 29.04. auf allen Webservern installiert haben. Betroffen sind ausschließlich Kunden, die PHP 7 manuell über eine .htaccess-Konfigurationsdatei aktiviert haben. Unter PHP 7 wird beim Aufruf der ownCloud-Seite die Fehlermeldung “Interner Serverfehler” angezeigt. Die Ursache ist ein Programmierfehler in ownCloud, der bei den vorigen PHP-Versionen noch keine Auswirkungen hatte.

Die einfachste Lösung für dieses Problem ist die ältere PHP-Version 5.6 zu nutzen, bis der Fehler durch ein ownCloud-Update behoben wird. Eine Anleitung zur Auswahl der PHP-Version finden Sie hier.

Falls Sie weiterhin PHP 7 nutzen möchten, muss die PHP-Datei “request.php” im ownCloud-Unterverzeichnis “lib/private/appframework/http” angepasst werden. Sie können diese Datei per (S)FTP herunterladen oder direkt auf dem Webserver mit einem Texteditor bearbeiten. Suchen Sie nach der Zeile “public function __isset($name) {” und fügen dort die folgenden 3 grün markieren Zeilen hinzu:

    public function __isset($name) {
        if (in_array($name, $this->allowedKeys, true)) {
            return true;
        }
        return isset($this->items['parameters'][$name])
    }

Update vom 02.05.2016: Wir haben bei allen von uns für Kunden installierten Owncloud-Instanzen die entsprechenden Änderungen vorgenommen.

Probleme beim POP3-Abruf in Outlook 2016

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.

Das perfekte Last-Minute-Geschenk für Kunden in Berlin, Hamburg und Köln

150 Vor- und Nachnamen-Domains im Angebot!
150 Vor- und Nachnamen-Domains im Angebot!

Ihnen fehlt noch das perfekte Weihnachtsgeschenk? Verschenken Sie eine Domain (oder beschenken Sie sich selbst)! Wir haben eine Reihe sehr persönlicher Domainnamen mit Vor- und Nachnamen mit den TLDs .berlin, .hamburg und .koeln erworben, die wir noch pünktlich zu Weihnachten anbieten können – von aaron.berlin bis yvonne.berlin, von adler.hamburg bis wolters.hamburg und von becker.koeln bis weber.koeln.

Wenn Sie nicht nur die Domain, sondern auch ein Hosting-Paket verschenken möchten, haben wir zu Weihnachten ein besonderes Angebot. Sie erhalten unser Easy.A-Paket (Wert: 24,- Euro pro Jahr), die Domaingebühren (Wert: zwischen 21,- und 48,- Euro pro Jahr) und ein SSL-Zertifikat (Wert: 79,- Euro pro Jahr) für 3 Jahre zum Komplettpreis von 80,- Euro als Upgrade zur gewählten Domain.

Bitte klicken Sie auf die gewünschte Domain, um zum Angebot zu gelangen. Folgende Domainnamen stehen zur Verfügung:

.berlin .hamburg .koeln

Um eine der Domains zu erwerben, nutzen Sie bitte das Formular auf der jeweiligen Seite oder schreiben Sie uns an info@variomedia.de.

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):

opcache-file-small

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.

Probleme bei der Einrichtung von E-Mail-Konten unter Thunderbird

Beim beliebten E-Mail-Client Thunderbird gibt es einen seit mehreren Jahren unbehobenen Bug bei der Erkennung der SMTP-Server-Einstellungen, der für Probleme bei der Einrichtung von E-Mail-Konten sorgt.

Das SMTP-Protokoll wird zum Versenden von E-Mails genutzt. Thunderbird nutzt für SMTP standardmäßig den TCP-Port 587, für den wir auf unseren SMTP-Servern (optional) Verschlüsselung mittels StartTLS anbieten. Bei der automatischen Erkennung der Server-Einstellungen versucht Thunderbird zunächst eine verschlüsselte Verbindung mittels StartTLS aufzubauen. Wenn dies fehlschlägt, wird eine unverschlüsselte Verbindung genutzt.

Leider hält sich Thunderbird bei der Erkennung der SMTP-Server-Einstellungen nicht genau an das SMTP-Protokoll, so dass unser Mail-Server beim Verbindungsaufbau mittels StartTLS eine Fehlermeldung zurückliefert, und Thunderbird dann automatisch eine unverschlüsselte Verbindung wählt:

smtp_500

In aktuellen Thunderbird-Versionen wird dann im nächsten Schritt eine Warnung angezeigt, dass keine Verschlüsselung genutzt wird, obwohl unsere Server sehr wohl Verschlüsselung unterstützen:

tb-fehler-500

Wählen Sie in diesem Fall für den SMTP-Server entweder unter Port 465 und unter SSL SSL/TLS und klicken dann auf “Erneut testen”, dann sollte die automatische Erkennung sofort funktionieren und Sie können “Fertig” auswählen.

Alternativ können Sie unter Port 587 und unter SSL StartTLS wählen und dann “Erneut testen” klicken. Meistens schlägt der Verbindungstest dann jedoch erneut fehl, und Thunderbird meldet einen Fehler. In diesem Fall sollten sie so lange auf “Erneut testen” klicken, bis es irgendwann klappt. Dies erfordert normalerweise mehrere Versuche, doch irgendwann funktioniert es und Sie können “Fertig” auswählen.

Probleme mit PayPal nach SSL-Abschaltung

Der Zahlungsanbieter PayPal hat zum 12.01.2015 die Unterstützung der mittlerweile veralteten SSL-Verschlüsselung eingestellt, dadurch funktionieren die Zahlungsmodule vieler bekannter Webshops wie Oxid, Gambio, xt:commerce oder Prestashop unter Umständen nicht mehr. Ältere Versionen der PayPal-Module dieser Webshops setzen die Verschlüsselung der Verbindung zu den PayPal-Servern fest auf SSL Version 3, daher wird die sonst standardmäßig benutzte, sichere TLS-Verschlüsselung nicht eingesetzt.

Die meisten Webshop-Anbieter haben mittlerweile Updates herausgebracht, die dieses Problem beheben. Falls Sie auf unseren Webservern einen Webshop mit PayPal-Anbindung installiert haben, sollten Sie daher dringend prüfen, ob es Updates für die von Ihnen eingesetzte Shop-Software gibt.

Sie können prüfen, ob Ihr Webshop betroffen ist, in dem Sie nach “CURLOPT_SSLVERSION” im PHP-Quellcode des PayPal-Moduls suchen. Loggen Sie sich dazu einfach per SSH auf Ihrem Webserver ein und geben folgenden Befehl ein:
ag CURLOPT_SSLVERSION

Dann werden Ihnen alle Dateien angezeigt in denen diese Zeichenkette vorkommt. Achten Sie dabei auf Dateien, deren Name “paypal” enthält. Sie sind von diesem Problem betroffen, wenn Sie in diesen Dateien Zeilen ähnlich den folgenden finden:
curl_setopt ($ch, CURLOPT_SSLVERSION, 3);
curl_setopt ($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv3);

Falls es keine Updates für Ihren Webshop gibt, können Sie diese Zeilen einfach im Quellcode auskommentieren (am Anfang der Zeile // hinzufügen), dann wird automatisch TLS-Verschlüsselung genutzt.

Ausführlichere Informationen und Hintergründe finden Sie bei t3n.

Probleme beim E-Mail-Versand mit Speedport-Routern der Deutschen Telekom

Bei den aktuellen Speedport-Routern (Modell “W 724V”) der Deutschen Telekom kommt es zu Problemen mit dem Mailversand über den Variomedia SMTP-Server, da die Telekom dort standardmäßig alle SMTP-Server bis auf die eigenen und die weniger anderer großer Anbieter gesperrt hat. Betroffen sind insbesondere Telekom-Kunden, die im Rahmen der Umstellung auf den IP-basierten Anschluss einen neuen Router erhalten haben.

Um wieder E-Mails über unseren SMTP-Server versenden zu können, müssen Sie diese Sperre entweder entweder ganz deaktiveren, oder den Variomedia SMTP-Server manuell freischalten. Loggen Sie sich dazu im Web-Interface des Routers (URL: “speedport.ip”) ein und wählen Sie oben das Menü “Internet”. Dann finden Sie links ein Menü “Liste der sicheren E-Mail-Server”, dort wählen Sie entweder die Option “Liste der sicheren E-Mail-Server verwenden” ab, oder Sie fügen den Variomedia SMTP-Server “smtp.variomedia.de” (bzw. “smtp.securehost.de”) zur Liste hinzu.

Nachtrag
Mit der Aktualisierung vom 10.03. hat die Telekom unsere SMTP-Server zu dieser Liste hinzugefügt, damit sollte das Problem behoben sein.

Apache-Modul “mod_speling” verfügbar

Auf unseren Linux-basierten Webservern wird (im Gegensatz zu normalen Windows-PCs) zwischen Groß- und Kleinschreibung bei Datei- und Verzeichnisnamen unterschieden, wenn Sie z.B. in Ihrem Webspace-Verzeichnis eine Datei “index.php” ablegen, und diese im Web-Browser als “INDEX.PHP” aufrufen, so wird der Aufruf fehlschlagen. Beim Domainnamen hingegen wird nicht zwischen Groß- und Kleinschreibung unterschieden, so macht es z.B. keinen Unterschied, ob Sie “variomedia.de” oder “VARIOMEDIA.DE” in Ihrem Browser aufrufen.
Manchmal ist es auch wünschenswert, dass kleine Tippfehler bei URLs automatisch korrigiert werden. z.B. wenn im Browser statt “.html” als Dateiendung “.htm” eingegeben wird.

Mit dem Apache-Modul mod_speling können diese Fehler in URLs automatisch korrigiert werden, der Webserver leitet dann auf die korrekte URL weiter. Falls es zu einer ungültigen URL mehrere möglicherweise passende Dateien auf dem Server gibt, wird eine Auswahl dieser Dateien angezeigt.

Das Modul wurde gestern auf allen Webservern installiert, ist jedoch aus Sicherheits- und Performancegründen standardmäßig deaktiviert. Um es zu aktivieren, muss eine .htaccess-Datei mit der Option “CheckSpelling on” im gewünschten Webspace-Verzeichnis erstellt werden. Sie können dabei wählen, ob ausschließlich Groß-/Kleinschreibung oder zusätzlich auch (maximal 1) Tippfehler automatisch korrigiert werden sollen:

Tippfehler und Groß-/Kleinschreibung korrigieren
<IfModule mod_speling.c>
  CheckSpelling on
</IfModule>

Nur Groß-/Kleinschreibung korrigieren
<IfModule mod_speling.c>
  CheckSpelling on
  CheckCaseOnly on
</IfModule>

Wie bei .htaccess-Dateien üblich gilt diese Einstellung dann auch für alle Unterverzeichnisse.

OpenSSL-Bug

Unter dem Namen “Heartbleed” ist in der Nacht von Montag zu Dienstag dieser Woche ein Fehler in der freien Software “OpenSSL” bekannt geworden, der sehr weitreichende Folgen für alle Internet-Nutzer hat. Heise Online schreibt dazu:

Die weit verbreitete Krypto-Bibliothek OpenSSL enthielt einen Programmierfehler, der es erlaubte, von betroffenen Systemen geheime Schlüssel, Passwörter und andere Daten auszulesen. Krypto-Guru Bruce Schneier stuft den Fehler als “Katastrophe” ein: “Auf einer Skala von 0 bis 10 ist das eine 11”.

Betroffen sind zahlreiche Dienste im Internet, die diese Software einsetzen – von Facebook, über Dropbox bis zu Yahoo und Google. Aktuelle Informationen und eine umfangreiche Erklärung des Fehlers finden Sie unter http://www.heise.de/thema/Heartbleed. Eine aktuelle Liste großer betroffener Dienste finden Sie hier.

Wie sind Variomedia-Kunden betroffen?

Es gibt zwei Ebenen, auf denen SSL und der Heartbleed-Bug bei uns eine Rolle spielen:

  • Kunden, die ein eigenes SSL-Zertifikat für die verschlüsselte Datenübertragung (z.B. für ihrem Online-Shop) nutzen sind bis auf sehr wenige Ausnahmen (<1%) nicht betroffen, da wir hier eine OpenSSL-Version einsetzen, die den Fehler nicht enthält.
  • Betroffen sind allerdings alle Nutzer unserer eigenen Dienste, wie des Webmails, des Kundenmenüs, DynDNS und aller weiteren Dienste, die unter variomedia.de und securehost.de angeboten werden.

Es gibt im Moment keine Hinweise darauf, dass der OpenSSL-Fehler ausgenutzt wurde und Daten unserer Kunden missbraucht wurden – eine endgültige Sicherheit gibt es diesbezüglich jedoch nicht. Wir haben wenige Minuten nach Bekanntwerden des Bugs ein Update auf allen Servern eingespielt, das den Fehler behebt. In den letzten Tagen wurden außerdem alle SSL-Zertifikate ausgetauscht, deren Schlüssel potentiell kompromittiert gewesen sein könnten.

Was ist zu tun?

Wir empfehlen dennoch allen Kunden, alle Passwörter zu ändern, d.h. insbesondere Passwörter für:

  • Kundenmenü
  • E-Mail-Postfächer

Nicht unmittelbar betroffen sind folgende Dienste, bei denen wir dennoch die Änderung von Passwörtern empfehlen:

  • FTP/SFTP/SSH
  • MySQL (Bitte beachten Sie, dass bei einer Änderung des MySQL-Passworts auch Änderungen in Ihren Scripten erforderlich sind.)
  • DynDNS (Bitte ändern Sie die Zugangsdaten auch in Ihren Routern/DynDNS-Scripten.)

Es ist eine gute Gelegenheit, wirklich sichere Passwörter zu vergeben. Hilfreiche Tipps dazu finden Sie auf den Seiten des BSI (Bundesamt für Sicherheit in der Informationstechnik).

Für Fragen stehen Ihnen wir Ihnen gerne zur Verfügung!