Emailsicherheit – der Test
Jetzt schreibe ich seit Monaten immer mal wieder über Emailsicherheit und Verschlüsselung – aber wie soll ich als Otto Normalverbraucher herausfinden, was mein Anbieter macht?
Natürlich gibt es für alles schon irgendeinen Test im Internet, aber alle irgendwie umständlich, unverständlich, oder nicht vollständig. Auch meiner ist nicht vollständig, aber dafür etwas für einfache Anwender... wenn Sie mir eine Email zum Sicherheitstest an de@et.lindenberg.one und de@ut.lindenberg.one schicken (die Mail soll wirklich an beide Adressen gehen), dann testet einer meiner Server Ihren Emailserver sowohl auf sein Verhalten bei dieser ausgehenden Email als auch wie er sich für eingehende Mails verhält. Beide Richtungen sind wichtig. Es kann durchaus sein, dass man mit Ihrem Emailserver zwar verschlüsselt kommunizieren kann, dass er selbst das bei ausgehenden Emails aber gar nicht versucht. Auch wird DKIM geprüft (aber noch nicht validiert) und die Liste der Tests kann noch erweitert werden – wenn Interesse besteht.
Der Test dauert manchmal nur wenige Minuten, kann aber auch einige Stunden oder sogar Tage dauern, also wundern Sie sich bitte nicht, wenn die Antwort nicht sofort kommt. Der Test muss Ihren Emailserver dazu überreden, mehrere Verbindungen aufzubauen und das auch noch zu verschieden Instanzen (für Profis: MX-Records). Wie schnell das geht, hängt davon ab, in welchen Zeitabständen Ihr Server das versucht, und ob er dann immer nur eine Adresse oder mehrere verwendet. Emailserver mit Postfix machen das teils sehr zügig, outlook.com lässt sich deutlich länger Zeit. Typischerweise bekommen Sie nach ca. 4 Stunden eine Warnung dass die Zustellung länger dauert – das ist normal. Nur wenn Sie eine Benachrichtigung erhalten, dass die Zustellung endgültig gescheitert ist – dann melden Sie sich bitte bei mir unter support@lindenberg.one.
Und natürlich gibt es eine Ausnahme: Wenn Sie eine Email der Artremote MX does not support STARTTLS (web.de) oder TLS is required, but was not offered by host (mailbox.org) erhalten, dann hat Ihr Emailserver beim Versuch, unverschlüsselte Kommunikation zu verwenden, die Email gleich als unzustellbar markiert. Das ist erstmal ein gutes Zeichen und ein Hinweis, dass möglicherweise RFC 7672 verwendet wird, denn für eine der beiden Domänen des Tests existiert im DNS die Information, dass DANE unterstützt und daher keine unverschlüsselte Verbindungen akzeptieren sollte. Web.de und Mailbox.org bestehen darauf, vielleicht auch weitere Domänen die DANE verwenden. Tatsächlich ist dieses Verhalten aber nicht perfekt, denn der Endanwender kann da gar nichts machen, und der RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) empfiehlt bei ähnlichen Fehlern Wiederholung statt Abbruch. In diesem Fall laufen die anderen Tests in dem Sie die Testmail erneut senden bis keine derartige Antwort mehr eingeht. Und Formalia: Wenn Sie ein Testmail schicken, erfasse ich natürlich Ihre Emailadresse um den Test (eine Verarbeitung Ihrer Emailadresse aka personenbezogener Daten) zu ermöglichen und die Ergebnisse erhalte ich dann auch – Neugier und vielleicht versteckt sich ja auch noch ein Fehler im Test. Ihre Emailadresse wird in der Antwort gekürzt, denn es kann durchaus sein, dass mehrere Anfragen parallel eingehen. Was prüft der Test?
Für Ihre abgehende Mail versucht er Ihren Mailserver dazu zu überreden, die Nachricht unverschlüsselt zu versenden. Gelingt das nicht – Topp! Leider ist das nicht Standard, oder allenfalls wenn der Server RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
verwendet und dann halt nur für Domänen die entsprechende DANE TLSA Records publizieren. Wenn Ihr Mailserver SNI verwendet (zwingend bei RFC 7672), dann bietet mein Server unterschiedliche Zertifikate an, um zu ermitteln, ob und wie tatsächlich auf gültige Zertifikate geprüft wird, oder ob das nicht der Fall ist. Dieser Teil kann dann wirklich dauern. Nicht direkt prüfen kann ich, ob Ihr Emailserver DNSSEC verwendet, aber der RFC 7672 verlangt DNSSEC um die TLSA Records auszuwerten, also steckt das Ergebnis da mit drin, oder Ihr Emailserver ist nicht standardkonform – da alle denkbaren Abweichungen zu prüfen ist illusorisch.
Dann wird für das Testergebnis auch wieder – wie bei meinen vorhergehenden Artikeln – geprüft, ob Ihre Domäne bzw. Ihr Betreiber DNSSEC verwendet, ob entsprechende Records vorhanden und signiert sind, ob Ihr Server STARTTLS unterstützt und gültige Zertifikate verwendet. Bei der letzten Prüfung habe ich nachgebessert: DANE Zertifikate werden jetzt als vertrauenswürdig eingestuft und wenn alles richtig konfiguriert ist, wird festgestellt, dass Ihr Server die qualifizierte Transportverschlüsselung
der Orientierungshilfe zur Emailverschlüsselung für den Posteingang unterstützt, jedoch ohne sie zu erzwingen.
Und weil das auch für nicht Laien verwirrend ist: Die Grundkomponenten sind wie schon beschrieben DNSSEC, STARTTLS, und Zertifikate. Zertifikate mit oder ohne DANE (RFC 6698, 7671). Unter DANE wird aber leider auch manchmal der schon erwähnte RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
verstanden. Dieser RFC definiert, dass ein sendender Server STARTTLS (und auch SNI) verwenden muss und die Zertifikate validieren muss, wenn er TLSA Records im DNS(SEC) findet. Die Empfängerdomäne verpflichtet sich gewissermaßen durch die Veröffentlichung von TLSA-Records, DNSSEC, STARTTLS, und mit den veröffentlichten TLSA-Records validierbare Zertifikate zu unterstützen. Existieren diese TLSA Records, dann darf er die Mail nicht anders zustellen, geht etwas schief, dann sollte er es später erneut versuchen – in diesem Punkt gibt es aber auch abweichende Ansichten.
Sichere Email wäre also ganz einfach, wenn alle Anbieter RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
samt Voraussetzungen unterstützen würden – sowohl beim Empfang als auch beim Senden. In Deutschland ist das leider selten, in den Niederlanden steht dieser RFC auf der Pflichtliste (siehe DANE for SMTP how-to und dort Suche nach Comply or Explain
). Die Aufsicht könnte das durchaus auch in Deutschland einfordern – am besten mit einer neuen Orientierungshilfe, in der PGP und S/MIME optional werden, aber RFC 7672 Pflicht. Ggfs. auch mit der zusätzlichen Pflicht auf Oberflächen (z.B. bei der Registrierung) auf die fehlende Unterstützung von RFC 7672 hinzuweisen. Sie meinen das geht nicht? Doch, habe ich in eine meiner Oberflächen schon eingebaut, und auch mail.de hat das. Auch die Prüfung einer Liste von Emailadressen ist kein Problem, das hab ich jetzt auch schon zweimal gezeigt.
Wie prüft der Test?
Dieser Teil ist sehr technisch, aber einige meiner Leser waren so neugierig, dass es jetzt hier dokumentiert ist. Natürlich auch um zu darzustellen, dass man Sicherheitsfunktionen automatisch testen kann. Wer nicht so technisch unterwegs ist darf diesen Teil gerne überspringen – Was ist mit dem BSI IT-Sicherheitskennzeichen oder TR03108-1?
Zunächst muss man die Serverkonfigurationen verstehen. Weil alles auf der gleichen IP-Adresse läuft, sind verschiedene Server nur anhand von SNI oder der Empfängeradresse unterscheidbar. Die Server verwenden dann unterschiedliche Zertifikate mit unterschiedlichen TLSA Records, und je nach Verschlüsselungspolicy (Beispiel Mailcow, siehe RFC 7672 mit Mailcow / Postfix, nur dass Postfix kein MTA-STS kann) müssen dann unterschiedliche Server tatsächlich Emails empfangen.
| Konfiguration | Senderpolicy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Server | STARTTLS | SNI | Zertifikat | TLSA Record | none | may | encrypt | verify | dane | dane-only | mta-sts |
| 1 | nein | -- (1) | -- | -- | ja | ja | -- | -- | -- | -- | -- |
| 2 | ja | -- (1) | selbstsigniert | -- | -- | ja | ja | nein | -- (3) | -- (3) | -- (3) |
| 3 | ja | mx03.et.lindenberg.one | selbstsigniert | ungültig | -- | (2) | (2) | nein | nein | nein | -- (4) |
| 4 | ja | mx04.et.lindenberg.one | selbstsigniert | gültig | -- | (2) | (2) | nein | ja | ja | nein |
| 5 | ja | mx05.et.lindenberg.one | Letsencrypt | ungültig | -- | (2) | (2) | ja | nein | nein | (5) |
| 6 | ja | mx06.et.lindenberg.one | Letsencrypt | gültig | -- | (2) | (2) | ja | ja | ja | ja |
| 7 | ja | ut.lindenberg.one (1) | Letsencrypt | -- | (1) | ja | ja | ja | ja | nein | ja |
| Anmerkungen | |||||||||||
| (1) | ut.lindenberg.one wird nicht nur an SNI sondern auch an der Empfängeradresse erkannt. Ohne SNI wird sonst mit STARTTLS Server 2 angenommen, ohne STARTTLS Server 1. | ||||||||||
| (2) | Dass ein Server mit Policy may oder encrypt SNI verwendet ist unwahrscheinlich, hingegen ist SNI sowohl für SMTP-DANE als auch MTA-STS Pflicht. | ||||||||||
| (3) | SNI ist sowohl für SMTP-DANE als auch MTA-STS Pflicht. | ||||||||||
| (4) | Dieser Server ist nicht in der MTA-STS Policy aufgeführt und wird daher bei MTA-STS nicht angesprochen. Für ut.lindenberg.one ist keine MTA-STS Policy definiert. | ||||||||||
| (5) | Hängt davon ab, ob der Sender auch SMTP-DANE implementiert: senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation – Abschnitt 2 von RFC 8461, letzter Satz. | ||||||||||
Die Prioritäten von mx03-mx06 werden alle paar Minuten neu gewürfelt, so dass irgendwann mal jeder Server drankommt, selbst dann wenn immer nur ein Server angesprochen wird. Als empfangen quittiert wird die Mail an et.lindenberg.one erst dann, wenn entweder nur Server 2, alle Server 3-6, oder hinreichend oft zumindest Server 4-6 mindestens einen Zustellversuch gesehen haben, was sich im Status Mail
in der Verbindungshistorie ausdrückt. Der Status stellt dabei verschiedene Phasen im Verbindungsaufbau dar, und geht von None, SniSeen, TlsStarted, Mail, bis Acked. Wenn eine Server mit Policies verify, dane/dane-only, oder mta-sts auf ein Zertifikat trifft das er als ungültig ansehen muss, dann trennt er die Verbindung ohne eine Mail zu senden.
Mit diesem Vorwissen lässt sich die Antwortmail entschlüsseln:
Verbindungshistorie:29.06.2022 09:08:45 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:45 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:50 – 09:08:50 (Server 1, nicht verschlüsselt, None): 29.06.2022 09:08:51 – 09:08:51 (Server 1, nicht verschlüsselt, None): ...
Bei den ersten vier Versuchen und innerhalb der ersten drei Minuten bietet der Testserver kein STARTTLS an — simulierte Downgrade-Angriffe. Ein Server der RFC 7672 implementiert darf aber nur an ut.lindenberg.one unverschlüsselt schicken, et.lindenberg.one hat TLSA-Records, da darf er es nicht. Damit an ut.lindenberg.one nicht unverschlüsselt geschickt wird muss man auf Senderseite eine entsprechende Policy definieren — das geht bei manchen Anbietern direkt in der Benutzeroberfläche, bei anderen muss der Administrator aktiv werden. Ist keine Policy definiert, dann taucht in den ersten fünf Minuten bereits eine Zeile mit (Server 7, nicht verschlüsselt, Mail) auf.
Nach ca. 3 Minuten wird STARTTLS aktiviert:
29.06.2022 09:12:03 – 09:12:06 (Server 7, verschlüsselt, Mail): From: <s***t@lindenberg.one> To: <de@ut.lindenberg.one> Signatures:Dkim29.06.2022 09:12:04 – 09:12:07 (Server 6, verschlüsselt, Mail): From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:12:07 – 09:12:11 (Server 4, verschlüsselt, Mail): From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:21:57 – 09:21:57 (Server 3, verschlüsselt, TlsStarted): 29.06.2022 09:21:56 – 09:22:00 (Server 7, verschlüsselt, Acked): From: <s***t@lindenberg.one> To: <de@ut.lindenberg.one> Signatures:Dkim29.06.2022 09:21:58 – 09:22:01 (Server 4, verschlüsselt, Mail): From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim29.06.2022 09:22:01 – 09:22:03 (Server 5, verschlüsselt, TlsStarted): 29.06.2022 09:22:03 – 09:22:07 (Server 6, verschlüsselt, Acked): From: <s***t@lindenberg.one> To: <de@et.lindenberg.one> Signatures:Dkim
Signatures:Dkim oder Arc deutet dann darauf hin, dass Mails signiert sind und wie. Erfolgreich zugestellt wird hier an Server 4 und 6, aber es wurden auch Verbindungsaufbauten zu Server 3 und 5 erfasst. Ob und welche Server eine Mail erhalten wird dann gewissermaßen mit der Tabelle oben verglichen und geht dann in die Antwortmail. Bestätigt wird dann die Mail bei Server 7 und in diesem Ablauf Server 6 – dann wenn alle zu erwartenden Server mindestens einmal einen Verbindungsaufbau registriert haben.
Danach folgt die Analyse des Ergebnisses und der Test für die Empfangsseite:
Es erhielen die Mailserver Post, die das nach RFC 7672 tun sollten. Ihr Mailserver verwendet vermutlich RFC 7672 (Postfix: dane-only) (sehr gut).Die Domäne lindenberg.one verwendet DNSSEC für MX-Records (gut).Die Domäne lindenberg.one verwendet DNSSEC für A-Records (gut).Die Domäne lindenberg.one verwendet DNSSEC für TLSA-Records (gut).Die Domäne lindenberg.one verwendet STARTTLS (gut).Die Domäne lindenberg.one verwendet gültige Zertifikate (gut).Die Domäne lindenberg.one unterstützt die qualifizierte Transportverschlüsselung (gut).Die Domäne lindenberg.one unterstützt RFC 7672 DANE-SMTP (gut).Mehr Informationen ggfs. auf https://blog.lindenberg.one/EmailSicherheitsTest#lindenberg.one
Bei neueren Tests wird RFC 7672 getrennt von der qualifizierten Transportverschlüsselung ausgewiesen, weil es tatsächlich Emailserver gibt, die für MX- und A-Records DNSSEC verwenden, aber keine TLSA-Records haben.
Was ist mit dem BSI IT-Sicherheitskennzeichen oder TR03108-1?
Leider ist das BSI IT-Sicherheitskennzeichen keine Garantie für sichere Email. Das denke nicht nur ich, sondern auch das BSI selbst Das IT-Sicherheitskennzeichen kann nicht ... garantieren, dass ein IT-Produkt absolut sicher ist.
. Viel unklarer: die zugrundeliegende technische Richtlinie (TR) TR03108-1 verlangt mit EMLREQ_5: DANE (outgoing)
, dass STARTTLS bei Existenz von TLSA Records erzwungen wird, aber sie fordert weder Konformität zu RFC 7672, noch prüft die TR03108-2 wesentliche Anforderungen von RFC 7672 oder genau die erwähnte Anforderung EMLREQ_5 ab, es wird also insbesondere nicht geprüft, wie sich der Emailserver z.B. bei Downgrade-Angriffen (s. RFC 7672 Sektion 1.3.1.) verhält. Mein Test prüft das nach, simuliert gewissermaßen einen Downgrade-Angriff, und prüft auch was passiert, wenn Zertifikate verwendet werden, die nicht zu den TLSA-Records passen. Auch mein Test ist kein vollständiger Test auf RFC-7672-Konformität. Die Tests habe ich ausgewählt, weil sie mit vertretbarem Aufwand und Zeitbedarf erkennbar machen, ob RFC 7672 verwendet wird oder nicht.
Dass die Anbieter mail.de – IT-Sicherheitskennzeichen bereits erteilt – und mailbox.org – im Prozess – in meinem Test gut abschneiden, liegt eher daran, dass diese Anbieter wissen worauf es ankommt, nicht dass das BSI das in eine technische Richtlinie geschrieben hat. Sie unterscheiden sich aber genau da, wo im RFC 7672 eine Anforderung fehlt, nämlich darin was genau passieren soll, wenn STARTTLS nicht angeboten wird. Der Autor des RFCs und ich stimmen darin überein, dass eine Wiederholung besser wäre als der Abbruch und Fehlermeldung an den Benutzer – der versteht das Problem nicht (hat mein Test bestätigt) und kann auch nichts anderes unternehmen, als die Mail wiederholen oder auf einen anderen Kanal ausweichen.
Deutlich schlechter sieht das bei den Verwaltungsportalen aus. Die sind nach meinem Verständnis der Orientierungshilfe zur Emailverschlüsselung verpflichtet, Verschlüsselung zu erzwingen (Abschnitt 4.2.1), fallen aber beim simulierten Downgrade-Angriff durch. Alle haben Emails unverschlüsselt gesendet obwohl gültige TLSA-Records existieren, und dann weder RFC 7672 noch TR03108-1 eine unverschlüsselte Übertragung erlaubt.
Informationen nach Domänen/Anbieter
Hier beabsichtige ich Informationen nach Anbietern ggfs. zu ergänzen, insbesondere wenn der Test nicht aussagekräftig sein sollte. Alle bisher getesteten Anbieter konnten STARTTLS und hatten gültige Zertifikate, wären also nach dem Farbcode der anderen Tests weiß bzw. die mit RFC 7672 grün – denn mit RFC 7672 auf beiden Seiten erfüllt man die Voraussetzungen für die qualifizierte Transportverschlüsselung. Wie immer kann das Ergebnis für eine eigene Domäne beim Anbieter schlechter sein, weil RFC 7672 erwartet, dass alle DNS-Einträge per DNSSEC gesichert sind.
Aufgefallen ist mir bei den Tests, dass einige Anbieter nur den experimentellen Standard ARC aber kein DKIM verwenden. Nach meinem Verständnis ist DKIM für den ursprünglichen Sender gedacht, ARC für den Empfänger der eine Mail wie bei Mailinglisten weiterleiten will. Aber das handhaben einige schon anders. Und manche verwenden beides.
| Domäne/Anbieter | Verschlüsselung | geeignete Zertifikate | RFC 7672 | Verschlüsselung erzwungen | DKIM | ARC | Kommentare |
|---|---|---|---|---|---|---|---|
| aol.com/yahoo.com | Ja | Ja | Nein | Nein | Ja | Nein | |
| dismail.de | Ja | Ja | Nur eingehend | Nein | Ja | Ja | dismail.de unterstützt RFC 7672 nur für eingehende Emails. Beim Versand wird weder Verschlüsselung erzwungen noch werden die TLSA-Records beachtet. Versand war in den vorhergehenden Tests nicht enthalten. |
| e.email/ecloud.global | Ja | Ja | Nur abgehend | Ja (2) | Ja | Ja | Schade, für eingehend RFC 7672 fehlen die TLSA Records. Qualifizierte Transportverschlüsselung also nur durch Konfiguration auf Seite des Senders. |
| gmx.de | Ja | Ja | Ja (1) | Nein | Ja | (3) | |
| google.com/gmail.com | Ja | Ja | Nein | Nein | Ja | Nein | |
| kasserver.com | Ja | Ja | Nein | Nein | Ja | (3) | |
| lindenberg.one | Ja | Ja | Ja | Optional | Ja | Nein | Die Standardeinstellung ist, dass nur verschlüsselt kommuniziert wird. Details in RFC 7672 mit Mailcow / Postfix. |
| mail.de | Ja | Ja | Ja | Nein | Ja | Nein | Schön ist, dass man in der Weboberfläche am grünen Schloss mit Haken sofort erkennen könnte, ob die Zieladresse auch RFC 7672 unterstützt, aber leider wird auch die weniger sichere Variante nur STARTTLS grün angezeigt (siehe Farbige Darstellung von Empfänger-Adressen in E-Mail verfassen). |
| mailbox.org | Ja | Ja | Ja (1) | Optional | Ja | Ja | Auch ohne RFC 7672 beim Empfänger kann mailbox.org Verschlüsselung erzwingen (siehe SSL-TLS-Verschluesselung bei mailbox.org). |
| outlook.com | Ja | Ja | Nein | Nein | Teilweise | Ja | outlook.com unterstützt MTA-STS, daher dauert der Test sehr lange, auch weil outlook.com Zustellversuche nur einmal je Stunde wiederholt. outlook.com unterstützt SMTP-DANE bisher nicht (es scheint Pläne im Bezahlbereich zu geben – How can Exchange Online customers use SMTP DANE Outbound?). DKIM habe ich bei manchen Domänen (outlook.com, live.com) beobachtet, bei manchen nicht (outlook.de). |
| t-online.de | Ja | Ja | Nein | Nein | Nein | Nein | |
| web.de | Ja | Ja | Ja (1) | Nein | Ja | Nein | |
| Anmerkungen | |||||||
| (1) | Sofortige Fehlermeldung wenn STARTTLS nicht angeboten wird. Sicher ist, dass keiner der Testanwender diese Fehlermeldung verstanden hat. | ||||||
| (2) | Unklar ob dafür Konfiguration nötig war. | ||||||
| (3) | Noch kein Test seit ARC erfasst wird. | ||||||
| Verwaltungsportale (kein Portal hat STARTTLS erzwungen oder SNI verwendet, daher RFC 7672 allenfalls eingehend, wobei unklar ist, ob die Verwaltungsportale überhaupt Emails empfangen) | |||||||
| service-bw.bwl.de (bwl.de) | Ja | Ja | Nein | Nein | Nein | Nein | Baden-Württemberg |
| freistaat.bayern, id.brandenburg.de (akdb.de) | Ja | Ja | Nein | Nein | Nein | Nein | Bayern, Brandenburg |
| itdz-berlin.de (verwalt-berlin.de) | Ja | Ja | Nein | Nein | Nein | Nein | Berlin |
| dataport.de | Ja | Ja | Nein | Nein | Nein | Nein | Bremen, Hamburg, Niedersachsen, Sachsen-Anhalt, und Schleswig-Holstein |
| bmi.bund.de (bfinv.de) | Ja | Ja | allenfalls eingehend | Nein | Nein | Nein | Bund |
| ekom21.de | Ja | Ja | allenfalls eingehend | Nein | Nein | Nein | Hessen |
| mvnet.de | Ja | Ja | allenfalls eingehend | Nein | Nein | Nein | Mecklenburg-Vorpommern |
| servicekonto.nrw (krzn.de) | Ja | Ja | Nein | Nein | Ja | Nein | Nordrhein-Westfalen |
| sid.sachsen.de (pzd-svn.de) | Ja | Ja | Nein | Nein | Nein | Nein | Sachsen |
| ldi.rlp.de | Ja | Ja | Nein | Nein | Nein | Nein | Rheinland-Pfalz |
| thueringen.de | Ja | Ja | Nein | Nein | Nein | Nein | Thüringen |
Anfragen?
Immer noch ohne befriedigendes Ergebnis sind diese Anfragen:| Erstellt | Geändert | Status | Behörde | Thema |
|---|
Veröffentlicht am 04.02.2022, zuletzt geändert am 29.06.2022.
© 2022 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.