Zusammenfassung

  • RFC 5230 ergänzte eine Sieve-Aktion, die eine neue Nachricht an den Envelope-Absender der eingegangenen Mail richtet und festhält, ob diese Adresse dieselbe Antwort bereits erhalten hat.
  • Entscheidend war nicht allein der Abwesenheitstext: Empfängerprüfung, Antwortidentität, Header gegen Rückkopplung und eine begrenzte Wartezeit bestimmten, wer wann benachrichtigt wurde.

Die Abwesenheit konnte auch andere treffen

Eine automatische Antwort wirkt harmlos, weil sie oft nur aus zwei Sätzen besteht. Trotzdem ist sie eine ausgehende Handlung im Namen des Kontoinhabers, ohne dass jeder Empfänger einzeln bestätigt wird. Sie kann eine Abwesenheit offenlegen, an eine Mailingliste antworten oder zwischen zwei unbeaufsichtigten Systemen kreisen. Die Spezifikation musste daher nicht nur festlegen, was das System sagt, sondern auch, wann es schweigt.

2008 nahm RFC 5230 die Aktion vacation in Sieve auf, eine absichtlich eingeschränkte Sprache zur Mailfilterung. Ein Skript konnte melden, dass eine Person nicht sofort antworten werde; der Interpreter erzeugte dann eine separate Nachricht. Es war die erste Sieve-Erweiterung, die eine vollständig neue Mail erzeugen konnte. Damit ging die Wirkung über das Einsortieren hinaus: Eine Filterregel begann eine externe Kommunikation, auf die ein weiteres automatisches System reagieren konnte.

Adressiert wird der SMTP-Envelope-Absender der ursprünglichen Nachricht — MAIL FROM, der nach einer endgültigen Zustellung oft im Return-Path steht — und nicht einfach das sichtbare From-Feld. Die neue Nachricht sollte mit leerem Envelope versandt werden. Ist die Erweiterung für Zustellbenachrichtigungen verfügbar, empfiehlt die Spezifikation, bei einem Fehler keine weitere Benachrichtigung anzufordern. Auto-Submitted kennzeichnet die Antwort als automatisch. Datum, Absender, Empfänger und Thread-Header beschreiben die erzeugte Nachricht offen als Antwort, statt sie als ursprüngliche Mail auszugeben.

Eine Adresse, eine konkrete Antwort, ein Zeitraum

Die wichtigste Zustandsregel fällt leicht unter den Tisch: Vacation merkt sich gesendete Antworten je Adresse und Zeitraum. Dieselbe Person kann während der Abwesenheit erneut schreiben, muss aber nicht bei jeder Mail dieselbe Nachricht bekommen. :days setzt die Sperrfrist. Fehlt der Parameter, gilt der größere Wert aus sieben Tagen und dem lokalen Minimum. Ein Standort darf ein positives Minimum und einen Höchstwert festlegen; Werte außerhalb des Bereichs werden entsprechend begrenzt. Die Zahl im Skript ist somit nicht zwangsläufig die tatsächlich angewandte Frist.

Das ist kein globales Kennzeichen „Abwesenheit gemeldet“. Entscheidend ist, welche Antwort die jeweilige Adresse erhalten hat. Ein explizites :handle gibt mehreren Vacation-Anweisungen dieselbe Antwortidentität. Ohne Handle entsteht sie aus :subject, :from, :mime und dem Begründungstext. So können zwei Zweige demselben Absender unterschiedliche Hinweise senden; identische Argumente teilen dagegen ihre Sperrhistorie. Wenn die Variablen-Erweiterung benutzt wird, darf die Auswertung der Variablen nicht vor dieser Identitätsbildung stattfinden. Maßgeblich sind die angegebenen Argumente, nicht ein Wert, der sich bei jeder Skriptausführung ändern kann.

Die Frist wirkt wie eine kleine Richtliniendatenbank. Ihr Schlüssel ist die Kombination aus Absenderadresse und Antwortidentität. So verhindert das System nutzlose Wiederholungen, ohne eine andere Erklärung für einen anderen Anlass zu sperren. Skriptautor und Betreiber teilen sich die Kontrolle: Der eine beschreibt, welche Antworten gleich sind, der andere begrenzt die effektive Häufigkeit.

Die Nachricht musste an die abwesende Person gerichtet sein

RFC 5230 verlangt, dass die Adresse des Benutzers in To, Cc, Bcc oder passenden Resent-Feldern vorkommt, bevor eine Vacation-Antwort versandt wird. Die Implementierung kann die Adresse aus Kontodaten, dem finalen Envelope-Empfänger oder einer skriptseitigen :addresses-Liste für Aliase ableiten. Bei mehreren Adressen hilft die Liste; Weiterleitungen und Subadressen können eine vollständige Liste jedoch unmöglich machen.

Weitere Vorkehrungen richten sich gegen automatische Systeme und Mailinglisten. Eine Implementierung muss eine Liste von Adressen führen, an die Vacation niemals senden darf; empfohlen werden typische Daemon- und Listenverwaltungsadressen. Auf Mail mit Listenverwaltungs-Headern sowie auf Nachrichten mit einem Auto-Submitted-Wert ungleich no sollte sie nicht antworten. Auch verdächtige Header oder Inhalte dürfen zur Unterdrückung herangezogen werden. Das garantiert nicht, dass jeder Server jeden automatisierten Ablauf erkennt: Manche Adressen bleiben implementationsspezifisch und die Sicherheit hängt davon ab, was die Software beobachten kann.

RFC 3834 hatte 2004 bereits breitere Empfehlungen für automatische Mailantworten veröffentlicht. RFC 5230 erklärt, dass Vacation als persönlicher Responder diesen Leitlinien folgen soll. Spätere Standards erweiterten den Spielraum: RFC 6131 fügte :seconds hinzu, einschließlich null für eine Antwort auf jede Nachricht; RFC 6133 zeigt die Kombination mit Präsenzinformationen und Adressbuch; RFC 8580 erlaubt das lokale Ablegen einer Kopie der erzeugten Antwort. Das dokumentiert technische Möglichkeiten, nicht deren Verbreitung.

Eine neue Nachricht besteht nicht nur aus ihrem Text

Die Erweiterung berücksichtigt UTF-8 und MIME, auch mehrsprachige Alternativen. Ein Skript kann eine Sprache aus Headern ableiten, doch die RFC warnt, dass ein naiver Feldvergleich getäuscht werden kann. Außerdem kann die passende Förmlichkeit davon abhängen, ob ein Kollege oder eine fremde Person schreibt, nicht nur von der Sprache. Die Antwortauswahl ist somit auch eine Entscheidung über ihr Publikum.

Die Aktion bleibt eng begrenzt: Sie darf pro Skript nur einmal ausgeführt werden, ist nicht mit reject oder refuse kompatibel und hebt Sieve’s implizites Keep nicht auf. Das verortet sie in der Sprache, wiederholt aber nicht RFC 3028s allgemeine Analyse von Aktionen. RFC 5230 handelt spezifisch von der Richtlinie für eine neue ausgehende Nachricht: Empfänger, Identität, Header und Wiederholungsfrist.

Die Quellen belegen den Entwurf, nicht eine überall sichere Implementierung. Ein Server kann oft nicht perfekt erkennen, ob eine Mail persönlich adressiert war oder ob ein weitergeleiteter Alias zum selben Konto gehört. Die Spezifikation legt beobachtbare Prüfungen und begrenzten Zustand um eine verlockend einfache Automatik. Die Abwesenheitsantwort war kein gespeicherter Satz, sondern eine zeitlich begrenzte Erlaubnis, an jemanden zu senden.

Quellen