Justizministerium Baden-Württemberg: Konzept eID und De

Transcrição

E-Government-Initiative
für De-Mail und den Personalausweis
Koordinierungsstelle für das automatisierte Mahnverfahren
beim Justizministerium Baden-Württemberg
Konzept: Einsatz von eID und De-Mail im automatisierten gerichtlichen
Mahnverfahren
Das Bundesministerium des Innern ist nicht verantwortlich für den Inhalt der Ergebnisdokumente, die im
Rahmen der E-Government-Initiative für De-Mail und den Personalausweis erstellt wurden. Deshalb
werden die jeweils Verantwortlichen im Impressum auf der letzten Seite der Dokumente genannt. Sie
stehen Ihnen für inhaltliche Fragen zur Verfügung.
E-Government-Initiative – eID und De-Mail im Online-Mahnverfahren
Einsatz von eID und De-Mail im automatisierten gerichtlichen Mahnverfahren
Koordinierungsstelle
für das automatisierte Mahnverfahren
02_konzept_eid_und_de-mail_im_mahnverfahren_jum_bw.docx
1/27
Inhaltsverzeichnis
1
Einführung und Zusammenfassung ................................................................ 4
2
Nutzung der Online-Ausweisfunktion.............................................................. 5
2.1
Anforderungen an prototypische Umsetzung ..................................................... 5
2.1.1
Infrastruktur-Erweiterungen des Online-Mahnverfahrens ................................. 5
2.1.2
Notwendige Anpassungen im Online-Mahnverfahren ....................................... 5
2.2
Umsetzungskonzept ............................................................................................. 6
2.2.1
Technische Umsetzung .................................................................................... 6
2.2.1.1
Integration des Governikus-Bürgerkontos ................................................. 7
2.2.1.2
Zielarchitektur OMA mit Ablauf der Online-Ausweisfunktion ...................... 7
2.2.2
Fachliche Umsetzung ....................................................................................... 9
3
Nutzung von De-Mail ....................................................................................... 15
3.1
Grundlagen der De-Mail-Kommunikation .......................................................... 15
3.1.1
De-Mail-Adressen und –Accounts .................................................................. 15
3.1.2
Bestätigungsnachrichten ................................................................................ 16
3.1.3
Zugriffsmöglichkeiten auf De-Mail-Konten ...................................................... 16
3.1.3.1
Webbrowser ............................................................................................ 16
3.1.3.2
De-Mail-Gateway .................................................................................... 16
3.1.3.3
OSCI-/De-Mail-Gateway.......................................................................... 18
3.2
Einsatz von De-Mail im automatisierten Mahnverfahren .................................. 19
3.2.1
De-Mail-Adressen der Mahngerichte .............................................................. 19
3.2.2
Architekturansätze ......................................................................................... 20
3.2.2.1
Voraussetzungen und grundsätzlicher Prozessablauf ............................. 20
3.2.2.2
Empfohlene Variante: Standard-De-Mail-Gateway .................................. 22
3.2.2.3
Alternativvariante 1: OSCI-/De-Mail-Gateway ......................................... 24
3.2.2.4
Alternativvariante 2: Spezielles De-Mail-Gateway für Mahnanträge ........ 26
2/27
Abbildungsverzeichnis
Abbildung 1: Einbindung Personalausweis in OMA-Architektur ............................................. 8
Abbildung 2: Auswahl einer Identifizierung mit der Online-Ausweisfunktion........................... 9
Abbildung 3: Hinweise zur Nutzung des Personalausweises ............................................... 10
Abbildung 4: Weiterleitung zum Login des Bürgerkontos ..................................................... 10
Abbildung 5: Aufruf der AutentApp und Sicherheitshinweis ................................................. 11
Abbildung 6: Auswahl der zu übermittelnden Daten ............................................................ 12
Abbildung 7: Rückübermittlung der Daten an das Online-Mahnverfahren ............................ 13
Abbildung 8: Bestätigung des Antragversands .................................................................... 13
Abbildung 9: Beispiel für die Nutzung der AusweisApp........................................................ 14
Abbildung 10: Anbindung über Standard-De-Mail-Gateway ................................................. 22
Abbildung 11: Anbindung über OSCI-/De-Mail-Gateway ..................................................... 24
Abbildung 12: Anbindung über ein spezielles De-Mail-Gateway für Mahnanträge ............... 26
3/27
1 Einführung und Zusammenfassung
Das Justizministerium Baden-Württemberg ist die bundesweit verantwortliche Koordinierungsstelle für das automatisierte Mahnverfahren. Alle 16 Bundesländer sind diesem bundesweit technisch einheitlichen Verfahren angeschlossen. Aufgrund der Neufassung von
§ 690 Abs. 3 ZPO zum 01.01.2018 müssen maschinell lesbare Anträge künftig nicht mehr
unterschrieben sein, eine Authentifizierung mittels Online-Ausweisfunktion (eID-Funktion des
Personalausweises) ist dann ausreichend. Diese zusätzliche Form der Antragslegitimation
muss neben die vorhandenen Formen (z.B. EGVP und qualifizierte elektronische Signatur)
gestellt und implementiert werden.
Die Antragstellung von Naturparteien (Bürgerinnen und Bürger sowie Unternehmen mit eigenen Rechtsabteilungen) soll zukünftig mittels Online-Ausweisfunktion und De-Mail erfolgen.
Bundesweit werden durch Naturparteien ca. 1,8 Millionen Anträge pro Jahr gestellt.
Das automatisierte Mahnverfahren ist eine länderübergreifende Anwendung, so dass eine
breite Nachnutzbarkeit in anderen Bundesländern gegeben ist. Die technische Einheitlichkeit
begünstigt dies zusätzlich.
Das hiermit vorgelegte Konzept beschreibt die Einführung der Online-Ausweisfunktion und
von De-Mail im zivilprozessualen Mahnverfahren.
Die Integration der Online-Ausweisfunktion in das Portal zur Antragstellung im automatisierten Mahnwesen (OMA) wird anhand einer prototypischen Umsetzung erläutert, die auf der
CeBIT 2014 präsentiert wurde. Dabei werden sowohl prozessuale und organisatorische als
auch technische Aspekte betrachtet. Die Einbindung der Online-Ausweisfunktion in den Online-Mahnantrag erwies sich als technisch deutlich weniger aufwändig als zunächst befürchtet. Aus diesen sehr positiven Erfahrungen resultierten Bestrebungen, die Nutzung der Online-Ausweisfunktion im automatisierten Mahnverfahren früher als geplant zuzulassen.
Zum besseren Verständnis der Nutzung von De-Mail im automatisierten Mahnverfahren werden zunächst einige Grundlagen der De-Mail-Kommunikation erläutert. Danach werden drei
Architekturansätze vorgestellt und hinsichtlich ihrer Vor- und Nachteile bewertet. Sie unterscheiden sich im Wesentlichen dadurch, dass unterschiedliche De-Mail-Gateways zum Einsatz kommen. Gegenwärtig ist noch nicht entschieden, welche Option in welchem zeitlichen
Rahmen umgesetzt werden soll.
Das vorliegende Konzept wurde gemeinsam von dem Justizministerium Baden-Württemberg
und dem Pilot-Amtsgericht Hagen mit Unterstützung der E-Government-Initiative des Bundesministerium des Innern (BMI) heraus erstellt.
4/27
2 Nutzung der Online-Ausweisfunktion
Die folgende Konzeption der Integration der Online-Ausweisfunktion des Personalauseises in
das bereits bestehende Portal zur Antragstellung im automatisierten Mahnverfahren
(www.Online-Mahnantrag.de) ist aufgrund Neufassung § 690 Abs. 3 ZPO bis 01.01.2018 zu
realisieren. Im Rahmen dieses Konzepts wird die Umsetzung eines ersten Prototyps beschrieben, der auf der Cebit 2014 präsentiert wurde. Die Aufnahme des Produktivbetriebs
wird, wie gesetzlich zulässig, zum 01.01.2018 erfolgen. Derzeit bestehen Bemühungen, Personalausweis und elektronischen Aufenthaltstitel schon zu einem früheren Zeitpunkt einsetzen zu können.
Das Konzept zeigt unter anderem, welche Mittel notwendig sind, um die OnlineAusweisfunktion in Testumgebungen zu nutzen.
2.1 Anforderungen an prototypische Umsetzung
Die folgenden Anforderungen beziehen sich auf eine nicht produktive Unterstützung des
Personalausweises in der sogenannten „Test-Public Key Infrastructure (Test-PKI)“.
2.1.1 Infrastruktur-Erweiterungen des Online-Mahnverfahrens
Für die Nutzung der Online-Ausweisfunktion im automatisierten Mahnverfahren sind folgende Infrastrukturerweiterungen erforderlich:
-
Zur Autorisierung des Auslesevorgangs in der Test-PKI ist die Bereitstellung eines
Berechtigungszertifikats in der Test-PKI notwendig. Im Chip des Personalausweises
ist das Wurzel-(Root-)Zertifikat der EAC-Public Key Infrastructure (EAC-PKI) gespeichert. Damit ist der Personalausweis in der Lage zu überprüfen, ob die ihm präsentierten Zertifikate echt sind.
-
Zum Übermitteln der Daten aus dem Personalausweis ist die Bereitstellung eines
eID-Servers und die Einbindung des erforderlichen Test-Berechtigungszertifikats
notwendig. Ein eID-Server ermöglicht es Diensteanbietern, die OnlineAusweisfunktion in ihre bereits existierenden IT-Systeme einzubinden. Der eIDServer übernimmt die elektronische Kommunikation zwischen dem Online-Angebot
der Behörde und dem Personalausweis der Bürgerin oder des Bürgers. Das heißt, er
übernimmt die sichere Kommunikation mit der Client-Software (z.B. AusweisApp) und
dem Personalausweis-Chip und gibt ausgelesene Daten an den Dienst weiter.
-
Für Test und Demonstration der Anwendung ist die Bereitstellung von Personalausweisen der Test-PKI notwendig.
2.1.2 Notwendige Anpassungen im Online-Mahnverfahren
Für die Nutzung der Online-Ausweisfunktion sind folgende Anpassungen im OnlineMahnverfahren erforderlich:
-
Beim Start der Anwendung wird die Auswahl des Authentifizierungsverfahrens getroffen. Hier muss eine neue Option zur Auswahl der Online-Ausweisfunktion des Personalausweises oder des Elektronischen Aufenthaltstitels ergänzt werden.
-
Das bestehende Online-Mahnverfahren nutzt die qualifizierte elektronische Signatur.
Im Fall einer Authentifizierung mit der Online-Ausweisfunktion muss anstatt der Mas-
5/27
ke „Drucken/Signieren“ eine neue Webseite ergänzt werden, die die Identifikation mit
der Online-Ausweisfunktion aufruft.
-
Das Mahnverfahren wird um eine Komponente erweitert, die die Kommunikation mit
dem eID-Server übernimmt. Die Personalausweis-Daten selbst werden dem Server
übermittelt und dann über eine Schnittstelle dem Mahnverfahren zur Verfügung gestellt. Für den Zugriff stellt der eID-Service-Provider eine Java-Programmbibliothek
zur Verfügung
-
Die Verbindung zwischen eID-Server und OMA muss mit einem zu erstellenden SSLZertifikat abgesichert werden. Dieses Zertifikat wird dann in den eID-Hilfsbibliotheken
konfiguriert. Die Erstellung des Zertifikats ist in der Dokumentation des eID-Server
Providers beschrieben.
-
Es muss eine Auswahl der zu nutzenden Schnittstelle zum eID-Server getroffen werden, z.B. SAML, WebService, eID-Bibliothek oder Bürgerkonto-Schnittstelle(siehe
auch Kapitel 2.2.1.1).
-
Der aus dem Personalausweis übermittelte Datensatz muss zum (ggf. erforderlichen)
Nachweis der Identifikation im Vorgang gespeichert werden.
-
Bei Personalausweis-Nutzung soll zur Übermittlung der Daten aus OMA ein Enterprise EGVP1 mit synchronem Nachrichtenversand verwendet werden. Das Enterprise
EGVP schickt den Antrag des Nutzers selbstständig weiter, ohne dass der Nutzer ein
EGVP installieren muss. Durch die synchrone Nachrichtenübermittlung kann dem
Nutzer die Übermittlung direkt bestätigt werden - evtl. durch eine zusätzliche Maske
in OMA.
2.2 Umsetzungskonzept
Das folgende Kapitel beschreibt die fachliche und technische Umsetzung im erstellten Prototyp.
2.2.1 Technische Umsetzung
Zur Kommunikation mit dem eID-Server kann der SAML-Standard- oder eine Web-ServiceSchnittstelle verwendet werden. Diese Schnittstellen sind in der technischen Richtlinie TR
31302 spezifiziert. Zusätzlich bieten ID-Server-Provider die Nutzung eigener Abstraktionsschichten(z.B. Bürgerkonten) an. Im Fall des Online-Mahnantrags wurde das GovernikusBürgerkonto zur Vereinfachung der Kommunikation mit dem eID-Server genutzt. Das Bürgerkonto nutzt nur ein Berechtigungszertifikat und bindet Fachverfahren über eine Mandanten-ID an das System an. Für die Fachverfahren (in diesem Fall OMA) bringt dies den Vorteil, dass ein einfacher Zugriff auf die Online-Ausweisfunktion möglich ist, ohne Schnittstellen
zum eID-Server direkt bedienen zu müssen.
1
Ein Enterprise EGVP stellt eine serverseitige Variante des EGVP dar. Dies ermöglicht einen Versand von EGVP
Nachrichten auf Serverseite ohne das ein Nutzer einen EGVP Client installieren muss.
2
Siehe https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03130/tr-03130.html
6/27
Über klar definierte Schnittstellen können Anwendungen die zum Auslesen der Daten eingesetzten Applikationen „AusweisApp“ bzw. „AutentApp“ aufrufen. Die dazu notwendigen technischen Abstimmungen konnten mit wenigen telefonischen Absprachen erledigt werden. Danach ist es allein Sache der rufenden Anwendung, wie sie mit den bereitgestellten Personalausweis-Daten umgeht.
2.2.1.1 Integration des Governikus-Bürgerkontos
Das Governikus-Bürgerkonto fordert die Übermittlung von Vornamen, Nachname, Geburtsdatum und Adresse vom Personalausweis an. Andere Ausweisdaten werden über das Bürgerkonto nicht unterstützt. Diese Daten genügen für die im Mahnverfahren an dieser Stelle
nötigen Prüfungen (Identität und Prozessfähigkeit).
Zurzeit unterstützt das Test-Bürgerkonto die Governikus AutentApp und die AusweisApp.
Die AusweisApp wird aktuell nur von den neueren Versionen des Microsoft Internet Explorers unterstützt.
Die Kommunikation zum Bürgerkonto basiert auf einer Ausprägung des HTTPS-Protokolls.
Anfragen an das Bürgerkonto werden als HTTP-GET oder HTTP-Post aus OMA an das Bürgerkonto geschickt. Die HTTP Anfrage ist parametrisierbar (z.B. um Festzulegen welche Daten aus dem Personalausweis ausgelesen werden) und wird verschlüsselt.
Beim Aufruf wird der Nutzer an das EntranceServlet des Bürgerkontos weitergeleitet. In der
Aufruf URL sind Parameter wie z.B. die Mandanten-Id enthalten. Nach erfolgreicher Analyse
der übergebenen Parameter wird der Nutzer an eine Webseite des Bürgerkontos weitergeleitet auf der die Entscheidung bzgl. Nutzung von AusweisApp oder Governikus AutentApp getroffen wird. Die Kommunikation mit dem eID-Server wird vom Bürgerkonto übernommen.
Nach dem Auslesevorgang wird der Nutzer zurück zu OMA geleitet. Die mit der OnlineAusweisfunktion ausgelesenen Daten werden als verschlüsselter String per HTTP Post an
OMA zurückgegeben.
2.2.1.2 Zielarchitektur OMA mit Ablauf der Online-Ausweisfunktion
Die OMA-Zielarchitektur stellt sich unter Nutzung der Online-Ausweisfunktion wie folgt dar:
7/27
EGVP
Intermediär
Gericht
mit Online Ausweisfunktion
OMA
10
11
Enterprise
EGVP
Intermediär
Gericht
PA
Bibliothek
1
9
2
mit Online Ausweisfunktion
3
4
5
8
Bürgerkonto
7
6
Bürger
eIDServer
Abbildung 1: Einbindung Personalausweis in OMA-Architektur
Ablaufbeschreibung
1. Der Nutzer ruft den Online-Mahnantrag auf und wählt nach Antragsdatenerstellung
die Übermittlungsoption „PA/eAT“.
2. Der Online-Mahnantrag erstellt einen HTTP Request mit Parametern für das Bürgerkonto (u.A. Mandantennummer, SPData, URL für Rückgabe der Daten) und antwortet
dem Browser des Nutzers mit einem Redirect auf das EntranceServlet des Bürgerkontos.
Der Online-Mahnantrag gibt damit die Steuerung an das Bürgerkonto ab.
3. Der Browser des Nutzers führt einen Redirect auf das Bürgerkonto durch und wartet
auf Antwort
4. Das Bürgerkonto erzeugt eine Session im eID-Server
5. Das Bürgerkonto bietet dem Nutzer die Auswahl zwischen AusweisApp und AutentApp an
6. Die AutentApp oder die AusweisApp, fordert Name, Adresse und Geburtsdatum des
Nutzers an. Der Nutzer kommuniziert nun über den eID-Client direkt mit eID-Server.
Der Browser des Nutzers wartet in dieser Zeit auf Antwort vom Bürgerkonto. Die
Kommunikation mit dem eID-Server entspricht der Beschreibung aus der Technischen Richtlinie TR-3130 des BSI.
8/27
7. Die Nutzung der Online-Ausweisfunktion ist abgeschlossen. Das Bürgerkonto holt die
Antwort vom eID-Server ab.
8. Bürgerkonto schickt Redirect mit verschlüsselter Antwort des eID-Servers an Browser
des Nutzers zurück
9. Redirect des Browser des Nutzers zum Online-Mahnantrag zurück
10. Bestätigt der Nutzer, werden die Daten in die Schnittstelle zur weiteren Verarbeitung
bei Gericht übernommen. Zur Übermittlung der ergänzten Antragsdaten wird eine unsignierte EGVP-Nachricht erzeugt, die synchron an das elektronische Postfach des
empfangenden Gerichts übermittelt wird.
11. Durch die synchrone Nachrichtenübermittlung kann dem Nutzer die Übermittlung direkt bestätigt werden. Der Vorgang ist abgeschlossen.
OMA kann auch auf gewohntem Weg ohne eID-Nutzung verwendet werden. In diesem Fall
wird zur Antragslegitimation, die hier nicht weiter beschriebene Verwendung von EGVP mit
qualifizierter elektronischer Signatur angeboten.
2.2.2 Fachliche Umsetzung
Die folgende Beschreibung bezieht sich nur auf die Testanwendung des OnlineMahnantrags. Der Prototyp führt auf Online-Mahnantrag-Seite keinerlei Plausibilisierung der
Daten durch. Die Nutzung der eID-Funktion des Personalausweises kann so auch ohne jegliche Antragsdaten vorgeführt werden. Auch die übermittelten Ausweisdaten werden nicht
plausibilisiert.
Das Online-Mahnverfahren bietet auf der Maske „Drucken/Signieren“ nun zusätzlich die
Auswahl der Onlinefunktion des Personalausweises.
Abbildung 2: Auswahl einer Identifizierung mit der Online-Ausweisfunktion
Es folgen Hinweise zur Nutzung der Online-Funktion (Kartenleser betriebsbereit, Personalausweis aufgelegt).
9/27
Abbildung 3: Hinweise zur Nutzung des Personalausweises
Durch Auswahl des Buttons „übertragen“ wird die Identifikation mit der Online Ausweisfunktion angestoßen. Der Nutzer wird dazu auf die Webseite des genutzten temporären Bürgerkontos weitergeleitet. Nach Abschluss des Auslesevorgangs werden die Daten im Hintergrund an die Anwendung übermittelt und der Nutzer automatisch zurück in das OnlineMahnverfahren geleitet. Das temporäre Bürgerkonto ermöglicht eine einfache Nutzung der
Online-Ausweisunktion ohne Aufruf der komplexen SAML- oder Web-Service-Schnittstellen.
Abbildung 4: Weiterleitung zum Login des Bürgerkontos
Das Bürgerkonto überlässt dem Nutzer die Entscheidung, ob er die AutentApp oder die
AusweisApp zum Auslesen der Daten aus dem Personalausweis nutzen möchte.
Wird die AutentApp gewählt, so wird ein Java Applet zum Auslesen der Daten geladen.
10/27
Abbildung 5: Aufruf der AutentApp und Sicherheitshinweis
Das Bürgerkonto liest Vorname(n), Name, Anschrift und Geburtstag aus dem Personalausweis aus. Je nach Kartenlesegerät kann die PIN auf dem Bildschirm oder auf der Tastatur
des Kartenlesegeräts eingegeben werden.
11/27
Abbildung 6: Auswahl der zu übermittelnden Daten
Das Governikus-Bürgerkonto übergibt die übermittelten Daten per Umleitung zurück an den
Online-Mahnantrag. Im Online-Mahnantrag werden die Daten aus dem Personalausweis
übernommen und zur Bestätigung angezeigt.
12/27
Abbildung 7: Rückübermittlung der Daten an das Online-Mahnverfahren
Jetzt kann der Antrag versendet werden („Versenden“-Button). Der vom Bürgerkonto
übermittelte Datensatz muss gespeichert werden, um später die Nutzung der OnlineAusweisfunktion nachweisen zu können.
Abbildung 8: Bestätigung des Antragversands
13/27
Wählt der Nutzer bei Anmeldung am Bügerkonto die AusweisApp zur Identifizerung aus,
öffnet sich die folgende Bildschirmmaske.
Abbildung 9: Beispiel für die Nutzung der AusweisApp
14/27
3 Nutzung von De-Mail
Für die Nutzung von De-Mail geht es zunächst darum, grundsätzliche Architektur- und organisatorische Entscheidungen zu treffen. Die Verwendung von De-Mail in weiteren Kommunikationsprozessen zwischen Antragsteller, Mahngericht und Antragsgegner ist grundsätzlich
möglich, wird hier aber nicht betrachtet.
3.1 Grundlagen der De-Mail-Kommunikation
3.1.1 De-Mail-Adressen und –Accounts
De-Mail-Adressen sind grundsätzlich wie E-Mail-Adressen aufgebaut. Ihre Struktur richtet
sich danach, ob es sich um natürliche oder juristische Personen, Personengesellschaften
bzw. öffentliche Stellen handelt:
Natürliche Personen:
-
Struktur: [email protected]
-
Beispiel: [email protected]
-
Anmerkungen:
o
Vorname kann abgekürzt werden.
o
Falls Vorname.Nachname bereits vorhanden ist, kann eine Nummer angefügt
werden.
o
Grundsätzlich kann auch eine andere zugelassene De-Mail-Domäne anstatt
„de-mail.de“ verwendet werden (z.Z. nicht üblich).
o
Natürliche Personen können auch Pseudonyme (mit dem Format „pn_...@...“)
verwenden.
Juristische Personen, Personengesellschaften und öffentliche Stellen:
-
Struktur: [email protected]
-
Beispiel: [email protected]
-
Anmerkungen:
o
Als 3rd-Level-Domain steht immer der De-Mail-Konto-Inhaber (im Beispiel:
„ag-hagen“), d.h. an der 3rd-Level-Domain einer De-Mail-Adresse soll immer
erkennbar sein, wer der Inhaber des De-Mail-Kontos ist.
o
Die Bezeichnung der 3rd-Level-Domain einer juristischen Person, Personengesellschaft oder öffentliche Stelle muss gemäß De-Mail-Gesetz immer in „direktem Bezug zu ihrer Firma, Namen oder sonstiger Bezeichnung“ stehen.
o
Vor dem „@“ kann eine beliebige Bezeichnung gewählt werden.
o
Es können zusätzlich beliebige 4th- und 5th-Level-Domains gewählt werden,
z.B. [email protected]
o
Grundsätzlich kann auch eine andere zugelassene De-Mail-Domäne anstatt
„de-mail.de“ verwendet werden (z.Z. nicht üblich).
o
Die von De-Mail entfalteten Rechtswirkungen beziehen sich immer auf den
De-Mail-Kontoinhaber, also auf die als 3rd-Level-Domain genannte Institution.
15/27
3.1.2 Bestätigungsnachrichten
Beim Versand von De-Mails können auf Wunsch des Absenders Bestätigungsnachrichten
angefordert werden. Dabei handelt es sich um spezielle, vom De-Mail-Anbieter des Absenders oder Empfängers qualifiziert elektronisch signierte De-Mails, die an den Absender und
z.T. zusätzlich an den Empfänger geschickt werden.
Folgende Bestätigungsnachrichten sind möglich:
-
Versandbestätigung
Sie wird vom De-Mail-Anbieter des Absenders erstellt und an den Absender geschickt, sobald die De-Mail vom Absender-Provider versendet wurde.
-
Eingangsbestätigung
Sie wird vom De-Mail-Anbieter des Empfängers sowohl an den Absender als auch an
den Empfänger der De-Mail geschickt, sobald die zugehörige De-Mail in das De-MailKonto des Empfängers eingelegt wurde.
-
Abholbestätigung
Sie wird vom De-Mail-Anbieter des Empfängers sowohl an den Absender als auch an
den Empfänger der De-Mail geschickt, sobald die zugehörige De-Mail in das De-MailKonto des Empfängers eingelegt wurde und dieser sich (auf hohem Sicherheitsniveau) an seinem De-Mail-Konto angemeldet hat. Abholbestätigungen dürfen nur von
öffentlichen Stellen angefordert werden.
3.1.3 Zugriffsmöglichkeiten auf De-Mail-Konten
3.1.3.1 Webbrowser
Grundsätzlich kann jeder De-Mail-Nutzer per Webbrowser auf sein De-Mail-Konto zugreifen
und so De-Mails versenden und empfangen. Die Anmeldung am De-Mail-Konto kann auf
normalem Sicherheitsniveau (Benutzerkennung + Kennwort) oder hohem Sicherheitsniveau
(z.B. mittels SMS-TAN oder Chipkarte) erfolgen.
Empfangene De-Mails können exportiert und so in anderen Systeme abgelegt und/oder weiterverwendet werden.
Bei Bedarf können im De-Mail-Konto sogenannte „Unterkonten“ mit eigenen De-MailAdressen und Zugangsdaten eingerichtet werden.
Grundsätzlich ist es also möglich, dass ein Mahngericht auf sein De-Mail-(Unter-)Konto per
Webbrowser zugreift. Damit sind die Möglichkeiten einer automatisierten Bearbeitung eingegangener De-Mails aber äußerst begrenzt.
3.1.3.2 De-Mail-Gateway
In der Regel werden juristische Personen und öffentliche Stellen De-Mail mittels De-MailGateway nutzen. Das Gateway kann in unterschiedlicher Art und Weise eingesetzt werden:
-
Software, die vom De-Mail-Nutzer selbst installiert und betrieben wird
-
Hard-/Softwaresystem (Appliance), das ebenfalls vom De-Mail-Nutzer selbst installiert und betrieben wird
16/27
-
System, das vom De-Mail-Anbieter betrieben und dem Nutzer zur Verfügung gestellt
wird
-
System („mandantenfähiges De-Mail-Gateway“), das von einem Dritten betrieben und
dem Nutzer zur Verfügung gestellt wird, z.B. durch ein kommunales Rechenzentrum
für die angeschlossenen Kommunen oder durch ein Landesrechenzentrum für alle
Landesbehörden.
Die gegenwärtig verfügbaren De-Mail-Gateways wandeln – vereinfacht gesprochen – DeMails in E-Mails um und umgekehrt.
Das De-Mail-Gateway ist auf der einen Seite mit dem De-Mail-Konto des jeweiligen Nutzers
beim De-Mail-Anbieter verbunden. Die Verbindung ist verschlüsselt. Die Authentisierung des
Gateways beim De-Mail-Anbieter erfolgt auf hohem Sicherheitsniveau (i.d.R. mittels Chipkarte).
Auf der anderen Seite ist das Gateway mit einem E-Mail-/SMTP-Relay oder -Server verbunden, an den die empfangenen De-Mails ausgeliefert und von dem die zu versendenden DeMails 3 entgegengenommen werden.
Grundsätzlich erfolgt der (einfache) Versand und Empfang von De-Mails über ein Gateway
(mit angebundenem E-Mail-Server) in folgenden Schritten:
Versand einer De-Mail durch eine öffentliche Stelle (z.B. Amtsgericht):
-
Ein Sachbearbeiter erstellt in seinem E-Mail-Client (z.B. Outlook, Thunderbird, Notes)
– ggf. unter Verwendung eines entsprechenden De-Mail-Plugins o.ä. – eine Mail an
eine De-Mail-Adresse und sendet diese ab.
-
Die Mail gelangt auf den E-Mail-Server und wird dort anhand der Empfänger-Adresse
als De-Mail identifiziert, z.B. anhand der Endung „de-mail.de“.
-
Der E-Mail-Server sendet die Mail (als „De-Mail-Entwurf“) an das De-Mail-Gateway.
-
Das De-Mail-Gateway prüft zunächst anhand einer sog. „Adress-Mapping-Tabelle“,
ob der Absender überhaupt berechtigt ist, eine De-Mail zu versenden. Wenn ja, dann
ändert es die Absenderadresse der Mail auf die gewünschte (neue) De-MailAbsenderadresse, z.B. von [email protected] auf [email protected].
-
Das Gateway liefert die Mail an das De-Mail-Konto des Absenders (z.B. Amtsgericht
Hagen) beim De-Mail-Anbieter aus.
-
Der De-Mail-Anbieter versieht die Mail mit der gesetzlichen Zeit, vergibt eine eindeutige ID und setzt weitere Sicherheitsmerkmale. Damit ist die Mail (De-Mail-Entwurf)
eine (echte) De-Mail und kann an den Empfänger ausgeliefert werden.
3
Strenggenommen handelt es sich hierbei noch nicht um De-Mails, sondern um „De-Mail-Entwürfe“. Erst beim
De-Mail-Anbieter werden bestimmte Header-Daten in der De-Mail gesetzt (z.B. Message-ID, Prüfsumme, gesetzliche Zeit usw.), wodurch der De-Mail-Entwurf zur (echten) De-Mail wird.
17/27
Der Empfang einer De-Mail durch eine öffentliche Stelle (z.B. Amtsgericht) stellt sich ähnlich
dar:
-
Die De-Mail trifft im De-Mail-Postfach der öffentlichen Stelle beim De-Mail-Anbieter
ein.
-
Das De-Mail-Gateway der öffentliche Stelle fragt in bestimmten Abständen beim Anbieter an, ab De-Mails zur Abholung bereit liegen.
-
Wenn ja, werden die De-Mails an das Gateway übertragen.
-
Das Gateway prüft anhand der Adress-Mapping-Tabelle, auf welche (interne) E-MailAdresse die Empfänger-De-Mail-Adresse umgeschrieben werden soll (z.B. von
[email protected] auf [email protected]) und nimmt diese
Adresstransformation vor.
-
Die De-Mail wird an das entsprechende Postfach (z.B. des Mahngerichts) auf dem EMail-Server ausgeliefert und kann dort (wie eine E-Mail auch) abgerufen, weitergeleitet usw. werden.
3.1.3.3 OSCI-/De-Mail-Gateway
Wie bereits beschrieben, wandeln die gegenwärtig verfügbaren De-Mail-Gateways De-Mails
in E-Mails (und umgekehrt). In ganz ähnlicher Art und Weise sind Gateways denkbar, die
De-Mails in OSCI-Nachrichten wandeln und umgekehrt.
Dazu hat das BSI im Mai 2013 ein Feinkonzept „Gateway für die Verknüpfung von De-Mail
und OSCI“ vorgelegt. Darin wird insbesondere beschrieben, wie das Gateway De-Mails vom
De-Mail-Anbieter abruft, diese unter Zuhilfenahme des EGVP-Verzeichnisdienstes (auf
S.A.F.E.-Basis) in eine OSCI-Nachricht wandelt und über den OSCI-Intermediär an das
EGVP ausliefert. Auch der entgegensetze Prozess wird erläutert.
Der von Governikus Gmbh & Co. KG (vormals Bremen Online Services) angebotene Governikus MultiMessenger erfüllt bereits einen Teil der Anforderungen an ein OSCI-/De-MailGateway.
Der Einsatz eines OSCI-/De-Mail-Gateways ist dann angezeigt, wenn unbedingt OSCINachrichten benötigt werden – für Versand und/oder Empfang. Dies ist insbesondere dann
der Fall, wenn vorhandene Fachverfahren oder andere Backendsysteme das OSCINachrichtenformat erfordern.
Dabei sollte berücksichtigt werden, dass bei einer Kopplung von OSCI und De-Mail Sicherheitseigenschaften von OSCI entbehrlich werden:
-
(Qualifizierte elektronische) Signatur
Insbesondere zur Erfüllung von Schriftformerfordernissen werden OSCI-Nachrichten
häufig qualifiziert elektronisch signiert. Gemäß § 130a eJustice-Gesetz können „elektronische Dokumente“ nun auch ohne qualifizierte elektronische Signatur der verantwortenden Person eingereicht werden, wenn dies auf einem sicheren Übermittlungsweg, also z.B. als (absenderbestätigte) De-Mail, erfolgt.
-
Verschlüsselung
OSCI bietet eine Ende-zu-Ende-Verschlüsselung zwischen Absender und Empfänger. Dies ist bei De-Mail nicht der Fall, da nur die Transportkänale verschlüsselt werden, was eine „Umschlüsselung“ (Ent- und erneute Verschlüsselung) beim De-Mail-
18/27
Anbieter erfordert. Dort werden die De-Mails verschlüsselt gespeichert. Da die DeMail-Anbieter allerdings bzgl. Sicherheit und Datenschutz zertifiziert sind, kann in fast
allen Fällen auf eine durchgängige Ende-zu-Ende-Verschlüsselung verzichtet werden. Auf Wunsch des Absenders können aber auch De-Mails Ende-zu-Ende verschlüsselt werden – nicht auf Basis OSCI. Die De-Mail-Anbieter müssen dies unterstützen.
-
Quittungen (Laufzettel)
In der De-Mail-Kommunikation gelten grundsätzlich nur die De-Mail-eigenen Quittungsmechanismen - d.h. insbesondere, dass eine De-Mail beim Empfänger dann als
eingegangen gilt, sobald sie in das De-Mail-Postfach des Empfängers bei seinem DeMail-Anbieter eingelegt wurde. Zu diesem Zeitpunkt erhält der Absender (auf
Wunsch) darüber eine Bestätigung („Eingangsbestätigung“) – und Fristen beginnen
ggf. zu laufen. Aus Sicht von De-Mail und den damit verknüpften Rechtswirkungen ist
es völlig unerheblich, wann der Empfänger die De-Mail aus seinem Postfach abholt
und wie dies geschieht, per Webbrowser bzw. „normalen“ oder OSCI-/De-MailGateway. In dieser Hinsicht hätte der OSCI-Laufzettel seine Bedeutung verloren.
OSCI-Komponenten könnten aber dazu verwendet werden, die z.T. an De-Mails angebrachten qualifizierten elektronischen Signaturen zu prüfen.
Zusammenfassend kann festgehalten werden, dass OSCI rein aus Sicherheitsgründen in einer De-Mail-Kommunikation entbehrlich ist. Wird das OSCI-Nachrichtenformat nicht aus anderen Gründen unbedingt benötigt, kann auf OSCI und damit auch auf ein OSCI-/De-MailGateway verzichtet werden.
3.2 Einsatz von De-Mail im automatisierten Mahnverfahren
3.2.1 De-Mail-Adressen der Mahngerichte
Die 12 Mahngerichte in Deutschland sind den entsprechenden Amtsgerichten zugeordnet,
z.B. ist das Mahngericht Hagen eine Abteilung des Amtsgerichts Hagen.
Da die Amtsgerichte zukünftig einen Zugang für De-Mail eröffnen müssen, sollte ein De-MailKonto pro Amtsgericht bei einem akkreditierten De-Mail-Anbieter einrichtet werden, vorzugsweise mit der De-Mail-Domain „amtsgericht-xyz.de-mail.de“, z.B. „ag-hagen.de-mail.de“
Eine 1:1-Übertragung des E-Mail-Adressformates des AG Hagen in De-Mail ist nicht ohne
weiteres möglich, da ein De-Mail-Konto mit der Adresse „ag-hagen.nrw.de-mail.de“ nicht
dem AG Hagen, sondern NRW gehören würde - welche konkrete Landesbehörde sich auch
immer hinter „NRW“ verbirgt. Dies wäre nur dann möglich, wenn die hinter „NRW“ stehende
Behörde die gesamte Verantwortung für alle ein- und ausgehenden De-Mails des Kontos
„nrw.de-mail.de“ übernehmen würde. Dies hieße beispielsweise, dass alle vom Mahngericht
Hagen versendeten De-Mails nicht vom AG Hagen, sondern von der hinter „NRW“ stehenden Behörde verschickt würden. Das dürfte vermutlich nicht gewollt sein.
Theoretisch ist auch ein De-Mail-Konto mit einer Adresse der Form „mahnwesen.demail.de“ denkbar. Dies hieße aber, dass es eine öffentliche Stelle gibt, deren Namen „in direktem Bezug“ mit „Mahnwesen“ steht (De-Mail-Gesetz) und die die gesamte Verantwortung
19/27
für alle 12 Mahngerichte übernimmt. Eine De-Mail von einem De-Mail-Konto mit der Adresse
„mahnwesen.de-mail.de“ würde dann nicht mehr von den einzelnen Mahngerichten/Amtsgerichten verschickt, sondern von der hinter „mahnwesen“ stehenden öffentlichen
Stelle. Dies dürfte vermutlich ebenfalls nicht gewollt sein.
Aus den genannten Gründen empfiehlt sich die Verwendung folgender De-Mail-Domains:
-
Amtsgerichte: „amtsgericht-xyz.de-mail.de“ oder „ag-xyz.de-mail.de“ o.ä.
-
Mahngerichte (keine eigenen De-Mail-Konten):
o
Adressierung als 4th-Level-Domain, d.h. eine Bezeichnung hinter dem „@“:
…@mahngericht.ag-xyz.de-mail.de,
z.B. “…@mahngericht.ag-hagen.de-mail.de”
o
Adressierung über eine Bezeichnung vor dem „@“:
[email protected],
z.B. [email protected]
3.2.2 Architekturansätze
3.2.2.1 Voraussetzungen und grundsätzlicher Prozessablauf
Die nachstehend genannten Voraussetzungen und der grundsätzliche Prozessablauf gelten
für alle in den folgenden Kapiteln erläuterten Architekturansätze.
Voraussetzungen

Der Antragsteller besitzt ein De-Mail-Konto bei einem akkreditierten De-Mail-Anbieter
seiner Wahl – z.B. [email protected]

Das Mahngericht, an das sich der Antragsteller wenden möchte, besitzt ebenfalls ein
De-Mail-Konto – z.B. [email protected]

Der Antragsteller hat Zugriff auf das Online-Mahnverfahren (OMA) unter www.onlinemahnantrag.de.

OMA ist der Lage, dem Antragsteller den (per De-Mail an das Mahngericht zu versendenden) Antrag in einer geeigneten Form zur Verfügung zu stellen (z.B. PDFDokument und/oder TXT-/XML-Datei, …).

OMA ist der Lage, dem Antragsteller den (per De-Mail an das Mahngericht zu versendenden) Antrag in einer geeigneten Form zur Verfügung zu stellen (z.B. PDFDokument und/oder TXT-/XML-Datei, …).

Nutzer können ihre Antragsdaten durch Einsatz einer geeigneten Software auch
selbst erstellen und lokal abspeichern. Die Übertragung unterscheidet sich danach
nicht von der Übertragung von mit OMA erstellten Antragsdaten.
Grundsätzlicher Prozessablauf
1. Der Antragsteller erstellt einen Mahnantrag in OMA (inkl. aller Plausibilitäts- und Vollständigkeitschecks).
2. Der Antragsteller entscheidet sich (in OMA) für den Versand des Mahnantrags per
De-Mail.
20/27
3. Dem Antragsteller werden die erforderlichen Dateien zum Download bereitgestellt.
Welche Formate hier verwendet werden sollen, muss noch geklärt werden (PDFDokument und/oder TXT-/XML-Datei, …).
4. Der Antragsteller speichert die Dateien lokal auf seinem Rechner ab – ein automatisches Anfügen der Dateien als Anhang einer De-Mail ist aufgrund der erforderlichen
Authentisierung am De-Mail-Konto nicht möglich.
5. Der Antragsteller erstellt eine neue De-Mail (z.B. an [email protected] ) und hängt die erforderlichen Dateien an. Hier ist noch zu klären, wie verhindert werden kann, dass der Antragstellung relevante Daten im Betreff oder im Body
der De-Mail mitschickt, die im Mahngericht nur schwer automatisiert verarbeitet werden können.
6. Der Antragsteller versendet die De-Mail an das Mahngericht und kann auf Wunsch
eine Versandbestätigung und Eingangsbestätigung (per De-Mail) anfordern.
7. Die De-Mail mit den Antragsdaten geht im De-Mail-Konto des Amtsgerichtes ein.
8. Die De-Mail wird in der Regel durch ein Gateway vom De-Mail-Konto abgerufen. Der
Zugriff per Webbrowser auf das De-Mail-Konto wird hier nicht betrachtet, da dadurch
eine automatisierte Weiterverarbeitung kaum möglich ist.
9. In Abhängigkeit vom eingesetzten Gateway wird die De-Mail gewandelt in:
o
E-Mail (SMTP)
o
OSCI-Nachricht
o
Text- oder XML-Dateien o.ä.
Alle drei Varianten werden in den folgenden Kapiteln betrachtet.
10. Die Inhalte der E-Mail- oder OSCI-Nachrichten bzw. die vom Gateway erzeugten Dateien werden (ggf. über weitere Zwischenschritte) in den EDA Manager eingelesen
und dort weiter bearbeitet.
21/27
3.2.2.2 Empfohlene Variante: Standard-De-Mail-Gateway
Architekturübersicht
Abbildung 10: Anbindung über Standard-De-Mail-Gateway
Prozessablauf
Da sich die Abläufe bis einschließlich Abholung der De-Mails vom De-Mail-Konto des Amtsgerichts durch das Gateway in dieser und den folgenden beiden Varianten nicht unterscheiden (siehe 3.2.2.1 Voraussetzungen und grundsätzlicher Prozessablauf), wird davon ausgegangen, dass sich die De-Mail mit dem Mahnantrag (Anhang) bereits auf dem Gateway befindet.
In der empfohlenen Variante kommt ein Standard-Gateway zum Einsatz, das sowohl durch
das Amtsgericht selbst als auch zentral betrieben werden kann. Das Gateway ändert auf Basis einer Adress-Mapping-Tabelle zunächst die Empfängeradresse (z.B. von [email protected] auf [email protected]).
Ferner ist im Gateway die Adresse eines SMTP-Relays/-Servers hinterlegt, an das/den die
empfangenen De-Mails (quasi als E-Mails mit zusätzlichen Headerdaten) ausgeliefert werden.
Da für das Mahnverfahren (im Mahngericht Hagen) nicht der vorhandene E-Mail-Server des
Amtsgerichts verwendet werden soll, wird ein SMTP-Relay zwischengeschaltet, dass z.B. alle Mails an die Adresse [email protected] an einen speziellen E-Mail-Server (für
das Mahnwesen) weiterleitet und alle anderen Mails an den vorhandenen E-Mail-Server des
Amtsgerichts. Als E-Mail-Server kann eine (kostenfreie) Standard-Software eingesetzt wer02_konzept_eid_und_de-mail_im_mahnverfahren_jum_bw.docx
22/27
den, da dieser lediglich die Aufgabe hat, sich um Versand und Empfang der ein- und ausgehenden (De-)Mails zu kümmern. Diese E-Mail-Server sollten in identischer Konfiguration in
allen Mahngerichten zum Einsatz kommen, um den Support zu erleichtern.
Die Mails auf dem E-Mail-Server des Mahnverfahrens können in einem weiteren Schritt
durch eine „Transformationskomponente“ so aufbereitet werden, dass die erforderlichen Daten (z.B. als TXT-Datei) in den EDA Manager übertragen und dort verarbeitet werden können. Diese Komponente müsste den E-Mail-Server nach anstehenden Eingängen abfragen
und diese abrufen. Jede eingegangene (De-)Mail muss hinsichtlich ihrer Headerdaten ausgewertet und daraus eine entsprechende Steuerdatei erzeugt werden. Darüber hinaus muss
der Nachrichtenbody in eine Datei mit geeigneter Struktur transformiert werden. Alle Daten
sind danach im Eingangsverzeichnis des EDA-Managers abzuspeichern.
Zum Versand von De-Mails muss die „Transformationskomponente“ die erforderlichen Daten
vom EDA-Manager entgegennehmen und daraus eine (De-)Mail erzeugen, die über den EMail-Server und das SMTP-Relay an das De-Mail-Gateway ausgeliefert wird.
Bewertung
Für diese Variante spricht, dass Standard-De-Mail-Gateways verwendet werden, die voraussichtlich zukünftig sowieso für die Amtsgerichte zum Einsatz kommen. Die Bearbeitung der
eingehenden (De-)Mails mit den Antragsdaten kann recht einfach durch eine eigenentwickelte Transformationskomponente vorgenommen werden. Dafür sind Headerdaten, Nachrichtenbody und Anhänge der eingegangenen (De-)Mail so aufzubereiten, dass die Daten an
den EDA-Manager übergeben werden können.
23/27
3.2.2.3 Alternativvariante 1: OSCI-/De-Mail-Gateway
Abbildung 11: Anbindung über OSCI-/De-Mail-Gateway
Diese Variante geht zunächst wieder davon aus, dass nur die De-Mails mit Mahnanträgen,
die an ein bestimmtes Unterkonto des Amtsgerichts gerichtet sind, z.B. [email protected], mittels OSCI-/De-Mail-Gateway abgerufen werden. Alle anderen De-Mails
werden von einem Standard-De-Mail-Gateway vom De-Mail-Konto abgeholt und an einen EMail-Server des Amtsgerichts ausgeliefert.
Weitere Varianten sind denkbar:
1. Das OSCI-/De-Mail-Gateway ruft weitere De-Mail-Unterpostfächer ab und liefert die
dort eingegangenen De-Mails als OSCI-Nachrichten an entsprechende OSCIPostfächer auf dem Intermediär aus. Die anderen De-Mails werden vom StandardGateway an den E-Mail-Server des Amtsgerichts geschickt.
2. Das OSCI-/De-Mail-Gateway ruft alle De-Mails aus dem Konto des Amtsgerichts ab
und liefert diese als OSCI-Nachrichten aus. In diesem Fall kann das Standard-DeMail-Gateway entfallen.
24/27
Prozessablauf
Das OSCI-/De-Mail-Gateway empfängt alle an ein bestimmtes Unterpostfach, z.B. [email protected], gerichteten De-Mails mit Mahnanträgen und wandelt diese in
OSCI-Nachrichten um. Die OSCI-Adresse des Empfängers muss dazu ggf. aus dem EGVPAdressverzeichnis (auf S.A.F.E.-Basis) abgerufen werden. Danach wird die OSCI-Nachricht
im entsprechenden OSCI-Postfach eines OSCI-Intermediärs abgelegt. Von dort aus erfolgt
die weitere Bearbeitung und die Übergabe der Daten an den EDA Manager – entsprechende
dem bereits heute implementierten Prozess unter EGVP-Nutzung.
Bewertung
Ein Vorteil dieser Variante ist, dass die Prozessschritte ab OSCI-Intermediär bereits implementiert sind. Grundsätzlich ist es für eine OSCI-Nachricht im OSCI-Postfach auf dem Intermediär ohne Belang, ob sie dorthin über die OSCI-/EGVP-Infrastruktur oder von einem
OSCI-/De-Mail-Gateway gelangt ist.
Nachteilig ist, dass ein OSCI-/De-Mail-Gateway mit der erforderlichen Funktionalität gegenwärtig noch nicht verfügbar ist – zukünftig könnten allerdings Lösungen angeboten werden.
Schwerer wiegt die Tatsache, dass der EDA Manager keinen Input im OSCI-Format benötigt.
Die erforderlichen Antragsdaten können ihm als Text-Datei zur Verfügung gestellt werden.
Da überdies beim Einsatz von De-Mail die Sicherheitsmerkmale von OSCI entbehrlich werden (vergleiche 3.1.3.3 OSCI-/De-Mail-Gateway) spricht wenig für ein OSCI-/De-MailGateway für Mahnanträge.
25/27
3.2.2.4 Alternativvariante 2: Spezielles De-Mail-Gateway für Mahnanträge
Abbildung 12: Anbindung über ein spezielles De-Mail-Gateway für Mahnanträge
Prozessablauf
Die im De-Mail-Konto des Amtsgerichts eingegangenen De-Mails müssen unterschiedlich
behandelt werden, da es sich nur zum Teil um Mahnanträge handelt.
Dazu ist im De-Mail-Konto ein sogenanntes „Unterkonto“ einzurichten, z.B. für die Adresse
[email protected]. Alle De-Mails in diesem Unterkonto werden durch ein
spezielles „Mahnwesen-Gateway“ abgeholt und derart transformiert, dass die erforderlichen
Daten, z.B. als TXT-Datei sofort an den EDA Manager übergeben werden können.
Alle anderen an das Amtsgericht gerichteten De-Mails werden von einem Standard-De-MailGateway vom De-Mail-Konto abgeholt und an einen E-Mail-Server des Amtsgerichts ausgeliefert. Dort können sie – wie gewöhnliche E-Mails – weitergeleitet, gespeichert, bearbeitet
usw. werden.
Bewertung
Gegenwärtig existiert kein spezielles De-Mail-Gateway für Mahnanträge. Dies müsste entwickelt werden. Die De-Mail-Anbieter halten sich zur Zeit mit der Bereitstellung einer (universellen) De-Mail-Schnittstelle für die Anbindung von Drittanbieter-Gateways sehr zurück. Aus
diesem Grunde ist eine starke Abhängigkeit einer Mahnwesen-Gateway-Entwicklung von
den Vorgaben der De-Mail-Anbieter gegeben, was die Entwicklung ggf. behindern, aber auf
jeden Fall wesentlich verteuern würde.
26/27
Es dürfte deutlich einfacher sein, die eingegangenen De-Mails zunächst durch ein StandardGateway an einen E-Mail-Server ausliefern und diese dann durch eine eigenentwickelte
„Transformationskomponente“ bearbeiten zu lassen, um die für den EDA Manager erforderlichen Formate zu erzeugen. So wäre man komplett unabhängig vom jeweiligen De-MailAnbieter.
27/27
Herausgeber
Bundesministerium des Innern
IT-Stab, Referat ITI4
Alt-Moabit 101 D, 10559 Berlin
Bezugsquelle
Bundesministerium des Innern
E-Mail: [email protected]
Internet: www.personalausweisportal.de
E-Mail: [email protected]
Internet: www.de-mail.de
Tel.: +49.030.18681.0
Veröffentlicht
November 2014
HINWEIS
Das Bundesministerium des Innern ist nicht verantwortlich für den Inhalt der Ergebnisdokumente,
die im Rahmen der E-Government -Initiative für De-Mail und den Personalausweis erstellt wurden.
Bitte wenden Sie sich bei inhaltlichen Fragen direkt an die hier genannten Ansprechpartner.
Verantwortlich für den Inhalt dieses Ergebnisdokumentes
Koordinierungsstelle für das automatisierte Mahnverfahren
Herr Ralf Selbmann
Schillerplatz 4, 70173 Stuttgart
Tel.: 0711.279.2143
E-Mail [email protected]
Internet: www.justizportal-bw.de
Diese Veröffentlichung ist Teil der Öffentlichkeitsarbeit der Bundesregierung.
Sie w ird kostenlos abgegeben und ist nicht zum Verkauf bestimmt.

Justizministerium Baden-Württemberg: Konzept eID und De

Transcrição

Documentos relacionados

Übersicht der Ausstellungsthemen und Mitaussteller auf dem BfIT

Anmeldung von Haushaltshilfen

DE-MAIL DIGITALISIERUNG VON GESCHÄFTSPOST

Was bringt die digitale Post? – E-Mail und De-Mail als Teil

Telekom-Rechnung für August 2015

Inkassodienste für Mitgliedsunternehmen der DNHK

De-Mail und rechtssichere Kommunikation

der fastenweg - Katholische Kirche Kärnten

Goya in Gmünd

Der Partner für Ihren Erfolg im Gesundheitswesen