Übergang der E-Mail-Infrastruktur des IETF für den 11. September geplant

Thewebbasierte Schnittstelle zur Mailinglisten-Software(Mailman3) wird auch während der Übergangszeit nicht verfügbar sein; der Zugriff aufdie Archivierung der E-Mail-Verzeichnisseund der IMAP-Zugang wird nicht beeinträchtigt.

Die neue E-Mail-Infrastruktur umfasst eine vollständige Neugestaltung vonpostconfirm, einem Open-Source-E-Mail-Filter (Milter) und einer Verarbeitungstools, das als E-Mail-Gatekeeper fungiert – es verhindert unerwünschte Nachrichten und führt erste Senderverifizierungen per E-Mail-basiertem Herausforderung-Antwort-Verfahren durch.

Die neue Software verfolgt einen modularen Ansatz für diese Funktionen und setzt auf neue Spam-Erkennungsprogramm (vonspamassassinzurspamd), neuAdress-Umschreibungssoftwareund Verbesserung der Zertifikats- und TLS-Handhabung fürDANE(DNS-basierte Authentifizierung von benannten Entitäten).

Das Ergebnis wird eine bessere E-Mail-Hygiene sein: verbesserte Bounce-Handhabung, reduzierte Spam-Möglichkeiten und die Möglichkeit, als offener Relay zu dienen, wird beseitigt.

Jede einzelne Funktion wird in einem separaten Container bereitgestellt, über Kubernetes in einem dedizierten Cluster geplant und kommuniziert über dasmilter-Protokoll,um die erforderliche Funktionalität bereitzustellen. Dies ermöglicht es uns, jede Komponente nach Bedarf horizontal zu skalieren. Die Ausnahme von Containern ist die Ausgehenden-E-Mail, die an mehrere virtuelle Maschinen in bekannten, sicheren Netzwerken weitergeleitet wird.

Derpostconfirm milterprüft zunächst die Zieladresse und vergleicht sie mit einem regulären Ausdruck, um festzustellen, ob eine Herausforderung erforderlich ist. Anschließend prüft er gegen eine Tabelle aller zuvor genehmigten Adressen, einschließlich aller aktuellen Abonnenten der Liste, um festzustellen, ob bereits eine Herausforderung beantwortet wurde. Wenn eine Herausforderung erforderlich ist, speichert er eine Kopie der ursprünglichen E-Mail, während er auf die Antwort des Absenders wartet. Sobald die Herausforderung angemessen beantwortet wurde, wird die gespeicherte Nachricht wie ursprünglich gesendet freigegeben und der Benutzer wird zur Liste der genehmigten Adressen hinzugefügt, um zukünftige E-Mails zu empfangen. Diese anfängliche Herausforderung ist entscheidend, um sicherzustellen, dass alle Teilnehmer der Mailingliste der IETF derBitte beachtenErklärung der Richtlinien und Verfahren zugestimmt haben.

DieE-Mail-Umleitungsfunktionist komplexer, da sie die SPF- und DMARC-Richtlinien des Absenders für jede ausgehende E-Mail überprüft. Wenn der Absender-Domäne eine SPF-Richtlinie hat, die unsere IP-Adressen nicht enthält, wird die Absender-Domäne in local-part@domain zu $local-part=40$domain@$ietf-domain umgeschrieben, wobei $ietf-domain auf dem ursprünglichen Zieldomäne basiert, die mit dmarc-präfigiert ist; dmarc.ietf.org, dmarc.irtf.org usw. und stellt so die SPF-Konformität sicher. Wenn der Absender-Domäne eine DMARC-Richtlinie mit p=reject oder p=quarantine hat, wird der Header From auf die gleiche Weise umgeschrieben, $local-part=40$domain@$ietf-domain. Anschließend wird die Nachricht mit dem entsprechenden Domänen-Schlüssel digital signiert, um eine gültige DKIM- und DMARC-Konformität zu gewährleisten. Beispielsweise, E-Mails vondane@email.examplean dietools-discuss@ietf.orgListe würden sowohl die Absender- als auch die Header-Domäne als dane=40email.example@dmarc.ietf.org umgeschrieben werden und es gäbe eine DKIM-Signatur mit d=dmarc.ietf.org, wenn sie an die Abonnenten der Liste geliefert werden. Wenn es sich um einen E-Mail-Post an eine Mailingliste handelt, wird der Return-Path-Header ebenfalls auf einen ähnlichen Wert gesetzt, um die normale Verarbeitung von Bounce-E-Mails für Mailinglisten zu ermöglichen.

Der E-Mail-Umleitungsdienst verarbeitet auch eingehende E-Mails, verarbeitet Bounce-E-Mails und leitet sie an zuvor umgeschriebene Adressen weiter, prüft gegen einen Datenbankeintrag, um sicherzustellen, dass die umgeschriebene Adresse aktuell ist und so die Weiterleitung über den Umleitungsdienst zu verhindern.

Wenn es keine SPF- oder DMARC-Richtlinien für die Absenderadresse gibt, erfolgt keine Adressumleitung.

Zertifikatsverwaltungerfolgt mithilfe einesaktuellen + nächsten 1 1 Rollover-Schemas, wobei die Zertifikate bei Bedarf rotiert und aktualisiert werden, um sicherzustellen, dass wir immer ein Zertifikat haben, das für DANE gültig ist, auch während einer Rotation.

Rspamd bietet DKIM-Signierung und Spam-Bewertungen mit der Möglichkeit, diese nach der anfänglichen Bereitstellung weiter zu optimieren.

Langfristig wird die neue Infrastruktur robuster und skalierbarer, einfacher zu warten und in Zukunft zu aktualisieren. Die heute verwendeten E-Mail-Verarbeitungssoftware und -Infrastruktur haben sich über viele Jahre hinweg zu einer extrem komplexen und schwierigen zu bedienenden und zu aktualisierenden Lösung entwickelt. E-Mail ist entscheidend für die Arbeit im IETF, und diese Aktualisierung bietet eine solide Grundlage für zukünftige Verbesserungen.

Allgemeiner ist der Übergang der E-Mail-Dienste Teil vonmehrjähriger Einsatzzudie gesamte IT-Infrastruktur zu aktualisieren die IETF zu unterstützen. Diese Aktualisierung der E-Mail-Dienste ist ein notwendiger Schritt, um den Teilnehmern der IETF eine integrierte Verwaltung der Mailinglisten und über den IETF Datatracker zu ermöglichen. Die gesamte neue Software ist auf demietf-tools Github-Repository. Feedback und Probleme können über Github oder direkt über dietools-discuss@ietf.orgE-Mail-Verteiler

HINWEIS: New Machine Futuresist ein Auftragnehmer der IETF Administration LLC, der an verschiedenen Komponenten der IT-Infrastruktur-Übergangsphase der IETF arbeitet.