Documentación

Email

Email entrante (IMAP) y saliente. Preservación de hilos, análisis de adjuntos.

El canal de email ingiere tus correos entrantes y permite que un pipeline responda, reenvíe o cree tareas aguas abajo.

Modelo

Dos módulos complementarios:

  • email_inbound — recepción (IMAP)
  • email_outbound — envío (operador configurado, o retransmisión vía tu SMTP)

Son independientes: puedes usar solo el módulo entrante (para triar sin responder), o solo el módulo saliente (para enviar notificaciones desde un pipeline disparado de otra forma).

Configuración

  1. Ajustes → Servicios → Correo electrónico, pestaña Cuentas — conecta un buzón IMAP con sus credenciales.
  2. Asigna el buzón a un pipeline de destino.
  3. (Opcional) Configura un remitente (SMTP) para responder.

Para arquitecturas que necesitan mantener el control de sus servidores de correo, betool no reemplaza tu MTA: leemos y escribimos vía IMAP / SMTP estándar.

Qué recibe el pipeline

Por cada correo entrante, se crea un nuevo exchange con:

  • exchange.user_message — cuerpo del email (HTML → texto normalizado)
  • exchange.email.subject — línea de asunto
  • exchange.email.from — remitente normalizado
  • exchange.email.thread_id — identificador del hilo (útil para el contexto multi-turno)
  • exchange.email.attachments — lista de FileMetadata (adjuntos analizados)

Adjuntos

Los adjuntos pueden pasarse al nodo file_transform: texto seleccionable de un PDF (pdf_extract_text, sin OCR — un PDF escaneado no devuelve texto), lectura de un libro de Excel en filas (xlsx_to_json, xls_to_json), división o renderizado en imágenes de un PDF, extracción de un archivo comprimido. A partir de ahí, tu agente puede trabajar con ellos como texto o como datos estructurados.

Hilos y contexto multi-turno

Cuando un cliente responde a una respuesta anterior, betool reconoce el thread_id y restaura el historial del hilo en el contexto del agente. Esto es transparente para el diseño del pipeline.

Calidad de las direcciones y no entregas

Tres nodos protegen tu reputación como remitente:

  • email_check — verifica una o varias direcciones antes de un envío: lista de supresión de la organización, sintaxis y luego DNS del dominio (MX, o en su defecto A/AAAA; un «null MX» equivale a rechazo). También señala, sin cambiar el veredicto, las direcciones desechables, los buzones genéricos (info@…) y los riesgos (errata en un gran proveedor, extensión duplicada, servidor «catch-all»). No bloquea nada por sí mismo: publica los veredictos y la lista de direcciones entregables. No se realiza ninguna sonda SMTP.
  • email_list_clean — califica una lista entera (por ejemplo procedente de un archivo importado) en tres hojas: limpias, a revisar, rechazadas, listas para exportar con data_to_file. Deduplicación, los mismos controles que email_check y análisis de la forma de la dirección. Facturado en créditos por dirección distinta, con el saldo verificado antes del tratamiento.
  • email_bounce_parse — lee un aviso de no entrega recibido en un buzón entrante. Las direcciones solo se toman de los campos estructurados del aviso, nunca del texto libre. Se añaden a la lista de supresión: un fallo permanente bloquea desde la primera ocurrencia; un fallo temporal bloquea tras 3 ocurrencias, durante 72 horas.

Los envíos posteriores (nodo email_outbound y tool email.send) eliminan automáticamente las direcciones suprimidas; si no queda ningún destinatario, no se envía nada. Solo un administrador puede levantar un bloqueo permanente.

Limitaciones conocidas

  • Todavía sin soporte nativo para MS Exchange EWS (puedes exponer Exchange sobre IMAP).
  • Sin soporte para Microsoft Graph en Office 365 (en la hoja de ruta).
  • Analizar correos muy antiguos (RTF anidado de Outlook 2003) puede perder parte del formato.