Bereits früh, ende der 90er Jahre, haben wir erkannt, dass eMail für viele Kunden enorm wichtig ist, wichtiger noch als der Webauftritt. eMails sollen ohne grosse Verzögerungen zuverlässig transportiert werden, Ausfälle sind äusserst problematisch. Gleichzeitig soll die Vertraulichkeit gewahrt bleiben und so viel Spam als möglich unterdrückt werden, ohne das legitime Mail betroffen ist. Dieser Herausforderung haben wir uns schon damals gestellt und unser Mailsystem über die Jahre immer weiter entwickelt, so dass wir heute ein äusserst leistungsfähiges, hochverfügbares Mailsystem bieten können.
Hochverfügbarer Mail-Cluster
Wir betreiben heute einen grossen, hochverfügbaren und performanten Mailcluster. Kaum eine Mail ist innerhalb unseres Clusters länger als eine Sekunde in der Zustellung. Die beiden redundanten Systeme für eingehende Mail können direkt ausliefern, es gibt kein Master-Slave-Setup, in dem eingehende Mail bei einem Ausfall des Masters auf dem Slave zwischengespeichert werden, sondern im Prinzip zwei Master-Systeme – so kommt es auch bei einem Ausfall eines Systems zu keinen Verzögerungen. Die Redundanzen sind hier Protokollimmanent.
Die Schnittstellen zu unseren Kunden – IMAP, POP3 und die SMTP-Hosts für von Kunden gesendete eMails – sind auf hochverfügbaren Clustern realisiert, der Ausfall eines Nodes sorgt somit nicht für einen Ausfall des Systems. Für die ausgehenden Mails arbeiten wir mit mehreren Instanzen, Massenmail wie Newsletter werden automatisch über eine andere Instanz versandt, so dass diese reguläre Mail nicht ausbremst.
Zum Zugriff auf Ihre Mail stellen wir Ihnen neben dem üblichen POP3 auch IMAP und ein Webmail-Interface (Sie können also Ihre Mail von jedem beliebigen Rechner mit Internet-Browser lesen und schreiben) zur Verfügung. Alle Protokolle sind auch mit SSL/TLS-Verschlüsselung nutzbar, wir empfehlen, das auch zu nutzen.
Mailaccounts, die zugehörigen Mailadressen und vieles mehr konfigurieren Sie ganz einfach über unser Control Center.
Neben all diesen für Sie als Kunden sichtbaren Frontends ist auch das gesamte Backend aus Storage-Systemen, Verzeichnisdiensten, Netzwerkinfratruktur usw. hoch redundant aufgebaut.
eMail made in…
Alle unsere Mailsysteme werden in Deutschland betrieben und unterliegen deutschem Recht.
Verschlüsselung
Einige grosse deutsche Mailprovider haben gerade mit erheblichem Medienrummel eine eMail-Verschlüsselung eingeführt. Hat man sich durch die Marketing-Worthülsen gequält, bleibt übrig, dass diese Provider nun endlich SSL/TLS aktiviert haben – dies ist bei uns seit 15 Jahren Standard. Nicht verschweigen tun wir dabei, dass diese nur bedingt hilft. Zum einen kommt eine verschlüsselte Verbindung nur zustande, wenn beide der beteiligten Mailserver diese beherrschen und aktiviert haben, ansonsten geht die Mail weiterhin unverschlüsselt durchs Netz. Zum anderen überprüfen Mailserver in der Regel die Zertifikate der Gegenseite nicht, so dass die Authentizität des Kommunikationspartners in keiner Weise verifiziert wird. Da die Mails selbst bei den Providern nach wie vor unverschlüsselt vorliegen, hilft das gegen staatliche Schnüffelei genauso wenig wie gegen gekaperte Mailsysteme. Da ein – viel einfacher zu realisierendes – mitschneiden der Verbindung nun aber nicht mehr ausreicht, um die Inhalte sehen zu können, ist diese Verschlüsselung dennoch ein Fortschritt und die Verwendung sinnvoll. Wirklich sensitive Informationen können nur mittels sogenannter Ende-zu-Ende-Verschlüsselung ohne Mitwirkung Dritter (wie uns als Provider) zuverlässig geschützt werden.
SPAM
Ein Thema, was heute leider unabdingbar mit eMail verknüpft ist, ist SPAM, also ungewollte Werbemail. Deren Anteil ist inzwischen so gross, dass ohne Gegenmassnahmen keine sinnvolle eMail-Nutzung mehr möglich ist.
Wir betreiben daher für unsere Mailplattform ein ausgeklügeltes Spam-Abwehrsystem. Hierbei kommt ein ganzes Bündel an Massnahmen zum Einsatz, von verteilten schwarzen Listen bis hin zur Verhaltensanalyse, um legitime Mailserver von Spambots zu unterscheiden. Gemeinsam haben alle diese Massnahmen, dass wir mit Ausnahme der explizit pro Mailbox zu aktivierenden benutzerdefinierten Filtern niemals einfach Mails herausfiltern und wegwerfen, grundsätzlich finden alle Massnahmen vor der eigentlichen Annahme der eMail statt. Lehnen wir die Annahme einer Mail ab, muss der einliefernde Mailserver den Absender darüber informieren. Unsere Mailserver senden eine Aussagekräftige Fehlermeldung an den einliefernden Server, so dass eine Nachvollziehbarkeit gegeben ist.
Dieses System, immer wieder von unseren Mitarbeitern “feingetuned”, ist sehr effizient. Viele Kunden schalten unsere Mailserver vor ihre eigenen, nur der Spamabwehr wegen – wenn auch das System in diesem Fall nicht seine ganze Stärke ausspielen kann, ist es doch immer noch sehr effektiv.
Erweiterte Authorisierung
Der wohl schwerwiegendste Mangel von eMail ist wohl das völlige Fehlen einer Authentifizierung des Absenders, womit auch keine Authorisierung möglich ist. So kann im Prinzip jeder mit jedem beliebigen Absender Mails verschicken, ohne dass der Empfänger dies sicher erkennen kann. Als das SMTP-Protokoll entwickelt wurde, kannten sich alle Teilnehmer des Internets noch persönlich, dass dieses einmal omnipräsent sein würde, war nicht mal zu erahnen. Die grosse installierte Basis und der Zwang zur Abwärtskompatibilität verhindert bisher eine wirkliche Lösung dieses Problems. Nur so können Betrüger gefälschte Mails von Zahlungsdienstleistern, Banken, Mailprovidern, Auktionshäusern etc verschicken und auf vielfältige Art und Weise versuchen, Zugangsdaten zu erlangen. Es gab und gibt viele Versuche, diese Situation zu verbessern – und jetzt gibt es endlich eine Technik, die dieses Problem mittelfristig lösen könnte und auch schon sofort positive Auswirkungen hat: DMARC. DMARC kombiniert und erweitert SPF und DKIM und wird vor allem von einer breiten Koalition von Mailanbietern, insbesondere inklusive der relevantesten Schwergewichte, unterstützt und gefördert.
Durch die Nutzung dieser Technik können Sie einerseits das Risiko, dass Ihre gesendeten Mails beim Empfänger als SPAM klassifiziert werden, deutlich senken, als auch – bei entsprechender Policy – den Missbrauch Ihrer Domain als Absender durch Dritte erheblich erschweren.
SPF: Sender Policy Framework
SPF wurde bereits kurz nach der Jahrtausendwende als Sender Permitted From spezifiziert. Dabei werden grob gesagt die Adressen der sendenden Mailserver für eine Domain im DNS veröffentlicht. Bei einer eingehenden Mail kann der Mailserver nun prüfen, ob diese von einem dieser veröffentlichten Mailserver kommt – ist das der Fall, ist die Mail legitim. Was zunächst einleuchtend klingt, zeugt leider von einem krassen Mangel an Verständnis von SMTP. So ist SPF schon mit einer einfachen Mailweiterleitung inkompatibel und damit nicht in der vorgeschlagenen Form nutzbar. Als Bestandteil von DMARC ist es aber sinnvoll und darum auch von uns implementiert – kommt eine Mail von einem der veröffentlichten Mailserver für die Domain, kann man davon ausgehen, dass diese legitim ist, der Umkehrschluss funktioniert allerdings überhaupt nicht.
DKIM: DomainKeys Identified Mail
Einen völlig anderen und weitergehenden Ansatz geht DKIM. Hierbei wird ein Schlüsselpaar generiert, den privaten Schlüssel kennt nur der Absender (typischerweise: deren Mailserver), der öffentliche Schlüssel wird im DNS veröffentlicht. Ausgehende Mail wird nun mittels dieses privaten Schlüssels signiert – dabei ist der gesamte Mailinhalt sowie ausgewählte Header-Felder, nämlich jene, die für die Anzeige beim Endbenutzer relevant sind, von dieser Signatur erfasst. Die Signatur selbst wird mit einigen Zusatzinformationen in den Header der Mail geschrieben. Der empfangende Mailserver kann nun anhand dieser Signatur überprüfen, dass der Absender Kenntnis des privaten Schlüssels hatte, somit mit an Sicherheit grenzender Wahrscheinlichkeit derjenige ist, der er behauptet zu sein, und dass die Mail seit dem signieren nicht modifiziert wurde. Neben der Authorisierung wird hier also auch die Integrität der Mail sichergestellt.
DKIM alleine ist für viele Anwendungsfälle schon hervorragend und ausreichend, krankt aber noch an 2 Stellen: zum einen wird der öffentliche Schlüssel im DNS zu einer im DKIM-Header genannten Domain gesucht, diese hat nicht zwnagsläufig etwas mit dem angezeigten Absender zu tun, und zum zweiten wird bei vielen Mailinglisten der Mailinhalt modifiziert, oft um weitgehend nutzlose Disclaimer oder An-/Abmeldeinformationen hinzuzufügen.
Es ist sehr aufwändig, DKIM in einem grösseren Mailsystem zu implementieren, und ist von daher momentan im wesentlichen bei Providern mit eMail-Spezialisierung – wie uns – und einigen wenigen sehr grossen Anbietern zu finden. Wir ermöglichen Ihnen eine sehr einfache Aktivierung und Konfiguration von DKIM, Domainweise und mit einem eigenen Schlüsselpaar pro Domain. Von Ihnen versandte Mail signieren wir für Sie mit diesem Schlüssel.
DMARC: Domain-based Message Authentication, Reporting and Conformance
DMARC kombiniert SPF und DKIM: eine Mail wird nach DMARC als legitim angesehen, sowie mindestens einer der beiden Tests, SPF und DKIM, erfolgreich ist. DMARC führt ein sogenanntes Alignment ein und berücksichtigt ausschliesslich die Absenderdomain aus dem From-Header, also dem dem Endbenutzer angezeigten Absender. DKIM-Signaturen von anderen Domains werden ignoriert und SPF nur berücksichtigt, wenn die Absenderdomain gemäss From-Header der des für die Zustellung relevanten envelope senders entspricht. Damit ist das Ziel der Authorisierung erreicht, ist der DMARC-Test erfolgreich, kann man davon ausgehen, dass die Mail wirklich von der angezeigten Absenderdomain kommt.
Mit DMARC veröffentlicht man eine Policy, die den Empfängersystemen sagt, wie sie mit Mail behandeln soll, die den DMARC-Test nicht besteht. Hier gibt es neutral, also keine andere Behandlung als bei erfolgreichem Test, quarantine, was soviel heisst wie dass die Mail suspekt ist, und reject, was den empfangenden Mailserver auffordert, die Mail zurückzuweisen. Darüber hinaus schicken sich DMARC-kompatible Mailsysteme regelmässig Reports mit statistischen Daten (nur solche, die im Rahmen des Mailaustauschs allen beteiligten Systemen eh bekannt sind, plus das Ergebnis der SPF, DKIM und DMARC-Tests), so dass die Effektivität dieser Massnahmen überwacht werden kann und sogar Fälschunsversuche durch Dritte erkannt werden können.
DMARC funktioniert alles in allem hervorragend, hat aber leider Probleme mit solchen Mailinglisten, die den Inhalt der Mail modifiziert. Der SPF-Test kann bei Mailinglisten nicht erfolgreich sein, da der envelope sender hier typischerweise aus der Domain des Mailinglistenbetreibers kommt und nicht mit dem From-Header identisch ist, so dass der aufgrund mangelnden Alignments für DMARC nicht berücksichtigt wird. Wird der Inhalt nicht unmodifizert gelassen, passt auch die DKIM-Signatur nicht mehr. Hier werden sich Mailinglisten und insbesondere die Mailinglistensoftware anpassen müssen, dies ist bereits im Gange. Dieses Problem ist vorhanden, aber in sehr vielen Szenarien nicht relevant. Absender, die keine Mailinglisten nutzen (was heute auf einen Grossteil der eMail-Nutzer zutrifft) können mit einer reject-Policy den Missbrauch Ihrer Domains durch Dritte als Absenderdomain erheblich erschweren, die wachsende Zahl DMARC-kompatibler Mailsysteme wird diese gefälschten Mails gar nicht erst annehmen. Besonders betroffene Absender wie Zahlungsdienstleister verwenden oft eine solche Policy, so dass unsere Mailsystem gefälschte Zahlungsaufforderungen etc erst gar nicht annehmen. Um das Mailinglistenproblem zu entschärfen erkennen unsere Mailsysteme Mails, die über Mailinglisten zu uns kommen, und verzichten in dem Falle auf eine Anwendung einer reject-Policy.
DMARC können Sie ebenfalls sehr einfach in unserem Control Center aktivieren und die Policy festlegen, die komplexen Vorgänge im Hintergrund bleiben unsichtbar. Wir stellen Ihnen die DMARC-Reports, die wir zu Ihren Domains mit aktivierten DMARC verschicken, als auch die Reports, die wir von anderen Anbietern zu Ihren Domains erhalten, bereit.
Authentication-Results
Unsere Mail-Systeme schreiben die Ergebnisse der SPF, DKIM, DMARC sowie ggf. weiterer Tests in den Header der jeweiligen Mail. Hierbei folgen wir dem Authentication-Results Standard, definiert in RFC 7001.
