E-Mail ist die eine Schnittstelle, über die bereits jede Organisation verfügt. Lieferanten schicken Rechnungen dorthin, Formulare liefern Eingaben und Maschinen senden Warnmeldungen. Beim E-Mail-Ingest wird daraus eine Schnittstelle statt einer lästigen Aufgabe: Ein Skript verbindet sich mit einem Postfach, liest die eingegangenen Nachrichten und verarbeitet sie.
Das Verfahren ist alt und wird dennoch unterschätzt. Die Alternative, jeden Geschäftspartner zur Anbindung an die eigene API zu bewegen, steht meist gar nicht zur Verfügung. Dieser Beitrag erklärt, wofür E-Mail-Ingest geeignet ist, wie eine dauerhaft zuverlässige Umsetzung aussieht und wann ein Webhook wirklich die bessere Lösung darstellt.
Wofür sich E-Mail-Ingest über IMAP eignet
E-Mail-Ingest ist überall dort sinnvoll, wo ein Absender sich nicht direkt mit Ihrem System verbinden kann oder will.
Dokumente von Geschäftspartnern. Rechnungen, Bestellungen, Lieferscheine und Abrechnungen kommen als Anhänge von Organisationen, die niemals eine direkte Anbindung an Ihr System entwickeln werden. Oft besteht die gesamte Integration aus einem Skript, das die Dokumente nach Absender und Referenz ablegt.
Meldungen von Geräten. Viele Geräte können nur E-Mails senden, darunter Backup-Appliances, Überwachungssysteme und ältere Industrieanlagen. E-Mail-Ingest über IMAP bietet ihnen eine gemeinsame Sammelstelle.
Formulareingaben und Antworten. Geeignet ist alles, was strukturierte Nachrichten per E-Mail versendet. Dazu gehören auch Unzustellbarkeitsmeldungen und automatische Abwesenheitsantworten, auf die Ihr System reagieren soll.
Freigaben per Antwort. Antwortet jemand mit „Ja“ auf eine Nachricht, kann dies einen Schritt im Arbeitsablauf auslösen. Eine solche Antwort programmgesteuert auszulesen ist häufig einfacher, als eine Oberfläche zu entwickeln, bei der sich niemand anmelden möchte.
So bleibt die Lösung dauerhaft zuverlässig
Die technische Funktionsweise von E-Mail-Ingest ist nicht außergewöhnlich. Seine Zuverlässigkeit hängt von einigen wenigen Entscheidungen ab.
Verwenden Sie ein eigenes Postfach. Nutzen Sie weder einen Ordner im Postfach eines Mitarbeiters noch ein Postfach, in dem ein Mensch dieselben Nachrichten liest. Bei einer dedizierten Adresse kann niemand beim Aufräumen unabsichtlich die Annahmen des Skripts verletzen. Da Postfächer hier nicht pro Nutzer abgerechnet werden, entstehen dadurch keine Zusatzkosten.
Beschränken Sie die Zugangsdaten auf diese Aufgabe. Verwenden Sie nicht die Anmeldung einer Person. Werden die Zugangsdaten des Skripts kompromittiert oder müssen sie ausgetauscht werden, darf das ausschließlich dieses Skript betreffen.
Verschieben Sie verarbeitete Nachrichten, statt sie zu löschen. Ein Ordner „Verarbeitet“ dient als Prüfpfad und ermöglicht nach der Behebung eines Fehlers eine erneute Verarbeitung. Durch Löschen wird jeder Fehler endgültig, und Fehler werden auftreten.
Berücksichtigen Sie den mehrfachen Eingang derselben Nachricht. Wiederholungsversuche, neue Verbindungen und eine erneute Verarbeitung sind unvermeidbar. Wenn die Message-ID als Schlüssel dient und bereits bekannte Nachrichten übersprungen werden, bleibt die Verarbeitung idempotent. Aus einem möglichen Datenproblem wird so ein Vorgang ohne Wirkung.
Machen Sie Ausfälle deutlich sichtbar. Wenn ein Skript sein Postfach nicht mehr liest, fällt dies erst auf, wenn jemand nach den verschwundenen Rechnungen fragt. Es sollte nicht nur Fehler melden, sondern auch Alarm schlagen, wenn es längere Zeit nicht gelaufen ist.
Warum IMAP dafür gut geeignet ist
E-Mail-Ingest funktioniert über IMAP, weil IMAP ein vollwertiges entferntes Dateisystem für E-Mails darstellt und nicht nur ein Protokoll zum Herunterladen ist.
Sie können serverseitig suchen, zunächst nur Kopfzeilen abrufen und dann entscheiden, ob der Nachrichtentext benötigt wird. Nachrichten lassen sich zwischen Ordnern verschieben und mit Markierungen versehen, ohne das gesamte Postfach herunterzuladen. Das Skript kann dadurch gezielt und ressourcenschonend arbeiten. Bei einem Postfach mit jahrelanger Historie ist das besonders wichtig.
Das entscheidende Argument ist jedoch die universelle Unterstützung. Für jede Programmiersprache gibt es eine Bibliothek, das Protokoll wurde nie auf eine Weise verändert, die bestehende Implementierungen unbrauchbar macht, und ein heute geschriebenes Skript wird auch in zehn Jahren noch funktionieren. Diese Verlässlichkeit bieten nur wenige herstellerspezifische APIs.
Gut zu wissen: Der kostenlose Tarif umfasst IMAP. Ein ausschließlich empfangendes Ingest-Postfach kostet daher überhaupt nichts. Es kann allerdings keine Nachrichten senden. Für programmgesteuerte Antworten ist ein kostenpflichtiger Tarif oder ein eigenes SMTP-Profil erforderlich.
Die laufenden Kosten
Die Kosten überraschen meist, weil sie wesentlich geringer ausfallen als erwartet.
Ein Ingest-Postfach ist ein gewöhnliches Postfach. Die Anzahl wird durch die Tarifstufe begrenzt und nicht einzeln berechnet. Eine zwölfte Ingest-Adresse verursacht daher keine zusätzlichen Grenzkosten. Genau das macht ein separates Postfach pro Quelle zu einer praktischen statt verschwenderischen Lösung. Tatsächlich verbrauchen Sie Speicher aus dem gemeinsamen Kontingent und Arbeitszeit, wenn etwas ausfällt.
Gegenüber Plattformen mit Nutzergebühren verändert dies die Architekturentscheidung. Dort werden mehrere Datenströme häufig in eine einzige überlastete Adresse gezwängt, weil jede neue Geld kostet. Das Skript muss anschließend mehrere voneinander unabhängige Ströme wieder auseinanderhalten. Hier ist die günstigste Lösung zugleich die sauberste.
Wann ein Webhook besser ist
Eine klare Abgrenzung verhindert, dass für die falsche Aufgabe die falsche Lösung gebaut wird.
Bietet der Geschäftspartner einen Webhook an, sollten Sie ihn nutzen. Push ist Polling bei Latenz, Zuverlässigkeit und Klarheit überlegen. Sie erhalten unmittelbar nach einem Ereignis strukturierte Daten, statt es beim nächsten Abruf zu entdecken und anschließend Fließtext auszuwerten. E-Mail-Ingest ist die Ausweichlösung, wenn keine solche Möglichkeit besteht.
Auch Polling hat eine sinnvolle Untergrenze. Jede Minute zu prüfen ist vertretbar, jede Sekunde zu prüfen ist missbräuchlich und wird durch eine Ratenbegrenzung verhindert. Benötigen Sie tatsächlich Echtzeitverarbeitung, ist E-Mail unabhängig vom Leseverfahren das falsche Transportmittel.
Auch das Auswerten frei formulierter E-Mails ist nicht zuverlässig lösbar. Eine Bestellnummer lässt sich aus einer maschinell erzeugten Nachricht sicher extrahieren. Aus einem von Menschen geschriebenen Absatz eine Absicht abzuleiten ist dagegen unzuverlässig. Ein davon abhängiger Arbeitsablauf erzeugt fortlaufend einzelne Fehler, die sich nie vollständig beseitigen lassen.
Über ein einzelnes Postfach hinaus skalieren
E-Mail-Ingest lässt sich gut erweitern. Die passende Struktur richtet sich nach der Anzahl der Datenströme.
Bei wenigen Quellen ist ein eigenes Postfach pro Quelle am übersichtlichsten. Jedes Skript liest seine eigene Adresse, und Änderungen an einer Quelle wirken sich nicht auf andere aus. Da die Anzahl der Postfächer je Tarif begrenzt, aber nicht einzeln abgerechnet wird, kosten zwanzig Ingest-Adressen genauso viel wie eine.
Bei vielen gleichartigen Quellen eignet sich ein gemeinsames Postfach hinter einer Catch-all-Konfiguration besser. invoice-acme@ und invoice-globex@ landen an derselben Stelle, während die Adresse selbst die für das Routing benötigte Information enthält. Es ist dasselbe Prinzip wie ein Alias pro Registrierung, hier für Maschinen statt für Anbieter eingesetzt.
Bei wirklich hohem Volumen sollten Sie an den gemeinsamen Speicher denken. Ein Ingest-Postfach mit immer mehr Anhängen verbraucht diesen Platz kontinuierlich. Eine Speicherquote und eine Aufbewahrungsrichtlinie gehören deshalb von Anfang an in den Entwurf, statt erst später als fehlend erkannt zu werden. Weitere Informationen finden Sie unter Speicherquoten für Postfächer.
