Zusammenfassung

  • Abschnitt 6.5 von draft-ietf-emailcore-as-30 verlangt, dass SMTP-Empfänger technisch Post mit oder ohne Vertraulichkeit der Übertragung annehmen können. Was ein Sender oder Empfänger im Einzelfall tut, soll jedoch lokale Politik bleiben. Der Text befindet sich als Internet-Draft im IESG-Status „AD Followup“ und ist kein veröffentlichter RFC.
  • In Version 29 stand an dieser Stelle noch, Empfänger dürften Vertraulichkeit von Sendern nicht verlangen. Die September-Debatte fragt, welchen Mehrwert die neue Fähigkeitsanforderung hat und ob sie mit einer Betriebspflicht verwechselt werden könnte. Ein abgeschlossenes IESG-Ergebnis ist daraus nicht abzuleiten.

Ein privater Mail-Relay kann TLS zur Bedingung machen und eine Verbindung ohne TLS beenden. Damit ist eine Zutrittsregel beschrieben, nicht sämtliche Möglichkeiten der eingesetzten Software. Ein Hersteller kann beide Empfangswege implementieren, während der Betreiber nur einen freigibt. Für die Fehlersuche ist dieser Unterschied selbstverständlich. In einer Standardschrift mit großgeschriebenem „MUST“ entscheidet er darüber, wer überhaupt verpflichtet wird.

Die drei Sätze in Abschnitt 6.5 der dreißigsten EMAILCORE-Fassung müssen deshalb zusammen gelesen werden. SMTP-Sender sollen Vertraulichkeit verwenden, wenn sie verfügbar ist und der Empfänger sie akzeptiert. SMTP-Empfänger sollen fähig sein, Post mit oder ohne sie anzunehmen. Die tatsächliche Handlung in einer bestimmten Situation ist Sache der lokalen Politik. Version 29 formulierte die Empfängerseite direkter als Verbot, vom Sender Vertraulichkeit auf dem Übertragungsweg zu fordern. Im Änderungsprotokoll ist die Neufassung des Sicherheitskapitels während der IESG-Prüfung vermerkt.

Nicht die Existenz von TLS ist neu, sondern die Zuordnung der Anforderung zu einer Implementierung und ihrem Betrieb.

Die IESG-Prüfung ist dadurch nicht automatisch beendet. Der Datatracker führt Version 30 weiterhin als aktiven Internet-Draft in „AD Followup“. Auf dem Stimmzettel sind DISCUSS-Positionen sichtbar; einzelne wurden gegen Version 29 eingereicht und betreffen verschiedene Fragen. John Klensin erläuterte am 18. September gegenüber Roman Danyliw, dass Teile seiner Antwort persönliche Überlegungen und noch nicht vom Arbeitskreis geprüft seien. Eric Rescorla vertrat am 28. September die Auffassung, eine normative Forderung ohne zusätzlichen Effekt gehöre gestrichen.

Rob Sayre betonte dagegen die Trennung zwischen Implementierungsfähigkeit und Betreiberentscheidung und rechnete mit mehr Betreibern, die TLS verlangen. Das sind zuordenbare Beiträge, weder eine abschließende IETF-Position noch belastbare Messungen der Praxis.

Ein bereits geltender RFC setzt eine engere Grenze. RFC 3207 besagt für STARTTLS, dass ein öffentlich referenzierter SMTP-Server es bei lokaler Zustellung nicht voraussetzen darf; ein nicht öffentlich referenzierter Server darf die Aushandlung verlangen. Diese Regel unterscheidet Serverrollen und einen bestimmten Mechanismus. Sie ist keine pauschale Zusage, jede ungeschützte SMTP-Verbindung anzunehmen. Die neue EMAILCORE-Formulierung wird hingegen als Grundfähigkeit eines Empfangsprodukts diskutiert. Wer beides gleichsetzt, übersieht, warum der jetzige Wortlaut umstritten ist.

Auch REQUIRETLS aus RFC 8689 beantwortet eine andere Frage. Ein einzelner Absender kann für eine Nachricht geschützte Weiterleitung über unterstützende Stationen verlangen und lieber einen Fehlschlag als einen Rückfall auf Klartext hinnehmen. BTW hat diesen nachrichtengebundenen Mechanismus schon behandelt. Daraus folgt nicht, dass eine generische Empfangsimplementierung einen bestimmten Weg anbieten oder ein Betreiber jede Verbindung hereinlassen muss. Nachrichtenvorgabe, öffentliche MX-Regel, Softwarefähigkeit und lokale Annahmeentscheidung sind vier getrennte Ebenen.

Für Hersteller und Betreiber ist die Formulierung mehr als eine semantische Feinheit. Standards-Track-Anwendungshinweise können in Konformitätstests, Ausschreibungen und Handbüchern landen. Wird „muss können“ als „muss zulassen“ verstanden, kann eine technische Basisanforderung fälschlich zur Vorgabe für eine offene Betriebskonfiguration werden. Wird die Fähigkeit aus einem Produkt ganz entfernt, könnte eine seltene Kompatibilitäts- oder Wiederherstellungssituation ein Software-Upgrade statt einer kontrollierten Ausnahme erfordern. Weder die Häufigkeit solcher Fälle noch einen aktuellen Zustellausfall belegt der Entwurf.

Die Grenze zwischen gemeinsamer Fähigkeit und lokalem Risikoentscheid ist noch Gegenstand der Prüfung.

Quellen