Vom eMail-Verkehr

E-Mail wirkt von aussen wie die verlässliche Konstante der Netzgeschichte: alt, unansehnlich, aber irgendwie unsterblich. Wer sich mit Sicherheit beschäftigt, sieht dagegen vor allem ein archaisches Protokoll, das für eine Welt entwickelt wurde, in der man noch davon ausging, dass alle Beteiligten sich halbwegs benehmen. Genau an diesem Bruch verläuft die Diskussion, die ich hier nachzeichne.

Ich habe mir den Thread zur Frage eines selbst gehosteten, möglichst „sicheren“ Mailservers genauer angeschaut. Die Spannweite reicht von klassischen Bastelvorschlägen bis zu durchaus ernsthaften Architekturen. Am Ende bleibt jedoch derselbe harte Kern: absolut vertrauliche Kommunikation und klassischer eMail-Verkehr sind strukturell kaum vereinbar. Man kann den Abstand verkleinern, aber nicht auf Null treiben.

Die Ausgangsidee im Thread ist recht naiv und gleichzeitig nachvollziehbar: Ein eigener Mailserver soll so betrieben werden, dass niemand ausser Betreiber und Nutzergruppen Zugriff auf Inhalte erhält, weder Provider, noch Behörden, noch beliebige Dritte. Im Idealfall Zero-Knowledge1, also eine Art ProtonMail2 zum Selberbauen.

Die erste Linie von Antworten greift zu neuen Werkzeugen. Stalwart3 wird ins Feld geführt, ein moderner in Rust implementierter Mail- und Groupware-Server, der MTA4, IMAP5, JMAP6, Kalender, Kontakte und Suchfunktionen in einem konsistenten Stack zusammenfasst und mit „Enhanced Security“ sowie „Encryption at Rest“ wirbt. Die Botschaft lautet: weg vom historisch gewachsenen Konglomerat aus Postfix7, Dovecot8, Amavis9, rspamd10 und ungezählten Kleinteilen, hin zu einem einheitlichen, modernen System.

Eine zweite Stimme setzt auf Bewährtes, konkret auf Mailcow11. Mailcow ist eine dockerisierte Suite aus bekannten Komponenten, die als „all around carefree e-mail server“ vermarktet wird und in der Praxis auf Postfix, Dovecot, rspamd, SOGo12 und weitere Dienste verteilt ist.13 Im Thread taucht dazu ein Setup auf: Hyper-V14 unter Windows, darunter eine Linux-VM, BitLocker15 für Full Disk Encryption16 17, der Mailserver selbst zu Hause, erreichbar über einen vorgeschalteten VPS18, der als VPN19-Endpunkt fungiert. Die Idee dahinter: Kontrolle über Hardware und Storage, verschlüsselte Platten, Kommunikation über einen Tunnel, regelmässige Backups und ansonsten so wenig Magie wie möglich.

Dann die Gegenbewegung. Ein Teilnehmer holt die Diskussion konsequent auf den Boden der Tatsachen: Solange der Server Mails im Klartext akzeptiert, prüft, filtert, in Ordner legt und per IMAP zur Verfügung stellt, kann der Server die Inhalte sehen. Punkt. Dovecot mail_crypt, Stalwart Encryption at Rest, verschlüsselte Dateisysteme, all das hilft gegen „Platte geklaut“ oder „Backup im falschen S3-Bucket“, aber nicht gegen einen Angreifer, der Root-Zugriff auf ein laufendes System erlangt oder den Betreiber rechtlich zwingt, Mails fremdlesen zu lassen.

Die radikalste Position kommt vom Skeptiker: Wer wirklich sicherstellen will, dass nur Sender und Empfänger Zugriff auf Inhalte erhalten, sollte sich ernsthaft fragen, ob eMail überhaupt das passende Vehikel ist. Für vertrauliche Kommunikation, bei der Metadaten, Inhalt und Kontext geschützt werden sollen, eigne sich ein modern konzipierter Messenger wie SimpleX20 oder eine On-Premises-Variante von Threema21 deutlich besser, weil das Protokoll von Beginn an auf Ende-zu-Ende-Verschlüsselung und möglichst geringe Metadatenlecks angelegt ist.

Zwischen diesen Positionen pendelt der Thread hin und her: Mehr Härtung, mehr Verschlüsselung, mehr „Zero Access“ auf Serverseite, aber keine saubere Trennung zwischen Transport, Lagerung und eigentlicher Vertraulichkeit der Inhalte. Genau dort setze ich an.

Threatmodell hinter dem Thread

Ich lese den Thread-Opener so, dass der Wunsch weit über das hinausgeht, was typische Admins unter einem „sicheren Mailserver“ verstehen. Es geht nicht um eine halbwegs robuste Konfiguration, bei der der eigene Server nicht als Spam-Schleuder missbraucht wird und Logins nicht im Klartext herumliegen. Das interessierende Bedrohungsmodell ist deutlich schärfer.

Im Zentrum stehen mehrere Klassen von Gegnern. Da sind zum einen Hoster und Cloud-Anbieter, einschliesslich deren Personal, das mit Root-Zugriff und Zugriff auf Storage, Snapshots und Backups systematisch oder opportunistisch in Datenbestände schauen kann. Dazu kommen staatliche Stellen, die mit Beschlagnahmen, Mirror-Images und forensischer Auswertung arbeiten und sich, je nach Rechtsraum, relativ leicht physische oder logische Zugriffe erzwingen können.

Auf einer zweiten Ebene stehen klassische Remote-Angreifer. Das Spektrum reicht von Massen-Scannern, die offene Ports und bekannte Schwachstellen in Postfix, Exim22, Dovecot oder Webmail-Oberflächen ausnutzen, bis hin zu gezielten Angriffen mit frischen Exploits23 gegen Kernel, Hypervisor oder Kryptobibliotheken. Auch ein scheinbar gut gehärteter Server ist hier keine Festung aus Granit, sondern ein regelmässig aktualisiertes Provisorium.

Schliesslich gibt es den zeitlichen Horizont. Inhalte, die heute verschlüsselt übertragen werden, können aufgezeichnet und später mit anderen Mitteln angegriffen werden. Die Diskussion um „harvest now, decrypt later“24 ist nicht marketinggetriebene Panikmache, sondern eine nüchterne Betrachtung: wer heute grosse Mengen verschlüsselten Verkehrs ausserhalb seiner Kontrolle weiss, muss davon ausgehen, dass Teile dessen in zehn oder zwanzig Jahren nicht mehr denselben Schutzgrad aufweisen wie heute.25

Meine Schutzziele sind entsprechend ehrgeizig. Inhalte von Mails sollen ausschliesslich bei Sender und Empfänger im Klartext vorliegen, nicht bei Providern, nicht bei Hostern, nicht dauerhaft auf dem Server. Metadaten lassen sich nur begrenzt verbergen, aber ihre Verfügbarkeit und Aggregierbarkeit soll minimiert werden. Integrität, also die Unverfälschtheit von Mails, Systemkomponenten und Konfigurationen, soll durchgängig über die gesamte Kette hinweg geprüft werden können. Und der Betrieb selbst soll reproduzierbar, auditierbar und nicht von proprietären „Magic Appliances“ abhängen.

Unter diesem Blickwinkel werden die üblichen „Sicherer Mailserver in 20 Minuten mit Script XY“-Anleitungen zu Karikaturen. Man kann so etwas machen, wenn die eigene Bedrohungslage sich auf Scriptkiddies und krude Spam-Bots beschränkt. Sobald man jedoch ernsthaft davon ausgeht, dass auch staatliche oder konzernielle Akteure Interesse an den eigenen Nachrichten haben, reicht diese Ebene schlicht nicht mehr.

Supply-Chain-Risiken und die Kompilierungsfrage

Auf dieser Ebene kommt schnell die Frage auf, wie man Supply-Chain-Angriffe26 verhindern oder zumindest stark erschweren kann. Wer heute einen „sicheren“ Mailserver betreibt, hängt typischerweise an mehreren Lieferketten: Distributionspakete, Container-Images, externe Repositories, eventuell sogar Binärdownloads von Projektseiten. Jedes dieser Glieder lässt sich manipulieren, ob durch kompromittierte Build-Infrastruktur, böswillige Maintainer oder einfach nur Schlamperei.

Der reflexhafte Vorschlag lautet dann oft: alles selbst kompilieren. Auf den ersten Blick klingt das plausibel. Auf den zweiten wird klar, dass das Problem damit höchstens verlagert wird. Um aus Quelltext vertrauenswürdige Binaries zu bauen, braucht es wieder eine Toolchain, wieder ein Betriebssystem, wieder Bibliotheken. Diese Teile stammen wiederum aus Paketquellen, die ihrerseits Pakete bauen, und so weiter. Wer es ganz ernst nimmt, landet irgendwann beim Verifizieren der Toolchain mittels Reproducible Builds und beim iterativen „Hochziehen“ aus einer minimalen, geprüften Basis.

Vollständige Selbstkompilierung aller Komponenten ist für eine Einzelperson auch mit hoher technischer Kompetenz kaum realistisch. Sinnvoll ist eher eine Hierarchie der Vertrauensstufen. Ganz unten die Hardware und deren Firmware, die nur begrenzt überprüfbar ist. Darauf das Betriebssystem, idealerweise aus einer etablierten Distribution mit halbwegs geregelten Sicherheitsprozessen. Darüber einzelne sicherheitskritische Komponenten, die man bewusst aus dem Standardpfad herauslöst, selbst baut und mit eigenen Signaturen versieht. Dazu gehören etwa Kryptobibliotheken, Kernel, Teilen von OpenSSH, gegebenenfalls auch zentrale Mailkomponenten.

Dieses Modell verschiebt den Angriffsschwerpunkt. Statt sich blind auf jede beliebige Container-Registry oder Paketquelle zu verlassen, schränkt man die Zahl der „Root of Trust“-Stellen ein. Gleichzeitig braucht es Attestationsmechanismen, die sicherstellen, dass genau jene Binaries, die man gebaut und signiert hat, beim Booten und zur Laufzeit tatsächlich eingesetzt werden. Ohne Secure Boot27 mit eigener PKI28, ohne initramfs-seitige Integritätsprüfungen und ohne systematisches Monitoring ist jede Kompilierungsstrategie bloss eine kosmetische Operation.

Am Ende bleibt eine unbequeme Wahrheit: Supply-Chain-Angriffe lassen sich nicht global eliminieren. Man kann ihre Erfolgswahrscheinlichkeit und ihre Auswirkung soweit reduzieren, dass sie nur noch für sehr finanzstarke oder politisch motivierte Akteure attraktiv sind. Wer mehr verspricht, verkauft Esoterik.

Inhärente Unsicherheit des eMail-Protokolls

Selbst wenn man Supply-Chain-Fragen und Kompilierungsproblematik auf ein hohes Niveau bringt, bleibt ein strukturelles Problem: eMail ist als Protokollfamilie nicht für Vertraulichkeit entworfen worden. SMTP29 transportiert Nachrichten von MTA zu MTA, Schritt für Schritt, über eine Kette aus unbekannten Stationen. Jede dieser Stationen sieht Absender, Empfänger, Zeitpunkte, Betreffzeilen, grobe Nachrichtengrösse und, ohne Ende-zu-Ende-Verschlüsselung, den kompletten Nachrichtentext.

Transportverschlüsselung mit STARTTLS30 lindert das Problem nur auf der Leitung, und zwar meist unter dem Label „opportunistic TLS“31. Der Witz daran: es wird verschlüsselt, wenn es geht, und im Klartext gesendet, wenn der Gegenüber das bevorzugt oder erzwungen hat. Downgrade-Angriffe32, bei denen ein aktiver Angreifer die STARTTLS-Aushandlung manipuliert und so die Verschlüsselung verhindert, sind seit Jahren beschrieben. Opportunistische Verschlüsselung schützt vor passiven Lauschohren, nicht vor entschlossenen aktiven Angriffen.

Ansätze wie DANE33 für SMTP versuchen genau dieses Downgrade-Problem zu adressieren, indem TLS-Verpflichtungen und Zertifikate34 über DNSSEC35-vertrauenswürdige TLSA-Records36 publiziert und geprüft werden.37 Damit lassen sich Man-in-the-Middle-Angriffe38 auf Transportebene deutlich erschweren, weil ein Angreifer nicht mehr „einfach“ ein beliebiges Zertifikat unterjubeln kann. Wer DNSSEC und DANE sauber implementiert, hebt die Mindestanforderungen für einen erfolgreichen Angreifer massiv an. Das ist sinnvoll und gehört zum Pflichtprogramm eines ernsthaft betriebenen Mailservers.

All das adressiert jedoch ausschliesslich den Transport zwischen MTAs. Die klassische eMail-Infrastruktur sieht vor, dass Mails beim Ziel-MTA entgegengenommen, in einer Queue gehalten, dann in Mailboxen abgelegt und von Clients über IMAP oder POP339 abgeholt werden. Auf diesem Weg werden Mails geprüft, gefiltert, indiziert, eventuell mit Suchfunktionen und serverseitigen Filtern versehen. All das funktioniert nur, solange der Server die Inhalte lesen kann oder sie zumindest kurzzeitig im Klartext vorliegen.

Anbieter wie ProtonMail setzen deshalb auf eine Mischung aus Ende-zu-Ende-Verschlüsselung40 und sogenannter Zero-Access-Architektur41. Die Mails werden auf Clientseite verschlüsselt oder spätestens beim Eingang auf dem Server mit einem Schlüssel verschlüsselt, der durch das Nutzerpasswort geschützt und serverseitig nicht im Klartext verfügbar ist. Selbst bei Zero-Access-Ansätzen bleibt ein sehr kurzer Moment vor der Verschlüsselung, in dem der Server die Nachricht technisch sehen könnte, allerdings mit massiven Hürden, wenn der Verschlüsselungsprozess korrekt implementiert ist.42

Die klassischen, selbst gehosteten Mailserver-Stacks arbeiten selten in dieser Logik. Sie setzen auf Storage-Verschlüsselung und Transportverschlüsselung, nicht auf echten Ende-zu-Ende-Schutz. Genau deshalb bleibt eMail selbst dann, wenn man alle Härtungsmassnahmen ausreizt, eine strukturbedingt unzuverlässige Hülle für wirklich vertrauliche Inhalte. Man kann sie benutzen, man sollte sich aber nie darüber täuschen, welche Trennlinien damit real gezogen werden und welche eben nicht.

Meine Architekturvorstellung

Trotz dieser strukturellen Probleme halte ich es für möglich, einen eMail-Dienst so zu bauen, dass er sich qualitativ deutlich von der üblichen „VPS plus Copy-Paste-Konfiguration“-Ware abhebt. Der Entwurf, den ich bevorzuge, basiert auf zwei Varianten der Infrastruktur: eigener Bare Metal mit vollständiger Kontrolle oder eine sehr streng konzipierte „Secure Cloud“ mit hardwaregestützter Attestation.

Im ersten Fall steht im Rechenzentrum physischer Hardware, die mir zugeordnet ist und nicht als beliebige Cloud-Ressource mit ständigem Lebenszykluskarussell behandelt wird. Kein wildes Multi-Tenant-Hosting mit zufälligen Nachbarn, sondern eine klar definierte Maschine. Im zweiten Fall nutze ich Virtualisierungstechnik mit Verschlüsselung und Remote Attestation, etwa SEV-SNP43 oder vergleichbare Mechanismen. Nur wenn der Hypervisor und der Virtualisierungsstack einen Zustandsnachweis liefern bekommt der Server den Schlüssel zum LUKS-Container.

In beiden Szenarien gilt eine eiserne Maxime: eine Maschine, ein Dienst. Der Mailserver ist kein Gemischtwarenladen mit Nextcloud, Git, Webhosting und Datenbankzoo, sondern ein Single-Purpose-System. Je weniger Code auf Root-Ebene läuft, desto kleiner die Angriffsfläche, desto leichter die Überwachung.

Darauf kommt ein System, das ich mit einem eigenen Installer, CISS.debian.installer44, auf Basis eines mit dem CISS.debian.live.builder45 erzeugten Images ausrolle. Der komplette Stack beginnt bei LUKS-Full-Disk-Verschlüsselung, inklusive verschlüsseltem /boot, und läuft über einen gehärteten Kernel mit restriktiven Parametern. Secure Boot mit eigener PKI sorgt dafür, dass weder Bootloader noch Kernel ausgetauscht werden können, ohne dass ich es merke.

Auf Netzebene reduziert sich der Expose auf das absolut Notwendige. Öffentlich erreichbar sind Port 25 für SMTP, 465 und 587 für Submission sowie, wenn nötig, 443 für Webmail oder administrative Oberflächen, abgesichert über gegenseitige TLS-Authentifikation oder vorgeschaltete VPN-Zugänge. SSH ist auf dedizierte Admin-IP-Bereiche beschränkt, mit Schlüssel-Authentifikation, gehärteten Algorithmen, Jump-Host-Zwang und zusätzlicher Zwei-Faktor-Komponente.

DNS ist keine nachgeschaltete Nebensache, sondern integraler Bestandteil. Autoritative Zonen laufen auf einer eigenen Nameserver46-Infrastruktur mit DNSSEC, CAA47, TLSA für DANE, MTA-STS48, SPF49 50, DKIM51 und DMARC52. Migration auf 4096-Bit-DKIM-Schlüssel ist Pflicht, DANE und DNSSEC sorgen dafür, dass SMTP-Transportverschlüsselung nicht mehr auf „Opportunistik“ reduziert bleibt, sondern verbindliche Erwartungen an Zertifikate und Ciphers durchsetzt.

Als Mailstack setze ich in dieser Architektur pragmatisch auf Mailcow oder eine vergleichbare Suite. Mailcow bündelt etablierte Komponenten in einer logisch konsistenten Docker-Landschaft und ist ausreichend verbreitet, um Fehler in vertretbarer Zeit zu entdecken und zu beheben. Der entscheidende Punkt liegt nicht darin, ob der MTA nun Postfix statt Exim heisst oder Dovecot statt Cyrus verwendet wird, sondern darin, dass der gesamte Unterbau kontrolliert, attestiert und gehärtet ist. Container sind hier nicht als magische Sicherheitsgrenze interessant, sondern als Bruchkante in der Konfiguration: Dienste lassen sich sauber voneinander trennen, Logs strukturieren und Updates gezielter einspielen.

Auf Storage-Ebene verschlüsselt LUKS die gesamte Platte. Die Schlüssel dafür werden mit Passphrasen, mind. 42 Zeichen hoher Entropie, und KDFs53 versehen, die nicht identisch mit beliebigen Systempasswörtern sind. Backups erfolgen grundsätzlich verschlüsselt, mit Schlüsseln, die nicht auf dem Produktivsystem liegen. Auch hier gibt es Kompromisse: ein vollständiges Zero-Knowledge-Modell bekommt man so nicht, aber das Niveau hebt sich dramatisch gegenüber dem Standard.

Über allem stehen Monitoring und Reaktion. Ein System wie certspotter54, das CT-Logs55 auf unerwartete Zertifikate für eigene Domains überwacht, ist obligatorisch. Ein SIEM56 wertet Logs der Mailkomponenten, des Systems, der Firewall und der Authentifizierungswege aus. Health-Checks prüfen DNSSEC, DANE, MTA-STS, Blacklist-Status, TLS-Konfigurationen, Fehlerraten und Anomalien im Traffic. Wer auf diesem Niveau betreibt, muss sich die Mühe machen, nicht nur harte Oberflächen zu haben, sondern auch mitzubekommen, wenn jemand lang genug dagegen hämmert.

Herausforderungen und Grenzen

Dieser Architekturentwurf ist kein theoretisches Luftschloss, sondern in der Praxis umsetzbar. Er verlangt jedoch eine tiefe Durchdringung der gesamten Kette, viel Disziplin in der Pflege und konstante Aufmerksamkeit. Bereits damit scheidet der durchschnittliche Hobby-Admin aus. Wer nebenbei auch noch Familie, Job und ein halbwegs funktionierendes Leben hat, wird nicht mehrere Stunden pro Woche in Logfiles, Kernel-Changelogs und TLS-Ökosystem investieren.

Hinzu kommt: selbst diese Architektur löst das eigentliche Problem nicht, sondern schiebt es eine Ebene weiter nach oben. Ohne Ende-zu-Ende-Verschlüsselung der Inhalte bleibt der Server stets potentieller Leser. Man kann zwar durch Zero-Access-nahe Konzepte die Zeitfenster verkürzen, in denen Klartext zugänglich ist, und die Hürden erhöhen, aber technisch sitzt der MTA immer in einer Rolle, in der er Metadaten sieht und Inhalte zumindest zeitweise bearbeitet.

Echte Vertraulichkeit erreicht man nur, wenn die eMail bereits auf dem Client verschlüsselt wird und der Server nur noch Ciphertext weiterreicht und lagert. Der Gegenseite muss dasselbe tun. In der Praxis bedeutet das: OpenPGP57 oder S/MIME58 mit konsequenter Schlüsselnutzung, idealerweise Smartcards oder Hardwaretoken, klar definierten Vertrauenspfaden und einem DNS, das SMIMEA59– oder OPENPGPKEY60-Records verlässlich publiziert. Ohne diese Ebene wird aus dem aufwendig gehärteten Mailserver ein sehr sicheres Relais für Klartext.

Selbst mit Ende-zu-Ende-Verschlüsselung bleiben Metadaten ein offenes Scheunentor. Routing-Informationen, Zeitpunkte, Kommunikationspartner, Betreffzeilen, unverschlüsselte Headerfelder, all das bildet ein reichhaltiges Profil dessen, wer wann mit wem in welcher Intensität kommuniziert. Die Protokolle selbst zwingen die meisten dieser Informationen in Klartextfelder, die weder TLS noch E2E verschleiern. Wer diese Ebene nicht nur kosmetisch, sondern ernsthaft angehen will, landet unweigerlich bei anderen Kommunikationsformen.

Genau hier liegt die letzte, unangenehme Einsicht. Man kann eMail so bauen, dass sie nicht mehr zum billigen Beifang für Massenüberwachung taugt, sondern ein ernstzunehmendes Hindernis darstellt. Man kann mit DANE, DNSSEC, Full Disk Encryption, Härtung, SIEM und strengem Betrieb erreichen, dass ein Angreifer, der Shopsysteme und WordPress-Installationen en masse kompromittiert, an diesem System erst einmal abprallt. Man kann es einem Staat deutlich schwerer machen, die eigene Mailinfrastruktur unter Kontrolle zu bringen, ohne dass dies auffällt.

Man kann jedoch nicht gleichzeitig die historische Architektur von eMail mit ihrem Relay- und Store-and-Forward-Modell bewahren und so tun, als liesse sich dadurch ein Medium schaffen, das für hochsensible, langfristig relevante Kommunikation wirklich geeignet ist. Diese Wertung lehne ich ab. Wer sich auf eMail einlässt, sollte die Spielregeln kennen: für viele Dinge nützlich, für bestimmte Dinge schlicht ungeeignet.

Für mich bleibt eMail eine Art notwendiges aber dennoch gerne genutztes Übel. Ich brauche sie für Kontaktaufnahme, für formale Kommunikation mit Institutionen, für allerhand Alltagsschnittstellen, die sich der Moderne verweigern. Ich akzeptiere das, aber ich renoviere das Haus so weit wie möglich: eigene Nameserver, eigene Resolver, eigene gehärtete Infrastruktur, eigener Installer, eigene Schlüssel, transparente Bootketten. Damit erreiche ich, dass ein Angreifer keine billige Einladung vorfindet, sondern ein System, das ihm Zeit, Ressourcen und Nerven frisst.

Gleichzeitig ziehe ich die Grenze dort, wo es um wirklich heikle Inhalte geht. Solche Dinge landen entweder gar nicht im eMail-Verkehr oder nur in Form von sauber implementierter Ende-zu-Ende-Verschluesselung, bei der weder mein Server noch der Server der Gegenseite je eine Klartextkopie sehen. Für viele Menschen mag das wie Paranoia wirken. Ich nenne es nüchterne Konsequenz aus einem Protokolldesign, das aus einer anderen Epoche stammt.

Sicherheit entsteht nicht aus Marketing-Slogans, sondern aus Architektur, Disziplin und der Bereitschaft, Aufwand zu treiben.

  1. https://en.wikipedia.org/wiki/Zero-knowledge_proof ↩︎
  2. https://proton.me/de/mail ↩︎
  3. https://stalw.art/open-source/ ↩︎
  4. https://de.wikipedia.org/wiki/Mail_Transfer_Agent ↩︎
  5. https://de.wikipedia.org/wiki/Internet_Message_Access_Protocol ↩︎
  6. https://de.wikipedia.org/wiki/JSON_Meta_Application_Protocol ↩︎
  7. https://de.wikipedia.org/wiki/Postfix_(Mail_Transfer_Agent) ↩︎
  8. https://de.wikipedia.org/wiki/Dovecot ↩︎
  9. https://de.wikipedia.org/wiki/Amavis ↩︎
  10. https://de.wikipedia.org/wiki/Rspamd ↩︎
  11. https://mailcow.email/ ↩︎
  12. https://de.wikipedia.org/wiki/SOGo ↩︎
  13. https://docs.mailcow.email/ ↩︎
  14. https://de.wikipedia.org/wiki/Hyper-V ↩︎
  15. https://de.wikipedia.org/wiki/BitLocker ↩︎
  16. https://de.wikipedia.org/wiki/Festplattenverschl%C3%BCsselung ↩︎
  17. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system ↩︎
  18. https://en.wikipedia.org/wiki/Virtual_private_server ↩︎
  19. https://en.wikipedia.org/wiki/Virtual_private_network ↩︎
  20. https://simplex.chat/de/ ↩︎
  21. https://threema.com/de ↩︎
  22. https://en.wikipedia.org/wiki/Exim ↩︎
  23. https://de.wikipedia.org/wiki/Exploit ↩︎
  24. https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later ↩︎
  25. https://certified-senders.org/wp-content/uploads/2020/02/Email-Transport-Encryption-STARTTLS-vs.-DANE-vs.-MTA-STS_updated.pdf ↩︎
  26. https://de.wikipedia.org/wiki/Supply-Chain-Attacke ↩︎
  27. https://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot ↩︎
  28. https://de.wikipedia.org/wiki/Public-Key-Infrastruktur ↩︎
  29. https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol ↩︎
  30. https://de.wikipedia.org/wiki/STARTTLS ↩︎
  31. https://en.wikipedia.org/wiki/Opportunistic_TLS ↩︎
  32. https://de.wikipedia.org/wiki/Downgrade-Angriff ↩︎
  33. https://de.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ↩︎
  34. https://de.wikipedia.org/wiki/Digitales_Zertifikat ↩︎
  35. https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions ↩︎
  36. https://de.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_Resource_Record ↩︎
  37. https://datatracker.ietf.org/doc/html/rfc7672 ↩︎
  38. https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff ↩︎
  39. https://de.wikipedia.org/wiki/Post_Office_Protocol ↩︎
  40. https://de.wikipedia.org/wiki/Ende-zu-Ende-Verschl%C3%BCsselung ↩︎
  41. https://de.wikipedia.org/wiki/Zero_Trust_Security ↩︎
  42. https://proton.me/security/end-to-end-encryption ↩︎
  43. https://www.amd.com/en/developer/sev.html ↩︎
  44. https://git.coresecret.dev/msw/CISS.debian.installer ↩︎
  45. https://git.coresecret.dev/msw/CISS.debian.live.builder ↩︎
  46. https://de.wikipedia.org/wiki/Domain_Name_System#Nameserver ↩︎
  47. https://de.wikipedia.org/wiki/DNS_Certification_Authority_Authorization ↩︎
  48. https://de.wikipedia.org/wiki/STARTTLS#MTA-STS ↩︎
  49. https://de.wikipedia.org/wiki/SPF_Resource_Record ↩︎
  50. https://de.wikipedia.org/wiki/Sender_Policy_Framework ↩︎
  51. https://de.wikipedia.org/wiki/DomainKeys_Identified_Mail ↩︎
  52. https://de.wikipedia.org/wiki/DMARC ↩︎
  53. https://de.wikipedia.org/wiki/Schl%C3%BCsselableitung ↩︎
  54. https://github.com/SSLMate/certspotter ↩︎
  55. https://letsencrypt.org/de/docs/ct-logs/ ↩︎
  56. https://de.wikipedia.org/wiki/Security_Information_and_Event_Management ↩︎
  57. https://de.wikipedia.org/wiki/OpenPGP ↩︎
  58. https://de.wikipedia.org/wiki/S/MIME ↩︎
  59. https://datatracker.ietf.org/doc/html/rfc8162 ↩︎
  60. https://datatracker.ietf.org/doc/html/rfc7929 ↩︎

Categories: Digitalisierung, IT-Security, Kryptoanalyse, Kryptographie
Tags: , , , , , , ,

You may also like

Search: