Zusammenfassung

Eine Nachricht mit mehreren Absendern

Der From-Eintrag im Nachrichtenkopf ist für Menschen sichtbar. Während des SMTP-Transports werden weitere Namen verwendet: MAIL FROM und EHLO. Ein Weiterleitungsdienst kann den technischen Pfad ändern, während der sichtbare Absender stehen bleibt. Eine im DNS veröffentlichte Liste erlaubter Versandserver beantwortet deshalb erst dann eine brauchbare Frage, wenn der Empfänger festlegt, auf welchen dieser Namen er sie bezieht.

Die MARID-Charta des IETF stellte diese Entscheidung an den Anfang. Sie nannte From, Sender, MAIL FROM und EHLO als mögliche Identitäten. Sender ID nutzte unter anderem den PRA-Algorithmus, um aus Nachrichtenköpfen eine vermeintlich verantwortliche Adresse abzuleiten. SPF prüfte die SMTP-Identität. Beide Verfahren konnten DNS-Richtlinien lesen. Eine gemeinsame Datenquelle machte aus verschiedenen Prüfobjekten jedoch keine einheitliche Prüfung.

Null Dollar, aber ein zusätzlicher Schalter

In seinem offenen Brief an MARID erklärte Apache, die damalige Patentvereinbarung sei mit der Apache License 2.0 unvereinbar. Die Stiftung nannte zwei ihrer E-Mail-Projekte ausdrücklich: den Spamfilter SpamAssassin und den Mailserver JAMES. Beide sollten Sender ID unter diesen Bedingungen nicht übernehmen.

Apache beschrieb konkrete Folgen für die Verteilung. Nach seiner Auslegung ließen sich die Patentrechte nicht ohne weiteres an nachgelagerte Empfänger unterlizenzieren. Wer eine Implementierung umbenennen oder weiterverbreiten wollte, sollte Microsoft kontaktieren. Bei offenem Code ist Weitergabe kein exotischer Sonderfall; sie ist der gewöhnliche Lebenslauf einer Software. Ein privater Ansprechpartner zwischen Entwickler, Paketbetreuer und nächstem Verteiler verändert diesen Lebenslauf auch dann, wenn keine Lizenzgebühr verlangt wird.

Die Stiftung verfügte über die Aufnahme in ihre eigenen Projekte. Sie konnte anderen Unternehmen weder eine Implementierung verbieten noch die spätere Marktentscheidung treffen. Ihre Ablehnung legte vielmehr offen, dass eine öffentlich lesbare Spezifikation und eine für bestimmte Entwickler nutzbare Verteilungslizenz verschiedene Güter sind.

Der IETF veröffentlichte den offenen Streit

Im April 2006 erschienen Sender ID und SPF gleichzeitig als Experimental RFCs. Die IESG-Anmerkung sprach von fehlendem allgemeinem technischen Konsens und gescheiterten Versuchen, die Ansätze zusammenzuführen. Sie warnte, dass Sender ID einen für SPF angelegten DNS-Eintrag mit der falschen Absenderlogik auswerten und eine gültige Nachricht verloren gehen lassen könnte. Auch automatische Weiterleitung und Resent-*-Kopfzeilen blieben ein Interoperabilitätsproblem.

Ein RFC hielt die Entwürfe fest und machte sie untersuchbar. Er zwang empfangende Server aber nicht zu derselben Bedeutung eines DNS-Eintrags. An dieser Stelle wurde aus einem Verfahrensstreit eine Frage der Zustellung.

Die IETF-Bilanz von 2012 stellte eine breite SPF-Nutzung einer schwachen Verbreitung von PRA und SUBMITTER gegenüber. Für beide Seiten gab es Software; fehlende Implementierungen waren laut Bericht nicht ausschlaggebend für die Wahl. Der Bericht beobachtete den Einsatz und traf keinen abstrakten Beweis über die technische Überlegenheit eines Verfahrens. 2014 kam SPF auf den Standards Track. 2020 wurden RFC 4405, 4406 und 4407 zu Historic.

Apaches Nein von 2004 betraf einen klar benannten Vertriebsweg. Die spätere IETF-Bilanz beschreibt die viel größere Entscheidung der Mailbetreiber. Dazwischen stand eine technische Warnung, die sich durch keinen Patentpreis und keinen Dokumentenstatus erledigte: Der Empfänger muss wissen, wessen Berechtigung ein DNS-Eintrag belegen soll.