Zusammenfassung

  • RFC 9671 erlaubt Sieve, kalenderlesbare Mailinhalte hinzuzufügen, zu ändern, abzusagen oder zu entfernen, sofern Format-, Ziel- und Sicherheitsbedingungen erfüllt sind.
  • Ohne :calendarid darf ein neues Objekt im implementierungsbestimmten Standardkalender landen; added beweist damit nicht das fachlich richtige Ziel.
  • updated fasst Änderung, Absage und Entfernung zusammen, sodass erst ein Readback den tatsächlichen Kalenderzustand belegt.

Die Reisebestätigung wurde sauber verarbeitet. processcalendar meldete added, die UID war neu und die Nachricht war an die richtige Person zugestellt worden. Trotzdem fehlte der Termin im gemeinsam geführten Reisekalender. Er lag im privaten Standardkalender des Benutzers.

Technisch konnte alles korrekt sein. RFC 9671 sieht :calendarid für das Ziel neuer Objekte vor. Wird das Argument weggelassen, wählt die Implementierung den Standardkalender des Benutzers. Die Rückgabe added beschreibt die Klasse der Mutation, nicht die fachliche Eignung des Ziels.

Damit zeigt sich eine typische Grenze von Automatisierung: Ein wahres Ausführungsergebnis wird zur Behauptung über eine Entscheidung, die außerhalb seines Geltungsbereichs liegt.

Vor dem Ziel kommt die Zulässigkeit

processcalendar erweitert Sieve, damit maschinenlesbare Kalenderdaten in MIME-Nachrichten verarbeitet werden können. Fehlerhafte Daten müssen ignoriert werden. Enthält eine Nachricht mehrere Kalenderteile, muss ihre semantische Gleichwertigkeit geprüft werden. Widersprechen sie sich, darf keine Verarbeitung stattfinden; sind sie gleichwertig, wird nur eine Darstellung verwendet.

Das verhindert, dass der sichtbare Text einen Ort nennt, während der maschinenlesbare Teil einen anderen speichert. Es verhindert auch doppelte Anwendung vermeintlich redundanter Formate. Mehrere Darstellungen dienen der Interoperabilität, nicht der Auswahl einer bequemen Wahrheit.

Die Aktion darf den Teilnahmestatus des Empfängers nicht ändern. Einen Termin einzutragen ist nicht dasselbe wie eine Zusage. Eine Oberfläche, die beides gleich darstellt, erzeugt eine Aussage, die der Sieve-Vorgang nicht getroffen hat.

Empfänger und Organisator bleiben getrennte Rollen

Ohne :allowpublic muss eine wohlgeformte iTIP-Nachricht vorliegen. Eine zum Empfänger gehörende Adresse muss das vom Verfahren bestimmte Ziel treffen: ORGANIZER bei REPLY, ATTENDEE bei REQUEST, CANCEL und ADD. Als Quelle kommen bekannte Kontoadressen, der endgültige Envelope-Empfänger oder :addresses in Betracht.

Diese Quellen haben unterschiedliche Herkunft. Der sichtbare Header ist nicht der endgültige Zustellweg. Ein Alias in :addresses ist eine lokale Erweiterung der Reichweite. Die ATTENDEE-Übereinstimmung beweist Zieladressierung, nicht Befugnis des Absenders oder Zustimmung des Empfängers.

:organizers kann eine externe Zulassungsliste einbinden. Dann muss ORGANIZER mit dieser Liste übereinstimmen und iTIP gültig sein. Fehlt das Argument, validiert RFC 9671 die ORGANIZER-Eigenschaft nicht. Auch eine Übereinstimmung mit einer Liste belegt nur eine konfigurierte Richtlinie, nicht den aktuellen Willen einer Person.

Mail-Authentisierung bleibt ein Vertrauenssignal

RFC 9671 bezeichnet die nicht interaktive Kalenderänderung ausdrücklich als möglichen Missbrauchsweg. Als Spam oder bösartig markierte Nachrichten dürfen nicht verarbeitet werden. Bekannte Absender sollen bevorzugt, potenziell bösartige oder nicht vertrauenswürdige Absender vermieden werden. S/MIME, SPF, DKIM und DMARC können in die Vertrauensentscheidung eingehen.

Jeder Mechanismus hat ein begrenztes Subjekt. SPF verbindet einen beobachteten SMTP-Client mit Domain-Policy. DKIM prüft eine Signatur über ausgewählte Nachrichtenteile unter einer Signing Domain. DMARC bewertet Alignment und Empfängerpolitik. S/MIME verlangt eine Bewertung von Signatur, Zertifikat und Identitätsbindung.

Ein gültiges Ergebnis beweist nicht allein, dass der angezeigte Mensch gerade diese Kalenderänderung wollte. Ein rechtmäßiges Konto kann kompromittiert, eine autorisierte Anwendung falsch konfiguriert oder eine alte Mitteilung erneut ausgelöst sein. Authentisierung bleibt wichtig, solange sie nicht zur erfundenen Absicht erweitert wird.

Vier Werte tragen keinen vollständigen Zustandswechsel

Mit der Variables-Erweiterung erhält :outcome einen der Werte no_action, added, updated oder error. :reason kann erklären, muss aber leer sein, wenn kein Grund verfügbar ist. Eine leere Begründung darf nicht nachträglich mit Vermutung gefüllt werden.

:updatesonly verhindert das Anlegen einer unbekannten UID. no_action kann daher ein gewollter Schutz sein. :calendarid und :updatesonly sind unvereinbar, weil sie verschiedene Betriebsentscheidungen ausdrücken: einen Zielort für neue Objekte versus die Verweigerung neuer Objekte.

Besonders grob ist updated: Der Wert umfasst Inhaltsänderung, Absage und Entfernung. Mit :deletecancelled soll ein abgesagtes Objekt entfernt werden; ohne das Argument bleibt es als abgesagt erhalten. Beide Wege passen unter updated, und das Argument allein beweist keine vollzogene Entfernung.

Der belastbare Nachweis benötigt deshalb zwei Abschnitte. Zuerst: Nachrichten-ID, endgültiger Empfänger, Script-Version, Spam- und Malwareurteil, Authentisierungssignale, alle Kalenderteile, Äquivalenz, iTIP-Methode, UID, ORGANIZER, ATTENDEE, externe Liste, Argumente und aufgelöstes Kalenderziel.

Danach: Readback aus dem Kalender. Existiert die UID? In welchem Kalender? Welche Revision und welcher STATUS gelten? Blieb der Teilnahmestatus unangetastet? Wurden Alarme wie empfohlen entfernt? Wurden eingebettete Anhänge decodiert und geprüft? Bei bösartigem Inhalt darf die Kalenderverarbeitung nicht stattfinden.

Auch die Mail bleibt getrennt. processcalendar hebt den implicit keep von Sieve nicht auf. Der Termin kann verändert werden, während die Nachricht gespeichert bleibt. Das Löschen einer Seite belegt nicht den Zustand der anderen.

CalConnect beschreibt, dass Kalender-Missbrauch Termine beliebig in Vergangenheit oder Zukunft platzieren, Wiederholungen nutzen und Alarme auf mehreren Geräten auslösen kann. Das menschliche Ergebnis endet nicht mit der Filterausführung. Es muss beobachtet werden.

RFC 9671 stellt ein minimales gemeinsames Verfahren bereit. Es entscheidet nicht, welcher Kalender für eine Organisation fachlich richtig ist. Diese lokale Freiheit ist nur dann verantwortbar, wenn ihr Ergebnis sichtbar bleibt.

Sources