Landeshauptstadt München - Fachkonzept zur Integration von De-Mail

Transcrição

Landeshauptstadt München - Fachkonzept zur Integration von De-Mail
E-Government-Initiative
für De-Mail und den Personalausweis
Landeshauptstadt München
Einsatzszenarien De-Mail - Fachkonzept
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.
Fachkonzept
Teilprojekt Einsatzszenarien De-Mail LHM – M058
eoGov_M058_Einsatzszenarien_De-Mail_LHM_Fachkonzept_V1.1_release.odt
Version: V1.0
Datum: 19.12.2014
Status: final
Erstellt von: Jens Dworzak (e/oGov Kernteam)
Review: Wolfgang Glock, Max Weinhart, Sabine Wagner
am_fachkonz_v.ott | V1.1 | Vorlage wurde erstellt von D-III-GB3
am_
2_63_Fachkonzept De-Mail 1.0.docx
Seite 2 von 57
1
Einleitung ...................................................................................................................... 5
2
Management Summary ................................................................................................ 5
3
Stakeholder .................................................................................................................. 8
4
Rahmenbedingungen und Einflussfaktoren ................................................................ 10
5
Ausgangslage ............................................................................................................. 12
6
Fachliche Ziele ........................................................................................................... 13
7
Geschäftsprozesse ..................................................................................................... 15
7.1
Mögliche Geschäftsprozesse/Einsatzszenarien ................................................... 15
7.2
Prozessrollen ........................................................................................................ 16
7.3
Prozessbeschreibungen ....................................................................................... 18
7.4
Mengengerüst ....................................................................................................... 23
8
Anwendungsfälle ........................................................................................................ 23
8.1
Anwendungsfall-Liste............................................................................................ 24
8.2
Akteur-Liste .......................................................................................................... 25
8.3
Beschreibung der Anwendungsfälle...................................................................... 26
8.4
Prüfung der Vollständigkeit und Notwendigkeit der Anwendungsfälle................... 28
9
Fachliches Datenmodell ............................................................................................. 29
9.1
Speicherung von De-Mail-Adressen (Adressbuch) ............................................... 29
9.2
Dokumentation der LHM De-Mail-Adressen ......................................................... 29
9.3
Private-ID .............................................................................................................. 30
9.4
De-Mail-Domain & -Adressen Konstruktionsprinzip .............................................. 30
10
Anforderungen und Ausgrenzungen ........................................................................ 31
10.1
Benutzeroberfläche ........................................................................................... 31
10.1.1
Thunderbird: Eingefügte Kennzeichnungen ................................................ 32
10.1.2
Thunderbird: Hervorhebung von De-Mails .................................................. 33
10.1.3
Kolab Mail-Client ......................................................................................... 35
10.2
Funktionale Anforderungen ............................................................................... 35
10.2.1
Anforderungen an ein De-Mail-Gateway ..................................................... 37
10.3
Nicht funktionale Anforderungen ....................................................................... 39
10.4
Ausgabevorlagen und -formate ......................................................................... 40
10.5
Zuordnungsmatrix.............................................................................................. 40
10.6
Motivation .......................................................................................................... 40
11 Schnittstellenbeschreibung ......................................................................................... 41
11.1
Integrierte DMGW Lösung ................................................................................. 41
11.2
Standalone DMGW Lösung ............................................................................... 43
11.3
Von der Anwendung angebotene Schnittstellen ................................................ 43
2_63_Fachkonzept De-Mail 1.0.docx
11.4
Seite 3 von 57
Von der Anwendung benötigte Schnittstellen .................................................... 43
12
Rollen- und Berechtigungskonzept .......................................................................... 44
13
Weitere Sicherheitsaspekte ..................................................................................... 44
13.1
Risikobetrachtung der Geschäftsinformationen ................................................. 44
13.2
Datenschutz ...................................................................................................... 44
13.3
Informationssicherheit ....................................................................................... 45
13.3.1
14
Notfallkonzept ............................................................................................. 46
Hilfe & Support ......................................................................................................... 46
14.1
Anforderungen an den Support für die IT-Lösung ............................................. 46
14.2
Anforderungen an das Hilfesystem für die IT-Lösung ........................................ 47
15
Initialbefüllung und Migrationskonzept ..................................................................... 47
15.1
Vorgängersystem............................................................................................... 47
15.2
De-Mail-Adressen .............................................................................................. 47
16
Einführungs- und Schulungsplan ............................................................................. 47
17
Abnahmekriterien ..................................................................................................... 48
17.1
17.1.1
Nachrichten der LHM an externe Partner ................................................... 48
17.1.2
Bürgeranfragen an die LHM ........................................................................ 49
17.1.3
Nachrichten aus LHM Fachverfahren an Bürger / Partner .......................... 50
17.2
18
Relevante Kommunikationsszenarien ............................................................... 48
Technische und organisatorische Abnahmekriterien ......................................... 51
17.2.1
Infrastrukturkomponenten ........................................................................... 51
17.2.2
De-Mail-Adressantrag (DMAA), Einrichtung Postfach ................................. 52
17.2.3
Support durch den IT-Support ..................................................................... 52
17.2.4
Aufgaben des STRAC/Direktorium ............................................................. 52
17.2.5
Thunderbird ................................................................................................ 53
17.2.6
Kontact (Kolab) ........................................................................................... 53
Anhänge................................................................................................................... 54
18.1
Glossar .............................................................................................................. 54
18.2
Quellenverzeichnis ............................................................................................ 55
19
Anhang..................................................................................................................... 56
19.1
Präsentation zu De-Mail Informationsveranstaltungen ...................................... 56
19.2
De-Mail Tarif ...................................................................................................... 56
19.3
Kolab Konzept ................................................................................................... 56
19.4
Textvorschlag für die elektrische Zugangseröffnung im Rahmen der LHM ........ 56
2_63_Fachkonzept De-Mail 1.0.docx
Seite 4 von 57
Abbildungsverzeichnis
Abbildung 1: Systemkontext De-Mail bei der Landeshauptstadt München ........................ 13
Abbildung 2: Eingehende De-Mail Kommunikation ............................................................ 18
Abbildung 3: Ausgehende Kommunikation ....................................................................... 20
Abbildung 4: Sequenz; Freischaltung für den De-Mail-Versand......................................... 22
Abbildung 5: Sequenz; Versand von De-Mails aus einem Fachverfahren ......................... 22
Abbildung 6 : Überblick De-Mail Anwendungsfälle ............................................................. 24
Abbildung 7: Aufbau De-Mail-Adressen ............................................................................. 31
Abbildung 8: Optionale farbliche Kennzeichnung über die Thunderbird Filteroptionen
mittels Schlagwort .............................................................................................................. 33
Abbildung 9: Schlagwörter in den Thunderbird-Einstellungen ........................................... 34
Abbildung 10: Lokalen Filter "De-Mail" im Thunderbird hinzufügen .................................. 34
Abbildung 11: Bedingungen des Filters „De-Mail“ zur Hervorhebung von De-Mails........... 34
Abbildung 12 Schnittstellenbetrachtung De-Mail-Gateway als integrierte Lösung ............. 42
Abbildung 13 Schnittstellenbetrachtung De-Mail-Gateway als Standalone Lösung ........... 43
Tabellenverzeichnis
Tabelle 1 Umsetzungsstufen ................................................................................................ 7
Tabelle 3 Rechtliche Aspekte im Rahmen von De-Mail ...................................................... 12
Tabelle 4 Fachliche Ziele für die Einführung der De-Mail ................................................... 15
Tabelle 6 Liste der De-Mail Anwendungsfälle .................................................................... 25
Tabelle 8 Zuordnungsmatrix der fachlichen Ziele und Anwendungsfälle ............................ 29
Tabelle 9 Behandlung der Kennzeichnungen Kommunikationstyp „De-Mail“ und der
Versandoptionen ................................................................................................................ 32
Tabelle 10 Rollen und Akteure im De-Mail-Umfeld............................................................. 44
2_63_Fachkonzept De-Mail 1.0.docx
Seite 5 von 57
1 Einleitung
De-Mail ist ein auf der E-Mail-Technik beruhendes, hiervon aber technisch getrenntes,
Kommunikationsmittel zur „sicheren, vertraulichen und nachweisbaren“ Kommunikation im Internet
(§ 1 Abs. 1 De-Mail-Gesetz). Realisiert und betrieben wird De-Mail von privatwirtschaftlichen
Unternehmen (derzeit T-Systems International, Telekom Deutschland, Mentana-Claimsoft und
1&1), den De-Mail-Diensteanbietern (oder umgangssprachlich auch: De-Mail-Providern). De-Mail
darf nur von durch das BSI akkreditierten De-Mail-Dienstanbietern angeboten werden und kann als
Alternative zur regulären Papierpost in Deutschland verstanden werden.
Das vorliegende Fachkonzept beleuchtet daher alle notwendigen Aspekte für eine nachhaltige DeMail-Integration innerhalb der Landeshauptstadt München, zur Ermöglichung einer digitalen und
rechtsverbindlichen Kommunikation mit Bürgern und juristischen Personen. Diese ist Teil des
Gesamtprojekts E- und Open-Government Stufe 1. Teil der Projektes ist es auch, mögliche
Einsatzszenarien für De-Mail zu prüfen und zu beurteilen.
Die dafür neu zu schaffende De-Mail-Infrastruktur agiert an einer zentralen Stelle im Hintergrund
und kann an bestehende E-Mail-Prozesse angebunden werden. Hierdurch kann die De-Mail an
nahezu alle bestehenden Verfahren, die bereits heute mit E-Mails umgehen können, angebunden
werden. Es werden daher auch Schnittstellen zu neuen und bestehenden Postfächern, den E-MailClients, innerhalb der Landeshauptstadt München sowie die Anbindung an das bereits bestehende
E-Mail-Verschlüsselungs-Gateway und die Anbindung zu den De-Mail-Diensteanbietern
vorgesehen. Die neu zu schaffende “digitale Poststelle“ wurde hierbei ebenfalls berücksichtigt.
Die Einführung wird zur Verbesserung des Bürgerservices sowohl von interner Seite als auch
durch externe Einflüsse wie den Städtetag und rechtliche Vorgaben bei der Umsetzung von
Verwaltungsverfahren gefordert. Als besondere Beispiele sind hier die elektronische KraftfahrzeugAußerbetriebsetzung (iKFZ) und die elektronische Gewerbemeldung zu nennen, die ab dem
1.1.2015 De-Mail im Rahmen des Verfahrens voraussetzen.
Die bereits geschaffenen und noch im Rahmen des bayrischen E-Government-Gesetzes zu
schaffenden gesetzlichen Rahmenbedingungen, ermöglichen durch den zusätzlich elektronischen
Kanal einen Bürokratieabbau und können zu einer Vereinfachung von Verwaltungsvorgängen und
zu einer Steigerung der Bürgerfreundlichkeit führen. Hierzu zählt beispielsweise die Erfüllung von
Schriftformerfordernissen (dieses wird voraussichtlich durch das bayrische E-Government-Gesetz
geregelt). Dadurch würde die elektronische Form der Willenserklärung ermöglicht.
Schreibweisen im Dokument
Zur leichteren Lesbarkeit wurde im vorliegenden Fachkonzept ausschließlich die männliche
Schreibweise bei Personenbezeichnungen wie Anwender oder Mitarbeiter verwendet. Es sind aber
an allen Stellen im Dokument jeweils weibliche wie männliche Mitarbeiterinnen und Mitarbeiter
gemeint. Dies betrifft bei externen Kommunikationspartnern auch die Bürgerinnen und Bürger.
2 Management Summary
Ziele sind:

Einführung der De-Mail bei der Landeshauptstadt München mit
anschließender Zugangseröffnung für die Kommunikation mit externen
Personen.
2_63_Fachkonzept De-Mail 1.0.docx



Seite 6 von 57
Ermittlung von möglichen Einsatzszenarien für die De-Mail bei der
Landeshauptstadt München
Schaffung einer zentralen Infrastrukturkomponente für die sichere
Entgegennahme und den Versand von De-Mails
Nachhaltige Integration der De-Mail bei der Landeshauptstadt München
Schaffung eines zentralen, stadtweiten Dienstes sowie der organisatorischen
Strukturen zur nachhaltigen und stabilen Bereitstellung der De-Mail für die
Kommunikation mit der Stadtverwaltung München.
Kontext
Keine
Varianten
Die Umsetzung der Anforderungen wurde in mehrere Ausbaustufen unterteilt.
Zudem wurden Alternativen für die technische Bereitstellung in dem
vorliegenden Fachkonzept beschrieben. Aufgrund der Komplexität und des
Gesamtumfangs wurde daher während der Konzepterstellung auf die
Beschreibung von Varianten verzichtet.
Empfohlene
Variante
Effekt +
Mit der Einführung der De-Mail wird eine deutlich einfachere Möglichkeit
geschaffen, rechtsverbindlich mit der Stadtverwaltung zu kommunizieren, da der Nutzen
Bürger beispielsweise keine qualifizierte elektronische Signatur mehr benötigt.
Zudem wird die Stadtverwaltung in die Lage versetzt, Bescheide und
Dokumente in digitaler Form an die jeweiligen Empfänger zuzustellen und damit
Verwaltungsverfahren zu beschleunigen und Medienbrüche zu reduzieren.
Die Umsetzung, die technische Bereitstellung sowie die Bekanntgabe der
elektronischen Zugangseröffnung für De-Mail müssen bis zum 1.1.2015
abgeschlossen sein, damit Verwaltungsverfahren - wie die elektronische
Kraftfahrzeug-Außerbetriebsetzung im Rahmen der rechtlichen Erfordernisse ausgeführt werden können.





Rundschreiben an alle Führungskräfte in den Referaten und
Eigenbetrieben
Interne Kommunikation über die Zugangseröffnung mit anschließender
Kommunikation nach Extern
Überführung von Fachverfahren auf die De-Mail
Ab Mitte 2015: Volumenvertrag mit einem ausgesuchten De-MailDiensteanbieter
Sommer 2015: Umstieg auf den E-Mail-Client Kontact von Kolab
Entscheidung
Nächste
Schritte
2_63_Fachkonzept De-Mail 1.0.docx
Seite 7 von 57
Geplante Umsetzungsstufen
Stufe
Umsetzungsbestandteil
Resultat/
Aktion
Stufe 1
(bis Ende
2014)
Bereitstellung der Infrastruktur und Schaffung der
Voraussetzungen zum Empfangen und Versenden von
De-Mails
Infrastruktur und
Funktionalität
Stufe 2
(bis Anfang
2015)
Elektronische Zugangseröffnung für De-Mail
Empfangen
Empfangen von De-Mails im Rahmen der digitalen
Poststelle
Empfangen
Erste Anbindung/Tests mit Fachverfahren
Versenden
Integration von weiteren Fachverfahren
Empfangen/
Versenden
Stufe 3
(Anfang
2015)
Stufe 4 (Ab Anfragen und Mitteilungen im Rahmen von
in
Verwaltungsverfahren empfangen und beantworten
Krafttreten
des
BayEGovG)
Tabelle 1 Umsetzungsstufen
Empfangen/
Beantworten
2_63_Fachkonzept De-Mail 1.0.docx
Seite 8 von 57
3 Stakeholder
ID
Stakeholder
Ansprechpartner Funktion/ Betroffenheit
SH10 Leitungsebene
SH11 D-III-L
Peter
Onderscheka
Leitung STRAC GB I,
(Sicherheitsbeauftragter)
SH12 eoGov
Wolfgang Glock
Gesamtprojektleiter eoGov, IT-Strategie
SH12 it@M
Roland Werner
IT-Architekt
SH13 D-R
Dr. Erhard
Glaser
Rechtsexperte
SH14 GRP
Stefan Sass
Der Gesamtpersonalrat muss bei einer
geplanten Verarbeitung
personenbezogener Daten bzw. von
Daten, die Rückschlüsse auf Personen
zulassen, konsultiert und hinzugezogen
werden.
SH15 D-R
Dr. Erhard
Glaser
Der Datenschutzbeauftragte muss bei
einer geplanten Verarbeitung
personenbezogener Daten bzw. von
Daten, die Rückschlüsse auf Personen
zulassen, konsultiert und hinzugezogen
werden.
SH16 D-III-L
Peter
Onderscheka
Der Sicherheitsbeauftragte ist an der
Einhaltung der Sicherheitsrichtlinien
interessiert.
SH20 Externe Personen
SH21 Bürger
Haben ein Interesse an funktionierenden
eGovernment-Prozessen und möchten
rechtsverbindlich mit der LHM
kommunizieren. Reduzierung der Wegeund Wartezeiten.
SH22 Behörden
Zustellung und Empfang von
rechtsverbindlichen Schreiben, ggf. auch
mit Empfangsbestätigung. Reduzierung
der Wege- und Wartezeiten.
SH23 Unternehmen/
Organisationen
Zustellung und Empfang von
rechtsverbindlichen Schreiben, ggf. auch
mit Empfangsbestätigung. Reduzierung
der Wege- und Wartezeiten.
2_63_Fachkonzept De-Mail 1.0.docx
ID
Stakeholder
Seite 9 von 57
Ansprechpartner Funktion/ Betroffenheit
SH24 Wachunternehmen
Erhalten Bescheide für das
Wachpersonal durch das
Bewachungswesen (KVR)
SH30 Referate
SH31 DIR, ZTS
Christian Singer, ZTS. Voraussichtlich Entgegennahme
Andrea
und Beantwortung von De-Mails
Schmidmeir
(rechtsverbindliche Kommunikation) im
Rahmen der DPS.
SH32 KOM
Hans Haberkorn Interesse besteht, ein konkretes
Einsatzgebiet konnte noch nicht benannt
werden.
SH32 KVR
Albert Demmel,
Uwe Möller
De-Mail-Pilotierung und Übermittlung von
Bescheiden, ggf. mit förmlicher
Zustellung.
SH33 KVR
Kurt Peichl
Übermittlung von Bescheiden im
Rahmen des iKFZ-Verfahren ab
01.01.2015.
SH33 PLAN
Andreas Harpf
Übermittlung von Bescheiden, ggf. mit
förmlicher Zustellung. De-Mail-Konten
sollten für fast alle Hauptabteilungen
angelegt werden.
SH34 RAW
Sabine Quanz
Übermittlung von Bescheiden, ggf. mit
förmlicher Zustellung.
SH35 SOZ
Ute Walter-Maas Übermittlung der ausgefüllten Formulare
zur Wohnungsfreimeldung via De-Mail1.
Dies würde eine medienbruchfreie
Übertragung in das Fachverfahren
ermöglichen.
SH40 Technische Bereitstellung
SH41 DMDA
T-Systems /
Mentana
Claimsoft
Akkreditierter De-Mail-Diensteanbieter
stellt De-Mail-Dienste bereit.
SH42 De-Mail-Gateway
Anbieter
Zertificon
Stellt Hard- und/oder
Softwarekomponenten für die
Kommunikation mit dem DMDA und die
interne Handhabung von Nachrichten bei
der LHM bereit.
SH43 ITM-I31
Florian Baier,
Christian Binder
Integration und Konfiguration von DeMail-Gateway und Einbindung in bereits
bestehende E-Mail-Infrastrukturen
1
Setzt das BayEGoVG voraus, da die Wohnungsfreimeldung gemäß BayVwVvG die Schriftform erfordert.
2_63_Fachkonzept De-Mail 1.0.docx
ID
Stakeholder
Seite 10 von 57
Ansprechpartner Funktion/ Betroffenheit
SH44 it@M/MigMaK
Dr. Stefanie
Lämmle
IT-Architektin - stellt im Projekt MigMaK
den Kolab E-Mail-Client bereit.
SH45 it@M/MigMaK
Richard Seif
Middleware EAI–Web-Services - stellt im
Projekt MigMaK den Kolab E-Mail-Client
bereit.
Tabelle 2 Stakeholder und die jeweiligen De-Mail-Einsatzmöglichkeiten
4 Rahmenbedingungen und Einflussfaktoren
Die Einführung der De-Mail bei der Landeshauptstadt München wird durch die folgenden
Rahmenbedingungen und Einflussfaktoren begleitet:
Fehlende Akzeptanz: Bei der Einführung von De-Mail wurde Kritik seitens der Medien hinsichtlich
der umständlichen Einrichtung und den anfallenden Kosten (insbesondere im Vergleich zur
klassischen E-Mail) gegenüber dem Verfahren De-Mail ausgeübt. Daher wird De-Mail bei den
Bürgerinnen und Bürgern, aber auch bei den Mitarbeiterinnen und Mitarbeitern der LHM wenig
akzeptiert. Teilweise ist die negative Grundhaltung gegenüber De-Mail aber auch durch mangelnde
und unrichtige Informationen begründet. Des Weiteren wird De-Mail auch mit dem E-Postbrief und
„E-Mail made in Germany“ verwechselt. Es ist den Bürgern teilweise nur schwer vermittelbar,
warum sie sich für eine „einfache E-Mail-Adresse“ ausweisen müssen und ihnen Kosten für den
Versand entstehen. Die Vorteile eines rechtsverbindlichen digitalen Dokumentenversandes sind
daher nicht präsent und müssen den Kommunikationspartnern kontinuierlich vermittelt werden.
Bestehende und zukünftige Kanäle: Derzeit gibt bei der Landeshauptstadt München
verschiedene Kanäle für die Kommunikation zwischen Verwaltung, Bürger und Institutionen. Hierzu
gehören die rechtsverbindlichen Kanäle, wie Briefpost und Fax, welche auch das
Schriftformerfordernis erfüllen. Zusätzlich werden Kommunikationskanäle wie die E- in Verbindung
mit der qualifizieren elektronischen Signatur (qeS) angeboten und in Verwaltungsakten genutzt. Mit
einzelnen Partnern und externen Dienststellen ist bereits die gesicherte Kommunikation via
S/MIME und dem Behördennetz möglich. Zukünftig soll die Nutzung der verschlüsselten
Kommunikation ausgeweitet werden. Speziell bei Fachverfahren, die keine rechtsverbindliche
Kommunikation, sondern nur eine verschlüsselte und datenschutzkonforme Datenübertragung
benötigen, besteht teilweise kein Erfordernis für den Einsatz der De-Mail.
Fehlende rechtliche Vorgaben: Durch das Fehlen eines Bayrischen E-Government-Gesetzes,
wurden die rechtlichen Rahmenbedingungen noch nicht geschaffen, die eine weitreichende
Nutzung der De-Mail bei Verwaltungsakten ermöglichen würden. Hierzu gehören auch die
gesetzlichen Änderungen zur Erfüllung des Schriftformerfordernisses beim Einsatz der De-Mail in
zahlreichen Gesetzestexten. Zwar ist es heute schon möglich, Verwaltungsakte bekanntzugeben
oder belastende Bescheide mit De-Mail zu verschicken, eine Entgegennahme von Anträgen aber
noch nicht.
Technische Unzulänglichkeiten: Die De-Mail wurde in ihrer Entstehungsphase durch das BSI in
technischen Richtlinien (TR) spezifiziert. Aus diesen geht hervor, welche Funktionalitäten die DeMail-Diensteanbieter unterstützen müssen. Im Rahmen von Gesprächen mit Anbietern und
Nutzern wurde allerdings bekannt, dass die Anbieter noch nicht vollumfänglich den
2_63_Fachkonzept De-Mail 1.0.docx
Seite 11 von 57
standardmäßigen Funktionsumfang unterstützen und es daher zu technischen
Unzulänglichkeiten/Einschränkungen im Bereich der Funktionalität und Zuverlässigkeit kommen
kann (Stand Mitte 2014).
Zudem sind Funktionalitäten beschrieben, welche nicht zum standardmäßigen Funktionsumfang
zählen, sondern optional angeboten werden.
Rechtliche Aspekte
Aspekt
Wirkungskreis
Bedeutung für die LHM
E-GovernmentGesetz2
Übergreifer,
Das EGovG führt auf Bundesebene Änderungen
Bundesaufgaben an Gesetzen durch, um E-Government-Vorgänge
in Deutschland zu ermöglichen. Die gesetzlichen
Änderungen gelten nur für die Ausführung von
Aufgaben im Namen des Bundes.
De-Mail Gesetz3
-
Gesetzliche Regelungen zur De-Mail. Erst durch
die gesetzlichen Änderungen im Rahmen des
EGovG wurde der Einsatz von De-Mail ermöglicht.
Bayrisches EGovernmentGesetz
Eigener
Geplantes Gesetz zur Regelung und Änderung
von bestehenden Gesetzen zur Ermöglichung und
Vereinfachung von E-Government-Vorgängen in
Bayern.
Bayerisches
Eigener
Verwaltungsverfahrensgesetz4
Regelt Verwaltungsvorgänge in Bayern.
Verwaltungszustellungs- und
Vollstreckungsgesetz5
Regelt die Formen der Zustellung in Bayern sowie
die dreitägige Zustellfiktion im Rahmen der DeMail (Art. 6, Abs. 4).
2
Eigener
Gesetze im Internet, „Gesetz zur Förderung der elektronischen Verwaltung (E-Government-Gesetz - EGovG)“. http://www.gesetze-im-
internet.de/egovg/BJNR274910013.html (17.09.2014)
3
Gesetze im Internet, „De-Mail-Gesetz“ (DeMailG). http://www.gesetze-im-internet.de/de-mail-g/BJNR066610011.html (17.09.2014)
4
Bayern-Recht, „Bayerisches Verwaltungsverfahrensgesetz (BayVwVfG)“. http://www.gesetze-
bayern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1&st=null&doc.id=jlr-VwVfGBYrahmen&doc.part=X&doc.origin=bs
(17.09.2014)
5
Bayern-Recht, „Bayerisches Verwaltungszustellungs- und Vollstreckungsgesetz (VwZVG)“. http://www.gesetze-
bayern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1&doc.id=jlr-VwZVGBYrahmen&doc.part=X (17.09.2014)
2_63_Fachkonzept De-Mail 1.0.docx
Aspekt
Empfangsbekenntnis durch
Abholbestätigung
(VwZVG, Art 6,
Abs. 1, 2. Satz)
Seite 12 von 57
Wirkungskreis
Eigener
Bedeutung für die LHM
Für die Zustellung von De-Mails nach Satz 1 sind
Art. 5 Abs. 4 und 6 mit der Maßgabe anzuwenden,
dass an die Stelle des Empfangsbekenntnisses
die Abholbestätigung tritt. De-Mails sind für den
entsprechenden Zustellungsnachweis
(Beweiskraft) daher jeweils mit der Versandoption
„Abholbestätigung“ zu versenden. Wenn keine
besondere Beweiskraft bei der Zustellung von
Bescheiden im Rahmen einer Bekanntgabe von
Verwaltungsakten notwendig ist, kann der Versand
auch ohne die Versandoption „Abholbestätigung“
erfolgen. Gegebenenfalls ist hierfür eine
entsprechende Regelung in der AGAM zu treffen.
Elektronische
LHM
Zugangseröffnung
Die auf der Webseite der LHM bekanntgebende
elektronische Zugangseröffnung legt fest, in
welchem Umfang und in welcher Art elektronische
Kommunikation mit der LHM möglich ist.
Allgemeine
LHM
Geschäftsanweisung der
Landeshauptstadt
München6
Regelt die allgemeine Handhabung von
Vorgängen und Verhaltensweisen innerhalb der
Stadtverwaltung der LHM. Die AGAM ist zum
heutigen Zeitpunkt noch nicht auf das Thema DeMail vorbereitet.
Dienstanweisung
Regelung zum Umgang mit einzelnen Vorgängen
innerhalb der Stadtverwaltung. Derzeit liegen noch
keine Dienstanweisungen für den Umgang mit DeMail vor.
Fachdienststelle
Tabelle 3 Rechtliche Aspekte im Rahmen von De-Mail
5 Ausgangslage
Papierbasierte Prozesse: Durch die Einhaltung der derzeit bestehenden Dienstanweisung zum
datenschutzkonformen Versand von vertraulichen und personenbezogenen Informationen, dürfen
keine unverschlüsselten Kommunikationskanäle bei der Übermittlung von personenbezogenen
Daten genutzt werden. Die Verwaltungsakte und belastende Bescheide werden daher in der
Papierform bekanntgegeben beziehungsweise zugestellt. Zudem ist nur bei der Nutzung der
papierbasierten Form die notwendige Rechtsverbindlichkeit gegeben. Die digitale Bekanntgabe
von Verwaltungsakten oder der Austausch von personenbezogenen und vertraulichen Daten findet
derzeit nur in Ausnahmefällen und mit wiederkehrenden Kommunikationspartnern über
entsprechend gesicherte Verbindungen (S/MIME, DOI Netz) und entsprechender Verschlüsselung
statt.
Siehe auch Ziffer 4 Rahmenbedingungen und Einflussfaktoren. Ausschnitt aus dem
fachlichen Bebauungsplan
6
Landeshauptstadt München, „Allgemeine Geschäftsanweisung der Landeshauptstadt München“.
http://intranet.muenchen.de/basis/vor/allg/agam.pdf (17.09.2014)
2_63_Fachkonzept De-Mail 1.0.docx
Seite 13 von 57
Systemkontext De-Mail innerhalb der Landeshauptstadt München.
Abbildung 1: Systemkontext De-Mail bei der Landeshauptstadt München
6 Fachliche Ziele
Es sollen die folgenden Ziele erreicht werden:
Ziel-ID Zielbeschreibung
Verbindlichkeit
1.1
De-Mails sind durch eine zentrale Soft- oder
Muss
Hardwarekomponente beim De-Mail-Diensteanbieter abzuholen
und zu übermitteln (sogenanntes De-Mail-Gateway), da eine
stadtweite Nutzung einer De-Mail-Weboberfläche organisatorisch
nicht handhabbar ist (Anmeldung per Personalausweis mit
Online-Ausweisfunktion oder MobileTAN).
1.2
De-Mail-Versandoptionen können beim Versand frei miteinander
kombiniert werden.
Muss
1.3
Dem Anwender soll eine möglichst einfache und
benutzerfreundliche Lösung zur Nutzung der De-Mail
bereitgestellt werden, um eine hohe interne Akzeptanz zu
erreichen.
Muss
1.4
Statt zusätzlicher De-Mail-Funktionspostfächer sollen die bereits
bekannten und vorhandenen Funktionspostfächer für das
Empfangen und Versenden von De-Mails verwendet werden.
Hierzu sollten diese auf Anfrage bei dem IT-Dienstleister
freigeschaltet werden.
Muss
2_63_Fachkonzept De-Mail 1.0.docx
Seite 14 von 57
Ziel-ID Zielbeschreibung
Verbindlichkeit
1.5
Die Beantragung eines neuen De-Mail-Postfachs beim DMDA
sowie der internen Bereitstellung durch den technischen
Dienstleister der LHM soll binnen einer Woche erfolgen. Die
entsprechenden organisatorischen Strukturen sollen hierfür
entsprechend geschaffen werden.
Soll
1.6
Für LHM Mitarbeiter muss eine kostenfreie, interne Weiterleitung Muss
von De-Mails (als E-Mails) von einem Funktionspostfach zu einem
anderen Funktionspostfach möglich sein, damit interne
Weiterleitungen nicht über den DMDA der LHM verschickt
werden.
1.7
Der interne Austausch von De-Mails (als E-Mails) sollte nur über Soll
die Funktionspostfächer erfolgen, damit die Stellvertreterregelung
weiterhin gegeben ist. Ein De-Mail-Versand von nicht
entsprechend freigeschalteten Funktionspostfächern ist
organisatorisch zu unterbinden.
1.8
Nach der Einführung der De-Mail muss eine unbegrenzte Anzahl
von Kommunikationsverbindungen mit externen
Kommunikationspartnern möglich sein.
1.9
Interne Anwenderfehler, wie das Verschicken von De-Mails an E- Muss
Mail-Adressen oder das Verschicken von Anhängen größer als 10
MB, müssen dem Anwender in einer für ihn verständlichen Form
angezeigt werden.
1.10
Generell müssen alle von außen eingehenden De-Mails durch die Muss
LHM angenommen, in den Funktionspostfächern bereitgestellt
und entsprechend bearbeitet werden.
1.11
Anhand einer Protokollierung soll die nachvollziehbare Aufteilung
der nutzungsabhängigen Kosten ermöglicht werden.
1.12
De-Mails dürfen nur in Funktionspostfächern bereitgestellt
Muss
werden, bei denen eine entsprechende Vertreterregelung
gegeben ist. Zur Erfüllung der Vertreterregelung und unter
Berücksichtigung der Zustellfiktion (drei Tage), dürfen persönliche
Postfächer nicht für den Empfang und Versand von De-Mails
freigeschaltet werden.
1.13
Entgegennahme und Übermittlung von End-to-Site (S/MIME)
verschlüsselten De-Mails.
1.14
Weiterleitungen an externe Kommunikationspartner dürfen zum
Muss
Schutz sensibler Daten nur per De-Mail oder in verschlüsselter
Form erfolgen. Wenn keine technischen Restriktionen geschaffen
werden können, sind organisatorische Regelungen zu treffen.
1.15
Ein- und ausgehende De-Mails sowie die jeweiligen Versand- und Muss
Abholbestätigungen müssen revisionssicher und rechtsverbindlich
beim DMDA vorgehalten werden.
Muss
Soll
Kann
2_63_Fachkonzept De-Mail 1.0.docx
Seite 15 von 57
Ziel-ID Zielbeschreibung
Verbindlichkeit
1.16
Die Nutzung und der Versand von De-Mails aus
Fachanwendungen muss analog zum E-Mail-Versand möglich
sein.
Muss
1.17
Die aufzubauende technische De-Mail-Infrastruktur ist redundant
und möglichst ausfallsicher bereitzustellen, um eine möglichst
hohe Erreichbarkeit zu garantieren. Für den Fall eines
Komplettausfalls (Nichtverfügbarkeit) der LHM De-MailInfrastruktur sind entsprechende Alternativszenarien und
Notfallkonzepte bereitzustellen.
Muss
Tabelle 4 Fachliche Ziele für die Einführung der De-Mail
7 Geschäftsprozesse
7.1
Mögliche Geschäftsprozesse/Einsatzszenarien
Im Rahmen der Fachkonzepterstellung wurde das Thema De-Mail in einzelnen Referaten
vorgestellt und diskutiert. Die Vorstellung des Themas fand vor allem vor dem Hintergrund der
Identifizierung von neuen De-Mail-Einsatzszenarien statt. Innerhalb der Gespräche konnten zwei
grundsätzliche Einsatzszenarien ermittelt werden: Zustellung von (belastenden)
Bescheiden/Bekanntgabe von Verwaltungsakten sowie Entgegennahme von Anträgen. Letzteres
bedingt aber das Vorhandensein eines bayrischen E-Government-Gesetzes, wenn keine
Bundesaufgaben ausgeführt werden.
Szenario
Referat, AnsprechFachbere
partner
ich
EntgegenDIR, ZTS
nahme und
Beantwortung von
rechtsverbindlicher
Kommunikation
iKFZ
Christian
Singer,
Andrea
Schmidmeir
Beschreibung
ZTS. Voraussichtliche
Entgegennahme und
Beantwortung von De-Mails
(rechtsverbindliche
Kommunikation) im Rahmen
der DPS.
Voraussetzung
Erweiterte
Zugangseröffnung (EZ)
KVR,
Kurt Peichel Zustellung von Bescheiden
EZ und
Zulassung
über die Außerbetriebsetzung Zugangseröffvon Kraftfahrtzeugen.
nung durch den
Bürger
2_63_Fachkonzept De-Mail 1.0.docx
Seite 16 von 57
Szenario
Referat, AnsprechFachbere
partner
ich
Beschreibung
Überprüfung
von
Wachpersonal
KVR,
Uwe Möller
Bewachun
gswesen
Übermittlung von Bescheiden
(Gebot) per De-Mail bei
tauglichen Personen für den
Wachdienst an die
Wachunternehmen
EZ und
Zugangseröffnung durch den
Bürger
Wohnungsfreimeldung
SOZ, SIII-S
Ute
WaltherMaas
Übermittlung von
Wohnungsfreimeldungen
ohne den Einsatz einer qeS
EZ, bayrisches
EGovG (erfordert
Schriftformerfüllung)
Bauantrag
PLAN
Andreas
Harpf
Übermittlung von
Bauanträgen
EZ, bayrisches
EGovG (erfordert
Schriftformerfüllung)
Michael
Schneider,
Dr. Thomas
Henkel
Übermittlung von
Gewerbemeldungen und
Bescheiden im Rahmen der
Gewerbemeldung.
EZ und
Zugangseröffnung durch den
Bürger
Elektronische KVR,
GewerbeGewerbe
meldung
meldung
Voraussetzung
Tabelle 5 Mögliche De-Mail Einsatzszenarien
7.2
Prozessrollen
Identifikator Akteure
Kurzbeschreibung
Geschäftsprozess
R-1
Externe Person
Person außerhalb der LHM
GP-1
R-2
Sachbearbeiter
Person innerhalb der LHM
GP-1, GP-2
R-3
Hauptbetreuer
Person innerhalb der LHM mit Zugriff
auf das De-Mail-Funktionspostfach
und die Postfächer der digitalen
Poststelle
GP-1, GP-2
R-4
Sachbearbeiter
digitale
Poststelle
Person innerhalb der LHM mit Zugriff
auf die Postfächer der digitale
Poststelle
GP-1, GP-2
R-5
Admin
Fachlicher und technischer Mitarbeiter GP-3
im dIKA, Betrieb oder bei it@M
R-6
Externer
Partner/
Unternehmen
Wiederkehrende
GP-1, GP-2
Kommunikationspartner außerhalb der
LHM
R-7
Fachverfahren
Automatisierter/maschineller Versand
2_63_Fachkonzept De-Mail 1.0.docx
Identifikator Akteure
Seite 17 von 57
Kurzbeschreibung
von De-Mails.
Geschäftsprozess
2_63_Fachkonzept De-Mail 1.0.docx
7.3
Seite 18 von 57
Prozessbeschreibungen
GP-1: Behandlung von eingehender Kommunikation
Abbildung 2: Eingehende De-Mail Kommunikation


Anfrage via De-Mail: Eine externe Person verfasst eine De-Mail an die LHM.
Übermittlung an DMDA: Die De-Mail wird an den DMDA des Absenders übermittelt und
2_63_Fachkonzept De-Mail 1.0.docx








Seite 19 von 57
vor der transportverschlüsselten Übermittlung an den DMDA der LHM – sofern die
Versandoption „Absenderbestätigt“ verwendet wurde – mit einer qualifizierten
elektronischen Signatur (qeS) versehen.
Übermittlung an LHM DMDA
Zustellung im Catch-All Postfach: Ungeachtet des lokalen Teils der De-Mail-Adresse,
werden alle eingehenden Nachrichten im Catch-All Postfach des DMDA zugestellt.
Abholung durch De-Mail-Gateway: Die im Catch-All Postfach beim DMDA
eingegangenen De-Mails werden mittels Pull-Verfahren abgeholt. Anhand der HeaderInformationen sowie anhand der enthaltenen Versandoptionen ist die Nachricht
eindeutig als De-Mail klassifizierbar. Der „Kommunikations-Typ De-Mail“ und die
verwendeten Versandoptionen können daher entsprechend innerhalb der Nachricht
kenntlich gemacht werden (vgl. Ziffer 10.1 Benutzeroberfläche)).
Übermittlung an E-Mail-Infrastruktur: Nach der Abholung der De-Mails durch das DeMail-Gateway, erfolgt die Verarbeitung des lokalen Teil der De-Mail-Adresse und die
Verteilung der Nachrichten als E-Mails an Postfächer der internen E-Mail-Infrastruktur.
Im Rahmen der Übermittlung sollte auch eine Virenprüfung stattfinden.
Bereitstellung im Funktionspostfach: Die De-Mail wird als reguläre E-Mail in dem
jeweiligen Funktionspostfach bereitgestellt. Anhand der enthaltenen HeaderInformationen (siehe Abholung durch De-Mail Gateway), können die De-Mails als solche
entsprechend hervorgehoben werden.
<Entscheidung> Bearbeitung möglich/Zuständigkeit gegeben: Überprüfung durch
den Sachbearbeiter, ob eine Bearbeitung der Nachricht möglich oder eine
entsprechende Zuständigkeit gegeben ist. Hier gibt es zwei Optionen:
1. Bearbeitung möglich/Zuständigkeit gegeben: Die Anfrage wird
bearbeitet/beantwortet (Prozess endet in dieser Prozessdarstellung)
2. Bearbeitung nicht möglich/Zuständigkeit nicht gegeben: Die Anfrage kann
nicht bearbeitet werden oder die entsprechende Zuständigkeit ist nicht gegeben.
Ist eine Bearbeitung nicht möglich oder keine Zuständigkeit gegeben,muss folgende
Entscheidung getroffen werden:
 <Entscheidung> Weiterleitung: Weiterleitung der Anfrage zur weiteren
Bearbeitung. Zudem erfolgt die Entscheidung, ob eine interne oder externe
Weiterleitung erfolgen soll. Hier gibt es verschiedene Weiterleitungsoptionen:
1. Interne Weiterleitung: Die Anfrage wird stadtintern zur weiteren Bearbeitung an
ein anderes Funktionspostfach weitergeleitet und es findet eine Bereitstellung
im Funktionspostfach statt. Anschließend folgen die nachfolgenden
Prozessschritte, wie beschrieben.
2. Externe Weiterleitung: Übermittlung an einen externen Kommunikationspartner.
Es sind durch den Sachbearbeiter die organisatorischen Regelungen im Umgang
mit personenbezogenen und vertraulichen Daten zu beachten. Es ist eine
Weiterleitung per De-Mail oder verschlüsselter E-Mail zu bevorzugen.
o Wenn 2:Übermittlung an E-Mail-Infrastruktur: Übermittlung der Nachricht an
die interne E-Mail-Infrastruktur.
o <Entscheidung> Versandart: Anhand der Empfängeradresse(n) und der
Funktionspostfachfreischaltung wird über die Versandart auf dem
Verschlüsselungs-Gateway entscheiden. Hier bestehen zwei Optionen:
1. Unverschlüsselte E-Mail: Funktionspostfach ist nur für den regulären E-MailVersand freigeschaltet. Personenbezogene und/oder vertrauliche Informationen
werden unverschlüsselt übertragen.
2. De-Mail: Wurde ein User-Command im Betreff und/oder eine De-Mail-Adresse
im Empfängerfeld eingetragen, findet eine Übermittlung an das De-Mail-Gateway
2_63_Fachkonzept De-Mail 1.0.docx
Seite 20 von 57
statt. Wurde das versendende Funktionspostfach nicht für den De-Mail-Versand
freigeschaltet, findet kein De-Mail-Versand statt. In dem Fall erhält der Absender
eine Fehlermeldung.
GP-2: Behandlung von ausgehender Kommunikation
Abbildung 3: Ausgehende Kommunikation
Da der De-Mail-Versand aus dem gleichen Funktionspostfach erfolgt, aus dem auch der Versand
von regulären E-Mails und verschlüsselten E-Mails erfolgt, werden diese Kommunikationsarten
aufgrund der vielen Überschneidungen auch in dem nachfolgenden GP-2 entsprechend
berücksichtigt:


Nachricht im Postfach verfassen: Erstellen/Weiterleiten einer Nachricht, Hinzufügen der
Empfängeradresse sowie von Schlagwörtern/Kennzeichnungen (Versandoptionen,
Kommunikationstyp).
<Entscheidung> Empfängeradresse: Anhand der Adresse des Empfängers wird der
2_63_Fachkonzept De-Mail 1.0.docx
Seite 21 von 57
weitere Versandweg entschieden. Hier bestehen zwei Optionen:
1. E-Mail-Adresse: Nachricht oder Weiterleitung an ein internes Funktionspostfach oder an
einen externen Empfänger. Nur innerhalb des Stadtnetzes ist die Kommunikation
entsprechend gesichert (Prozessende in der Prozessdarstellung).
2. De-Mail-Adresse enthalten: Wurde eine De-Mail-Adresse als Empfänger eingetragen,
findet eine Weiterverarbeitung durch das De-Mail-Gateway statt.
 Ist eine De-Mail Adresse enthalten muss geprüft werden, ob das Funktionspostfach für DeMail aktiviert wurde. <Entscheidung> Postfach für De-Mail aktiviert: Hier bestehen zwei
Optionen:
1. ist für das Funktionspostfach aktiviert. De-Mail-Versand ist für Funktionspostfach
aktiviert
2. De-Mail Versand ist nicht für Postfach aktiviert.
 Wenn 1.: <Entscheidung> Adressierung: Prüfung, ob im Empfängerfeld E-Mail- und DeMail-Adressen verwendet wurden.
 Wenn Mischadressierung (es wurden E-Mail- und De-Mail-Adressen im Empfängerfeld
verwendet) dann Ablehnung der Nachricht mit Fehlermeldung. Hier muss eine
organisatorische Regelung getroffen werden, wenn der Umgang mit einer
Mischadressierung nicht technisch lösbar ist.
 Wenn Einheitliche Adressierung(es wurden nur De-Mail-Adressen in der Nachricht
verwendet) Anschließend Übermittlung an den DMDA: Die Nachricht wird in eine De-Mail
umgewandelt und an den DMDA der LHM übermittelt.
 Wenn 2.: Fehlermeldung an den Absender
2_63_Fachkonzept De-Mail 1.0.docx
Seite 22 von 57
GP-3: De-Mail-Freischaltung beantragen (DMAA)
Abbildung 4: Sequenz; Freischaltung für den De-Mail-Versand
1.
2.
3.
4.
5.
Sachbearbeiter: Fragt Freischaltung beim Vorgesetzten/Hauptbetreuer des
Funktionspostfachs an.
Hauptbetreuer: Vorgesetzter erteilt Freigabe und beantragt die Freischaltung beim jeweiligen
Dienstleister. Eventuell ist ein Business Requirement oder ein entsprechendes Formular im
Rahmen des DMAA (siehe 10.3 , Abs. 2) zu übermitteln.
Admin: Legt Verknüpfung zwischen der Postfachadresse und der De-Mail-Adresse auf dem
De-Mail-Gateway (DMGW) an
Admin: Rückmeldung an den Vorgesetzten/Hauptbetreuer des Funktionspostfachs
Hauptbetreuer: Rückmeldung an den Sachbearbeiter
GP-4: De-Mail-Versand aus Fachverfahren
Der nachfolgend aufgezeigte Geschäftsprozess stellt eine mögliche Integration/Anbindung an ein
Fachverfahren dar. Es wird dabei auch die Behandlung von Rückantworten und
Zustellbestätigungen berücksichtigt.
Abbildung 5: Sequenz; Versand von De-Mails aus einem Fachverfahren
1.
Funktionspostfach: Versenden einer E-Mail via SMTP inklusive der benötigten
Versandoptionen, einer Private-ID (optional) sowie der Anlagen.
2_63_Fachkonzept De-Mail 1.0.docx
2.
3.
4.
5.
6.
7.
7.4
Seite 23 von 57
E-Mail-Infrastruktur: Routing der Nachricht an das De-Mail-Gateway (DMGW).
DMGW: Über das De-Mail-Gateway findet die transportverschlüsselte (SSL/TLS) Übermittlung
an den DMDA statt.
DMGW: Turnusmäßig erfolgt ein Abruf der Postfächer beim DMDA. Vorliegende De-Mails
werden durch das De-Mail-Gateway abgerufen.
DMGW: Abgerufene De-Mails werden an die E-Mail-Infrastruktur geroutet.
E-Mail-Infrastruktur (EMI): Die EMI stellt die Nachricht im zugeordneten Funktionspostfach
bereit.
Funktionspostfach: Bereitgestellte Nachrichten können manuell geprüft/bearbeitet oder
automatisiert in das Fachverfahren (sofern durch das Fachverfahren möglich) eingelesen
werden. Hierfür könnte auch die Private-ID in einer späteren Ausbaustufe zum Einsatz
kommen.
Mengengerüst
Durch die noch geringe7 Verbreitung der De-Mail bei Bürgern, Verbänden, Institutionen und der
Wirtschaft ist in der Anfangsphase nur mit einem geringen Volumen zu rechnen. Es ist davon
auszugehen, dass ein Großteil des De-Mail-Volumens auf die Interbehördenkommunikation und
auf die Kommunikation mit wiederkehrenden Kommunikationspartnern entfallen wird.
Ein weiterer Anteil wird auf die ausgehende Kommunikation in Form von Bescheiden entfallen. Von
der Bürgerseite ist nur vereinzelt mit Anfragen per De-Mail zu rechnen. Nach der Startphase wird
mit einem Gesamtvolumen beim ein- und ausgehenden Versand von 2.000 De-Mails pro Tag
gerechnet.
Nach der De-Mail-Anlaufphase, ab Mitte 2015, sollte auf der Basis einer rückwirkenden
Versandvolumenbetrachtung ein Kostenschlüssel festgelegt werden oder eine
verbrauchsabhängige Abrechnung zwischen den Referaten erfolgen. Die Kostenverteilung könnte
dabei monatsweise auf der Grundlage der Rechnungsstellung des DMDA oder den
Abrechnungsdaten aus der Gateway-Komponente (siehe Ziffer 10.2.1, Abs. 13) erfolgen.
8 Anwendungsfälle
Folgende Grafik gibt einen Überblick über die Anwendungsfälle:
7
Abgerufen unter www.computerwoche.de, "E-Government - die Ansprüche steigen", 19.05.2014. http://www.computerwoche.de/a/e-
government-die-ansprueche-steigen,3061429,2 (20.05.2014)
2_63_Fachkonzept De-Mail 1.0.docx
Seite 24 von 57
Abbildung 6 : Überblick De-Mail Anwendungsfälle
8.1
Anwendungsfall-Liste
Identifikator Name
Kurzbeschreibung
UC-1-1
Sendet De-Mail an LHM
Senden von De-Mails von extern
UC-1-2
Empfängt De-Mail von der LHM
Empfangen von De-Mails der LHM
UC-1-3
Eröffnet Zugang
Zugangseröffnung durch den Bürger
2_63_Fachkonzept De-Mail 1.0.docx
Seite 25 von 57
Identifikator Name
Kurzbeschreibung
und juristische Personen
UC-1-4
Verwendet nicht bekannte De-MailAdresse (Zustellung im Catch-AllPostfach beim DMDA)
Absender verschreibt sich beim
Eintippen der De-Mail-Adresse oder
verwendet eine nicht vorhandene
Adresse.
UC-1-5
Eingetroffene De-Mail an VPS
Mitarbeiter zuteilen.
Der VPS Leiter/Vertreter prüft, ob es
sich um eine Bürgeranfrage handelt
und ob die Anfrage durch die
Mitarbeiter der VPS beantwortet
werden können. Es findet hierbei eine
Vorsortierung statt.
UC-1-6
Bearbeitung der zugeteilten De-Mail Bearbeitung und später auch
Beantwortung von De-Mails
UC-1-7
Antworten auf De-Mail
Antworten auf eine De-Mail
UC-1-8
Interne Weiterleitung
Interne Weiterentwicklung einer
Nachricht an ein anderes
Funktionspostfach
UC-1-9
Externe Weiterleitung
Weiterleiten einer Nachricht als DeMail an einen externen Komm.Partner
UC-1-10
De-Mail-Freischaltung
Beantragen einer neuen De-MailAdresse inkl. der Zuordnung zu
einem Funktionspostfach beim ITDienstleister (dIKA, IT@M)
UC-1-11
Versand De-Mail
Versenden einer De-Mail aus einem
Funktionspostfach heraus
UC-1-12
De-Mails abholen
De-Mails beim DMDA abholen
UC-1-13
De-Mails übermitteln
De-Mails an den DMDA übermitteln
UC-1-14
Versand ablehnen
Versand bei Mischadressierung und
fehlender Freischaltung ggf.
ablehnen.
Tabelle 6 Liste der De-Mail Anwendungsfälle
8.2
Akteur-Liste
Identifikator Akteure
Kurzbeschreibung
Use Cases
A-1
Person außerhalb der LHM (Bürger,
Organisation, Behörde).
UC-1-1,
UC-1-2,
Externe Person
2_63_Fachkonzept De-Mail 1.0.docx
Identifikator Akteure
Seite 26 von 57
Kurzbeschreibung
Use Cases
UC-1-3,
UC-1-4,
(UC-1-7)
A-2
Sachbearbeiter
Person innerhalb der LHM.
UC-1-7,
UC-1-8,
UC-1-9,
UC-10
UC-1-11
A-3
Hauptbetreuer
(DPS)
Person innerhalb der LHM mit Zugriff auf
das De-Mail-Funktionspostfach und die
Postfächer der digitale Poststelle. Diese
Person ist vertretungsberechtigt und kann
daher auch Sachbearbeiter der DPS
vertreten.
UC-1-5,
(UC-1-6),
UC-1-8,
UC-1-9,
UC-1-10
UC-1-11
A-4
Sachbearbeiter
digitale
Poststelle
Person innerhalb der LHM mit Zugriff auf die UC-1-6,
Postfächer der digitalen Poststelle.
UC-1-7,
UC-1-8,
UC-1-9,
UC-1-11
A-5
Fachverfahren
Elektronisches System/Software mit der
Möglichkeit, Informationen an bekannte
Empfänger per E-Mail/De-Mail zu
versenden.
UC-1-11
A-6
De-MailGateway
Abholung und Übergabe von De-Mails an
den DMDA.
UC-1-12,
UC-1-13,
UC-1-14
A-7
Admin
Fachliche und technische Administration der UC-1-11
De-Mail-Bereitstellung.
Tabelle 7 Akteure im Umfeld von De-Mail
8.3
Beschreibung der Anwendungsfälle
 Sendet
De-Mail an LHM (UC-1-1): Eine natürliche oder juristische Person außerhalb der LHM
stellt eine Anfrage oder übermittelt Informationen oder Dokumente an die LHM. Hierdurch erfolgt,
sofern nicht anders durch den Absender festgelegt, eine Zugangseröffnung. Die LHM erhält damit
die Möglichkeit die Anfrage per De-Mail zu beantworten.
 Empfängt
De-Mail von der LHM (UC-1-2): Eine natürliche oder juristische Person außerhalb der
LHM empfängt eine De-Mail von der LHM. Dieser Anwendungsfall setzt das Vorhandensein einer
fallbezogenen oder globalen Zugangseröffnung durch die natürliche oder juristische Person
voraus.
2_63_Fachkonzept De-Mail 1.0.docx
Seite 27 von 57
 Eröffnet
Zugang (UC-1-3): Innerhalb dieses Anwendungsfalls gibt eine natürliche oder
juristische Person der LHM ihre De-Mail-Adresse bekannt und eröffnet (z.B. durch das Senden
einer De-Mail oder das Bekanntgeben der De-Mail-Adresse auf der Firmen-Website), wenn nicht
weiter durch den Absender spezifiziert, eine einzelfallspezifische Zugangseröffnung. Bei
juristischen Personen erfolgt durch die Bekanntgabe ihrer Adresse eine globale Zugangseröffnung.
 Verwendet
nicht bekannte De-Mail-Adresse (UC-1-4): In diesem Anwendungsfall vertippt sich
der Absender bei der Eingabe oder verwendet eine nicht vorhandene De-Mail-Adresse. Vertippt
sich der Absender lediglich bei dem Postfachnamen und nicht bei der De-Mail-Domain, wird die
De-Mail trotz des Schreibfehlers beim DMDA angenommen und in dem Catch-All-Postfach der
LHM bereitgestellt und gilt somit rechtlich als zugegangen. Durch das De-Mail-Gateway wird diese
Nachricht ebenfalls abgerufen, in dem dafür vorgesehenen internen Postfach bereitgestellt und
durch die für das interne Catch-All-Postfach zuständigen Mitarbeiter entsprechend intern
zugeleitet.
 Eingetroffene
De-Mail an VPS Mitarbeiter zuteilen (UC-1-5): Bei diesem Anwendungsfall
liegen die De-Mails bereits in dem dafür vorgesehenen Postfach vor. Hier wird die De-Mail nach
der inhaltlichen Sichtung entweder an eine externe Stelle, ein Referat oder an einen Mitarbeiter
der VPS zur Bearbeitung zugeteilt.
 Bearbeitung
zugeteilte De-Mail (UC-1-6): In diesem Anwendungsfall werden die Anfragen der
Bürgerinnen und Bürger durch VPS Mitarbeiter bearbeitet.
 Antworten
auf De-Mail (UC-1-7): Die Beantwortung einer De-Mail erfolgt nach dem gleichen
Prinzip wie die Beantwortung einer E-Mail. Je nach DA werden vor dem Versenden die
entsprechenden De-Mail-Versandoptionen gesetzt. Für die Beantwortung müssen auch die
rechtlichen Rahmenbedingungen (siehe BY VwZVG) beachtet werden.
 Interne
Weiterleitung (UC-1-8): Beim Anwendungsfall der internen Weiterleitung wird die als DeMail eingegangene Nachricht, an ein anderes Funktions- oder persönliches Postfach zur direkten
Bearbeitung oder Kenntnis weitergeleitet. Bei diesem Vorgang darf die Nachricht nicht die
Infrastruktur der LHM verlassen, da die Informationen ungeschützt übermittelt würden.
 Externe
Weiterleitung (UC-1-9): Beim Anwendungsfall der externen Weiterleitung wird die per
De-Mail eingegangene Nachricht an eine andere externe Stelle zur Bearbeitung oder Kenntnis
weitergeleitet. Da die Nachricht bei diesem Vorgang die Infrastruktur der LHM verlässt, müssen die
organisatorischen Maßnahmen und Dienstanweisungen beachtet werden.
 Versenden
De-Mail (UC-1-10): Bei diesem Anwendungsfall kann sowohl ein manueller als auch
ein automatisierter De-Mail-Versand erfolgen. Dieser Anwendungsfall ist vom Ablauf vergleichbar
mit dem Fall „Antworten auf De-Mail“, erfolgt aber nicht als Antwort auf eine De-Mail, sondern ist
selbst initiiert. Dieser Anwendungsfall setzt speziell bei der Kommunikation eine entsprechende
Zugangseröffnung voraus, damit ein selbst initiierter Versand an externe Kommunikationspartner
erfolgen darf (Beispiel: i-Kfz, online Abmeldung von Kraftfahrzeugen ab 1.1.2015). Die Vorgaben
der AGAM sowie des BY VwZVG, Abs. 6 sollten bei dem Versand beachtet werden.
 De-Mail-Freischaltung
beantragen (UC-1-11): Bei diesem Anwendungsfall beantragt eine
berechtigte Person bei dem technischen Dienstleiter der LHM eine De-Mail-Adresse (DMAA) und
lässt diese mit einem vorhandenen Funktionspost verbinden. Der De-Mail-Postfachname ist damit
identisch mit dem Namen des Funktionspostfachs. Der interne Freigabeprozess zur
2_63_Fachkonzept De-Mail 1.0.docx
Seite 28 von 57
Kostenfreigabe ist nicht Teil des DMAA und muss gesondert organisatorisch geklärt werden (vgl.
Ziffer 7.3 Prozessbeschreibungen, GP-3 ).
 De-Mails
abholen (UC-1-12): In diesem Anwendungsfall werden die beim DMDA vorliegenden
De-Mails durch das De-Mail-Gateway zentral für alle Anwender der LHM abgeholt und gemäß der
Zuordnung in den vorgesehenen Postfächern bereitgestellt. Innerhalb des Anwendungsfalls erfolgt
auch eine entsprechende Berücksichtigung der verwendeten Versandoptionen. So werden die vom
Absender verwendeten Versandoptionen und der Kommunikationstyp „De-Mail“ in Form von
Schlüsselwörtern im Betreff oder in Form von X-Header-Angaben in die bereitzustellende E-Mail
übertragen.
 De-Mails
übermitteln (UC-1-13): In diesem Anwendungsfall nimmt das De-Mail-Gateway die für
den Versand vorgesehenen Nachrichten von der internen LHM E-Mail-Infrastruktur entgegen,
übersetzt sie in Form von Schlüsselwörtern im Betreff oder in X-Header-Angaben enthaltenen
Versandoptionen in die De-Mail und überträgt die Nachrichten an den DMDA. Für diesen
Anwendungsfall muss sichergestellt sein oder werden, dass es sich bei der oder den
Empfängeradressen um De-Mail-Adressen handelt, keine Mischadressierung vorliegt und die
Nachricht nicht größer als 10 MB ist.
 Versand
ablehnen (UC-14): Wenn eine der nachfolgenden Bedingungen zutrifft, muss der
Versand durch den Mailserver oder das De-Mail-Gateway (DMGW) abgelehnt werden (vgl.
 Ziffer 7.3 Prozessbeschreibungen, GP-2):
oFunktionspostfach oder persönliches Postfach wurden nicht für den De-Mail-Versand
freigeschaltet.
oBeim Versand wurde eine Mischadressierung verwendet (Mailserver).
oDie De-Mail ist größer als 10 MB.
8.4
Prüfung der Vollständigkeit und Notwendigkeit der Anwendungsfälle
FZ1
UC1
FZ2
FZ3
FZ4
FZ5
FZ6
FZ7
FZ8
FZ9
FZ
10
FZ
11
FZ
12
FZ
13
x
UC2
UC3
x
UC4
UC5
x
UC6
x
UC7
UC8
UC9
x
x
x
x
x
x
x
x
x
x
FZ
14
FZ
15
FZ
16
FZ
17
2_63_Fachkonzept De-Mail 1.0.docx
FZ1
UC
10
FZ2
FZ3
x
x
UC
11
UC
12
xn
UC
13
x
UC
14
x
FZ4
FZ5
x
x
x
Seite 29 von 57
FZ6
FZ7
FZ8
FZ9
x
x
x
x
FZ
10
FZ
11
FZ
12
FZ
13
FZ
14
x
x
FZ
15
FZ
16
FZ
17
x
x
x
x
x
x
x
x
x
Tabelle 8 Zuordnungsmatrix der fachlichen Ziele und Anwendungsfälle
9 Fachliches Datenmodell
9.1
Speicherung von De-Mail-Adressen (Adressbuch)
Sollte eine zweckgebundene Speicherung von externen De-Mail-Adressen zur späteren
Verwendung erfolgen, z.B. für den automatisierten Versand aus Fachanwendungen oder
Fallsystemen, dann sollten folgende Attribute entsprechend beachtet werden:
 Speicherung Name beziehungsweise Identifikationsmerkmal und
De-Mail-Adresse: bool
 Globale Zugangseröffnung liegt vor; Juristische Person: bool
(vgl. unter Ziffer 10.2 Funktionale Anforderungen, Globale Zugangseröffnung)
9.2
Dokumentation der LHM De-Mail-Adressen
Zu Dokumentationszwecken sollte an einer zentralen Stelle eine Liste oder Zuordnung von DeMail-Adressen und den Fachdienststelle gepflegt werden. Diese Dokumentation kann z.B. auf der
Basis einer zentral abgelegten Datei oder im Gateway erfolgen und sollte im Minimum die
folgenden Informationen enthalten:
 Postfachname (identisch mit dem Namen des Funktionspostfach)
 Fachdienststelle, Referat
2_63_Fachkonzept De-Mail 1.0.docx
9.3
Seite 30 von 57
Private-ID
Durch das optionale Setzen der Header-Angabe „X-de-mail-private-id“, besteht die Möglichkeit der
Übermittlung eines eindeutigen Schlüssels für eine spätere Zuordnung von Rückantworten im
Rahmen eines Fachverfahrens. Durch die technische Richtlinie De-Mail des BSI ist vorgegeben,
dass der DMDA dieses Feld nicht verändern darf und es auch in Bestätigungsnachrichten
übernommen werden muss.
9.4
De-Mail-Domain & -Adressen Konstruktionsprinzip
(1) Grundlagen für De-Mail-Adressen

Nur im englischen Alphabet vorhandene Buchstaben und Zahlen,
max. 64 Zeichen

Case Insensitive „Max.Mustermann“ == „max.mustermann“

Leerzeichen sind nicht zulässig

Mögliche Sonderzeichen !#$%&'*+/=?^`{|}~ sind zu vermeiden
(1) Aufbau De-Mail-Adressen (Unterkonten)
Der Aufbau der De-Mail-Adressen sollte sich an den Namen der zu verknüpfenden
Funktionspostfächern orientieren und wenn möglich folgenden Aufbau haben:
<Postfachname>.<Abkürzung Referat>@De-Mail-Domain
Beispiel: [email protected]
(2) Bildungsregel für Domain-Teil:
Die nachfolgende Beschreibung führt die validen Bildungsregeln für De-Mail-Adressen auf. Um die
Adressen möglichst einfach zu halten, sollten keine Level 4 und Level 5 Sub-Domains angelegt
werden.

1. Level (.de) und 2. Level Domain (de-mail) sind bereits definiert

Die Bezeichnung der 3. Level Domain identifiziert den De-Mail Account-Inhaber
*@munchen.de-mail.de
*@stadt-muenchen.de-mail.de

Weitere Sub-Domains möglich (Administrative Hoheit der LHM):
4. Level *@kvr.muenchen.de-mail.de
5. Level *@dika.kvr.muenchen.de-mail.de
2_63_Fachkonzept De-Mail 1.0.docx
Seite 31 von 57
Abbildung 7: Aufbau De-Mail-Adressen
10 Anforderungen und Ausgrenzungen
10.1
Benutzeroberfläche
Die Erstellung, Beantwortung und Weiterleitung von De-Mails findet bei der LHM in einem nativ in
LiMux laufenden E-Mail-Programm statt. Hierbei handelt es sich bis zum Sommer 2015 um den
Thunderbird und danach zum größten Teil um den Kolab Mail-Client. Durch den anstehenden
Wechsel des Mail-Clients ist es ratsam, beim Thunderbird keine zusätzlichen Plugins oder
Erweiterungen zu entwickeln. Es sollte daher versucht werden, mit den vorhandenen
Möglichkeiten im Thunderbird die folgenden Anforderungen umzusetzen:
 Kennzeichnung: Kommunikationstyp „De-Mail“
 Anzeige der vom Absender verwenden Versandoptionen
Zur Steigerung der Benutzerfreundlichkeit und einer verbesserten Handhabung zur Steigerung der
internen Akzeptanz, sollten im Kolab Mail-Client (nativer und Web-Client) zusätzlich folgende
Auswahlmöglichkeiten und Erweiterungen in der Darstellung integriert werden:
 Kennzeichnung: Kommunikationstyp De-Mail (Symbol)
 Anzeige der vom Absender/Verfasser verwenden Versandoptionen
(Meta-Information)
 Mehrfach Auswahlmenü: Versandoptionen
Versandart
Aktion
Eingehende De-Mail
Kennzeichnungen übernehmen
(Kommunikations-Typ, Versandoptionen)
Interne Weiterleitung
Kennzeichnungen beibehalten (Kommunikations-Typ,
Versandoptionen)
Externe Weiterleitung auf
eine E-Mail-Adresse
Kennzeichnungen beibehalten. Die Nachricht sollte - wenn
möglich - verschlüsselt übermittelt werden
Externe Weiterleitung auf
eine De-Mail-Adresse
Kennzeichnungen entfernen. Bei der Weiterleitung einer
De-Mail ist davon auszugehen, dass der LHM Mitarbeiter
die Versandoptionen entsprechend abändern wird, um die
Zustellung beeinflussen zu können. Die im Betreff
2_63_Fachkonzept De-Mail 1.0.docx
Seite 32 von 57
enthaltenen Versandoptionen (User Commands) sind daher
vor dem Entfernen durch das De-Mail-Gateway
anzuwenden.
Beantwortung der De-Mail
Kennzeichnungen entfernen. Bei der Beantwortung einer
De-Mail ist davon auszugehen, dass der LHM Mitarbeiter
die Versandoptionen entsprechend abändern wird, um die
Zustellung beeinflussen zu können. Die im Betreff
enthaltenen Versandoptionen (User Commands) sind daher
vor dem Entfernen durch das De-Mail-Gateway
anzuwenden
Tabelle 9 Behandlung der Kennzeichnungen Kommunikationstyp „De-Mail“ und der
Versandoptionen
10.1.1 Thunderbird: Eingefügte Kennzeichnungen
Wie eingangs erwähnt, wird im Thunderbird eine Übergangslösung bis Sommer 2015 benötigt, um
die in Ziffer 10.1 erwähnten Anforderungen zu erfüllen.
(1) Kennzeichnung: Kommunikationstyp „De-Mail“: Das Konzept zur internen Bereitstellung
von De-Mails bei der LHM sieht vor, dass Nachrichten vom Typ „De-Mail“ in den bereits
vorhandenen und bekannten Funktionspostfächern bereitgestellt werden. Um eine leichtere
Unterscheidung zu regulären E-Mails zu ermöglichen, sollten die De-Mails im Posteingang
entsprechend hervorgehoben oder gekennzeichnet sein. Eine De-Mail ist zwar anhand der
Adresse erkennbar, der Aufbau ist allerdings nicht allen Sachbearbeitern geläufig und birgt
Verwechselungsgefahr. Eine entsprechende Hervorhebung im Thunderbird anhand der X-Header
Angabe wurde unter Ziffer 10.1.2 beschrieben.
Zur Behandlung der Kennzeichnung, sollte auch die Tabelle 9 Behandlung der Kennzeichnungen
Kommunikationstyp „De-Mail“ und der Versandoptionen beachtet werden.
(2) Versandoptionen (Empfangen/Senden): Optional kann der De-Mail-Versand mit
Versandoptionen noch genauer spezifiziert werden. Für den Fall, dass diese Versandoptionen in
der Gateway-Komponente hinterlegt werden müssen und die jeweilige Behandlung der Nachricht
beeinflussen, sollte für ein- und ausgehende De-Mails die gleiche Nomenklatur verwendet werden.
Aufgrund der langen Bezeichnungen der Versandoptionen sollten diese entsprechend abgekürzt
werden (Siehe Versandoptionen in 3510.2, Abs. 2). In der Kombination mit dem KommunikationsTyp sollte der Aufbau innerhalb des Betreffs wie folgt sein:
Aufbau: [DEMAIL_<Versandoptionen>] <Original Betreff>
Beispiel: [DEMAIL_AB] <Original Betreff>
Es können dabei maximal fünf Versandoptionen in einer De-Mail vorkommen. Die Anzahl und die
Reihenfolge können dabei variieren. Bei der Beantwortung oder Weiterleitung der Nachricht als
De-Mail ist davon auszugehen, dass die Versandoptionen durch den LHM Mitarbeiter
entsprechend abgeändert oder ergänzt werden.
Zur Behandlung der Kennzeichnung sollte auch die Tabelle 9 („Behandlung der Kennzeichnungen
Kommunikationstyp „De-Mail“ und der Versandoptionen“) beachtet werden.
2_63_Fachkonzept De-Mail 1.0.docx
Seite 33 von 57
10.1.2 Thunderbird: Hervorhebung von De-Mails
Zur Steigerung der Sichtbarkeit von eingehenden De-Mails im Funktionspostfach kann optional
auch über die lokalen Filterregeln eine Hervorhebung mittels farbiger Schlagwörter im Thunderbird
eingerichtet werden. Hierdurch sind die De-Mails leichter von regulären E-Mails zu unterscheiden.
Werden die Filter wie nachfolgend beschreiben angelegt, erfolgt die Hervorhebung nicht bei
weitergeleiteten De-Mails.
Hierbei handelt es sich allerdings – sofern sich diese nicht zentral steuern lässt – um eine lokale
Einstellung, die durch den jeweiligen LHM Mitarbeiter vorgenommen werden muss.
Als Filterkriterium kann im Absenderfeld überprüft werden, ob die Adresse einen „de-mail.de“ oder
einen anderen De-Mail-Domainteil enthält. Trifft der Fall zu, ist davon auszugehen, dass es sich
bei der Nachricht um eine De-Mail handelt. Wurde die De-Mail allerdings bereits hausintern als
reguläre E-Mail weitergeleitet, greift die Regel nicht mehr. Bei Bedarf könnte die Regel
entsprechend erweitert werden.
Abbildung 8: Optionale farbliche Kennzeichnung über die Thunderbird Filteroptionen mittels
SchlagwortOptionale Einrichtungsmöglichkeit für die farbliche Hervorhebung von De-Mails
im Thunderbird
1.
2.
3.
Hinzufügen des Schlagworts „De-Mail“ in den Thunderbird-Einstellungen unter: Datei >
Einstellungen... > Reiter: Ansicht > Reiter: Schlagwörter (vgl. Abb. 9), mit der Farbe Gelb.
Hinzufügen des Filters „De-Mail“ im Thunderbird unter: Extras > Filter...
(vgl. Abb. 10)
Auswählen der Filterbedingung „Anpassen...“ um die Filterbedingung „X-De-Mail-Version“
hinzuzufügen.(vgl. Abb. 11).
2_63_Fachkonzept De-Mail 1.0.docx
Seite 34 von 57
Abbildung 9: Schlagwörter in den Thunderbird-Einstellungen
Abbildung 10: Lokalen Filter "De-Mail" im Thunderbird hinzufügen
Abbildung 11: Bedingungen des Filters „De-Mail“ zur Hervorhebung von De-Mails.
2_63_Fachkonzept De-Mail 1.0.docx
Seite 35 von 57
10.1.3 Kolab Mail-Client
Die Inhalte der Oberflächenanforderungen werden in dem Dokument Änderungsanforderung
„Kolab Oberflächenanpassungen hinsichtlich De-Mail“ separat behandelt.
10.2
Funktionale Anforderungen
(1) Erweiterung der bestehenden Zugangseröffnung der LHM: Voraussetzung für die
Entgegennahme von De-Mails ist die elektronische Zugangseröffnung der LHM auf der Website
der Stadt. Hierzu muss die bereits bestehende elektronische Zugangseröffnung8 erweitert oder
um einen neuen Abschnitt ergänzt werden. Hierzu muss ein entsprechender Text ausgearbeitet
und durch den Lenkungskreis verabschiedet werden. Ansprechpartner für die Integration der
neuen Textversion ist das Presse und Informationsamt (PIA). Ein Textvorschlag für die
Zugangseröffnung im Rahmen der De-Mail ist dem Anhang unter Ziffer56zu entnehmen. In der
erweiterten Zugangseröffnung sind folgende Inhalte zu berücksichtigen:

De-Mail-Adresse (voraussichtlich [email protected])

Akzeptierte Dateiformate

Maximale Größe der De-Mail (10 MB. Begrenzt durch den DMDA)

Bekanntgabe der akzeptierten Zuleitungen (Anträge und Mitteilungen im Rahmen von
Verwaltungsverfahren)

Hinweis auf Transportverschlüsselte (SSL/TLS) Kommunikation für den sicheren Austausch
von Informationen

Abhängig von dem BayEGovG: De-Mail erfüllt die Schriftformerfordernis
(2) Umgang mit Versandoptionen: Bei dem Versenden von De-Mails können fünf
Versandoptionen9 verwendet und je nach Bedarf miteinander kombiniert werden. Mit den
Versandoptionen lassen sich zum Beispiel förmliche Zustellungen gemäß dem BY VwZVG
realisieren. Die nachfolgenden Versandoptionen sind dabei sowohl durch die LHM E-Mail-/De-MailInfrastruktur als auch durch die E-Mail-Clients zu unterstützen. Abkürzungen der Versandoptionen
jeweils in eckigen Klammern.
1. Persönlich [DEMAIL_P]10: Das erforderliche Authentisierungsniveau von Absender und
Empfänger muss mindestens „hoch“ sein, um die Nachricht lesen zu können, beispielsweise
wegen der besonderen Vertraulichkeit der Nachricht.
2. Absender-Bestätigt [DEMAIL_SB]10: Das erforderliche Authentisierungsniveau des
Absenders muss - wegen der besonderen Verbindlichkeit der Nachricht - mindestens „hoch“ sein.
Der De-Mail-Provider des Absenders bestätigt nach Entgegennahme der Nachricht mittels
qualifizierter elektronischer Signatur, dass er den angegebenen Nachrichteninhalt von dem
Absender entgegengenommen hat und dieser sich mindestens mit „hoch“ authentisiert hat. Der
Empfänger erhält dadurch einen glaubwürdigen („starken“) Nachweis der Authentizität des
Absenders und der Integrität der Nachricht. Mit den noch in Bayern zu schaffenden rechtlichen
8
Bestehende elektronische Zugangseröffnung der Landeshauptstadt gemäß §3a des VwVfG:
http://www.muenchen.de/rathaus/Kontakt/Elektronische-Kommunikation.html (24.03.2014).
9
Technische Spezifikation De-Mail Headerangaben: BSI – Technische Richtlinie, Postfach- und Versanddienst
Interoperabilitätsspezifikation, Version 1.1.1.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/De_Mail/TR_De_Mail_PVD_IO_pdf.pdf?_
_blob=publicationFile (04.06.2014)
10
Die Versandoptionen „persönlich und „absenderbestätigt“ sind optional und daher keine Muss-Anforderung.
2_63_Fachkonzept De-Mail 1.0.docx
Seite 36 von 57
Rahmenbedingungen in Form des E-Government-Gesetz wird voraussichtlich durch die De-Mail
auch die Schriftformerfordernis erfüllt.
3. Versandbestätigung [DEMAIL_VB]: Der De-Mail-Anbieter des Absenders erstellt eine
qualifizierte signierte Bestätigung, dass er eine referenzierte Nachricht zu einem bestimmten
Zeitpunkt für den Versand an einen bestimmten Empfänger versandt hat.
4. Eingangsbestätigung [DEMAIL_EB]: Der De-Mail-Anbieter des Empfängers erstellt nach
Ablage der Nachricht in das Postfach des Empfängers eine qualifiziert signierte Bestätigung, dass
er eine referenzierte Nachricht zu einem bestimmten Zeitpunkt in das Postfach des Empfängers
eingestellt hat.
5. Abholbestätigung [DEMAIL_AB]: Der De-Mail-Anbieter des Empfängers erstellt nach einer
sicheren Anmeldung des Nutzers und bei Vorhandensein einer Nachricht mit AbholbestätigungsAnforderung im Postfach des Empfängers eine qualifiziert signierte Bestätigung, dass der Nutzer
eine Nachricht einsehen konnte.
(3) Zugangseröffnungen für externe Kommunikationspartner: Voraussetzung für die
Kommunikation mit externen Kommunikationspartnern (Bürger, Wirtschaft, Institutionen) ist die
beidseitige Zugangseröffnung. Die Zugangseröffnung erfolgt bei Privatpersonen durch die
Kontaktaufnahme mit der jeweiligen Verwaltung und bei juristischen Personen (Firmen,
Organisationen) durch die Bekanntgabe der Adresse auf Website, Visitenkarte oder Briefbogen:
 Fallbezogene Zugangseröffnung: Dem Absender darf nur fallbezogen auf die Anfrage
geantwortet werden. Ein späterer selbst initiierter De-Mail-Versand an den Absender ist in diesem
Fall nicht möglich. Dies betrifft hauptsächlich Privatpersonen, um sie vor selbst initiierten
Anschreiben zu schützen.
 Globale Zugangseröffnung (für Partner): Bei der globalen Zugangseröffnung findet auf der
Basis der Zugangseröffnung der LHM eine Zugangseröffnung durch den Kommunikationspartner
(in der Regel Firmen, Institutionen oder Behörden) statt. Dieser gibt auf seiner Website, seiner
Visitenkarte oder seinem Briefbogen die jeweilige De-Mail-Adresse bekannt oder eröffnet der LHM
damit global den Zugang und ermöglicht den selbst initiierten Versand von Bescheiden oder der
Bekanntgabe von Verwaltungsakten.
(4) Archivierung: In der Anfangsphase soll die Archivierung zunächst bei dem jeweiligen DMDA
erfolgen. Der DMDA oder Gateway-Anbieter sollten allerdings zum Zeitpunkt der Beauftragung
über eine Archiv-Schnittstelle für De-Mails verfügen bzw. einen entsprechenden Zeitpunkt für die
Bereitstellung nennen. Langfristig sollte aber über eine hausinterne und revisionssichere
Langzeitarchivierung nachgedacht werden.
(5) Verschlüsselte Weiterleitung: Es ist davon auszugehen, dass De-Mails in der Regel
personenbezogene und vertrauliche Informationen enthaltenen. Es sollte analog zu dem Umgang
mit Inhalten in E-Mails eine organisatorische Regelung getroffen werden, wie mit Weiterleitungen
an E-Mail-Adressen außerhalb der muenchen*.de Domain umgegangen werden soll. Nachrichten
mit personenbezogenen oder vertraulichen Daten sollten das städtische Netz nur per De-Mail oder
S/MIME verschlüsselt verlassen.
(6) Virenprüfung: Um einen sicheren und störungsfreien Austausch von De-Mails zwischen
DMDA und internem E-Mail-System herzustellen, sollten zusätzlich alle De-Mails auf Malware und
Viren überprüft werden, damit ausgehende Nachrichten nicht durch den DMDA abgelehnt werden.
Diese Maßnahme soll die Mitarbeiter der LHM und die externen Kommunikationspartner vor
schädlichen Inhalten schützen. Für den Umgang mit Viren und Malware bei eingehenden De-Mails
müssen entsprechende organisatorische Regelungen getroffen werden, da die De-Mails bereits als
zugestellt gelten. Für eingehende De-Mails sollte beachtet werden, dass diese bereits bei der
Übermittlung durch den DMDA des Absenders und durch den DMDA der LHM auf Viren geprüft
2_63_Fachkonzept De-Mail 1.0.docx
Seite 37 von 57
wurden.
10.2.1 Anforderungen an ein De-Mail-Gateway
Für die interne Zustellung von De-Mails in Postfächern und den Versand von De-Mails wird
innerhalb der LHM Infrastruktur ein zentrales De-Mail-Gateway (DMGW) benötigt. Dieses Gateway
ist die Schnittstelle zwischen dem DMDA und dem internen Funktionspostfach. Das Fachkonzept
sieht vor, dass vorhandene und bereits interne bekannte Funktionspostfächer für den Empfang
und den Versand von De-Mails freigeschaltet werden. Das De-Mail-Gateway sollte folgende
Anforderungen erfüllen:
(1) Unterstützung Dienstanbieter: Das Gateway muss die Abholung beziehungsweise die
Übermittlung von De-Mails von mehreren DMDAs unterstützen. Für die Gewährleistung einer
revisionssicheren Aufbewahrung der De-Mails beim DMDA, dürfen die De-Mails nur abgerufen
aber nicht beim DMDA gelöscht werden.
(2) Empfänger-/Absenderadresse: Durch die bei der De-Mail zum Einsatz kommende CatchAll/Send-All Mechanik bei ein- beziehungsweise ausgehenden Nachrichten muss der lokale Teil
der Postfachadresse jeweils gleichbleibend durchgereicht werden (postfachname@*).
(3) Erfüllung der Sicherheitsrichtline: Der generelle Betrieb des De-Mail-Gateways muss die
Vorgaben der LHM Sicherheitsrichtline für die Zusammenarbeit und den Datenaustausch mit
Dritten erfüllen.
(4) Übermittlung an Dienstanbieter: Transportverschlüsselte Abholung (SSL/TLS) und
Übermittlung von ein- und ausgehenden De-Mails von bzw. an einen definierten De-Mail
Dienstanbieter (DMDA) der LHM. Bei dem DMDA kann es sich um T-Systems oder MentanaClaimsoft handeln.
(5) Zuordnung zu Funktionspostfächern: Das De-Mail-Gateway muss neben der Abholung von
De-Mails beim DMDA auch die Bereitstellung der Nachrichten in Funktionspostfächern bei der
LHM ermöglichen. Hierzu muss das Gateway eine Zuordnung zwischen De-Mail-Adressen zu
Funktionspostfächern gestatten. Die Anlage und Pflege von neuen Zuordnungen zwischen DeMail-Adressen und Funktionspostfächern sollte für die administrativ tätigen Mitarbeiter möglichst
komfortabel gestaltet sein. Bei der Zuordnung handelt es sich um eine 1:1 Verbindung. Diese
Zuordnung gilt sowohl für den Empfang als auch den Versand von Nachrichten über die
entsprechende Adresse.
(6) Umgang mit Mischadressierung: Das Gateway sollte eine Konfigurationsmöglichkeit bieten,
wie mit einer Mischadressierung (De-Mail- und E-Mail-Adressen im An- bzw. im Kopie-Feld) beim
Versand umgegangen werden soll. Es wird empfohlen, analog zum Vorgehen im Bereich „Secure
Mail“, Nachrichten bei enthaltener Mischadressierung (De-Mail- und E-Mail-Adressen) bei dem
Nachrichtenversand am Gateway abzulehnen. Es sind allerdings auch andere Lösungswege – z.B.
durch unterstützende Oberflächenfunktionen (siehe Ziffer 10.1 31) – denkbar.
(7) Versandoptionen: De-Mail ermöglicht die Verwendung von „Versandoptionen“ wie
persönlich, absenderbestätigt, Versandbestätigung, Eingangsbestätigung und Abholbestätigung.
Die Auswahl der jeweils erforderlichen Versandoptionen kann über ein zusätzlich zu entwickelndes
Plugin/Mail-Client Erweiterung und/oder entsprechende Schlüsselwörter in der Betreffzeile
erfolgen. Da die Versandoptionen miteinander kombinierbar sind, muss diese Auswahlmöglichkeit
2_63_Fachkonzept De-Mail 1.0.docx
Seite 38 von 57
auch für den LHM Sachbearbeiter gegeben sein. Bezugnehmend auf die in Ziffer 10.1 , Tabelle 9,
aufgeführten Anforderungen bezüglich der Kennzeichnung von De-Mails und den jeweiligen
Versandoptionen ist direkt eine für den Kolab Mail-Client kompatible Lösung herzustellen. Somit ist
gewährleistet, dass auch ältere De-Mails (vor dem Kolab Mail-Client Rollout) mit der
entsprechenden Kennzeichnung angezeigt werden können.
(8) Abholung der Bestätigungen: Die Versandoptionen „Versandbestätigung“ und
„Absenderbestätigung“ werden durch den jeweiligen DMDA via De-Mail bestätigt. Diese
Bestätigungen sind ebenfalls durch das De-Mail-Gateway abzuholen und in dem dazugehörigen
Funktionspostfach bereitzustellen.
(9) Versandaufgaben: Die bei der LHM verwendete E-Mail-Clientsoftware ermöglicht es derzeit
nicht, clientseitig De-Mails zu erzeugen und an den DMDA zu übermitteln. Bislang sind daher nur
Gateway-Anbindungen möglich. Aus diesem Grund müssen durch das De-Mail-Gateway folgende
Aufgaben bei dem Versand ausgeführt werden:

Die verwendeten Versandoptionen (siehe Absatz 7) müssen durch das Gateway entsprechend
berücksichtigt und beim Versand angewendet werden. Hierzu müssen die mittels Plugin oder
als Schlüsselwörter in der Betreffzeile gesetzten Versandoptionen ausgelesen werden.

Ersetzung der internen Funktionspostfachadresse gegen die externe De-Mail-Adresse.

Empfängeradressenprüfung: Wenn es sich bei den Empfängern um eine Mischadressierung
handelt, kann die Nachricht abgewiesen und dem Absender als abgelehnt zurückgegeben
werden. Diese Überprüfung wird höchstwahrscheinlich an dem Mailserver stattfinden und nicht
beim De-Mail-Gateway.

Übermittlung der Nachrichtengröße. Wird die zulässige Größe von 10 MB überschritten, muss
der Versand abgelehnt und der Anwender entsprechend durch eine Fehlermeldung informiert
werden.
(10) Anzeigen der Versandoptionen und Typ: Das De-Mail-Gateway soll die Möglichkeit bieten,
die vom Absender verwendetet Versandoptionen entsprechend zu übermitteln. Dies kann über
Schlüsselwörter im Betreff oder durch X-Header-Einträge erfolgen. Hierdurch wird dem LHM
Sachbearbeiter in seinem E-Mail-Client angezeigt, welche Versandoptionen beim Versand durch
den Absender verwendet wurden. Zudem soll angezeigt werden, dass es sich bei der Nachricht um
eine De-Mail handelt.
(11) Zustellungen im Catch-All-Postfach: Teil des Fachkonzepts „Sichere Kommunikation Teil
DE-MAIL“11 des KVR ist es, dass De-Mails, welche an nicht vorhandene Postfächer innerhalb einer
De-Mail-Domain (Bsp. *@muenchen.de-mail.de / *@stadt-muenchen.de-mail.de) geschickt
werden, nicht abgewiesen, sondern in einem internen „Catch-All-Postfach“ zugestellt werden. Bei
den Adressen [email protected] bzw. [email protected] handelt es sich
jeweils um das zentrale De-Mail-Postfach der De-Mail-Domain. Dieses wurde auch entsprechend
beim DMDA als solches festgelegt. In diesem Postfach ankommende De-Mails werden durch das
Gateway abgeholt und in dem dafür vorgesehenem Funktionspostfach bei der LHM bereitgestellt.
Im besten Fall werden diese Fehlsendungen bereits als solche gekennzeichnet oder entsprechend
erkennbar. Sichtung und Weiterverarbeitung der Fehlsendungen erfolgt dann im internen Postfach
„[email protected]“ (wird voraussichtlich durch die „digitalen Poststelle“ betreut) der LHM in
einem manuellen Arbeitsschritt.
11
E-Government-Initiative für De-Mail und den neuen Personalausweis, Fachkonzept Sichere Kommunikation Teil DE-MAIL, "10.1.8.
Catch-All-Postfach". http://www.cio.bund.de/SharedDocs/Publikationen/DE/InnovativeVorhaben/E_Government_Initiative/muenchen.pdf?__blob=publicationFile, Seite 17 (05.04.2014)
2_63_Fachkonzept De-Mail 1.0.docx
Seite 39 von 57
(12) Datenschutz bei Beantwortung und Weiterleitung: Zum Schutz der via De-Mail
übermittelten Informationen und Daten muss technisch oder organisatorisch sichergestellt werden,
dass De-Mails nur über die folgenden Arten beantwortet oder weitergeleitet werden können:
1. Beantwortung De-Mail: Nachricht wird per De-Mail beantwortet
2. Interne Weiterleitung: Nachricht wird innerhalb des städtischen Netz als E-Mail übertragen
3. Externe Weiterleitung De-Mail: Nachricht wird via De-Mail übermittelt
4. Externe Weiterleitung E-Mail: Unverschlüsselte Weiterleitungen von vertraulichen oder
personenbezogenen Information unterliegen einer entsprechenden organisatorischen Regelung.
(13) Abrechnungsdaten: Beim Versand und Nutzung von Versandoptionen der De-Mail entstehen
nutzungsabhängige Kosten. Um die Möglichkeit einer Kostenaufteilung zwischen den jeweiligen
Stellen zu schaffen, soll das De-Mail-Gateway die Möglichkeit bieten, Aufstellungen zur Anzahl von
abgehenden Nachrichten zu exportieren (CSV o.ä. Standardform), auf deren Basis eine sinnvolle
Kostenaufteilung erfolgen kann. Die Daten sollten im Rahmen der Datensparsamkeit mindestens
folgende Informationen enthalten:

De-Mail-Postfachname Absender (hieraus ergibt sich die Zuordnung zum jeweiligen
Verbraucher)

Versandzeitpunkt (Tag, Monat, Jahr, Uhrzeit)

Verwendete Versandoptionen

Größe der Nachricht
(14) Fehlerbehandlung / Anwendungsfehler:
1. Wird durch einen Anwender versucht, aus einem Funktionspostfach (nicht mit einer
entsprechenden LHM De-Mail-Adresse verknüpft) eine Nachricht an eine De-Mail-Adresse zu
versenden, soll dem Anwender der Anwenderfehler durch eine entsprechende Fehlermeldung
anzeigt werden.
2. Wird von einem Anwender versucht eine De-Mail zu verschicken, die eine zulässige
Gesamtgröße von 10 MB überschreitet (betrifft die zulässige De-Mail-Größe beim DMDA), soll
dem Anwender der Anwenderfehler durch eine entsprechende Fehlermeldung anzeigt werden.
3. Wird bei dem Versand eine Mischadressierung (De-Mail- und E-Mail-Adressen) verwendet,
könnte dem Anwender die definierte Restriktion durch eine entsprechende Fehlermeldung anzeigt
werden.
10.3
Nicht funktionale Anforderungen
(1) De-Mail-Adressantrag (DMAA): Zur technischen Bereitstellung von neuen De-Mail-Adressen
wird ein Antragsprozess benötigt, über den neue Adressen durch entsprechend berechtigte
Personen angefordert werden können. Damit die neuen Adressen durch den LHM IT-Dienstleister
(dIKA, it@M, Betreibsdienst) entsprechend beim DMDA angelegt und mit den internen
Funktionspostfächern verknüpft werden können, werden mindestens die folgenden Angaben im
Antragsprozess benötigt:
1. De-Mail-Postfachname (entspricht dem Namen des Funktionspostfachs)
2. Fachdienststelle und Referat (entspricht auch dem Kostenträger)
Anforderungen an ein De-Mail-Gateway
(1) Bereitstellungszeitpunkt: Die Bereitstellung des De-Mail-Gateways mit der Möglichkeit des
Empfang und des Versand von De-Mails in/aus Funktionspostfächern muss bis Ende 2014
gegeben sein. Durch die gesetzliche Vorgabe ab 01.01.2015 das Vorhaben iKFZ (internetbasierten
2_63_Fachkonzept De-Mail 1.0.docx
Seite 40 von 57
Kraftfahrzeug-Außerbetriebsetzung) umzusetzen, muss bis spätestens Jahresende ein
automatisierter De-Mail-Versand aus einem Fachverfahren ermöglicht werden.
(2) De-Mail-Durchsatz: Das De-Mail-Gateway muss einen täglichen Gesamtdurchsatz von 2.000
De-Mails ermöglichen. Diese Mengenannahme wird bedingt durch die Annahme, dass im Zuge der
De-Mail-Gateway (DMGW) Integration keine Reihenschaltung erfolgt und nur die für den De-MailVersand vorgesehenen Nachrichten an das Gateway übermittelt werden.
(3) Verfügbarkeit: Das De-Mail-Gateway (DMGW) sollte sich hinsichtlich Verfügbarkeit an der
Verfügbarkeit des LHM Mailservers orientieren, da das DMGW nicht ohne den Mailserver arbeiten
kann. Das DMGW sollte redundant aufgebaut werden, um ein hohes Maß an Verfügbarkeit im
täglichen Betrieb zu gewährleisten. Ein entsprechender SLA ist im Rahmen der Betriebsübergabe
zu erstellen.
(4) Bereitstellung: Die Freischaltung von Funktionspostfächern für den De-Mail-Versand durch
den technischen Dienstleister der LHM, soll binnen einer Arbeitswoche erfolgen (siehe Ziffer 10.3 ,
Abs. 1, DMAA).
(5) Kompatibilität: Das De-Mail-Gateway muss technisch und organisatorisch kompatibel mit
dem bereits vorhandenen Verschlüsselungs-Gateway sein. Hierzu zählen die Anforderungen im
Rahmen der Infrastrukturintegration für Wartung/Betrieb, Redundanz, Monitoring/Überwachung
und Softwarearchitektur. Optional ist eine spätere zusätzliche End-to-Site Verschlüsselung von DeMails wünschenswert.
10.4
Ausgabevorlagen und -formate
(1) Abrechnungsdaten: Sollte eine Bereitstellung von Abrechnungsdaten für die Ermittlung von
nutzungsabhängigen Kosten erfolgen, sollte dies mit einem bei der LHM vorhandenen
Softwareprodukt (z.B. OpenOffice 3) in einem lesbaren Format, welches bei der LHM bearbeitet
werden kann, erfolgen. Beispiel: CSV oder Text-Datei.
(2) De-Mail-Archivexport: Sollte eine LHM interne und rechtssichere Archivierung von De-Mails
angestrebt werden, sollte die Langzeitspeicherung gemäß TR-ESOR erfolgen.
10.5
Zuordnungsmatrix
Nicht relevant.
10.6
Motivation
Das vorliegende Fachkonzept beschreibt die fachlichen Anforderungen für eine sinnvolle und
2_63_Fachkonzept De-Mail 1.0.docx
Seite 41 von 57
anwenderorientierte De-Mail-Einführung bei der LHM und kann eine Reihe von positiven Effekten
erzielen, die allerdings nicht direkt durch das Fachkonzept beeinflusst werden können.
 Weniger
Medienbrüche: Mit der Umstellung von papierbasierten zu vollständig digitalen
Prozessen, können Kosten und Aufwände reduziert werden. Die De-Mail kann mit der erwarteten
Erfüllung des Schriftformerfordernisses durch das BayEGovG, hierzu positiv beitragen, hat aber
keinen Einfluss auf die spätere Umsetzung und Nutzung der jeweiligen Fachverfahren.
 Digitaler
Versand von Bescheiden: Durch die technischen Möglichkeiten der De-Mail können
die Bekanntgabe von Verwaltungsakten sowie die förmliche Zustellung nach dem VwZG mittels
Abholbestätigung ermöglicht werden. Hierfür kann das Fachkonzept nur die Anforderungen an
eine Basisumsetzung stellen, nicht aber die spätere komplette Ausgestaltung der nachfolgenden
Fachkonzepte vorgeben.
 Bessere
Erreichbarkeit der Verwaltung und kürzere Wegezeiten: Mit der Einführung der DeMail bei der LHM werden neue Möglichkeiten für digitale Zugänge geschaffen und der
Bürgerservice verbessert. Dadurch kann dem Bürger und juristischen Personen ermöglicht
werden, auch außerhalb der regulären Öffnungszeiten mit der Verwaltung rechtsverbindlich auf
dem elektronischen Weg zu kommunizieren. Für die Verwaltung wird zudem die Möglichkeit
geschaffen Bescheide schneller zuzustellen.
11 Schnittstellenbeschreibung
Dieses Kapitel ist eingehender in der Systemspezifikation zu behandeln. Dort werden unter
anderem folgende Themen beschrieben:
 Schnittstelle zwischen De-Mail-Gateway und De-Mail-Diensteanbieter
 Evtl. Beschreibung einer LDAP-Anbindung zur Pflege der Adresstransformationstabelle
(Zuordnungstabelle)
 Schnittstelle De-Mail-Gateway zum E-Mail-Server/-Relay
Innerhalb der Integration und Bereitstellung des De-Mail-Gateways sind zwei Konstellationen
denkbar. Zum einen eine integrierte Lösung (Abbildung 12), bei der das De-Mail-Gateway in das
bereits vorhandene Verschlüsselungs-Gateway integriert wird und zum anderen eine Standalone
Variante (Abbildung 13), bei der das De-Mail-Gateway an die bestehende Infrastruktur
angeschlossen wird.
11.1
Integrierte DMGW Lösung
Der integrierte Ansatz würde auf vorhandenen Softwarekomponenten aufsetzten und diese
entsprechend erweitern. Durch die Integration des DMGW würden daher redundante Strukturen im
Bereich der Administration, Dokumentation und technischen Bereitstellung vermieden werden. Des
Weiteren könnten bereits vorhandene und redundant verfügbare Bestandteile genutzt werden.
Hierdurch bleiben vor allem die Routingprozesse leichter handhabbar und müssen nicht an
mehreren Stellen gepflegt und getestet werden.
2_63_Fachkonzept De-Mail 1.0.docx
Abbildung 12 Schnittstellenbetrachtung De-Mail-Gateway als integrierte Lösung
Seite 42 von 57
2_63_Fachkonzept De-Mail 1.0.docx
11.2
Standalone DMGW Lösung
Abbildung 13 Schnittstellenbetrachtung De-Mail-Gateway als Standalone Lösung
11.3
Von der Anwendung angebotene Schnittstellen
Dieses Kapitel ist in der Systemspezifikation zu behandeln.
11.4
Von der Anwendung benötigte Schnittstellen
Dieses Kapitel ist in der Systemspezifikation zu behandeln.
Seite 43 von 57
2_63_Fachkonzept De-Mail 1.0.docx
Seite 44 von 57
12 Rollen- und Berechtigungskonzept
Rolle
Berechtigungen
Administra- Postfächertor
Zuordnungen
treffen
Wirkungsbereich
Pro Referat oder
übergreifend
Erlangung der
Rolle
Prozessrolle
bzw. Akteur
Wird vom
Systembetrieb
angelegt.
Mitarbeiter im
dIKA/Betrieb
Hauptbetreuer
Uneingeschränk- Pro
ter Postfachzugriff, Funktionspostfach
entscheidet über
Postfachzugriff
Wird vom
Administrator
angelegt.
Hauptbetreuer,
Hauptbetreuer
digitale
Poststelle
Sachbearbeiter
Beantworten/
Verfassen von
Nachrichten,
Versandoptionen
auswählen
Erhält
Zugangsdaten
von
Hauptbetreuer
Sachbearbeiter,
Sachbearbeiter
digitale
Poststelle
Pro
Funktionspostfach
Tabelle 10 Rollen und Akteure im De-Mail-Umfeld
13 Weitere Sicherheitsaspekte
13.1
Risikobetrachtung der Geschäftsinformationen
Die De-Mail ermöglicht die rechtssichere und vertrauliche Übermittlung von personenbezogenen
Informationen und Dokumenten. Daher handelt es sich immer um besonders schützenswerte
Informationen, die Unbefugten nicht wissentlich oder grob fahrlässig zugänglich gemacht werden
dürfen. Entsprechende Zuwiderhandlungen oder „Datenpannen“ führen sowohl innerhalb der LHM
als auch bei unseren externen Kommunikationspartnern zu einem Vertrauensverlust.
Ergebnis der Risikobetrachtung im Rahmen der Fachkonzepterstellung von möglichen Risiken, die
eintreten können oder derzeit bestehen:
(1) Stadtintern (innerhalb der Domain muenchen.de) werden derzeit alle Nachrichten
unverschlüsselt zwischen Mailserver und E-Mail-Clients ausgetauscht.
(2) De-Mails werden unverschlüsselt an externe E-Mail-Adressen übermittelt.
(3) Selbstinitiierter De-Mail-Versand ohne die vorliegende Zugangseröffnung durch den jeweiligen
externen Kommunikationspartner.
(4) Die Betriebsübergabe eines geeigneten und gemäß den in Ziffer 10.2.1 und 10.3 erhobenen
Anforderungen entsprechenden De-Mail-Gateways erfolgt nicht bis zum Ende des Jahres (2014).
(5) Es werden innerhalb der geplanten Pilotphase keine geeigneten Kommunikationspartner für
die Pilotierung und Erprobung gefunden.
(6) Interne Ablehnung des neuen Kommunikationskanals aufgrund von fehlenden
Einsatzszenarien und dem ausstehenden BayEGovG.
13.2
Datenschutz
2_63_Fachkonzept De-Mail 1.0.docx
Seite 45 von 57
Durch die Übermittlung von größtenteils sensiblen Informationen benötigt der De-Mail-Versand
eine Reihe von organisatorischen und technischen Regelungen zum Schutz der übermittelten
Daten. Die interne und externe Datenverarbeitung muss gemäß der Anforderungen der ITSicherheitsrichtlinie der Landeshauptstadt München, Version 2.0 erfolgen.
(1) Schutzbedarf: Bedingt durch die Festlegung, dass der stadtinterne Datenaustausch als
sicher eingestuft wurde, müssen bei dem internen Datenaustausch keine besonderen
Schutzmaßnahmen ergriffen werden. Für den externen Datenaustausch sind entsprechende
organisatorische Regelungen zu treffen, damit personenbezogene und vertrauliche Daten nicht
ungeschützt über die externen Netze übertragen werden. Für den externen Datenaustausch ist die
De-Mail oder der S/MIME verschlüsselte Austausch zu bevorzugen.
(2) Datenaustausch: Bei der Weitergabe bzw. dem Austausch von Informationen mit Externen
sind die Anforderungen hinsichtlich IT-Sicherheit der zu übermittelnden Informationen zu prüfen
und es ist den Sicherheitsrichtlinien und -regeln entsprechend zu verfahren. Gegebenenfalls sind
entsprechende Vereinbarungen, z.B. Vertraulichkeitsvereinbarungen, abzuschließen.
(3) Datensparsamkeit: Teil des Datenschutzes sollte auch die sparsame Datenerfassung sein,
sodass lediglich nur die Speicherung der tatsächlich benötigten Daten erfolgt.
(4) Gesicherte Kommunikationsbeziehungen: Bei der Übertragung von Informationen über
externe Kommunikationsnetze sind diese möglichst zu sichern. Es sind vor allem die
Kommunikationsbeziehungen zwischen DMDA und De-Mail-Gateway gegen ungesicherten
Datenaustausch abzusichern. Hierbei ist die technische Richtlinie De-Mail zu beachten.
(5) Zugriff auf Funktionspostfächern: Bei Funktionsaccounts definiert die für den Account
verantwortliche Person (Hauptbetreuer) die Gruppe der Personen, die den Account nutzen darf,
und hat dafür Sorge zu tragen, dass nur die Personen dieser Gruppe in den Besitz der Merkmale
gelangen. Hierbei ist besonders zu beachten, dass es sich bei der De-Mail um rechtsverbindliche
Kommunikation im Namen der Landeshauptstadt München handelt.
(6) Passwörter: Die Passwörter der Funktionspostfächer mit De-Mail-Freischaltung müssen
zwingend den Vorgaben der IT-Sicherheitsrichtlinie der LHM entsprechen und sollten in
regelmäßigen Abständen ausgetauscht und nur an die zugangsberechtigten Personen
ausgehändigt werden.
13.3
Informationssicherheit
Durch das Einsatzgebiet einer schnelleren und rechtsverbindlichen Kommunikation mit externen
Kommunikationspartnern ergibt sich bereits eine erhöhte Verfügbarkeitsanforderung an die DeMail-Infrastruktur. Aufgrund der dreitägigen Zustellfiktion bei eingehenden Nachrichten, muss das
De-Mail-Gateway im Minimum werktäglich zur Verfügung stehen und Nachrichten bei dem DMDA
abholen und in den dafür vorgesehenen Postfächern bereitstellen. Da der abgehende De-MailVersand sowohl manuell als auch durch Fachverfahren erfolgen kann, ist speziell beim
automatisierten Versand mit entsprechenden Lastspitzen, Versandtätigkeiten außerhalb der
regulären Arbeitszeiten und am Wochenende zu rechnen.
Durch die Übermittlung der vertraulichen und personenbezogenen Informationen via De-Mail, wird
ein höherer Passwortstandard sowie eine entsprechende Freigabe des Funktionspostfach-
2_63_Fachkonzept De-Mail 1.0.docx
Seite 46 von 57
Verantwortlichen vorausgesetzt.
Im Rahmen der Integration der De-Mail-Infrastrukturkomponenten ist sicherzustellen, dass die
Infrastruktur und die Übertragungswege zwischen dem DMDA und der LHM Infrastruktur
entsprechend abgeschirmt und gegen unerlaubte Zugriffe von außen gesichert sind.
13.3.1 Notfallkonzept
Analog zum Notfallkonzept E-Mail muss auch für die De-Mail ein entsprechendes Notfallkonzept
erarbeitet werden, um im Falle eines Komplettausfalls der De-Mail-Infrastrukturkomponenten den
Zugriff auf De-Mails weiterhin sicherzustellen. Hierfür sollten unter anderem die folgenden Punkte
behandelt werden:
 Umgang mit Teilausfällen der Hard- und Softwarekomponenten.
 Umgang mit einem Komplettausfall der De-Mail Hard- und Softwarekomponenten.

Bereitstellen der alternativen Zugriffsmöglichkeit beim DMDA über die Weboberfläche für die
Sachbearbeiter der LHM.
 Wiederherstellungszeitraum und Rückkehr in den Normalbetrieb.
14 Hilfe & Support
14.1
Anforderungen an den Support für die IT-Lösung
(1) Bestellen/Freischalten von Funktionspostfächern (DMAA): Die Freischaltung (Zuordnung)
von neuen oder bestehenden LHM Funktionspostfächern sollte durch den IT Dienstleister der LHM
erfolgen. Der Ablauf kann sich hierbei an dem unter Ziffer 7.3 beschriebenen Geschäftsprozess
GP-3 orientieren. Die dedizierten Anforderungen für den DMAA wurden unter Ziffer 10.3 , Abs. 1
beschrieben.
(2) Anwender informieren: Im Zuge der Freischaltung sollten zudem grundlegende
Informationen zur Nutzung der De-Mail sowie die jeweils aktuelle DA ausgehändigt werden.
(3) Dokumentation der Freischaltungen: Zu Dokumentationszwecken und für eine
entsprechende Beauskunftung über Freischaltungen sollte eine zentrale Liste mit De-MailAdressen und den Funktionspostfachzuordnungen gepflegt werden. Diese Dokumentation kann
z.B. auf Basis einer zentral abgelegten Datei erfolgen.
(4) Abrechnung: Sofern organisatorisch nicht anders festgelegt, sollte durch den IT-Dienstleister
eine monatliche Aufstellung über die beim DMDA angefallenen nutzungsabhängigen Kosten an
den Hauptbetreuer des Funktionspostfach erfolgen. Die entsprechenden Anforderungen wurden
unter Ziffer 10.2.1 , Abs. 13 erhoben.
(5) Notfallkonzept: Im Falle eines Komplettausfalls der LHM De-Mail-Infrastruktur sollte der
Support anhand des Notfallkonzepts (siehe Ziffer 13.3.1 Notfallkonzept) die Anwender
entsprechend unterstützen.
(6) Telefonischer Helpdesk: Zur Behebung von technischen De-Mail-Problemen sollte der
technische Dienstleister einen entsprechenden telefonischen Helpdesk anbieten. Die telefonische
Erreichbarkeit sollte sich an dem Thema E-Mail und „sichere E-Mail“ orientieren. Gesetzliche
Feiertage und dienstfreie Tage müssen nicht berücksichtigt werden.
(7) Technisches Fachwissen: Um eine optimale Betreuung im Rahmen des Helpdesk zu
ermöglichen, sollten die beteiligten Mitarbeiten entsprechend in dem Thema De-Mail und der
Wirkungsweise des De-Mail-Gateways unterwiesen sein.
2_63_Fachkonzept De-Mail 1.0.docx
14.2
Seite 47 von 57
Anforderungen an das Hilfesystem für die IT-Lösung
 Bekanntgabe
von Nichtverfügbarkeit: Wie bei Störungen von anderen zentralen Diensten und
stadtweiten Komponenten sollten Störungen und Ausfälle des De-Mail-Gateways auch auf der
Startseite des LHM Intranet-Angebots angezeigt werden.
 Präsentationen/Anleitungen: In den Intranet-Seiten der LHM sollte ein weiterer Bereich
geschaffen werden, welcher den Antragsprozess zu neuen Adressen beschreibt und begleitendes
Material (Beschreibungen, Dienstanweisungen) zum Thema zusammenfasst und anbietet. Sofern
das Thema weiterhin durch das E- und Open Government Kernteam betreut wird, sollten die
Kontaktdaten zusätzlich aufgeführt werden.
15 Initialbefüllung und Migrationskonzept
15.1
Vorgängersystem
Da der stadtweite Dienst De-Mail initial bei der LHM eingeführt wird, findet keine Migration von
einem Vorgängersystem auf ein neues System statt. Es ist lediglich darauf zu achten, dass der
Umstieg von dem E-Mail-Client „Thunderbird“ auf Kontact (Kolab) nicht zum Verlust von
Informationen bei Nachrichten führt. Hierzu zählt beispielsweise das Anzeigen der vom Absender
verwendeten Versandoptionen.
15.2
De-Mail-Adressen
Innerhalb der De-Mail-Erprobungsphase wurden bereits erste De-Mail-Postfächer bei beiden
DMDA angelegt, um erste Zugänge zu eröffnen. Diese Postfächer müssen bei dem Umstieg auf
die Gateway-Komponente ebenfalls berücksichtigt und übernommen werden. Zur Dokumentation
wurden die angelegten Postfächer im eoGov-Projektverzeichnis12 dokumentiert.
16 Einführungs- und Schulungsplan
Da die Handhabung der De-Mail in den LHM E-Mail-Clients - abgesehen von kleineren Zusätzen –
mit der der bereits bekannten E-Mail übereinstimmt, sind vor allem rechtliche und organisatorische
Aspekte zu vermitteln.
(1) Generelle Informationen: Im Rahmen einer Schulung oder Schulungsunterlagen für das
Selbststudium sollten zunächst generelle Informationen zu De-Mail vermittelt werden. Hierzu
gehören unter anderem die Gründe der Einführung, Informationen zum rechtsverbindlichen
Schriftverkehr, die Regelungen bei der LHM (AGAM, Dienstanweisungen), Nutzung von
Funktionspostfächern, Zustellfiktion, Dateigrößenbeschränkung, die Inhalte der Zugangseröffnung,
Erfüllung der Schriftformerfordernis (Abhängig vom BayEGovG), Einsatzszenarien sowie sichere
12
E- und Open Government Projektverzeichnis, Projektleitung. ~/eoGov/TP_M058_EinsatzszenarDEMail/Projektleitung/eoGov_De-
Mail-Verzeichnis_Mentana_T-Systems_19092014.ods
2_63_Fachkonzept De-Mail 1.0.docx
Seite 48 von 57
Versandwege zwischen Empfänger, DMDA und der LHM.
(2) Versandoptionen: Die Hintergründe sowie die Anwendungsmöglichkeiten der einzelnen
Versandoptionen müssen den Anwendern vermittelt werden.
(3) Datenschutz: Analog zur E-Mail-Nutzung bei der LHM sollten noch einmal auf
datenschutzrelevante Themen beim Antworten oder Weiterleiten von personenbezogenen und
vertraulichen Inhalten hingewiesen werden. Sollten bis zur Schulung bereits entsprechende DA
vorliegen, sollte auf die Inhalte hingewiesen werden.
(4) Einschränkungen: Zum Schutz der übermittelten Daten sollte innerhalb der Schulung auch
vermittelt werden, dass eine Mischadressierung (E-Mail- und De-Mail-Empfänger) bei De-MailNachrichten generell nicht erwünscht ist und bei Versand entsprechend behandelt werden kann.
(5) E-Mail-Client: Empfangen und Versenden von De-Mails im Thunderbird und ab Sommer
2015 im Kolab Mail-Client.
17 Abnahmekriterien
Die Abnahmekriterien für die Bereitstellung der De-Mail enthalten sowohl technische als auch
organisatorische Kriterien. Hierzu wurden die entsprechenden relevanten
Kommunikationsszenarien aufgezeigt.
17.1
Relevante Kommunikationsszenarien
Die nachfolgenden Ziffern beschreiben die abnahmerelevanten Kommunikationsszenarien
zwischen der LHM und externen Kommunikationspartnern.
17.1.1 Nachrichten der LHM an externe Partner
Im Rahmen der De-Mail-Pilotierung und auch in der späteren stadtweiten Nutzung wird die
Kommunikation zwischen wiederkehrenden externen Partnern (in der Regel Firmen, Institutionen)
und der LHM voraussichtlich der häufigste Anwendungsfall sein. Hierbei findet in der Regel eine
Zustellung von zeitkritischen oder digital benötigten Bescheiden statt. Durch dieses Szenario kann
die papierbasierte Zustellung von rechtsverbindlichen Schreiben oder die Bekanntgabe von
Verwaltungsakten auf die digitale Form der Zustellung umgestellt werden. Für dieses Szenario
bestehen die nachfolgen Voraussetzungen:
(1) Externe Voraussetzungen:
 Der externe Partner ist bekannt und verfügt bereits über eine De-Mail-Adresse oder plant eine
entsprechende Adresse einzurichten.
 Der externe Partner hat seine De-Mai-Adresse bereits bekanntgegeben (siehe
 10.2.3).
 Der bekanntzugebende Verwaltungsakt enthält personenbezogene bzw. vertrauliche
Informationen oder ist förmlich (Versandoption „Abholbestätigung“ erforderlich) zuzustellen.
(2) Interne Voraussetzungen
 Die zu übermittelnden Informationen liegen digital (als Text oder PDF) vor oder können durch
den Sachbearbeiter automatisiert an das zu erstellende Schreiben angehängt werden.
 Das jeweilige Fachverfahren lässt sich auf die digitale Zustellung umstellen.
 Die Sachbearbeiter haben Zugang zu einem Funktionspostfach, um den De-Mail-Versand
2_63_Fachkonzept De-Mail 1.0.docx

Seite 49 von 57
durchzuführen.
Die IT-sicherheitstechnischen Rahmenbedingungen sehen einen datenschutzkonformen
Versand vor.
Kommunikationsablauf
In dem Kommunikationsablauf zum Szenario „Nachrichten der LHM an externe Partner“ wird
davon ausgegangen, dass die oben beschriebenen Voraussetzungen (Ziffer 1 und 2) erfüllt sind.
1. Die zu versendende Informationen (z.B. Bescheide) liegen in digitaler Form für den
Versand vor.
2. Erstellung einer neuen De-Mail im Funktionspostfach A.
1. Hinzufügen der Empfängeradresse (muss für das Fachverfahren entsprechend
vorliegen und/oder gespeichert sein)
2. Hinzufügen der Versandoptionen (z.B. Abholbestätigung)
3. Übermittlung der Nachricht nach dem Abschicken an die E-Mail/De-Mail-GatewayInfrastruktur zur Übermittlung an den DMDA der LHM.
1. Verarbeitung der verwendeten Versandoptionen durch das De-Mail-Gateway
2. Umschreiben der E-Mail-Adresse des Absenders in eine gültige De-Mail-Adresse
(Bsp.: [email protected] wird zu [email protected])
3. Übermittlung des De-Mail-Entwurfs an den DMDA
4. Nach der erfolgreichen Zustellung beim Empfänger, erfolgt die Übermittlung der beim
Versand angeforderten Zustellnachweise (siehe Versandoptionen). Diese werden durch die
De-Mail-Infrastruktur abgeholt und über die E-Mail-Infrastruktur in dem Funktionspostfach
[email protected] bereitgestellt.
5. Sofern für Fachverfahren notwendig, werden die Zustellnachweise entsprechend für das
Fachverfahren digital abgelegt. Es ist dabei zu beachten, dass diese Art der Ablage keine
rechtsverbindliche und belastbare Archivierung darstellt, sondern lediglich als lokale Ablage
zu verstehen ist. Die Archivierung erfolgt daher Übergangsweise beim DMDA.
6. Aufgrund der digitalen Übermittlung kann es auch zu Rückantworten kommen, welche
direkt an die Absenderadresse der LHM (Funktionspostfach A) zugestellt werden. Da es
sich hierbei um Widerspruchserklärungen handeln kann, müssen diese ebenfalls durch die
Sachbearbeiter des Funktionspostfach A bearbeitet beziehungsweise bearbeitet werden.
17.1.2 Bürgeranfragen an die LHM
Bei der Kommunikation zwischen Bürgern und der LHM kann es auf der Seite der Bürger zu einer
großen Menge an unterschiedlichen Kommunikationspartnern kommen. Bei den Anfragen ist daher
zunächst die entsprechende Zuständigkeit zu prüfen. Die Anfragen können dabei sowohl an eine
zentrale Adresse gerichtet sein (z.B. [email protected]) als auch direkt an eine
spezifische Adresse bei der LHM erfolgen. Bei einer Anfrage eines Bürgers mit einer De-MailAdresse erfolgt durch konkludentes Handeln eine fallbezogene Zugangseröffnung. Die Antwort
muss daher auch fallbezogenen erfolgen.
(1) Externe Voraussetzungen:
 Der externe Kommunikationspartner (Bürger) hat eine De-Mail-Adresse.
(2) Interne Voraussetzungen
 Die LHM hat bereits von ihrer Seite aus auf der Website der LHM eine Zugangseröffnung für die
Entgegennahme von De-Mails durchgeführt (siehe Ziffer 10.2 ).
 Die/das angeschriebene Stelle/Referat ist für die Entgegennahme von De-Mails geschult,
2_63_Fachkonzept De-Mail 1.0.docx
Seite 50 von 57
entsprechend personell aufgestellt oder kann sich bei Fragen an eine unterstützende Stelle
wenden.
Kommunikationsablauf
In dem Kommunikationsablauf zum Szenario „Bürgeranfragen an die LHM“ wird davon
ausgegangen, dass die oben beschriebenen Voraussetzungen (Ziffer 1 und 2) erfüllt sind. Es
werden zudem nur Schritte beschrieben, die unseren Systemkontext betreffen beziehungsweise
bekannt und beeinflussbar sind.
1. Die vom Bürger an die LHM übermittelte De-Mail an das Postfach B wird durch das LHM
De-Mail-Gateway abgeholt.
1. Bei der Abholung werden entsprechend der Vorgaben unter Ziffer 10.1 , Tabelle 9, die
jeweiligen Kennzeichnungen gesetzt
2. Umschreiben der De-Mail-Empfängeradresse in eine gültige E-Mail-Adresse (Bsp.:
[email protected] wird zu [email protected])
2. Übermittlung der Nachricht an die E-Mail-Infrastruktur zur Bereitstellung in dem
adressierten Funktionspostfach [email protected].
3. Nach der Bereitstellung der Nachricht im Funktionspostfach sollte eine Prüfung erfolgen,
ob die nachfolgenden Bedingungen gegeben sind:
1. Die adressierte Stelle ist für die Art der Anfrage zuständig.
2. Die adressierte Stelle ist für die Anfrage des Bürgers direkt zuständig.
3. Die Dateiformate der Anhänge entsprechen den in der Zugangseröffnung genannten
Formaten und sind durch die Sachbearbeiter lesbar.
4. Die rechtlichen Rahmenbedingungen zur Bearbeitung der Anfrage sind gegeben (Bsp.:
Erfüllung der Schriftformerfordernis seitens der De-Mail gemäß BayEGovG).
4. Bei Nichterfüllung der Bedingungen:
1. Zu 3.1: Die Anfrage wird entweder intern oder an eine externe Stelle weitergeleitet. Die
organisatorischen Regelungen zur externen Weiterleitung von sensiblen Daten sind
entsprechend zu beachten.
2. Zu 3.2: Siehe 4.1. Ggf. wird auch der Absender entsprechend darüber informiert, dass
seine Anfrage nicht durch die LHM beantwortet werden kann.
3. Zu 3.3: Bei nicht zulässigen Dateiformaten sollte eine Rückmeldung an den Bürger
erfolgen.
4. Zu 3.4: Sofern das BayEGovG noch nicht vorhanden ist oder die Anfrage im Rahmen
des BayEGovG nicht bearbeitet werden kann, sollte der Bürger eine entsprechende
Rückmeldung erhalten.
5. Bei Erfüllung der Bedingungen:
1. Bearbeiten der Anfrage
2. Ablage oder Speicherung des Vorgangs gemäß entsprechender DA
3. Ggf. Beantwortung der Anfrage: Per De-Mail oder auf dem Briefweg
17.1.3 Nachrichten aus LHM Fachverfahren an Bürger / Partner
Unter Übermittlung von De-Mails aus LHM Fachverfahren heraus, ist der automatisierte Versand
von Nachrichten an Bürger oder Partner (juristische Personen) zu verstehen. Bei diesem Verfahren
werden die Nachrichten durch ein System erstellt und auch elektronisch verschickt. Es kann sich
hierbei um einen einmaligen oder wiederkehrenden Versand handeln. Speziell beim einmaligen
Versand ist davon auszugehen, dass es sich hierbei um Anfragen des Bürgers handelt (z.B. iKFZ).
Beim wiederkehrenden Versand zum Beispiel von Bescheiden wird es sich voraussichtlich um
wiederkehrende Kommunikationspartner (Partner) handeln.
2_63_Fachkonzept De-Mail 1.0.docx
Seite 51 von 57
(1) Externe Voraussetzungen:
 Privatperson besitzt ein De-Mail-Konto und hat über ein Onlineportal eine entsprechende
Anfrage an ein LHM Fachverfahren gestellt und der LHM damit auch gleichzeitig eine
fallbezogene Zugangseröffnung erteilt.
 Der externe Partner hat ein De-Mail-Konto eröffnet und in seiner Außenkommunikation (z.B.
Website) bekanntgegeben (siehe Ziffer 10.2 , Abs. 3) oder hat seinen De-Mail-Zugang auf
seiner Website bekanntgegeben.
 Es wird eine datenschutzkonforme Kommunikation erwartet.

(2) Interne Voraussetzungen
Die zu übermittelnden Informationen liegen digital (als Text oder PDF) vor und stehen auch dem
jeweiligen Fachverfahren zur Verfügung.
 Das jeweilige Fachverfahren lässt sich auf den automatisierten digitalen Versand umstellen und
ist dazu auch technisch in der Lage.
 Die Empfängeradressen lassen sich für den einmaligen oder wiederkehrenden Versand in einer
für das Fachverfahren geeigneten Form speichern.
 Es besteht ein Funktionspostfach, das für den Versand und Empfang von De-Mails
freigeschaltet wurde.
Kommunikationsablauf
In dem Kommunikationsablauf zum Szenario „Nachrichten aus LHM Fachverfahren an Bürger /
Partner“ wird davon ausgegangen, dass die oben beschriebenen Voraussetzungen (Ziffer 1 und 2)
erfüllt sind und der Versand von Bescheiden in digitaler und in Papierform entsprechend in einem
zugrundeliegenden Fachkonzept fachlich ausgearbeitet wurden. Siehe hierzu auch Abbildung 5..
1. Durch das Fachverfahren wird die zu versendende Nachricht (E-Mail) inkl. aller Anhänge
und Versandoptionen (ggf. als X-Header) für den jeweiligen Empfänger generiert.
2. Es erfolgt die Übermittlung der Nachricht (Absender [email protected]) an die E-MailInfrastruktur mit anschließender Übermittlung an das De-Mail-Gateway.
1. Umschreiben der De-Mail-Empfängeradresse in eine gültige E-Mail-Adresse (Bsp.:
[email protected] wird zu [email protected])
3. Nach der Übermittlung der De-Mail an den LHM DMDA übernimmt dieser die Übermittlung
an den DMDA des Empfängers.
4. Eventuelle Rückantworten auf den Versand des Bescheids werden durch die De-Mail- und
E-Mail-Infrastruktur abgeholt.
5. Umschreiben der De-Mail-Empfängeradresse in eine gültige E-Mail-Adresse (Bsp.:
[email protected] wird zu [email protected])
6. Bereitstellung im Funktionspostfach [email protected].
7. Optional erfolgt dann eine Bearbeitung der Rückmeldung oder eine automatische/manuelle
Überführung der Rückmeldung in das Fachverfahren, sofern notwendig.
17.2
Technische und organisatorische Abnahmekriterien
17.2.1 Infrastrukturkomponenten
Unter den Infrastrukturkomponenten sind die technischen Komponenten zu verstehen, welche für
den Datenaustausch zwischen DMDA und LHM zuständig sind (De-Mail-Gateway) sowie die
Komponenten zur Bereitstellung/Versenden von De-Mail-Nachrichten.
2_63_Fachkonzept De-Mail 1.0.docx










Seite 52 von 57
Die unter Ziffer 6 beschriebenen fachlichen Ziele 1.1, 1.2, 1.7 - 1.10, 1.16, 1.17 müssen erfüllt
sein.
Die unter Ziffer 7.3 beschriebenen Geschäftsprozesse GP-1, GP-2, GP-3 und GP-4 müssen
sich durch die Infrastrukturkomponente durchführen lassen.
Die unter Ziffer 8.1 beschriebenen Anwendungsfälle UC-1-4, UC-1-7, UC-1-9 - UC-1-14 müssen
sich durch die Infrastrukturkomponente ausführen lassen.
Die hinsichtlich der Kennzeichnung getroffenen Anforderungen in Ziffer 10.1 werden im Rahmen
der Möglichkeiten durch das De-Mail-Gateway erfüllt.
Die unter Ziffer 10.2.1 beschriebenen Anforderungen werden erfüllt. Hiervon ausgenommen
sind die Kann-Anforderungen in Abs. 6 und 13.
Die unter Ziffer 10.3 beschriebenen Anforderungen werden erfüllt.
Die Integration der Komponenten entspricht entweder der unter Ziffer 11.1 oder Ziffer 11.2
beschriebenen Schnittstellenbetrachtung.
Die De-Mail-Infrastrukturkomponenten können durch eine Monitoringsoftware hinsichtlich
technischer Verfügbarkeit/Erreichbarkeit überwacht werden.
Die unter Ziffer 17.1 beschriebenen Szenarien sind mit den Infrastrukturkomponenten
abdeckbar.
Im Rahmen der De-Mail-Bereitstellung muss ein dauerhaftes, physikalisch und technisch von
der im Betrieb bereitgestellten De-Mail-Infrastruktur vorgehalten werden.
Die Testumgebung darf zur Ausführung der Versandtests nicht mit der produktiven
De-Mail-Adresse beim DMDA verbunden sein oder mit realen Nachrichten arbeiten. Für die
Versandtests sind eine separate Stagingumgebung beim DMDA vorzusehen und Testdaten zu
verwenden.
17.2.2 De-Mail-Adressantrag (DMAA), Einrichtung Postfach
Der De-Mail-Adressantrag beschreibt den Vorgang einer Beauftragung und
Bereitstellung/Freischaltung eines Funktionspostfachs für den Versand und den Empfang von DeMails.
 Die unter Ziffer 6 beschreiben fachlichen Ziele 1.4 und 1.5 müssen erfüllt sein.
 Der unter Ziffer 7.3 beschriebene Geschäftsprozess GP-3 lässt sich ausführen.
 Der unter Ziffer 8.1 beschriebene Anwendungsfall UC-1-10 wird erfüllt.
 Die unter Ziffer 10.3 , Abs. 1 beschriebene Anforderung wird erfüllt.
17.2.3 Support durch den IT-Support
 Im
HelpDesk wurden Personen im Umgang mit der De-Mail geschult und die in Ziffer 14.1
beschriebenen Anforderungen werden erfüllt. Hiervon ausgenommen ist die Kann-Anforderung in
Abs. 4.
17.2.4 Aufgaben des STRAC/Direktorium
 Archiv
und Speicherplatz: Für das De-Mail-Hauptpostfach (Catch-All Postfach, derzeit
[email protected]) muss eine personelle Betreuung festgelegt werden, die neben der
Postfachauslastung (Speicherplatzbelegung) auch die Archivierung der De-Mails beim DMDA
2_63_Fachkonzept De-Mail 1.0.docx
Seite 53 von 57
überwacht. Im Falle einer Komplettauslastung des Postfachspeicherplatzes muss die
Postfachgröße beim DMDA entsprechend erweitert werden. Da keine De-Mails aus dem Postfach
entfernt werden dürfen, muss ständig genug Speicherplatz beim DMDA vorgehalten werden.
Kostenschlüssel: Nach der De-Mail-Anlaufphase, ab Mitte 2015, sollte auf der Basis einer rückwirkenden Versandvolumenbetrachtung ein Kostenschlüssel festgelegt werden
oder eine verbrauchsabhängige Abrechnung zwischen den Referaten erfolgen. Die Kostenverteilung könnte dabei monatsweise auf der Grundlage der Rechnungsstellung des
DMDA oder den Abrechnungsdaten aus der Gateway-Komponente (siehe Ziffer
10.2.1, Abs. 13) erfolgen.
 Regelung
der Nutzung: Vorgaben des Direktoriums (DA, erweiterte AGAM) regeln die generelle
Nutzung der De-Mail und deren Zugängen.
 Hilfeseiten: Im Intranet der LHM wurden entsprechende Seiten bereitgestellt gemäß Ziffer14.2,
auf denen der Umgang mit der De-Mail (analog zur Nutzung der E-Mail) erklärt wird. Es sind
zudem alle Versandoptionen noch einmal erläutert.
 Zugangseröffnung: Die elektronische Zugangseröffnung wurde gemäß der Anforderungen unter
Ziffer 10.2, Abs. 1 erweitert und entsprechend auf der Website der LHM veröffentlicht.
17.2.5 Thunderbird
 Die
unter Ziffer 6 beschriebenen fachlichen Ziele 1.2 und 1.3 müssen erreicht sein.Die unter den
Ziffern 10.1.1 und 10.1.2 beschriebenen Anforderungen wurden im Rahmen
der Möglichkeiten umgesetzt.
17.2.6 Kontact (Kolab)
Da der E-Mail-Client „Kontact“ (Kolab) zum Zeitpunkt der Abnahme der De-Mail Infrastruktur 2014
noch nicht bereitsteht, ist dieser nicht Teil der Abnahme.
2_63_Fachkonzept De-Mail 1.0.docx
Seite 54 von 57
18 Anhänge
18.1
Glossar
Begriff
Erläuterung
AGAM
Allgemeine Geschäftsanweisung der Landeshauptstadt München
API
Programmierschnittstelle (englisch application programming
interface)
BayEGovG
Bayrisches E-Government-Gesetz
BSI
Bundesamt für Sicherheit in der Informationstechnik
DA
Dienstanweisung
DMAA
De-Mail-Adressantrag zur internen Beantragung einer De-MailAdresse
DMDA
De-Mail-Diensteanbieter, siehe auch Provider
DMGW
De-Mail-Gateway
DPS
Digitale Poststelle
EEGW
E-Mail Encryption Gateway (Verschlüsselungs-Gateway)
Funktionspostfach
Funktionspostfach, welches für den Versand und Empfang von
De-Mails konfiguriert oder freigeschaltet wurde.
E-Mail Sammelbüro Siehe Funktionspostfach
LHM
Landeshauptstadt München
PDF
Plattformübergreifendes Dokumentenformat (englisch: portable
document format)
qeS
Qualifizierte elektronische Signatur nach Signaturgesetz (SigG).
SLA
Service Level Agreement
SMTP
Simple Mail Transfer Protocol
VPS
Virtuelle Poststelle (alter Konzeptname, siehe DPS)
VwZG
Verwaltungszustellungsgesetz
Tabelle 11 Glossar der Begriffe im De-Mail Umfeld
2_63_Fachkonzept De-Mail 1.0.docx
18.2













Seite 55 von 57
Quellenverzeichnis
Gesetze im Internet, „Gesetz zur Förderung der elektronischen Verwaltung (E-GovernmentGesetz - EGovG)“. http://www.gesetze-im-internet.de/egovg/BJNR274910013.html
(17.09.2014)
Gesetze im Internet, „De-Mail-Gesetz“ (DeMailG). http://www.gesetze-im-internet.de/de-mailg/BJNR066610011.html (17.09.2014)
Gesetze im Internet, „Verwaltungsverfahrensgesetz (VwVfG)“. http://www.gesetze-iminternet.de/vwvfg/BJNR012530976.html (17.09.2014)
Bayern-Recht, „Bayerisches Verwaltungsverfahrensgesetz (BayVwVfG)“. http://www.gesetzebayern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1&st=null&doc.id=jlrVwVfGBYrahmen&doc.part=X&doc.origin=bs (17.09.2014)
Bayern-Recht, „Bayerisches Verwaltungszustellungs- und Vollstreckungsgesetz (VwZVG)“.
http://www.gesetze-bayern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1&doc.id=jlrVwZVGBYrahmen&doc.part=X (17.09.2014)
Technische Spezifikation De-Mail Headerangaben: BSI – Technische Richtlinie, Postfach- und
Versanddienst Interoperabilitätsspezifikation, Version 1.1.1.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/
De_Mail/TR_De_Mail_PVD_IO_pdf.pdf?__blob=publicationFile (04.06.2014)
NeSsi Fachkonzept, TP111, Secure Mail, Seite 245-254.
BSI, TR-ESOR, „BSI TR-03125 Beweiswerterhaltung kryptographisch signierter
Dokumente„.https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03125/index_ht
m.html (31.07.2014)
Gesetze in Bayern, „Bayerisches Datenschutzgesetz, (BayDSG)“. http://www.gesetzebayern.de/jportal/portal/page/bsbayprod.psml;jsessionid=C49F28031B506C0B802D0167C656
A501.jpf4?showdoccase=1&st=null&doc.id=jlrDSGBY1993rahmen&doc.part=X&doc.origin=bs (31.07.2014)
BSI, TR-01201 De-Mail.
https://www.bsi.bund.de/DE/Themen/EGovernment/DeMail/TechnischeRichtlinien/TechnRichtli
nien_node.html (31.07.2014)
Landeshauptstadt München, „Allgemeine Geschäftsanweisung der Landeshauptstadt
München“. http://intranet.muenchen.de/basis/vor/allg/agam.pdf (17.09.2014)
Wikipedia, „Eigener Wirkungskreis“. https://de.wikipedia.org/wiki/Eigener_Wirkungskreis
(15.10.2014)
Bestehende elektronische Zugangseröffnung der Landeshauptstadt gemäß §3a des VwVfG:
http://www.muenchen.de/rathaus/Kontakt/Elektronische-Kommunikation.html (24.03.2014)
2_63_Fachkonzept De-Mail 1.0.docx
Seite 56 von 57
19 Anhang
19.1
Präsentation zu De-Mail Informationsveranstaltungen
Zur Vermittlung von allgemeinen Informationen rund um das Thema De-Mail wurden
Präsentationen erstellt, um diesen Themenkomplex unterschiedlichen Personengruppen LHM
intern näher zu bringen. Es wurde eine Lang- und eine Kurzversion mit allgemeinen und LHM
spezifischen Informationen zusammengestellt. Das entsprechende Informationsmaterial kann bei
dem E- und Open Government Kernteam abgefragt werden.
19.2
De-Mail Tarif
Im Zuge der geplanten De-Mail-Einführung wurden die monatlichen Kosten und
nutzungsabhängigen Kosten in dem Dokument „De-Mail Tarif für 2014 – 1. Hj 2015“ festgehalten.
Die LHM bleibt daher weiterhin offen für beide DMDA.
19.3
Kolab Konzept
Alle Anforderungen und Beschreibungen hinsichtlich der Kolab „Kontact“ (E-Mail-Client)
Oberflächenanpassungen wurden in dem Dokument „Kolab Oberflächenanpassungen hinsichtlich
De-Mail“ erfasst. Dieses Dokument ist auch die Ausgangsbasis für die Umsetzung.
19.4
Textvorschlag für die elektrische Zugangseröffnung im Rahmen der LHM
Im Rahmen der Eröffnung des elektronischen Kommunikationskanals „De-Mail“ muss zunächst die
Bekanntgabe der Adresse und der Rahmenbedingungen in der Zugangseröffnung für die
Elektronische Kommunikation mit der Stadtverwaltung München13 erfolgen. Da es sich bei dem
Kanal De-Mail um einen eigenen Kommunikationskanal handelt, sollten die Vorgaben für De-Mail
in einem eigenen Abschnitt stehen, damit es zu keiner Verwechselung mit den E-Mail-Vorgaben
kommt.
Folgender Textabschnitt wäre daher in Anlehnung an die erweiterte Zugangseröffnung im Rahmen
der qeS vom 01.17.2014 denkbar:
De-Mail
1. Die Stadtverwaltung München hat das De-Mail-Postfach [email protected]
eröffnet und nimmt Anträge und Mitteilungen im Rahmen von Verwaltungsverfahren über diese und
weitere Adressen innerhalb der De-Mail-Domain muenchen.de-mail.de an. Es gelten im Rahmen
13
Bestehende elektronische Zugangseröffnung der Landeshauptstadt gemäß §3a des VwVfG:
http://www.muenchen.de/rathaus/Kontakt/Elektronische-Kommunikation.html (24.03.2014)
2_63_Fachkonzept De-Mail 1.0.docx
Seite 57 von 57
der Kommunikation via De-Mail auch die Vorgaben 2, 3, 5, 6, 7, 8 und 10 aus dem vorherigen
Abschnitt E-Mail.
2. De-Mails dürfen (inkl. Anhänge) technisch bedingt nicht mehr als 10 Megabyte Umfang
haben.
Herausgeber
Bundesministerium des Innern
IT-Stab, Referat IT I 4
Alt-Moabit 101 D, 10559 Berlin
Bezugsquelle
Bundesministerium des Innern
E-Mail: [email protected]
Internet: www.personalausweisportal.de und www.de-mail.de
Tel.: +49(0)30 18681-0
Fax: +49(0)30 18681-2926
Veröffentlicht
April 2015
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
Landeshauptstadt München
Herr Wolfgang Glock
Marsstraße 22, 80331 München
Tel.: +49.89.233.82410
E-Mail: [email protected]
Internet: www.muenchen.de/rathaus
Diese Veröffentlichung ist Teil der Öffentlichkeitsarbeit der Bundesregierung.
Sie wird kostenlos abgegeben und ist nicht zum Verkauf bestimmt.