Die Ausgangslage

Agenten, die etwas Nützliches tun sollen, brauchen irgendwann einen Kanal nach außen. E-Mail ist dafür naheliegender, als es zunächst wirkt: Sie ist asynchron, sie hinterlässt eine Spur, und fast jedes System kann sie erzeugen. Ein Agent, der Berichte verschickt oder auf eingehende Anfragen reagiert, braucht also eine Adresse.

Die schnellste Lösung wäre, ihm die Zugangsdaten eines vorhandenen Postfachs zu geben. Genau davon handelt der erste Teil dieses Beitrags, denn es ist die Variante, die man später bereut.

Warum der Agent eigene Zugangsdaten bekommt

Drei Gründe sprechen gegen das Mitbenutzen, und alle drei zeigen sich erst, wenn etwas schiefgeht.

Der erste ist die Abschaltbarkeit. Ein Agent, der in eine Schleife gerät oder dessen Zugangsdaten irgendwo landen, wo sie nicht hingehören, muss sich abklemmen lassen, ohne dass dabei das eigene Postfach stillsteht. Mit geteilten Zugangsdaten ist jede Sperrmaßnahme eine Entscheidung gegen den eigenen Mailverkehr.

Der zweite ist die Nachvollziehbarkeit. Im Protokoll des Mailservers steht bei jedem Versand der Anmeldename, unter dem eingeliefert wurde. Teilen sich Mensch und Agent diesen Namen, lässt sich hinterher nicht mehr sagen, wer eine Nachricht ausgelöst hat. Das ist genau die Frage, die man sich stellt, wenn eine Mail rausgegangen ist, die nicht hätte rausgehen sollen.

Der dritte ist der Wirkungskreis. Ein Postfach, das einem Agenten gehört, kann man eng halten: kleine Quota, eingeschränkte Protokolle, eigenes Sendelimit. Ein Postfach, an dem auch der eigene Mailverkehr hängt, kann man das nicht, ohne sich selbst einzuschränken.

Ein Postfach je Agent? Besser nicht

Aus dem gleichen Gedanken heraus liegt der nächste Schritt nahe: für jeden weiteren Agenten wieder ein eigenes Postfach. Das skaliert schlechter, als es aussieht.

Mailserver begrenzen Domains üblicherweise doppelt, über die Anzahl der Postfächer und über den insgesamt vergebenen Speicher. Die zweite Grenze wird zuerst erreicht. Wer jedem Agenten ein Gigabyte zuteilt, ist nach einer Handvoll Agenten am Ende des Budgets, und zwar unabhängig davon, wie viele Postfächer die Domain noch erlauben würde. Die Postfächer sind dabei fast alle leer, weil ein Agent selten große Mengen aufbewahrt.

Der bessere Weg ist Plus-Adressierung. Eine Adresse mit einem Pluszeichen und einem frei wählbaren Zusatz wird demselben Postfach zugestellt, ohne dass dafür etwas angelegt werden muss. Aus einer Adresse werden damit beliebig viele, und jede davon lässt sich einer Aufgabe zuordnen.

agent@beispiel.tld          → Postfach des Agenten
agent+recherche@beispiel.tld → dasselbe Postfach
agent+berichte@beispiel.tld  → dasselbe Postfach

Gängige Mailserver können diese Zusätze zusätzlich automatisch in Unterordner einsortieren. Die Einstellung heißt je nach Oberfläche anders, meint aber immer dasselbe: Der Teil nach dem Pluszeichen wird zum Ordnernamen. Damit hat jede Aufgabe ihren eigenen Posteingang, ohne ein einziges zusätzliches Konto.

Das Limit, an das niemand denkt

Ein Mensch schreibt am Tag vielleicht dreißig Mails. Ein Agent in einer Schleife schreibt dreißig in der Minute, und er merkt es nicht. Genau dafür haben Postfächer ein Sendelimit, das in den meisten Installationen abgeschaltet ist, weil es für Menschen nie nötig war.

Der Schaden ist dabei nicht die Mailflut selbst, sondern was danach passiert. Die Zustellbarkeit einer Domain hängt an ihrem Ruf bei den Empfängern, und dieser Ruf ist in Stunden zerstört und in Wochen zurückgewonnen. Wer sich einmal mit PTR-Einträgen, SPF und DKIM beschäftigt hat, um überhaupt zugestellt zu bekommen, möchte das nicht an einer Endlosschleife verlieren.

Passwörter, die man nur einmal sieht

Beim Anlegen des Postfachs gibt es einen Passwortgenerator, und der ist eine kleine Falle. Seine Voreinstellung ist auf Bedienbarkeit ausgelegt, nicht auf Länge. Für ein Konto, dessen Zugangsdaten dauerhaft in einer Konfigurationsdatei liegen und das niemand je von Hand eintippt, gibt es keinen Grund, an der Länge zu sparen.

Wichtiger ist die Reihenfolge: Nach dem Absenden ist das Passwort nicht mehr auslesbar. Die Oberfläche zeigt beim Bearbeiten leere Felder, und das ist richtig so. Wer es vorher nicht gesichert hat, setzt es neu. Das kostet wenig, aber man merkt es genau dann, wenn man es eilig hat.

Für den Agenten selbst ist ein anwendungsgebundenes Passwort die bessere Wahl, wenn der Mailserver das anbietet. Es gilt nur für den Zugriff, für den es ausgestellt wurde, und lässt sich einzeln zurückziehen, ohne das Hauptpasswort zu ändern und überall nachzuziehen. Bei einem Agenten, der auf einem anderen Rechner läuft als der Mailserver, ist das der Unterschied zwischen einem Widerruf und einer Suche nach allen Stellen, an denen das Passwort hinterlegt wurde.

Angelegt heißt nicht empfangsbereit

Das Postfach steht in der Liste, es ist aktiv, die Quota stimmt. Damit ist bewiesen, dass ein Datenbankeintrag existiert, und sonst nichts. Ob tatsächlich Post ankommt, hängt an einer Kette aus Empfang, Spamprüfung und Zustellung, und jedes Glied davon kann eine Mail verschwinden lassen, ohne dass die Oberfläche etwas anderes anzeigt als vorher.

Die belastbare Prüfung ist eine Testmail, deren Weg man im Protokoll verfolgt. Zu sehen sein muss die Übergabe an die Zustellkomponente mit einem Ergebnis, das Annahme bedeutet.

to=<agent@beispiel.tld>, relay=dovecot, delay=2,
  dsn=2.0.0, status=sent (250 2.0.0 Saved)

Interessant sind dabei zwei Angaben. Der Status sent heißt, dass die Nachricht angenommen wurde und nicht etwa in einer Warteschlange liegt. Der Antwortcode 250 mit dem Hinweis auf das Speichern kommt von der Zustellkomponente selbst und belegt, dass die Nachricht tatsächlich in einem Ordner gelandet ist.

Der Junk-Ordner, den es noch nicht gibt

Damit ist eine Frage noch offen: In welchem Ordner liegt die Nachricht? Das Protokoll verrät es nicht. Eine Mail, die der Spamfilter aussortiert hat, ist ebenfalls zugestellt und erzeugt dieselbe Erfolgsmeldung.

Die Antwort holt man sich direkt vom Mailspeicher, indem man die Nachrichtenzahl je Ordner abfragt. Bei einem frisch angelegten Postfach ergibt sich dabei ein Nebeneffekt, der die Sache angenehm eindeutig macht.

doveadm mailbox status -u agent@beispiel.tld messages INBOX Junk

INBOX messages=1

Der Junk-Ordner fehlt in der Ausgabe, und das ist kein Fehler. Er wird erst angelegt, wenn er zum ersten Mal gebraucht wird. Solange er nicht existiert, hat der Spamfilter noch nie etwas aussortiert. Bei einem neuen Postfach ist seine Abwesenheit also ein stärkerer Beleg als jede Zahl, die dort stehen könnte.

Bei einem Postfach, das schon länger läuft, gilt das nicht mehr. Dann hilft nur der Vergleich: Ist die Zahl im Posteingang um eins gestiegen oder die im Junk-Ordner?

Zwei Prüfungen, die den Unterschied machen

Die erste ist der Blick ins Protokoll statt auf die Oberfläche. Eine Verwaltungsmaske zeigt den gewünschten Zustand, nicht das Verhalten. Sie kann gar nicht anzeigen, dass eine Mail später am Spamfilter hängen bleibt, weil sie den Weg einer Mail nicht kennt. Erst eine echte Nachricht, die man durch das System schickt, prüft die Kette vollständig.

Die zweite ist der Blick in den Ordner statt auf den Zustellstatus. Zugestellt und gelesen sind zwei verschiedene Dinge, und dazwischen liegt der Spamfilter. Gerade bei automatisch erzeugten Nachrichten ist das keine theoretische Sorge, denn sie haben oft genau die Eigenschaften, auf die ein Spamfilter achtet: immer derselbe Absender, immer dieselbe Struktur, kein Verlauf.

Beides zusammen dauert zwei Minuten und beantwortet eine Frage, die man sonst erst dann stellt, wenn eine erwartete Nachricht nicht angekommen ist. Zu diesem Zeitpunkt sucht man dann in der Anwendung nach dem Fehler, und der liegt woanders.