Dokumentation

E-Mail

Eingehende E-Mail (IMAP) und ausgehend. Thread-Erhalt, Analyse von Anhängen.

Der Kanal E-Mail nimmt Ihre eingehenden E-Mails auf und ermöglicht es einer Pipeline, zu antworten, weiterzuleiten oder nachgelagerte Aufgaben zu erstellen.

Modell

Zwei sich ergänzende Module:

  • email_inbound — Empfang (IMAP)
  • email_outbound — Versand (konfigurierter Betreiber oder Relay über Ihr SMTP)

Sie sind unabhängig: Sie können nur das Eingangsmodul nutzen (zum Sortieren ohne Antworten) oder nur das Ausgangsmodul (um Benachrichtigungen aus einer anderweitig ausgelösten Pipeline zu senden).

Einrichtung

  1. Einstellungen → Services → E-Mail, Reiter Konten — verbinden Sie ein IMAP-Postfach mit seinen Zugangsdaten.
  2. Ordnen Sie das Postfach einer Ziel-Pipeline zu.
  3. (Optional) Konfigurieren Sie einen Absender (SMTP) zum Antworten.

Für Architekturen, die die Kontrolle über ihre Mailserver behalten müssen, ersetzt betool Ihren MTA nicht: Wir lesen und schreiben über Standard-IMAP / -SMTP.

Was die Pipeline erhält

Für jede eingehende E-Mail wird ein neuer exchange erstellt mit:

  • exchange.user_message — E-Mail-Text (HTML → normalisierter Text)
  • exchange.email.subject — Betreffzeile
  • exchange.email.from — normalisierter Absender
  • exchange.email.thread_id — Thread-Kennung (nützlich für Mehrschritt-Kontext)
  • exchange.email.attachments — Liste von FileMetadata (analysierte Anhänge)

Anhänge

Anhänge können an den Knoten file_transform übergeben werden: auswählbarer Text eines PDF (pdf_extract_text, ohne OCR — ein gescanntes PDF liefert keinen Text), Lesen einer Excel-Arbeitsmappe als Zeilen (xlsx_to_json, xls_to_json), Aufteilen eines PDF oder Rendern als Bilder, Entpacken eines Archivs. Von dort kann Ihr Agent sie als Text oder strukturierte Daten nutzen.

Threads & Mehrschritt-Kontext

Wenn ein Kunde auf eine frühere Antwort reagiert, erkennt betool die thread_id und stellt den Thread-Verlauf im Kontext des Agents wieder her. Dies ist für das Pipeline-Design transparent.

Adressqualität und Unzustellbarkeiten

Drei Knoten schützen Ihre Absenderreputation:

  • email_check — prüft eine oder mehrere Adressen vor einem Versand: Sperrliste der Organisation, Syntax, dann DNS der Domain (MX, ersatzweise A/AAAA; ein „Null-MX“ gilt als Ablehnung). Ohne das Ergebnis zu ändern, meldet er außerdem Wegwerfadressen, generische Postfächer (info@…) und Risiken (Tippfehler bei einem großen Anbieter, doppelte Endung, „Catch-all“-Server). Er blockiert selbst nichts: Er veröffentlicht die Ergebnisse und die Liste der zustellbaren Adressen. Es wird keine SMTP-Prüfung durchgeführt.
  • email_list_clean — qualifiziert eine ganze Liste (zum Beispiel aus einer importierten Datei) in drei Blättern: sauber, zu prüfen, abgelehnt, bereit zum Export mit data_to_file. Deduplizierung, dieselben Prüfungen wie email_check und Analyse der Form der Adresse. Abgerechnet in Credits pro eindeutiger Adresse, Guthaben vor der Verarbeitung geprüft.
  • email_bounce_parse — liest eine in einem Eingangspostfach empfangene Unzustellbarkeitsmeldung. Die Adressen werden nur aus den strukturierten Feldern der Meldung übernommen, nie aus dem Freitext. Sie werden der Sperrliste hinzugefügt: Ein dauerhafter Fehler sperrt ab dem ersten Auftreten; ein vorübergehender Fehler sperrt nach 3 Vorkommen, für 72 Stunden.

Nachfolgende Sendungen (Knoten email_outbound und Tool email.send) entfernen automatisch die gesperrten Adressen; bleibt kein Empfänger übrig, wird nichts versendet. Nur ein Administrator kann eine dauerhafte Sperre aufheben.

Bekannte Einschränkungen

  • Noch keine native MS-Exchange-EWS-Unterstützung (Sie können Exchange über IMAP bereitstellen).
  • Keine Microsoft-Graph-Unterstützung für Office 365 (auf der Roadmap).
  • Die Analyse sehr alter E-Mails (verschachteltes Outlook-2003-RTF) kann etwas Formatierung verlieren.