Abschaltung der unverschlüsselten Nutzung unserer Mailserver zum 05. März 2025

Ab dem 05. März 2025 werden wir keine unverschlüsselten Verbindungen und keine Verbindungen mit den veralteten TLS-Versionen (1.0 und 1.1) zu unseren SMTP-, IMAP- und POP3-Servern mehr zulassen. Diese Maßnahme dient dazu, die Sicherheit Ihrer Daten und unserer Systeme zu erhöhen.

Warum diese Änderungen?

Unverschlüsselte Verbindungen stellen ein erhebliches Sicherheitsrisiko dar: Zugangsdaten und E-Mail-Inhalte können einfach abgefangen werden.

Die TLS-Versionen 1.0 und 1.1 gelten seit 2021 als veraltet und werden von aktuellen Betriebssystemen und E-Mail-Programmen ohnehin nicht mehr unterstützt.

Was bedeutet das für Sie?

Die meisten unserer Kundinnen und Kunden müssen nichts tun. E-Mail-Konten, die in den letzten Jahren auf einem PC oder Smartphone eingerichtet wurden, sollten automatisch mit den richtigen Einstellungen für verschlüsselte Verbindungen angelegt worden sein.

Dennoch sollten Sie dies in den Konto-Einstellungen Ihres E-Mail-Programms prüfen. Für die Verbindung zu unseren Servern muss SSL/TLS oder STARTTLS aktiviert sein. Die Standard-Ports lauten:

SMTP
smtp.variomedia.de
IMAP
imap.variomedia.de
POP3
pop3.variomedia.de
STARTTLS587, 25143110
SSL/TLS465993995

Die Nutzung von TLS 1.2 (seit 2008) und neuer wird von den meisten Systemen seit vielen Jahren unterstützt:

  • Microsoft Outlook: ab Version 2016
  • Mozilla Thunderbird: ab Version 52
  • Windows: ab Version 8
  • macOS: ab Version 10.11.6
  • iOS: ab Version 9
  • Android: ab Version 5

Problematisch könnten sehr alte E-Mail-Programme, Betriebssysteme oder IoT-Geräte (z.B. Router, Multifunktionsdrucker, Netzwerkkameras) aus der Zeit vor dem Jahr 2016 sein, die E-Mails über unsere Server verschicken oder abrufen.

Erlaubt eines Ihrer Geräte oder E-Mail-Programme keine verschlüsselten Verbindungen zu Mailservern, sollten Sie prüfen oder beim Hersteller nachfragen, ob es ein entsprechendes Update gibt.

Übergangszeit

Für eine beschränkte Übergangszeit bis zum 30.05.2025 stellen wir alternative SMTP- und IMAP/POP3-Server bereit, die noch TLS 1.0 und 1.1 und unverschlüsselte Verbindungen unterstützen:

ProtokollServername
SMTPsmtp-legacy.variomedia.de
IMAPimap-legacy.variomedia.de
POP3pop3-legacy.variomedia.de

Bei Bekanntwerden schwerwiegender Sicherheitsprobleme mit TLS 1.0 oder 1.1 kann jedoch eine frühere Abschaltung dieser TLS-Versionen erforderlich werden.

Hintergrund: Abschaltung veralteter TLS-Versionen

Transport Layer Security (TLS), auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist das am häufigsten verwendete Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Es wird beispielsweise zur verschlüsselten Übertragung von Webseiten (HTTPS) oder E-Mails (SMTPS, IMAPS, POP3S) genutzt.

Die ursprüngliche TLS-Version 1.0 wurde im Jahr 1999 vorgestellt, aktuell ist die TLS-Version 1.3 aus dem Jahr 2018. Die TLS-Versionen 1.0 und 1.1 wurden von der Internet Engineering Task Force (IETF) im März 2021 als veraltet eingestuft und sollten nicht mehr verwendet werden.

Die Unterstützung von TLS 1.0 und 1.1 bei verschlüsselten Webseiten (HTTPS) haben wir aufgrund von Sicherheitsproblemen bereits am 15. Februar 2020 eingestellt. Bei den E-Mail-Protokollen SMTP, IMAP und POP3 unterstützen wir jedoch aus Kompatibilitätsgründen bisher noch diese veralteten TLS-Versionen.

E-Mail-Programme verwenden normalerweise automatisch die aktuellste unterstützte TLS-Version, für die Nutzung einer aktuellen TLS-Version ist daher keine Konfigurationsanpassung erforderlich; es genügt ein aktuelles E-Mail-Programm zu verwenden. TLS 1.0 und 1.1 werden von aktuellen Betriebssystemen und E-Mail-Programmen nicht mehr unterstützt, diese verwenden immer TLS 1.2 oder 1.3.

Momentan können die TLS-Versionen 1.0 und 1.1 im E-Mail-Kontext mit bestimmten Schlüsselaustauschprotokollen und Verschlüsselungsalgorithmen noch ohne gravierende Sicherheitsprobleme genutzt werden, da es für diese bisher keine bekannten Schwachstellen gibt, die über die E-Mail-Protokolle ausgenutzt werden können. Einige bekannte E-Mail-Anbieter wie Google Mail unterstützen aus Kompatibilitätsgründen ebenfalls noch diese veralteten TLS-Versionen.

Im Hinblick auf mögliche Sicherheitsprobleme können wir diese veralteten TLS-Versionen jedoch nicht unbegrenzt weiter unterstützen, da es im Falle von neu entdeckten Problemen keine Updates der betroffenen TLS-Softwarebibliotheken mehr geben wird. Außerdem kann die Nutzung von veralteten TLS-Versionen durch Sicherheitsrichtlinien untersagt sein. Auch Cyberversicherungen untersagen ihren Kundinnen und Kunden vermehrt die Nutzung von Mailservern, die noch die veralteten TLS-Versionen unterstützen.

Neue Funktionen in der E-Mail-Verwaltung

Nutzer:innen eines Postfachs können für dieses Postfach unter https://my.variomedia.de/mail auch ohne Kundenmenü-Zugang zahlreiche Einstellungen vornehmen:

  • Änderung des Passworts
  • Setzen von automatischen Antworten mit Start- und Enddatum
  • Hinzufügen und Entfernen von zusätzlichen Empfängern
  • Konfiguration des Spamschutzes

Neu hinzugekommen sind nun zwei weitere Funktionen:

  • Anzeige des verbrauchten Speicherplatzes im Postfach (stündlich aktualisiert)
  • Anlegen von Anwendungspasswörtern

Beide Funktionen waren bisher nur im Kundenmenü verfügbar, für das in der Regel nur wenige berechtigte Personen (z.B. die Geschäftsleitung) einen Zugang haben.

Die Nutzung von Anwendungspasswörtern (auch “App-Passwords” oder “Application Passwords” genannt) ist ein deutlicher Sicherheitsgewinn bei der E-Mail-Nutzung. Anstatt für jedes Gerät und jede Anwendung, in der ein Postfach eingerichtet ist, das gleiche Kennwort zu benutzen, können Sie individuelle Passwörter für jedes Gerät anlegen. Geht ein Gerät verloren, können Sie genau dieses Passwort löschen und damit den unberechtigten Zugriff auf Ihre E-Mails verhindern. Mehr Informationen dazu finden Sie in unserem FAQ-Artikel “Wie nutze ich Application Passwords?

DKIM-Signierung aller ausgehenden E-Mails

Seit einigen Wochen werden ausgehende E-Mails, die über unseren SMTP-Server verschickt werden, automatisch mit dem DKIM-Verfahren (DomainKeys Identified Mail) signiert.

Was ist DKIM?

DKIM ist ein Verfahren zur E-Mail-Authentifizierung, das ausgehende E-Mails mit einer digitalen Signatur versieht. Diese Signatur ermöglicht es dem empfangenden Mailserver zu prüfen, ob die E-Mail tatsächlich von Ihnen stammt und unterwegs nicht manipuliert wurde.

Warum ist DKIM wichtig?

DKIM erhöht die Sicherheit und Zuverlässigkeit Ihrer E-Mail-Kommunikation durch folgende Vorteile:

  • Schutz vor Fälschungen: DKIM verringert die Wahrscheinlichkeit, dass gefälschte E-Mails im Namen Ihrer Domain vom Empfänger akzeptiert werden.
  • Besseres Ansehen Ihrer E-Mails: Viele E-Mail-Provider wie Gmail oder Microsoft bevorzugen signierte E-Mails und stufen sie seltener als Spam ein.
  • Mehr Vertrauen: Empfänger können sicherer sein, dass Ihre E-Mails authentisch und tatsächlich von Ihrer Domain versendet wurden.

Mit der Einführung von DKIM stärken wir die Sicherheit und Vertrauenswürdigkeit Ihrer E-Mail-Kommunikation.

Tipps zur Nutzung von DKIM

Ausführliche Informationen zur Funktionsweise von DKIM, der Nutzung eines Postfachs als SMTP-Relay (Smarthost) sowie der Einbindung externer Domains finden Sie in unserem FAQ-Artikel „Wie kann ich DKIM zur Authentifizierung von ausgehenden E-Mails nutzen?“.

Darüber hinaus bietet DKIM die Grundlage für den Einsatz von DMARC. Mit DMARC können Sie festlegen, wie E-Mails behandelt werden sollen, die mit gefälschten Absendern verschickt wurden. Mehr dazu erfahren Sie in unserem Artikel „Wie erstelle ich eine DMARC-Richtlinie?“.

Probleme mit Leerzeichen in Apache Rewrite Regeln

Wir haben heute früh ein Update der Webserver-Software Apache auf die aktuelle Version 2.4.56 eingespielt. Seit diesem Update gibt es nun vereinzelt Probleme beim Aufruf von URLs mit Leerzeichen.

Fehlermeldung

Falls Sie eine URL mit einem Leerzeichen aufrufen, erhalten Sie unter Umständen seit heute früh die folgende Fehlermeldung:

Forbidden

You don’t have permission to access this resource.

In den Error Logs findet sich dann folgender Fehler:

Rewritten query string contains control characters or spaces

Besonders häufig betroffen sind die Content Management Systeme Drupal und MODX, die problematische Rewrite-Regeln in der automatisch generierten .htaccess-Konfigurationsdatei verwenden.

Fehlerursache

Die Ursache für den Fehler ist ein fehlendes Escaping von Sonderzeichen in den Rewrite Regeln einer .htaccess-Konfigurationsdatei. Das Escaping von Sonderzeichen in Rewrite Strings war bis Apache Version 2.4.55 optional, seit Version 2.4.56 ist es aus Sicherheitsgründen (CVE-2023-25690) verpflichtend.

Sie können das Escaping über die Flags B (bei Umleitung auf Query Strings) bzw. BNP (bei Umleitung auf Pfade) aktivieren. Weitere Informationen finden Sie in der Apache-Dokumentation.

Beispiel

Die folgende Rewrite Regel des MODX Content Management Systems erzeugt bei Leerzeichen in der URL eine Fehlermeldung:

RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Um die Fehlermeldung zu beheben, muss die Regel wie folgt geändert werden:

RewriteRule ^(.*)$ index.php?q=$1 [B,L,QSA]

Passwort-Reset für Endkunden von Resellern

Bereits seit einiger Zeit lässt sich in unseren Reseller-Verträgen in den Einstellungen konfigurieren, ob die eigenen Nutzer:innen für my.securehost.de einen Passwort-Reset durchführen dürfen.

Die eigentliche Passwort-Reset-Funktion fehlte allerdings bisher noch. Sie ist inzwischen unter https://my.securehost.de/ verlinkt und führt zur Seite https://my.securehost.de/reset-password:

Dialog für den Passwort-Reset unter https://my.securehost.de/reset-password

Mit dem Ausfüllen des Formulars wird – sofern vollständig und freigeschaltet – eine E-Mail von no-reply@securehost.de verschickt. Diese E-Mail enthält einen Link, der eine Stunde lang gültig ist. Durch das Anklicken des Links wird nach einer weiteren Bestätigungsabfrage ein neues Passwort für den Kundenmenüzugang gesetzt und angezeigt.

Muster einer E-Mail, wie Sie beim Passwort-Reset an Account-Inhaber:innen verschickt wird

Phishing-Mails im Namen von Variomedia

Heute Nacht wurden massenhaft Phishing-Mails im Namen von Variomedia an bei uns gehostete Postfächer gesendet, in denen die Empfänger dazu aufgefordert werden, das Variomedia-Webmail zu aktualisieren. Auf der verlinkten Webseite werden die Zugangsdaten des Postfachs abgefragt, die dann in den Händen von Unbefugten landen.

Phishing-Mail, die an Variomedia-Kunden geschickt wurde
Phishing-Mail, die an Variomedia-Kunden geschickt wurde

Diese Mails sind relativ gut gemacht und nicht auf den ersten Blick als Fälschung zu erkennen. Falls Sie der Aufforderung nachgekommen sind, und Ihre Zugangsdaten hier eingegeben haben, sollten Sie umgehend das Passwort des betroffenen E-Mail-Postfachs ändern.

Hinweise zur Erkennung von Phishing-Mails

Echte E-Mails von Variomedia enthalten immer eine persönliche Anrede mit Ihrem Namen.

In Phishing-Mails werden häufig E-Mail-Absenderadressen und HTTP-Links genutzt, die im Beschreibungstext eine abweichende Adresse anzeigen. So wird z.B. als Absenderadresse “Variomedia” angezeigt aber nicht die tatsächliche Absenderadresse nutzt eine .ca Domain, und im Link steht “https://www.variomedia.de/mail/pakete/”, doch der tatsächliche Link verweist auf eine .at Domain.

E-Mails von Variomedia haben immer eine Absenderadresse (nach dem @) der Domain variomedia.de oder einer oder einer Sub-Domain von variomedia.de.

Falls wir Ihnen per E-Mail einen Link auf eine unserer Webseiten senden, so achten Sie bitte darauf, dass in der Adresszeile des Web-Browsers eine Webseite unter der Domain variomedia.de oder einer Sub-Domain von variomedia.de geladen wird. Nur auf diesen Webseiten können Sie gefahrlos Ihre E-Mail-Zugangsdaten eingeben.

Ursprung der E-Mail-Adressen

Wir können nicht sicher sagen, woher die Versender die E-Mail-Adressen haben. Es scheint sich um eine relativ alte Liste zu handeln, da bei uns viele Postfächer angeschrieben wurden, die es gar nicht mehr gibt. Alle von uns stichprobenhaft getesteten E-Mail-Adressen befinden sich in Listen von früheren Leaks. In welchen Leaks Ihre eigene E-Mail-Adresse auftaucht, können Sie auf der Seite https://haveibeenpwned.com/ oder beim Angebot des deutschen Hasso-Plattner-Instituts unter https://sec.hpi.de/ilc/search?lang=de testen.

Keine Gefahr durch “Log4j”-Sicherheitslücke

Am 09.12.2021 wurde unter dem Namen Log4Shell eine schwere Sicherheitslücke in der von vielen Java-Anwendungen genutzten Softwarebibliothek Log4j bekanntgegeben, die das Ausführen von beliebigem Schadcode auf betroffenen Servern ermöglicht.

Java ist eine eigentlich als sehr sicher geltende Programmiersprache, die daher häufig für Server-Dienste genutzt wird und auch bei uns für einige Dienste zum Einsatz kommt. Die Log4j- Softwarebibliothek wird von vielen Java-Anwendungen zum Schreiben von Protokolldateien (Logs) genutzt. Durch spezielle Zeichenketten (z.B. im User Agent-Header einer gewöhnlichen HTTP-Anfrage) können Angreifer das Nachladen von beliebiger Software veranlassen, sofern diese unverändert zur Protokollierung an Log4j durchgereicht werden.

Wir haben nach Bekanntwerden der Sicherheitslücke alle von uns genutzten Java-Anwendungen überprüft und bei von der Sicherheitslücke betroffenen Anwendungen umgehend die von den Log4j-Entwicklern vorgeschlagenen Gegenmaßnahmen umgesetzt. In den Log-Dateien der betroffenen Server gibt es keine Hinweise darauf, dass diese Sicherheitslücke vor der Umsetzung der Gegenmaßnahmen erfolgreich ausgenutzt wurde.

Web-Anwendungen wie WordPress, Typo3, Magento usw., die von unseren Kund:innen oder uns auf unseren Webservern installiert werden, sind nicht von dieser Sicherheitslücke betroffen, da sie kein Java nutzen.

Datenbankserver nicht mehr über öffentliche IP-Adressen erreichbar

Die meisten unserer Datenbankserver (MySQL und MariaDB) waren bisher über öffentliche IP-Adressen auch außerhalb unseres Rechenzentrums erreichbar. Dies ist aus Sicherheitsgründen nicht ideal, weshalb wir für neue Datenbankserver seit Anfang 2020 nur noch interne IP-Adressen nutzen.

Für ältere Datenbankserver werden wir nun zum 04.10.2021 ebenfalls eine Umstellung auf interne IP-Adressen vornehmen, damit alle Datenbankserver nur noch innerhalb des Rechenzentrums von unseren Webservern aus erreichbar sind. Für Zugriffe außerhalb unseres Rechenzentrums ist dann der Aufbau eines SSH-Tunnels zu einem unserer Webserver erforderlich.

Wen betrifft diese Änderung?

Diese Änderung ist nur für wenige Kunden relevant, die von ihrem Rechner über lokal installierte Clientsoftware wie HeidiSQL oder Warenwirtschaftssysteme direkt auf unsere Datenbanken zugreifen. Falls Sie unsere Datenbanken nur für Web-Anwendungen wie WordPress nutzen, und nicht von außerhalb auf die Datenbankserver zugreifen, ändert sich für Sie nichts.

Welche Datenbankserver sind betroffen?

Die Änderung betrifft folgende Datenbankserver (MySQL 5.5, 5.6, 5.7, 8.0, MariaDB 10.1 bis 10.5):

  • db1
  • db2
  • db3
  • db4
  • db5
  • db6
  • db7
  • db8
  • db9
  • db10
  • db12
  • db13
  • db15
  • db19
  • db21
  • db22
  • db26
  • db27

Alle anderen Datenbankserver sind schon von Anfang an nur über interne IP-Adressen erreichbar.

Wie funktioniert ein SSH-Tunnel?


Ein SSH-Tunnel stellt eine verschlüsselte VPN-Verbindung zu einem unserer Webserver her. Über diesen Tunnel können Sie sich dann mit unseren Datenbankservern verbinden, als würde es sich um lokale Datenbankserver handeln.

In unserem FAQ-Artikel “Wie kann ich mich verschlüsselt mit einem MySQL-Server verbinden?” beschreiben wir den Verbindungsaufbau über einen SSH-Tunnel für verschiedene Software-Clients und Betriebssysteme.

Wir haben festgestellt, dass nur auf etwa 0,6% aller Datenbanken ohne einen SSH-Tunnel zugegriffen wird. Nutzer, die mit einem lokalen SQL-Client auf die Datenbankserver zugreifen, haben hier nur einen überschaubaren Umstellungsaufwand. Aufwendiger könnte die Umstellung z.B. von Warenwirtschaftssystemen werden. Wir beraten Sie hier gern und helfen, eine pragmatische Lösung zu finden.

Wichtig ist: Nutzer, die weiterhin von außerhalb unserer Webserver auf unsere MySQL- und MariaDB-Datenbanken zugreifen möchten, müssen vor dem 04.10.2021 aktiv werden, damit dieser Zugriff auch nach der Umstellung noch funktioniert.

Wir werden alle Kunden, von denen wir aus Logdateien wissen, dass sie in den letzten Wochen entsprechende Zugriffe auf Datenbanken hatten, explizit anschreiben. Hören Sie nichts von uns, besteht mit großer Wahrscheinlichkeit auch kein Anpassungsbedarf.

Aktualisierung vom 30.09.2021: Ursprünglich sollte die Änderung am Freitag, den 01.10.2021 durchgeführt werden. Um bei eventuellen Problemen für Kunden besser erreichbar zu sein, haben wir die Umstellung auf Montag, den 04.10.2021 verschoben.

Wie sicher sind meine Daten bei Variomedia?

Der Brand eines Rechenzentrums unseres Mitbewerbers OVH und die damit verbundenen Datenverluste haben bei einigen unserer Kunden Fragen zur Sicherheit ihrer Daten bei Variomedia aufgeworfen. Wir nutzen diesen Anlass, um hier unsere Backup-Strategien zu beschreiben und die Brandschutzmaßnahmen im Rechenzentrum zu erläutern.

Was wird gesichert?

Wir führen tägliche (bzw. nächtliche) Sicherungen aller Webspace-Inhalte, MySQL-Datenbanken und E-Mail-Postfächer durch. Gesichert werden zudem alle Informationen, die in speziellen Datenbanken vorliegen, z.B. DNS-Einträge, Kalender und Kontakte in Open-Xchange und Webmail-Profile.

Eine besondere Maßnahme gibt es im besonders ausfallkritischen Bereich des E-Mail-Hostings: Alle Inhalte von Postfächern werden in Echtzeit auf einen zweiten Server synchronisiert. Dieser dient als “Hot Standby”. Fällt ein E-Mail-Backend aus, kann der zweite Server die Arbeit sofort übernehmen und es gehen keine E-Mails verloren.

Wie lange werden die Backups gespeichert?

Alle täglichen Backups stehen 30 Tage lang zur Verfügung. Zusätzlich bewahren wir ein Backup von jedem Sonntag für 6 Monate auf. Monatliche Backups von jedem ersten Sonntag im Monat halten wir für weitere 5 Monate vor. Insgesamt ist das älteste Backup daher in der Regel etwa ein Jahr alt.

Wie lassen sich Daten aus einem Backup wiederherstellen?

Auf Webspace- und MySQL-Backups können Sie selbst zugreifen. Eine Anleitung dazu finden Sie im FAQ-Artikel “Wie spiele ich ein Backup auf dem Server ein?”. Die Wiederherstellung ist auch durch uns möglich (kostenpflichtig).

Postfach-Inhalte können nur durch unsere Systemadministratoren wiederhergestellt werden. Nähere Informationen dazu finden Sie im FAQ-Artikel “Gibt es Backups meiner E-Mail-Postfächer?”.

Wohin wird gesichert?

Die täglichen Backups werden auf Servern gesichert, die im gleichen Rechenzentrum stehen, wie die Quellserver, von denen gesichert wird. Diese Backups helfen also nur bei Hardware-Fehlern oder bei selbst verursachten Datenverlusten, würden bei einem Brand im Rechenzentrum aber nichts nützen.

Aus diesem Grund betreiben wir in einem zweiten Rechenzentrum (ebenfalls in Berlin, aber geografisch getrennt) weitere Server, die als “Off-Site-Backup” dienen. Sobald die regulären, täglichen Backups erledigt sind, werden diese vom lokalen Backup-Server zum Off-Site-Backup-Server übertragen und dort für 30 Tage aufbewahrt.

Falls es also einen Brand in unserem primären Rechenzentrum geben sollte, stehen alle Daten vom Vortag im zweiten Rechenzentrum zur Verfügung und könnten von dort auf produktiv genutzte Server übertragen werden. Dieses Off-Site-Backup findet bei uns für alle auf unseren Servern gehosteten Daten statt und muss nicht kostenpflichtig gebucht werden.

Welche Brandschutzmaßnahmen werden im Rechenzentrum getroffen?

Die Server für unsere Webhosting-, Datenbanken- und E-Mail-Dienste sind in einem Rechenzentrum in Berlin untergebracht. Da es sich um ein sehr großes Rechenzentrum handelt, ist es in mehrere Gebäudebrandabschnitte mit hoher Feuerwiderstandsklasse (F 90 A) unterteilt. Die einzelnen Serverräume innerhalb des Rechenzentrums sind ebenso als Brandbekämpfungsabschnitte (F 90 A) ausgeführt. Dadurch wird verhindert, dass sich ein Brand innerhalb eines Serverraums innerhalb kurzer Zeit auf weitere Serverräume ausbreiten kann.

Um die Ausbreitung eines Brandes innerhalb der Serverräume zu erschweren, wurden für den Innenausbau ausschließlich spezielle, nicht-brennbare oder schwer entflammbare Materialien verwendet.

Die Serverräume sind mit Brandmeldern und einer automatischen Gaslöschanlage ausgerüstet: Im Falle eines Brandes wird der betroffene Serverraum automatisch mit einem speziellen Löschgas geflutet, das den Brand erstickt. Durch das Löschgas entstehen keine zusätzlichen Schäden an den Servern, wie sie etwa beim Löschen mit Wasser entstehen würden.

Zusätzlich zu konventionellen Brandmeldern sind die Serverräume mit einem Brandfrüherkennungssystem ausgestattet: Werden erste Anzeichen eines möglichen Brandes erkannt, so erfolgt eine umgehende Kontrolle durch Mitarbeiter des Rechenzentrums, die permanent vor Ort sind.

Durch diese Maßnahmen ist ein Brand des Rechenzentrums mit totalem Datenverlust sehr unwahrscheinlich.

Eigene Passwörter unter my.variomedia.de/mail

Passwörter für E-Mail-Postfächer bei uns lassen sich über drei verschiedene Wege setzen:

Bisher war es nur für Vertragsinhaber:innen und unter Verwendung der API möglich, ein Passwort frei zu wählen. Für Postfachnutzer:innen hingegen gab es nur die Möglichkeit, automatisch generierte Passwörter zu verwenden. Dies hat sich nun geändert.

Ab sofort ist es auch in den E-Mail-Einstellungen (my.variomedia.de/mail), eigene Passwörter zu wählen. Es gelten dabei strenge Richtlinien, die zu einfache Passwörter verhindern sollen. Ein gutes Passwort ist eher länger als kürzer und wird ausschließlich für einen einzigen Dienst verwendet. Wir empfehlen dringend die Nutzung eines Passwortmanagers.

Passwort-Regeln
Regeln zum Setzen eines Passworts unter https://my.variomedia.de/mail

Im Kundenmenü und per API ist es auch möglich, so genannte “Application Passwords” anzulegen. Hier handelt es sich um automatisch generierte Passwörter, die sich zusätzlich zum Haupt-Passwort eines Postfachs nutzen lassen und einer bestimmten Anwendung (z.B. Outlook oder Thunderbird) auf einem bestimmten Gerät (z.B. “Mein PC”) zugeordnet sind.