Zusammenfassung

  • RFC 3965 behandelt den ausgehenden Faxanruf als eigenständig freizugebende Handlung, nicht als Recht, das automatisch auf alle Mail-Empfänger übergeht.
  • Das Beispiel „Allen antworten“ ist ein hypothetischer Replay-Fall: Die Berechtigung sollte an einen bestimmten Absender und eine bestimmte Nachricht gebunden sein. Der RFC berichtet keinen realen Angriff.

Eine E-Mail-Adresse konnte mehr bezeichnen als ein Postfach. Im Modell von RFC 3965 konnte sie auch zu einem Fax-Offramp führen: Software, die eine Nachricht entgegennahm und anschließend eine Telefonnummer wählte, um ein Group-3-Faxgerät zu erreichen. Damit lagen zwei sehr unterschiedliche Handlungen auf demselben Weg. Die eine transportierte Internet-Mail; die andere konnte Telefonressourcen und Geld verbrauchen.

Diese Grenze gab einer alltäglichen Geste eine unerwartete Wirkung. Wer „Allen antworten“ auswählte, konnte eine neue Nachricht auch an das Fax-Gateway senden, das bereits unter den ursprünglichen Empfängern stand. Verwendete das Gateway die Freigabe des vorherigen Absenders erneut, konnte die Antwort einen weiteren Anruf auslösen, obwohl sie von jemand anderem stammte. RFC 3965 nennt dies ein nicht böswilliges Beispiel für Replay. Es ist ein Bedrohungsszenario, kein Bericht über ein tatsächlich erneut versandtes Fax oder ein kompromittiertes System.

Die Unterscheidung beginnt bei den Feldern, die das Gateway erreichen. Rufnummer und Gateway-Referenz gehören laut RFC in die Transportfelder der Mail, etwa RCPT TO bei SMTP. Der durch die Domain bezeichnete Mail Transfer Agent interpretiert den lokalen Adressteil. Das Gateway ist daher nicht bloß ein kopierbarer Kontakt im Faxadressbuch. Es entscheidet, ob eine Nachricht einen Telefonanruf auslösen darf. Ein Gateway für mehrere Nutzer kann als MTA arbeiten, eines für nur einen Empfänger eher als User Agent.

Auch die sichtbare Adresse beweist nicht, wer die Nachricht verfasst hat. RFC 3965 weist darauf hin, dass tatsächlicher Absender, From oder Sender im Nachrichtenkopf und MAIL FROM im SMTP-Umschlag voneinander abweichen können. SMTP authentifiziert den Verfasser nicht von sich aus. Ein Gateway kann den Ursprung authentifizieren und eine private Berechtigungstabelle prüfen oder nach Quellhost beziehungsweise -netz filtern. Der RFC hält jedoch fest, dass es für diesen Dienst keine standardisierte Autorisierungsmethode in Internetprotokollen gab. Er beschreibt also eine Kontrollgrenze, kein standardisiertes, interoperables Autorisierungstoken.

Die Vorgabe ist konkret: Die Berechtigung sollte sowohl einem bestimmten Absender als auch einer bestimmten Nachricht zugeordnet sein. So wird eine Freigabe für ein Fax nicht stillschweigend zur Befugnis für die nächste Nachricht. Eine identische Empfängerliste genügt nicht. Eine Antwort kann dieselben Adressen behalten und dennoch Verfasser, Inhalt, Zweck und Zeitpunkt ändern. Eine fortgesetzte Unterhaltung bedeutet keine fortgesetzte Autorisierung.

An derselben Grenze drohte eine weitere Offenlegung. Für den Anruf nötige Angaben, etwa eine Telefonkarten-Berechtigungsnummer, konnten als Adressparameter erscheinen und auf der Faxdeckseite gedruckt werden. Der RFC empfiehlt, Absendern eine Möglichkeit zum Unterbinden dieser Offenlegung zu geben, stellt aber fest, dass es damals keine standardisierten Schutzmechanismen gab. Außerdem sollte der Faxempfänger genug Informationen zur Rückverfolgung erhalten; From oder MAIL FROM allein reichen dafür nicht. Autorisierung, Vertraulichkeit und Rechenschaftspflicht hängen zusammen, ersetzen einander aber nicht.

Auch Fehlermeldungen müssen die Stufen auseinanderhalten. Scheitert die SMTP-Weiterleitung, muss eine Fehlermeldung erzeugt werden, möglichst als Delivery Status Notification (DSN). Kann das Gerät den TIFF-Inhalt nicht verarbeiten, ist das ein anderer Fehler; die Benachrichtigung bleibt lokaler Entscheidung überlassen. Eine erfolgreiche Mail-Weiterleitung beweist weder, dass das Fax gedruckt wurde, noch dass es jemand gelesen oder angenommen hat. Auch eine Unzustellbarkeitsmeldung zeigt nicht das Endergebnis am Faxgerät. Die Spezifikation beschreibt mehrere Schritte, aber keinen einzigen Ende-zu-Ende-Beleg.

Die historische Bedeutung von RFC 3965 liegt in der sichtbaren Lücke zwischen Gesprächsverlauf und Ausführungsbefugnis: Die Empfängerliste kann bestehen bleiben, obwohl sich die Autorität jeder neuen Nachricht ändert. Ein vorsichtiges Gateway darf aus der kopierten Faxadresse kein Recht zum Anrufen ableiten. Es muss prüfen, für welchen Absender und welche Nachricht die Freigabe gilt. Der RFC dokumentiert das Designproblem, misst aber weder seine Häufigkeit noch, wie Gateways es tatsächlich gelöst haben.

Quellen: RFC 3965, RFC 2305, RFC 3191, RFC 3192, RFC 3461, RFC 3464, RFC 5321, RFC 5322, RFC 3949, RFC 2306.