Der Einsatz von E-Mail (SMTP) in der EDI@Energy-Marktkommunikation: Status Quo und Ausblick

Die Digitalisierung der deutschen Energiewirtschaft ruht auf einem entscheidenden Fundament: standardisierte, sichere und automatisierbare Kommunikationswege zwischen Marktpartnern. Nur so lassen sich komplexe Geschäftsprozesse, vom Lieferantenwechsel über Bilanzkreisabrechnungen bis hin zu Redispatch-Prozessen, effizient und rechtssicher abwickeln.

Über die Jahre hat sich dabei eine klare technologische Entwicklung vollzogen. Was einst mit klassischen E-Mail-Übertragungen (SMTP) begann, führte über AS2 zu modernen Protokollen wie AS4 und weiter zu API-basierten, echtzeitfähigen Kommunikationsarchitekturen. Diese Entwicklung spiegelt den Wandel von filebasierten Austauschverfahren hin zu ereignisgesteuerten und sicheren System-zu-System-Verbindungen wider.

SMTP als Fundament der Marktkommunikation

Das Simple Mail Transfer Protocol (SMTP), also das Standardprotokoll für den Versand von E-Mails im Internet, bildete über viele Jahre hinweg das technische Rückgrat der elektronischen Marktkommunikation in der Energiewirtschaft.

Für zentrale Marktprozesse wie GPKE (Geschäftsprozesse zur Kundenbelieferung mit Elektrizität), WiM Strom (Wechselprozesse im Messwesen Strom) oder MaBiS (Marktregeln für die Bilanzkreisabrechnung Strom) diente der Versand von E-Mails als Hauptweg, um strukturierte EDIFACT-Nachrichten zwischen den Marktteilnehmern auszutauschen.

Diese E-Mail-basierte Kommunikation war zwar nicht perfekt, aber sie galt lange Zeit als verlässlich, weit verbreitet und technisch vergleichsweise einfach umzusetzen. Über SMTP konnten Energieversorger, Netzbetreiber und andere Marktpartner standardisierte Datenformate austauschen, um z. B. Lieferantenwechsel, Messdatenübertragungen oder Abrechnungsprozesse zu koordinieren.

Damit die Kommunikation trotzdem den hohen regulatorischen Anforderungen genügte, wurden präzise technische Vorgaben geschaffen:

• Funktionsbezogene Adressen: Jede Marktrolle nutzt eine personenneutrale E-Mail-Adresse (z. B. [email protected]), um eine automatisierte Verarbeitung sicherzustellen [1].
• Strenge Formatvorgaben: Der eigentliche EDIFACT-Inhalt wird als Anhang übertragen, während der E-Mail-Body leer bleibt.
• Verbindliche Sicherheit über S/MIME: Nachrichten müssen signiert und verschlüsselt sein.
  • Signatur: Es ist ausschließlich das Signaturverfahren RSASSA-PSS [1] gemäß IETF RFC 4056 mit den Hash-Algorithmen SHA-256 oder SHA-512 gemäß IETF RFC 5754 zu verwenden.
  • Verschlüsselung: Für die Inhaltsverschlüsselung ist nun AES-128 GCM der verbindliche Standard [2].
    • Übergangsregelung (Sparte Gas): Bis zum 01. Oktober 2025 durften alternativ noch AES-128 CBC oder AES-256 CBC eingesetzt werden. Eigentlich sollte dies bereits mit 01. Oktober 2024 erzwungen werden [3].
    • Für die Sparte Strom war AES-128 GCM bereits verbindlich vorgeschrieben und ist es weiterhin.
• Zertifikate müssen von anerkannten CAs stammen (keine Self-Signed Zertifikate) [4].
• Zertifikatsaustausch: Vor Beginn der Kommunikation müssen Marktpartner ihre öffentlichen Schlüssel austauschen [5].
• Darüber hinaus gibt es noch einige weitere spezifische Vorgaben bzw. Anforderungen.

Wo SMTP heute noch zulässig ist und wo nicht

Heute existiert kein einheitlicher Kommunikationskanal mehr. Die Zulässigkeit von SMTP hängt stark vom jeweiligen Prozess und dessen regulatorischem Umfeld ab.

Klassische EDIFACT-Prozesse
Die von der Bundesnetzagentur (BNetzA) festgelegten EDIFACT-basierten Marktprozesse, wie zum Beispiel GPKE (Geschäftsprozesse zur Kundenbelieferung mit Elektrizität), WiM (Wechselprozesse im Messwesen), MaBiS (Marktregeln für die Bilanzkreisabrechnung Strom), MPES (Marktprozesse für Energielieferanten-Stammdaten), GeLi Gas (Geschäftsprozesse Lieferantenwechsel Gas) und GaBi Gas (Grundmodell für die Bilanzierung im Gasbereich), wurden vollständig auf den modernen, sicheren Übertragungsstandard AS4 (Applicability Statement 4) umgestellt.

Redispatch 2.0

Für den Austausch der operativen, XML-basierten Prozessdaten (z. B. Steuerungsdaten, Nichtbeanspruchbarkeiten) sind gemäß den "Regelungen zum Übertragungsweg" ausschließlich die Protokolle SFTP (Secure File Transfer Protocol) und REST (Representational State Transfer) vorgesehen. Für diesen Datenaustausch ist SMTP für den Regelbetrieb explizit ausgeschlossen.

Fahrplanprozesse (FP) (BKV <-> ÜNB)

Die Fahrplanprozesse (FP) regeln den Datenaustausch zwischen Bilanzkreisverantwortlichen (BKV) und Übertragungsnetzbetreibern (ÜNB) im Rahmen der Fahrplanmeldungen. Fahrplanmeldungen, auch Schedule Messages genannt, dienen der Übermittlung geplanter Energieflüsse, die von den ÜNB zur Systembilanzierung und Netzstabilität verwendet werden.

Ab dem 01. Dezember 2024 ist der Versand und Empfang von Fahrplanmeldungen sowie der zugehörigen Rückmeldungen (ACK; Empfangsbestätigung, ANO; Ablehnung, CNF; Bestätigung) per SMTP m Regelbetrieb für alle Bilanzkreisverantwortlichen untersagt. Der Nachrichtenaustausch hat dann ausschließlich über den sicheren Kommunikationsstandard AS4 (Applicability Statement 4) zu erfolgen.

In Notfällen, also bei einer technischen Störung der primären AS4-Kommunikation, darf E-Mail ausnahmsweise als Ersatzweg genutzt werden. Dabei gilt zwingend:

• Jede E-Mail muss signiert und verschlüsselt nach dem S/MIME-Standard versendet werden.
• Nicht signierte oder unverschlüsselte Nachrichten werden nicht verarbeitet.

Zu beachten ist außerdem: Probleme mit Zertifikaten (z. B. abgelaufene, nicht erneuerte oder nicht ausgetauschte Zertifikate) gelten nicht als technische Störung und rechtfertigen keine Nutzung des E-Mail-Verfahrens! Einige Bilanzkreisverantwortliche nehmen in der Praxis zwar vereinzelt nicht konforme Nachrichten an, klären diese jedoch dann direkt im Rahmen einer individuellen 1:1-Kommunikation außerhalb des regulären Prozesses.

Verpflichtende Technische und Kryptografische Details (S/MIME)

Für die im Rahmen der zulässigen E-Mail-Kommunikation gemäß RD2.0- bzw. Fahrplan-Notfallprozessen geltenden Vorgaben sind die in der RzÜ Version 1.9 (gültig ab dem 01. Oktober 2025) [3] definierten technischen und kryptografischen Anforderungen verbindlich einzuhalten. Grundlage bildet die BSI-Technische Richtlinie TR-03116-4 [7].

Kryptografische Spezifikationen:
Die Inhaltsverschlüsselung (Content Encryption) ist verpflichtend mittels AES-128 GCM gemäß IETF RFC 5084 umzusetzen. Die bisherige Ausnahmeregelung, welche die Nutzung von AES-128 CBC oder AES-256 CBC erlaubte, ist mit Wirkung zum 01. Oktober 2025 ausgelaufen. Für Zertifikate, die ab dem 01. April 2022 ausgestellt wurden, gilt eine minimale Schlüssellänge von 3072 Bit für RSA. Es ist mindestens S/MIME Version 4.0 gemäß IETF RFC 8551 (2019) zu verwenden. Für jede E-Mail-Adresse ist exakt ein Kombinationszertifikat einzusetzen, das sowohl für Signatur als auch Entschlüsselung genutzt wird.

Allgemeine E-Mail-Struktur und Formatierung:
Zur Sicherstellung eines "hohen Automatisierungsgrades" auf Empfängerseite sind folgende Formatierungsregeln strikt zu beachten:

• Die verwendete E-Mail-Adresse muss eindeutig dem Kommunikationsprozess zugeordnet und eindeutig identifizierbar sein. Es dürfen keine für die Verarbeitung relevanten Informationen im Nachrichteninhalt (Body) enthalten sein [1].
• Jede E-Mail darf ausschließlich eine Übertragungsdatei (EDIFACT-, Fahrplan- oder RD2.0-Datei) als Anhang enthalten; zusätzliche Anhänge sind unzulässig. Der Anhang ist Base64-kodiert zu übermitteln [1].
• Der E-Mail-Betreff muss exakt dem Dateinamen des Anhangs entsprechen, einschließlich Dateiendung [1].
• Die für den Austausch von Fahrplandaten festgelegte E-Mail-Adresse ist ausschließlich für den Austausch von Fahrplandaten zu nutzen (wenn der Notfall-Kommunikationsweg genutzt wird).

Organisatorische Pflichten beim Zertifikatsaustausch:
Für die Sicherstellung der Ende-zu-Ende-Verschlüsselung und der Signaturprüfung ist der empfangende Marktpartner verpflichtet, ein gültiges S/MIME-Zertifikat bereitzustellen. Der Zertifikatsinhaber hat spätestens zehn Werktage vor Ablauf des bestehenden Zertifikats das Nachfolgezertifikat an alle relevanten Marktpartner zu verteilen, um eine unterbrechungsfreie und vertrauenswürdige Kommunikation zu gewährleisten.

Konsequenzen bei Nichteinhaltung der E-Mail-Sicherheitsvorgaben

Die Einhaltung der definierten Sicherheitsvorgaben für Signatur und Verschlüsselung ist zwingende Voraussetzung für die Gültigkeit der E-Mail-Kommunikation im Rahmen der RD2.0- und Fahrplanprozesse. Ein Verstoß gegen diese Anforderungen wird als Nichtzustellung der Übertragungsdatei gewertet. Die nachfolgend beschriebenen Szenarien legen die jeweiligen Konsequenzen und Verantwortlichkeiten fest [3].

1. Verstoß 1: Fehlendes gültiges Zertifikat des Empfängers:
   Stellt der Empfänger kein gültiges Zertifikat zur Verfügung, kann der Sender die E-Mail-Nachricht nicht verschlüsseln. In diesem Fall ist der Sender berechtigt, die Kommunikation zu verweigern. Sämtliche daraus resultierenden Konsequenzen, insbesondere Fristversäumnisse oder Datenübertragungsverzögerungen, trägt der Empfänger als Verursacher.
2. Verstoß 2: Fehlende oder ungültige Signatur (Integritätsverletzung):
   Ist eine eingehende E-Mail nicht signiert oder weist die Signatur Fehler auf, gilt die Integrität der Nachricht als verletzt. Der Empfänger ist berechtigt, die Verarbeitung dieser Nachricht abzulehnen. Die Verantwortung für den Verstoß liegt beim Sender. Der Empfänger hat den Verursacher über den Vorfall zu informieren (soweit ich weiß lediglich einmalig).
3. Verstoß 3: Fehlgeschlagene Entschlüsselung
   Die E-Mail ist verschlüsselt, aber mit einem Schlüssel, der nicht zum aktuellen Zertifikat des Empfängers gehört. Der Sender trägt die Konsequenzen, Empfänger ist zur Ablehnung berechtigt.
4. Verstoß 4: Fehlende Verschlüsselung bei vorhandener Signatur:
   Wird eine E-Mail lediglich signiert, jedoch unverschlüsselt übermittelt, ist die Vertraulichkeit der enthaltenen Informationen nicht gewährleistet. Der Empfänger ist in diesem Fall berechtigt, die Verarbeitung zu verweigern.
5. Verstoß 5/6 (nur RD2.0): Fehlende gzip-Komprimierung der XML-Nachrichtendatei:
   Für RD2.0-Prozesse ist die Übertragung der XML-Nachrichtendatei ausschließlich in gzip-komprimierter Form zulässig. Wird diese Vorgabe nicht erfüllt, darf der Empfänger die Verarbeitung ablehnen. Der Sender (Verursacher) ist über den Verstoß zu informieren.

Quellenangaben:
[1] 20211011_security and protection mechanisms to be used for electronic data transfer_Vers Feb 2021.pdf, [2] Regelungen_zum_Übertragungsweg_1.9.pdf, [3] Regelungen_zum_Übertragungsweg_1.8_v04.pdf, [4] Regelungen_zum_sicheren_Austausch_im_Fahrplanprozess.pdf, [5] EDI@Energy Regelungen zum Übertragungsweg 1.4.pdf, [6] Redispatch 2.0 Anwendungsempfehlung des BWE-Betriebsführerbeirates, [7] BSI TR-03116-4 Kryptographische Vorgaben für Projekte der Bundesregierung Teil 4 Stand 2025

Rechtlicher Hinweis:
Dieser Beitrag stellt keine rechtsverbindliche oder individuelle Beratung dar. Eine verbindliche Bewertung erfordert stets die Prüfung der jeweils einschlägigen Marktregeln, Vereinbarungen und technischen Spezifikationen im konkreten Einzelfall.

Da sich die regulatorischen und technischen Vorgaben im Umfeld der EDI@Energy-Marktkommunikation laufend ändern, ist in jedem Fall zu prüfen, ob zwischenzeitlich neue oder abweichende Regelungen veröffentlicht wurden.

Der Artikel gibt den Stand der Informationen zum Zeitpunkt der Veröffentlichung nach bestem Wissen wieder. Alle Quellen wurden sorgfältig geprüft, dennoch können Änderungen oder Fehler nicht ausgeschlossen werden.

Es wird empfohlen, die jeweils aktuellen Regelungen zum Übertragungsweg, BSI-Vorgaben sowie BNetzA-Veröffentlichungen regelmäßig zu prüfen und bei Unsicherheiten fachkundige Beratung einzuholen.