FAQ: Warum korrekte TLS-Zertifikate für E-Mail-Ports sinnvoll sind

Autor: Oliver Schranz | CTO

TLS-Zertifikate sind allgegenwärtig in unserer täglichen Kommunikation. Am häufigsten treffen wir sie beim Besuchen von Webseiten an, auch wenn wir es typischerweise nicht bemerken, solange alle Mechanismen korrekt funktionieren und ineinander greifen.

Gelegentlich hält uns unser Browser allerdings davon ab, eine Webseite zu besuchen, bei der ein Zertifikatsproblem vorliegt, das wir als Nutzer lösen sollen: Entweder wir "akzeptieren das Risiko" oder fliegen "zurück in Sicherheit". Die Validierung funktioniert zwar automatisch, aber die Entscheidung liegt beim Benutzer. Klingt eigentlich recht einfach.
Wenn wir uns allerdings das durchschnittliche Zertifikat ansehen, das uns für E-Mail-Ports präsentiert wird, dann sieht das ganze schon wieder anders aus. Ausgelaufene, selbst signierte oder anderweitig ungültige Zertifikate sind tatsächlich sehr häufig, weshalb wir uns an diesem Punkt fragen: Was ist hier so anders? Warum sehen wir so wenige Zertifikatsprobleme für Webseiten und so viele für E-Mail-Protokolle wie z.B. SMTPS, POP3S und IMAPS?

Leider ist das E-Mail-Ökosystem kompliziert und braucht andere Ansätze, auch wenn das Problem auf den ersten Blick ähnlich klingt:

1. Die breitflächige Umsetzung von HTTPS wurde sehr stark von großen Firmen mit starkem Einfluss auf das moderne Web vorangetrieben. Google hat beispielsweise schon 2014 signalisiert, dass die korrekte Nutzung von HTTPS ein positiver Rankingfaktor für ihre Suche darstellt. In 2018 kam dann das passende Update für ihren Chrome Browser (und ähnliches passierte bei Mozilla, Apple und anderen Browserherstellern), so dass Webseiten ohne HTTPS als "unsicher" markiert wurden. Man sieht solche Vorstöße nur sehr begrenzt für das E-Mail-Ökosystem.
2. Im Web fordert normalerweise ein Benutzer Inhalte von einem Server an, also sprechen wir von Mensch-zu-Maschine Kommunikation. Im Fall von ungültigen Zertifikaten können wir also den Benutzer fragen, ob und wie es weitergeht. Bei E-Mails haben wir allerdings zusätzlich eine reine Maschine-zu-Maschine Komponente, wenn E-Mails vom Server des Senders zum Server des Empfängers übertragen werden. Ein Zertifikatsproblem an dieser Stelle muss also ohne menschliche Intervention vollautomatisch behandelt werden.
3. E-Mails gelten heutzutage immer noch als wesentlicher Grundpfeiler moderner Unternehmenskommunikation. Daher kann das Nicht-Empfangen von E-Mails (beispielsweise von Kunden) einen starken, negativen Einfluss auf Unternehmen haben. Aus diesem Grund existiert weiterhin die starke Neigung in Richtung Auslieferung der E-Mail, wenn zwischen Kompatibilität (liefern) und Sicherheit (abbrechen) entschieden werden muss.

Obwohl beide Ökosysteme ihre Eigenheiten aufweisen, gibt uns der Vergleich doch zumindest eine Intuition, warum es sich lohnt, sich die Schnittmenge von E-Mail-Protokollen und TLS etwas genauer anzuschauen.

Übertragung einer E-Mail

Die folgende Grafik zeigt den (vereinfachten) 3-Schritte-Prozess zum Versenden einer E-Mail.

1. Im sogenannten "Submission" Schritt überträgt der E-Mail-Client des Senders (Mail User Agent, MUA) die E-Mail an den E-Mail-Server des Benutzers (Mail Transmission Agent, MTA) mithilfe einer SMTP-Verbindung auf Port 587 oder 465. Dieser Schritt ist synchron und ein Benutzer ist anwesend, daher kann Erfolg oder Misserfolg direkt zurückgemeldet werden.
2. Der MTA des Senders findet nun den MTA des Empfängers und leitet die E-Mail via SMTP auf Port 25 weiter. Hierbei handelt es sich um reine Maschine-zu-Maschine Kommunikation, bei der kein Benutzer mehr involviert ist. Aus der Sicht des originären Senders ist dieser Prozess asynchron: Nach Abschluss von Schritt Eins gibt es keine Garantie, dass die E-Mail direkt zugestellt wird. Falls es zu Fehlern kommt (und diese auch kommuniziert werden), passiert das asynchron: beispielsweise wird das Senden einer E-Mail an eine nicht existierende E-Mail-Adresse dazu führen, dass der MTA des vermeintlichen Empfängers die Adresse nicht kennt (evtl. aufgrund eines Tippfehlers?) und bei dem originären Sender eine sogenannte "Bounce"-Nachricht ankommt, die mitteilt, dass der Empfänger nicht auffindbar ist.
3. Ab einem unbestimmten Zeitpunkt nach dem Ankommen der E-Mail beim MTA des Empfängers wird der E-Mail-Client des Empfängers (MUA) die aktuelle Liste der neuen E-Mails anfragen. Auch das passiert asynchron aus Sicht des Senders, da dieser nicht weiß, wann der MUA des Empfängers wieder aktiv wird. Zum Empfang von E-Mails werden typischerweise die Protokolle IMAP(S), POP3(S) und Exchange ActiveSync (EAS) verwendet.

Und wo kommen jetzt TLS-Zertifikate ins Spiel?

Gute Frage, tatsächlich können sie bei jedem einzelnen der obigen Schritte involviert sein. Aber nicht immer auf die gleiche Weise:

In den Schritten Eins und Drei wird die Verbindung vom MUA (Client) zum MTA (Server) initiiert. Dem normalen TLS-Ablauf folgend präsentiert der Server sein Zertifikat, was den Clients die Möglichkeit gibt (a) die Authentizität des Servers zu checken und (b) eine verschlüsselte Verbindung zum Server aufzubauen. Das alles funktioniert reibungslos und automatisch, solange valide Zertifikate verwendet werden. Sollte das präsentierte Zertifikat allerdings nicht valide sein, dann wird der MUA den Benutzer nach einer Entscheidung fragen. Inwiefern es eine gute Idee ist, Endnutzern Sicherheitsentscheidungen treffen zu lassen, ist allerdings ein Thema für ein anderes Mal.

Im zweiten Schritt sprechen zwei MTAs miteinander, ohne dass ein Mensch involviert ist. Der Sender initiiert eine SMTP Verbindung auf Port 25 zum Empfänger. Wenn die Kommunikation über TLS stattfinden soll, muss der Empfänger wie üblich sein Zertifikat präsentieren und der Ablauf funktioniert wie bei den Schritten Eins und Drei. Theoretisch könnte auch der Client ein Zertifikat präsentieren um sich zu authentifizieren. Das klingt erstmal nach einem guten Plan um Spam zu verhindern, oder? Leider ist die Verwendung von TLS Client-Zertifikaten nicht sehr verbreitet im E-Mail-Ökosystem und stattdessen werden Mechanismen wie SPF (siehe meinen vorherigen FAQ-Artikel) verwendet.

Was passiert nun aber, wenn ein ungültiges Zertifikat präsentiert wird? Der Sender muss eine Entscheidung treffen, wobei Abbrechen das Nichtzustellen der E-Mail zur Folge hat, was gerade im Business-Kontext oftmals keine Option ist. Das gemeldete Sicherheitsproblem aber einfach zu ignorieren, wäre wiederum aus der Sicherheitsperspektive schlecht, würde aber die Kompatibilität der E-Mail-Zustellung gewährleisten, selbst wenn der Empfänger falsch konfiguriert wurde. Hier muss man sich allerdings klar machen, dass ein ungültiges Zertifikat sowohl aufgrund einer Fehlkonfiguration als auch aufgrund eines tatsächlichen, aktiven Man-in-the-Middle ("MitM")-Angriffs zustande kommen kann. In der Praxis entscheiden sich die Betreiber von Servern typischerweise dafür, die Zustellung zu bevorzugen, auch wenn man dafür gewisse Sicherheitsrisiken akzeptieren muss, indem die Validierung von Zertifikaten ignoriert oder erst garnicht durchgeführt wird. Im Fall eines Angriffs hätten wir hier also tatsächlich eine MitM-Situation. Also sehen wir uns einmal an wie genau das funktioniert:

Kurzes Intermezzo: Man-in-the-Middle Angriffe

Der Name Man-in-the-Middle stammt von dem visuellen Bild eines Angreifers, der mittig auf einem Pfad zwischen zwei kommunizierenden Parteien steht. Um eine Tradition aus der IT-Sicherheitsforschung fortzuführen, nennen wir unsere kommunizierenden Parteien Alice und Bob, und den böswilligen Angreifer Eve. Die folgende Grafik zeigt einen erfolgreichen MitM- Angriff auf eine TLS Verbindung im Fall eines nicht korrekt validierten, ungültigen Zertifikats.

Alice will mit Bob über eine TLS-gesicherte Verbindung kommunizieren. Um in unserem E-Mail-Beispiel zu bleiben, nehmen wir an Alice ist eine Benutzerin die mithilfe ihres E-Mail-Programms (MUA) eine Nachricht über ihren eigenen E-Mail-Server Bob (MTA) verschicken will.

Um die Empfängerseite zu authentifizieren und die Verschlüsselung zu starten, präsentiert Bob sein eigenes Zertifikat B. Wenn wir jetzt von einem aktiven Angreifer im Netzwerk ausgehen, kann Eve sämtliche Nachrichten zwischen Alice und Bob abfangen und entweder blockieren, unverändert weiterleiten oder vorher beliebig verändern. Dieses Angreifermodell ist weit verbreitet und wurde schon oftmals als sehr realistisch bewiesen (Beispiele: ISPs, Hardware-Hersteller, Middle Boxes). Was also passieren wird ist, dass Eve ihr eigenes Zertifikat E anstatt dem korrekten Zertifikat B von Bob an Alice weiterleiten wird. Das Ziel ist, dass Alice mithilfe von Zertifikat E eine sichere Verbindung zu Eve und Eve eine sichere Verbindung mithilfe von Zertitifkat B zu Bob herstellt. In der Theorie haben wir jetzt also zwei sichere, verschlüsselte Kanäle. Das schützt zwar vor passiven Angreifern, die Netzwerkverkehr nur mitlesen, aber nicht aktiv beeinflussen können, schützt aber offensichtlich nicht vor aktiven Angreifern wie Eve. TLS ist eine Transportverschlüsselung, die nur den Übertragungsweg zwischen zwei Parteien sichert. Bei jeder Partei liegt der Inhalt wieder im Klartext vor. Daher kann Eve den Inhalt beliebig lesen und verändern, so zum Beispiel die versendeten E-Mails in unserem Beispiel.

An diesem Punkt hätte uns eine saubere Zertifikatsvalidierung gerettet. Die Annahme ist, dass nur Bob ein gültiges Zertifikat für den von Alice benutzten E-Mail-Server haben kann, da nur Bob (bzw. die Betreiber) Kontrolle über den Server (genauer: die vom Server verwendete Domain) beweisen kann. Daher kann Eve nur ein ungültiges Zertifikat erstellen, das sie beispielsweise selbst signiert hat. Wenn Alice also das ihr präsentierte Zertifikat korrekt validiert, wird sie das falsche Zertifikat E, das für die Domain von Bob nicht gültig ist, nicht akzeptieren und die Verbindung beenden.

Stellen wir uns jetzt mal vor, dass MUAs Zertifikate typischerweise nicht validieren. Wenn also nicht einmal Bob als rechtmäßiger Besitzer der Domain ein ungültiges Zertifikat präsentiert (vielleicht weil sowieso nur wenige MUAs überhaupt verifizieren), dann muss Alice das ungültige Zertifikat akzeptieren um eine Verbindung aufbauen zu können. Und in der Welt der E-Mails würde das bedeuten, dass man potenziell wichtige E-Mails nicht versenden kann.

Das Abschalten der Valdierung hat aber zur Folge, dass Eve nun die Geheimhaltungs-, Unveränderbarkeits- und Authentizitätsgarantien, die wir von TLS erwarten, vollständig aushebeln kann.

Ok, korrekte Zertifikatsvalidierung und dann passt das schon, richtig?

Zum Teil... beim Thema IT-Sicherheit sind wir leider nie wirklich fertig. Es geht immer nur darum, den Balken ein wenig höher zu legen. Schauen wir uns mal an, wo wir jetzt stehen:

• TLS mit ungültigen Zertifikaten schützt schonmal vor passiven "Mitlesern".
• TLS mit gültigen, validierten Zertifikaten schützt zusätzlich auch vor aktiven Angreifern, die ihre eigenen, ungültigen Zertifikate nutzen.

Super! Wenn wir nur auf TLS alleine schauen sind wir hier fertig. Leider ist das E-Mail-Ökosystem aber etwas komplizierter als das.

Nehmen wir nochmal SMTP als Beispiel, aber das gleiche gilt auch für IMAP und POP3. Wenn wir von Anfang an eine TLS-Verbindung aufbauen, ist das soweit in Ordnung. Diesen Ansatz nennt man verpflichtendes ("*mandatory*") oder implizites TLS. E-Mail-Protokolle wurden allerdings ursprünglich als Klartextprotokolle designed und genau dafür wurden die entsprechenden Ports auch reserviert. Um die gleichen Protokolle auf den gleichen Port beibehalten zu können, wurde das STARTTLS Kommando eingeführt. Mit diesem Kommando signalisiert man der Gegenseite, dass man auf einen sicheren Kommunikationsweg wechseln möchte. Im Anschluss verhandeln Client und Server dann über die Details, beispielsweise die TLS-Version und andere Konfigurationen, bis man sich auf eine gemeinsame Liste von Sicherheitsparametern einigen kann.

Dieses Vorgehen erlaubt E-Mail-Servern, Unterstützung für TLS einzuführen, während man gleichzeitig kompatibel zu den Klartextvarianten der Protokolle bleibt. Dieses Vorgehen nennt man opportunistisches TLS. Nur genau dann, wenn beide Parteien über TLS kommunizieren wollen und sie sich auf eine Liste von Sicherheitsparametern einigen können, dann kommt eine sichere Verbindung zustande. Ansonsten bleibt die Verbindung im Klartext, um wie üblich Kompatibilität auf Kosten der Sicherheit zu erhalten.

Der Schwachpunkt dieses Vorgehens ist die Tatsache, dass die Anfrage zum Wechseln auf einen sicheren Kanal im Klartext versendet wird. Wenn wir uns nochmal unser aktives Netzwerkangreifermodell ansehen, bemerken wir, dass Eve beliebige Nachrichten abfangen, verändern und unterdrücken kann.

Wenn also Alice ein STARTTLS Kommando an Bob schickt, dann kann Eve einen sogenannten "Downgrade" Angriff starten, indem sie beispielsweise Bobs Antwort so verändert, dass Bob angeblich TLS überhaupt nicht unterstützt. Alternativ kann Eve auch die Verhandlung der Parameter zwischen Alice und Bob so beeinflussen, dass es zu einer Situation kommt, in der es keinen gemeinsamen Konsens bezüglich der Sicherheitsparameter gibt. Ein konkretes Beispiel wäre, dass Eve die Nachrichten so verändert, dass Alice angeblich nur TLS 1.2 und Bob angeblich nur TLS 1.3 verwenden kann. In einem solchen Fall gibt es keine Einigung und die Kommunikation verbleibt ungesichert und im Klartext.

Schutz vor Downgrade Angriffen

Zwei Mechanismen werden typischerweise angeführt, um dieses Problem zu lösen. Erstens, ein Standard mit dem Namen "SMTP Strict Transport Security" (kurz MTA-STS) erlaubt es einem Besitzer einer Domain (z.B. Bob), seine Präferenzen bezüglich TLS-Verbindungen öffentlich zu machen.

Hier zeigt ein DNS TXT Eintrag auf eine HTTPS-URL mit einer Konfigurationsdatei, in der Bob genau angeben kann, dass er für eine gewisse Liste an Subdomains beispielsweise nur verschlüsselte Verbindungen akzeptiert. Da diese Konfiguration ein Haltbarkeitsdatum hat, müssen MUAs wie beispielsweise Alice diese Datei nicht jedes Mal anfordern und können den Inhalt stattdessen eine Weile vorhalten ("caching").

Ein solches Vorgehen verbessert unsere aktuelle Situation bereits, weil Clients die MTA-STS unterstützen, wissen, dass Bob verpflichtendes TLS unterstützt (und eventuell sogar hart durchsetzt), so dass Clients direkt von Anfang an eine sichere TLS-Verbindung aufbauen können. Da es nicht zur Klartextkommunikation kommt, besteht hier also auch kein "Downgrade" Risiko.

Trotzdem gibt es auch hier einige Schwächen:

1. Der Client muss MTA-STS implementieren und entsprechen nutzen. Das Hinterlegen einer Konfigurationsdatei auf der Serverseite und der Support auf der Clientseite sind nicht verpflichtend.
2. Da wir bereits einen aktiven Netzwerkangreifer annehmen, könnte Eve auch die DNS-Anfrage abfangen bzw. das Resultat beispielsweise so verändern, dass es aussieht, als gäbe es keine Konfigurationsdatei. Das funktioniert natürlich nur, wenn der Client nicht bereits eine entsprechende Konfigurationsdatei aus der Vergangenheit im Cache hat. Der Mechanismus etabliert also Vertrauen beim Erstkontakt ("TOFU - trust on first use"): die Entscheidung fällt bei der ersten Verbindung.

Die gute Nachricht: Auch dafür gibt es eine Lösung. DANE ist ein Sicherheitsmechanismus, der es Servern erlaubt, ihre TLS-Zertifikate öffentlich zur Verfügung zu stellen. Um das TOFU Problem von MTA-STS zu vermeiden wird hier DNSSEC benutzt, eine Gruppe von DNS-Erweiterungen, die es erlauben zu verifizieren, dass DNS-Antworten tatsächlich von der korrekten Quelle stammen (Authentizität) und dass sie nicht verändert wurden (Integrität).

Warum sprechen wir dann eigentlich noch über Sicherheitsprobleme bei der E-Mail-Kommunikation, wenn wir doch DANE haben? Leider ist DNSSEC nicht sehr weit verbreitet und daher können wir uns nicht überall im Internet auf seine Verfügbarkeit verlassen.

Es wird oftmals als zu kompliziert und fehleranfällig bezeichnet, was uns leider aktuell mit einem bunten Strauß an Mechanismen zurücklässt, von STARTTLS bis MTA-STS und in seltenen Fällen DANE.

Zusammenfassung

E-Mails absichern ist verdammt schwer. Das Ökosystem ist historisch gewachsen, gleichzeitig aber absolut essenziell für die aktuelle Business-Welt und kann daher als Ganzes nicht einfach ersetzt werden. Aufgrund dieser Wichtigkeit sehen wir immer wieder, dass im Zweifel Kompatibilität höher gehalten wird als Sicherheit, obwohl sich das Blatt langsam zu wenden scheint.

Trotz allem ist der erste Schritt immer erst einmal, ein Verständnis für das Problem zu entwickeln, und gerade bei der IT-Sicherheit geht es immer um Details. Ich hoffe daher, dass der Artikel an dieser Front etwas beitragen kann.

Was wir als Nutzer tun können ist, in unseren MUAs immer implizites TLS zu konfigurieren, auf STARTTLS zu verzichten, wo es möglich ist, und Zertifikatsfehler stets zu überprüfen.

Auf der Infrastrukturseite gilt: je stärker der implementierte Sicherheitsmechanismus, desto höher die Chance Angreifer abzuwehren. DANE ist zwar auf dem Papier eine tolle Lösung, pragmatischerweise sollte man allerdings ebenfalls MTA-STS implementieren und damit möglichst viele, möglichst sichere Wege anbieten um die Sicherheit zu verbessern. Letztendlich ist die Hoffnung, dass Clients, die mehrere solcher Mechanismen unterstützen, stets den sichersten Weg nutzen werden.

Bonus FAQ

Warum schreibst du überhaupt über das Thema?

Unsere SaaS Lösung Findalyze sucht, identifiziert und meldet aktiv ungültige Zertifikate. Obwohl wir in der Web App selbst die Gründe dahinter erklären, ist eine Einordnung mit Blick auf existierende Sicherheitsmechanismen und Angreifermodelle zu weit ausgeholt für Findalyze und stattdessen in einem Artikel wie diesem besser aufgehoben. Netter Bonus: wir haben jetzt eine Ressource, auf die man aktiv verlinken kann ;-)

Was hat es mit Port 465 auf sich?

Port 465 hat eine interessante und zum Teil verwirrende Historie. Ich kann nur empfehlen, einmal den entsprechenden RFC-Paragraphen zu lesen. Dort wird erklärt, warum 465 ursprünglich für SMTP + verpflichtendes TLS reserviert war, dann wieder freigegeben wurde, weil STARTTLS als der beste Weg vorwärts gesehen wurde, und dann schließlich erneut registriert wurde, weil (a) populäre MUAs ihn weiter für "Submission" benutzt haben und (b) verpflichtendes TLS stärkere Garantien als STARTTLS bietet (wie oben besprochen). Deshalb haben wir heutzutage Port 465 für SMTP via verpflichtendem TLS und 587 typischerweise für beides, sowohl Klartext SMTP mit STARTTLS als auch verpflichtenden TLS von Anfang an. Gleiches gilt für Port 25, der für die Übertragung zwischen MTAs zuständig ist. Hier werden ebenfalls beide Varianten unterstützt. Ich vermute, dass wir die breite Nutzung von allen dreien noch für eine ganze Weile sehen werden.

Wie nützlich ist Zertifikatsvalidierung bei der Maschine-zu-Maschine Kommunikation wirklich?

Während einer Diskussion um die Expansion von Let's Encrypt in Richtung des E-Mail-Ökosystems kann es zu einer sehr interessanten Debatte. Einer der Teilnehmer äußerte eine starke Meinung, dass für Maschine-zu-Maschine Kommunikation (MTA-zu-MTA im Speziellen) die Validierung der Vertrauenskette von TLS-Zertifikaten wenig Sinn ergibt, weil offiziell kein Vertrauensanker für das E-Mail-Ökosystem definiert wurde. Ich gebe dem Autor Recht, dass DANE die "korrekte" Lösung für das Problem ist, aber die geringe Verfügbarkeitsrate von DNSSEC verhindert die tatsächliche Nutzung und Umsetzung, wenn man das Internet als Ganzes betrachtet.

Ich kann nur jeden ermutigen, den Thread selbst zu lesen und sich eine eigene Meinung zu bilden. Hier ist meine:

Tatsächlich definieren beide RFCs, sowohl 8314 als auch 7817, Regeln für die Zertifikatsvalidierung speziell für MUAs, also Client zu Server Kommunikation. Maschine-zu-Maschine Kommunikation ohne einen involvierten Menschen scheint erstmal nicht reguliert zu sein. Ich persönlich kann mich aber dem Argument, "man kann kein signiertes Zertifikat erwarten, weil es keine offizielle Liste an vertrauten Zertifikatsausstellern ("Certificate Authorities", CAs) gibt", nicht anschließen. Eine solche Liste an vertrauenswürdigen CAs gibt es bereits für HTTPS. In automatisierten Fällen, wie beispielsweise bei Let's Encrypt, muss man Kontrolle über eine Domain beweisen, sonst kann man kein valides Zertifikat erstellen. Der gleiche Mechanismus könnte auch bei E-Mails angewendet werden: die bewiesene Kontrolle über eine Domain gegenüber einer CA sollte reichen, um ein valides Zertifikat für diese Domain zu erhalten, egal ob für HTTPS oder SMTP über TLS. Es stimmt, dass das CA-System seine ganz eigenen Probleme und Schwächen hat, aber wir müssen uns nochmal klar machen, dass ein vollständig verteiltes System wie DANE via DNSSEC weiterhin viel zu geringe Akzeptanz erfahren hat, als dass man es als notwendigen Teil eines Verbindungsaufbaus nutzen könnte.

Gab es nicht mal die Idee einer vordefinierten MTA-STS Liste um TOFU zu entschärfen?

Richtig, das STARTTLS Everywhere Projekt startete 2014 mit dem noblen Ziel, die Verbreitung von STARTTLS für opportunistisches TLS voranzutreiben. Eine der resultierenden Initiativen war die Erstellung einer zentralen Liste, ähnlich der HSTS Preload Liste im HTTP-Ökosystem, auf der Betreiber von E-Mail-Servern freiwillig ihre Konfigurationen eintragen konnten. Wie MTA-STS, aber mithilfe einer vordefinierten, lokal vorliegenden Liste statt einer DNS-Anfrage.

Das würde zwar das TOFU Problem für eingetragene Server lösen, leider haben solche zentralen Liste aber noch ganz andere Probleme.

Letztendlich wurde das Projekt aufgrund geringer Nachfrage eingestellt und nahm keine weiteren Konfigurationsdateien mehr an.