Zusammenfassung

  • RFC 3098 verstand unerbetene Werbung als Kostenverschiebung in einem gemeinsamen Netz. Die Antwort war eine eigene Liste williger Empfänger, bei der Nichtteilnahme der Ausgangszustand blieb.
  • Eine sofortige Bestätigung sollte Adresse, Übermittlungsweg, Zeit, Quellhost, Header, Werbenden und Abmeldung zeigen. Sie machte die Anmeldung bestreitbar, nicht automatisch echt.

Billiger Versand beseitigte die Rechnung nicht

Bei E-Mail kostete eine weitere Adresse den Sender fast nichts. Empfänger und Provider zahlten dennoch Verbindung, Speicher, Betrieb, Filter und Aufmerksamkeit. RFC 2635 beschrieb diese Umkehr: Anders als bei Papierpost trug im elektronischen Massenversand die nicht bestellende Seite einen großen Teil der Kosten.

RFC 3098 begann 2001 mit genau dieser Ökonomie. Das Internet sei keine kostenlose Ressource: Eine Anzeige durchquerte private Systeme, verbrauchte Infrastruktur und belegte fremde Postfächer. Technische Leichtigkeit machte diese Güter nicht herrenlos.

Das Dokument verbot Handel nicht. Es suchte die Grenze, an der ein Werbender Aufmerksamkeit gewinnen konnte, ohne Fremde seine Suche finanzieren zu lassen. Geeignete Orte, sichtbare Identität, Erlaubnis der Systeme und Verantwortung für die Zielgruppe gehörten dazu.

Eine gekaufte Liste kaufte keine Erlaubnis

Zusammengestellte Listen konnten aus abgesaugten Archiven, geratenen Adressen, veralteten Datensätzen und ehemaligen Beschäftigten bestehen. RFC 3098 warnte sogar vor Anbietern, die Abmeldewünsche als neue Interessenten weiterverkauften.

Der Kauf lagerte Verantwortung nicht aus. Zielauswahl, Identität, Systemerlaubnis und Wartung blieben beim Werbenden, der den Nutzen erwartete. Auch eine selbst aufgebaute Liste williger Empfänger sollte nicht verkauft werden: Die Erlaubnis für ein Unternehmen ging nicht stillschweigend an Partner über.

Die Liste verkörperte eine begrenzte Beziehung zwischen Adresse und benanntem Absender, keinen kontextfreien Vermögenswert.

Der Vorgabewert bestimmte, wer handeln musste

Das Kontrollkästchen gehörte zu einem Datenschutzentwurf. Eine Person musste die Erhebung kennen, bei geplanter Mailnutzung eine klare Erklärung sehen und die eigentliche Information auch ohne Werbung abgeben können.

RFC 3098 empfahl Nichtempfang als Standard. Die Aufnahme erforderte eine bewusste Handlung, etwa das Markieren einer Bitte um Produktnachrichten. Die Trägheit der Oberfläche schützte die Nichtteilnahme.

Damit kehrte der Akquisitionsaufwand zum Werbenden zurück. Er musste eine positive Wahl gewinnen, statt eine Vorbelegung oder einen versteckten Nebenzweck zu nutzen. Die Liste wuchs vielleicht langsamer, doch jeder Eintrag stand näher an einer ausdrücklichen Bitte.

Ein Kästchen bewies weder Verständnis noch menschliche Urheberschaft oder universelle Rechtmäßigkeit. RFC 3098 erkannte unterschiedliche Rechtsräume an und ließ die Prüfung beim Werbenden. Historisch entscheidend waren Vorgabe und Kontrolle, nicht die Form des Widgets.

Bestätigung schuf eine anfechtbare Spur

In ein öffentliches Formular kann jeder eine fremde Adresse schreiben. RFC 3098 trennte deshalb Anfragedaten von Echtheit. Nur der Inhaber der eingetragenen Adresse könne die Anmeldung bezeugen; jede Einreichung solle sofort bestätigt werden.

Die Bestätigung sollte mehr als Willkommen enthalten: Adresse, Übermittlungsart, Datum und Uhrzeit, IP des Quellhosts, vollständige Header soweit vorhanden, Name und Kontakte des Werbenden sowie dauerhafte Entfernung. Bei fremder Eintragung konnte der Inhaber das Ereignis entdecken.

Das war ein frühes Herkunftspaket für eine Geschäftsbeziehung. Ein Streit erhielt Zeitpunkt, Route und Quelle. Die Grenzen blieben: Eine IP identifiziert keinen Menschen, Zustellung beweist keine Initiierung durch den Inhaber, Header schaffen keine Autorisierung. Der Mechanismus bot Mitteilung und Widerspruch.

Der Austritt schloss den Regelkreis

Wünsche ändern sich. RFC 3098 verlangte eine Abmeldung und den Schutz der Listendaten. Eine durch Wahl begonnene Beziehung brauchte einen erreichbaren Ausgang.

RFC 2369 standardisierte List-Unsubscribe, RFC 2142 Betriebsadressen wie ABUSE und POSTMASTER. RFC 2505 und RFC 3013 behandelten Relais und Betriebsverantwortung. Absenderpraxis, Empfängerkontrolle, Maschinenbefehle und Infrastrukturschutz waren verschiedene Ebenen.

Keine Ebene garantierte Vollzug. Ein Header kann auf einen defekten Mechanismus zeigen. Beweisfähig ist die ganze Folge: Anfrage, Mitteilung, Reaktion, Ende späterer Sendungen und weiterer Umgang mit der Adresse.

Rat, Betrieb und Recht blieben getrennt

RFC 3098 war Informational und FYI 38, weder Standards Track noch Gesetz oder Zertifikat. Eine Verbreitungsmessung enthielt es nicht. Es beschrieb empfohlene Kontrolle, nicht beobachtete Umsetzung.

Der US-amerikanische CAN-SPAM Act folgte 2003. Die FTC beschreibt gesetzliche Identifikations- und Austrittspflichten. Diese spätere Autorität darf ohne Gesetzgebungsgeschichte weder als Umsetzung noch als Produkt des RFC dargestellt werden. Es sind getrennte Autoritätsketten.

Der bleibende Beitrag lag in beobachtbaren Entscheidungen: Wer setzt die Vorgabe, besitzt die Liste, bewahrt den Antrag, zeigt Identität und erfüllt den Austritt? Kontrolle und Kosten blieben bei dem, der kommerziellen Gewinn suchte.

Das Modell garantiert keine Einwilligung, Ehrlichkeit oder Rechtskonformität. Es macht die Behauptung einer Erlaubnis prüfbar und gibt Empfängern einen Widerspruchsweg. Bevor Einwilligung zum allgegenwärtigen Oberflächenwort wurde, erkannte RFC 3098, dass Kästchen, Bestätigung und Listenbesitz Macht im gemeinsamen Netz verteilten.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3098.html
  2. https://www.rfc-editor.org/info/rfc3098
  3. https://datatracker.ietf.org/doc/rfc3098/
  4. https://www.rfc-editor.org/rfc/rfc2635.html
  5. https://www.rfc-editor.org/info/rfc2635
  6. https://datatracker.ietf.org/doc/rfc2635/
  7. https://www.rfc-editor.org/rfc/rfc2505.html
  8. https://www.rfc-editor.org/info/rfc2505
  9. https://datatracker.ietf.org/doc/rfc2505/
  10. https://www.rfc-editor.org/rfc/rfc1855.html
  11. https://www.rfc-editor.org/rfc/rfc2142.html
  12. https://www.rfc-editor.org/rfc/rfc2369.html
  13. https://www.rfc-editor.org/rfc/rfc3013.html
  14. https://www.ftc.gov/legal-library/browse/statutes/controlling-assault-non-solicited-pornography-marketing-act-2003-can-spam-act