betool betool

Documentation

Email

Email entrant (IMAP) et sortant. Threads conservés, pièces jointes parsées.

Email

Le canal email ingère vos emails entrants et permet à un pipeline de répondre, transférer ou créer des tâches downstream.

Modèle

Deux modules complémentaires :

  • email_inbound — réception (IMAP)
  • email_outbound — émission (opérateur configuré, ou relai via votre SMTP)

Ils sont indépendants : vous pouvez n'utiliser que le entrant (pour trier sans répondre), ou n'utiliser que le sortant (pour notifier depuis un pipeline déclenché autrement).

Mise en place

  1. Paramètres → Services → Email, onglet Comptes — connecter une boîte IMAP avec ses credentials.
  2. Mapper la boîte vers un pipeline cible.
  3. (Optionnel) Configurer un émetteur (SMTP) pour répondre.

Pour les architectures qui veulent rester en contrôle de leurs serveurs mail, betool ne se substitue pas à votre MTA : nous lisons et écrivons via IMAP / SMTP standards.

Ce que le pipeline reçoit

Pour chaque email entrant, un nouvel exchange est créé avec :

  • exchange.user_message — corps de l'email (HTML → texte normalisé)
  • exchange.email.subject — sujet
  • exchange.email.from — expéditeur normalisé
  • exchange.email.thread_id — identifiant de fil (utile pour le contexte multi-turn)
  • exchange.email.attachments — liste de FileMetadata (pièces jointes parsées)

Pièces jointes

Les pièces jointes peuvent être passées au nœud file_transform : texte sélectionnable d'un PDF (pdf_extract_text, sans OCR — un PDF scanné ne rend pas de texte), lecture d'un classeur Excel en lignes (xlsx_to_json, xls_to_json), découpe ou rendu en images d'un PDF, extraction d'une archive. De là, votre agent peut les exploiter comme du texte ou des données structurées.

Threads & contexte multi-turn

Si un client répond à une réponse précédente, betool reconnaît le thread_id et restore l'historique du fil dans le contexte de l'agent. C'est transparent pour la conception du pipeline.

Qualité des adresses et non-remises

Trois nœuds protègent votre réputation d'expéditeur :

  • email_check — vérifie une ou plusieurs adresses avant un envoi : liste de suppression de l'organisation, syntaxe, puis DNS du domaine (MX, à défaut A/AAAA ; un « null MX » vaut refus). Il signale aussi, sans changer le verdict, les adresses jetables, les boîtes génériques (info@…) et les risques (faute de frappe sur un grand fournisseur, extension dupliquée, serveur « attrape-tout »). Il ne bloque rien lui-même : il publie les verdicts et la liste des adresses délivrables. Aucune sonde SMTP n'est effectuée.
  • email_list_clean — qualifie une liste entière (par exemple issue d'un fichier importé) en trois feuilles : propres, à revoir, rejetées, prêtes à exporter avec data_to_file. Dédoublonnage, mêmes contrôles qu'email_check, et analyse de la forme de l'adresse. Facturé en crédits par adresse distincte, solde vérifié avant le traitement.
  • email_bounce_parse — lit un avis de non-remise reçu dans une boîte entrante. Les adresses ne sont prises que dans les champs structurés de l'avis, jamais dans le texte libre. Elles sont ajoutées à la liste de suppression : un échec permanent bloque dès la première occurrence ; un échec temporaire bloque après 3 occurrences, pour 72 heures.

Les envois suivants (nœud email_outbound et tool email.send) retirent automatiquement les adresses supprimées ; si plus aucun destinataire ne reste, rien ne part. Seul un administrateur peut lever un blocage permanent.

Limites connues

  • Pas (encore) de support MS Exchange EWS natif (vous pouvez exposer Exchange en IMAP).
  • L'ingestion Office 365 passe par IMAP, pas par l'API Microsoft Graph. (Pour envoyer depuis une boîte Microsoft via Graph, utilisez le nœud microsoft_send_mail.)
  • Le parsing des emails très anciens (Outlook 2003 RTF imbriqué) peut perdre du formatage.