your-mail-mcp

Tu correo ya contiene las respuestas: referencias de reserva, códigos de puerta, facturas, períodos de garantía, promesas que la gente hizo por escrito. Este servidor permite que tu asistente de IA las encuentre.

Pregúntale cosas como:

• "Encuentra la referencia de reserva del ferry de junio."

• "¿Cuál era la contraseña del wifi que el hotel envió el verano pasado?"

• "¿Qué respondió el contable sobre el IVA, y cuándo?"

• "Recopila todo lo que hay entre el constructor y yo sobre el tejado, en orden, y resume quién prometió qué."

• "¿Qué ha llegado esta mañana, en todas mis cuentas, que realmente requiera mi atención?"

Úsalo para:

• Búsqueda que entiende preguntas. Búsqueda de texto completo en todo tu historial, todas las cuentas en un solo índice, formulada como piensas en lugar de como funciona la sintaxis de búsqueda.

• Triaje desde el móvil. Un resumen matutino de lo que ha llegado durante la noche, con la basura ya filtrada, desde donde estés.

• El correo como contexto para otros trabajos. Extrae los requisitos del cliente del hilo y llévalos a tu sesión de programación o escritura, en lugar de volver a teclearlos.

• Agentes que puedes dejar funcionando. El servidor solo puede leer. Un correo malicioso que llegue a tu asistente se lee y nada más, porque enviar, eliminar y mover no existen aquí. Eso hace que los resúmenes programados y los agentes siempre activos sean algo tranquilo de ejecutar.

La configuración son dos archivos y docker compose up -d — consulta Cómo ejecutarlo.

Un servidor MCP autoalojado que da a un cliente MCP (Claude, o cualquier otro cliente que hable MCP HTTP con streaming y OAuth) acceso de lectura a tu correo. Replica una o más cuentas IMAP en un maildir local con mbsync, las indexa con notmuch y responde a las llamadas de herramientas desde ese índice.

El correo solo se mueve de izquierda a derecha en esa imagen. La única flecha que el servidor hace hacia un proveedor es un único LIST de IMAP al arrancar, para averiguar cómo llama ese servidor a sus carpetas de basura y spam; nunca selecciona un buzón y nunca descarga un mensaje. La fuente del diagrama es docs/diagrams/how-it-works.html.

Lo que no puede hacer

La propiedad de solo lectura está integrada en la arquitectura.

El espejo es solo de extracción. La configuración de mbsync generada para cada cuenta lleva Sync Pull, Create Near, Remove None, Expunge None — nada en esa configuración puede enviar un cambio de vuelta al servidor, eliminar un mensaje o purgarlo.

La única operación IMAP en todo el código Go es LIST, emitida una vez por cuenta al arrancar para encontrar las carpetas de basura y spam de cada cuenta (consulta Notas sobre proveedores y Solución de problemas). Esa conexión inicia sesión, lista los buzones y cierra sesión. Nunca selecciona un buzón y nunca descarga un mensaje.

No hay envío, ni eliminación, ni movimiento, ni etiquetas. Los adjuntos se listan en show y thread y se sirven de solo lectura mediante la herramienta attachment, una parte cada vez, con un límite de 5 MB. Las partes más grandes se sirven en bruto en GET /attachment/{id}/{part}, autenticadas con un token de portador o con el enlace firmado de corta duración que la herramienta devuelve cuando rechaza una parte sobredimensionada. Nada en el proceso tiene acceso de escritura a ninguna cuenta.

Diez herramientas, todas de solo lectura:

search, ids, files y count aceptan una consulta de notmuch (from:, to:, subject:, tag:, folder:, date:2026-01-01..2026-06-30, combinada con and/or/not), una account opcional para limitar a una cuenta, y pueden incluir basura/spam con include_excluded.

Related MCP server: notmuchproxy

Cómo ejecutarlo

Tres formas de ejecutar esto. Se diferencian en una cosa: quién puede llegar al servidor. Empieza por el caso 1 y sube solo cuando lo necesites. Ninguna de ellas está endurecida más allá de los valores predeterminados — eso es Endurecimiento, más abajo, y está deliberadamente separado para que puedas hacer que funcione primero.

El servidor se distribuye como imagen de contenedor en ghcr.io/wildsurfer/your-mail-mcp, compilada y publicada por CI para amd64 y arm64. No hay que compilar nada, y todos los casos empiezan igual: dos archivos en un directorio vacío:

mkdir your-mail && cd your-mail
curl -fsSLO https://raw.githubusercontent.com/wildsurfer/your-mail-mcp/main/compose.yaml
curl -fsSL https://raw.githubusercontent.com/wildsurfer/your-mail-mcp/main/accounts.example.json -o accounts.json

Edita accounts.json con tus cuentas (consulta El archivo de cuentas) y luego pon los secretos a los que hace referencia en un archivo .env junto a compose.yaml:

# .env
OAUTH_PASSPHRASE=pick-a-long-one-you-can-type-on-a-smartphone
WORK_PASS=your-gmail-app-password
PERSONAL_PASS=your-icloud-app-specific-password

OAUTH_PASSPHRASE es la única credencial entre internet y tu correo en los casos 2 y 3. Trátala como corresponde.

Estos dos archivos contienen las contraseñas de tu correo. Si alguna vez pones este directorio bajo control de versiones o en una copia de seguridad que salga de la máquina, trátalos como corresponde.

Caso 1 — en tu máquina, solo para tu máquina

El servidor se vincula al loopback. Nada fuera de tu máquina puede alcanzarlo, así que no hay TLS que organizar ni nombre de host que poseer. Tus herramientas CLI pueden usarlo. Tu smartphone no.

Añade una línea a .env:

PUBLIC_URL=http://127.0.0.1:8080

Luego inícialo:

docker compose up -d
docker compose logs -f          # watch the first sync

La primera sincronización puebla el maildir y tarda un rato en un buzón grande. Es más lenta de lo que podría ser a propósito, un comando IMAP cada vez, porque los proveedores limitan. No hay paso de inicialización separado.

Claude Code

claude mcp add --transport http your-mail http://127.0.0.1:8080/mcp

Luego ejecuta /mcp dentro de Claude Code, elige your-mail y autentícate. Un navegador abre la página de consentimiento, que pide una sola cosa: tu OAUTH_PASSPHRASE. Hasta que lo hagas, claude mcp list muestra Needs authentication.

Codex

codex mcp add your-mail --url http://127.0.0.1:8080/mcp
codex mcp login your-mail

codex mcp list muestra el estado de autenticación. Si las herramientas siguen sin aparecer en una sesión después de un inicio de sesión exitoso, es un error conocido de Codex en el que las credenciales OAuth se obtienen y luego nunca se usan (openai/codex#20009). Usa el puente de abajo hasta que se arregle.

mcp-remote hace el baile OAuth por sí mismo y vuelve a exponer el servidor a través de stdio, que todos los clientes MCP soportan:

# ~/.codex/config.toml
[mcp_servers.your-mail]
command = "npx"
args = ["-y", "mcp-remote", "http://127.0.0.1:8080/mcp"]

Abre la misma página de consentimiento en el primer uso y guarda los tokens en caché.

Caso 2 — en tu máquina, accesible desde cualquier lugar

El mismo servidor, más algo que le dé una dirección HTTPS pública. Tu correo se queda en tu máquina, y nada escucha en tu red doméstica, porque el túnel marca hacia fuera. Necesitas esto para las aplicaciones de smartphone y de escritorio: un conector personalizado lo descargan los servidores del proveedor, así que no puede alcanzar una dirección privada.

Con Tailscale (sin necesidad de dominio)

Un comando, igual en macOS y Linux, y obtienes un nombre de host HTTPS sin poseer un dominio.

tailscale funnel --bg 8080

--bg lo mantiene en ejecución entre reinicios. Imprime la URL pública, que tiene este aspecto: https://tu-máquina.tu-tailnet.ts.net. Ese es el nombre de host que hay que usar:

# .env
PUBLIC_URL=https://your-machine.your-tailnet.ts.net

docker compose up -d

Funnel necesita certificados HTTPS y el atributo de nodo Funnel habilitado para tu tailnet; el CLI ofrece añadir la línea de política la primera vez, y el resto está en tu consola de administración. tailscale funnel status muestra lo que está expuesto, y tailscale funnel --https=443 off lo desactiva.

Con Cloudflare (tienes un dominio, y está en Cloudflare)

Usa esto si quieres un nombre de host en tu propio dominio en lugar de uno .ts.net. mail.example.com a continuación es tu dominio, ya añadido a tu cuenta de Cloudflare — Cloudflare no te entrega un nombre de host para un túnel con nombre.

cloudflared tunnel login
cloudflared tunnel create your-mail

create imprime el UUID del túnel y el archivo de credenciales que acaba de escribir:

Tunnel credentials written to /Users/you/.cloudflared/f9e2…-… .json
Created tunnel your-mail with id f9e2…-…

Usa esa ruta exacta a continuación; cloudflared tunnel list imprime el UUID de nuevo si lo pierdes. Enruta el nombre de host y luego escribe ~/.cloudflared/config.yml:

cloudflared tunnel route dns your-mail mail.example.com

tunnel: your-mail
credentials-file: /Users/you/.cloudflared/f9e2….json   # the path create printed
url: http://localhost:8080

cloudflared tunnel run your-mail

Para mantenerlo en ejecución: en Linux, sudo cloudflared service install. En macOS, instálalo a través de Homebrew y usa brew services start cloudflared, porque la ruta de instalación con sudo busca su certificado en el directorio personal del usuario root y no encontrará el que cloudflared tunnel login escribió en el tuyo.

Luego establece PUBLIC_URL=https://mail.example.com en .env y docker compose up -d.

En cualquier caso

PUBLIC_URL tiene que coincidir exactamente con lo que escribes en el cliente. El servidor publica PUBLIC_URL + /mcp como resource en sus metadatos OAuth, y un desajuste ahí es la razón más común por la que un conector se niega a añadirse.

Una cosa que debes saber antes de empezar en un smartphone: ni Claude ni ChatGPT te permiten añadir un conector desde la aplicación del smartphone. Lo añades una vez en la web (o en la aplicación de escritorio de Claude), y luego aparece en tu smartphone. Intentar hacer la configuración en el propio smartphone te hará perder el tiempo.

Claude — añádelo en la web o en el escritorio, luego úsalo en tu smartphone

1. En claude.ai o en Claude Desktop, ve a Configuración → Conectores y haz clic en + junto a Conectores, o en Añadir conector personalizado.

2. Ponle un nombre y la URL <PUBLIC_URL>/mcp. Deja los campos avanzados de OAuth vacíos: este servidor registra clientes dinámicamente.

3. Claude abre la página de consentimiento. Introduce tu OAUTH_PASSPHRASE.

4. Abre la aplicación de Claude en tu smartphone. El conector ya está ahí, y las herramientas están disponibles en un chat. Actívalo para una conversación desde el menú de herramientas o conectores del compositor.

ChatGPT — añádelo en la web, luego úsalo en tu smartphone

Los conectores MCP personalizados están detrás del modo de desarrollador, que requiere una cuenta Pro, Plus, Business, Enterprise o Education y solo está disponible en la web.

1. En ChatGPT en la web, abre Configuración → Seguridad e inicio de sesión y activa el modo de desarrollador. En los espacios de trabajo Business y Enterprise, un administrador puede tener que permitirlo primero.

2. Añade un conector para un servidor MCP remoto y dale la URL <PUBLIC_URL>/mcp, con OAuth como autenticación. ChatGPT admite el registro dinámico de clientes, así que no hay nada que pegar.

3. Aprueba la página de consentimiento con tu OAUTH_PASSPHRASE.

4. Abre ChatGPT en tu smartphone y activa el conector en un chat.

Estos menús se mueven. Si los nombres anteriores no coinciden con lo que ves, busca el modo de desarrollador en la configuración y luego el lugar que añade un conector por URL.

ChatGPT desactiva algunas acciones de escritura de MCP en móvil. Eso no tiene efecto aquí, porque este servidor no tiene ninguna acción de escritura.

Claude Code

claude mcp add --transport http your-mail https://your-host/mcp

Codex

codex mcp add your-mail --url https://your-host/mcp
codex mcp login your-mail

Caso 3 — en un VPS, accesible desde cualquier lugar

Elige esto cuando quieras que el espejo siga activo tanto si tu máquina está encendida como si no. Cuesta unos pocos dólares al mes y tiene un verdadero inconveniente: una copia completa en texto plano de tu correo se traslada a un disco alquilado, con las contraseñas de aplicación en el mismo entorno. Lee Seguridad antes de elegirlo.

La instalación es el caso 1 más un túnel, en el ordenador de otra persona. No hay puertos que abrir, ni DNS que configurar, ni certificados que gestionar.

En una máquina Debian o Ubuntu recién creada:

# 1. Docker
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER && newgrp docker

# 2. The two files, and your accounts
mkdir your-mail && cd your-mail
curl -fsSLO https://raw.githubusercontent.com/wildsurfer/your-mail-mcp/main/compose.yaml
curl -fsSL https://raw.githubusercontent.com/wildsurfer/your-mail-mcp/main/accounts.example.json -o accounts.json
$EDITOR accounts.json             # your accounts
$EDITOR .env                      # OAUTH_PASSPHRASE and the account passwords

# 3. A public address, exactly as in case 2
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale funnel --bg 8080        # prints your https://….ts.net hostname

# 4. Put that hostname in .env, then start
echo "PUBLIC_URL=https://your-machine.your-tailnet.ts.net" >> .env
docker compose up -d
docker compose logs -f

PUBLIC_URL va al final porque no conoces el nombre de host hasta que el paso 3 lo imprime.

Conectar un cliente es idéntico al caso 2.

restart: unless-stopped en compose.yaml devuelve los contenedores a la vida después de un reinicio. Compruébalo con la herramienta folders, que informa de la última sincronización de cada cuenta y de su último error, o con docker compose logs --tail=50.

Ahora ve y lee Endurecimiento. Un VPS al que puedes hacer SSH con una contraseña, que contiene una copia de tu correo, es peor que no ejecutar esto en absoluto.

Endurecimiento

Nada de esto es necesario para que el servidor funcione, por eso no está en los pasos de instalación. Está ordenado por cuánto te beneficia. El caso 1 no necesita nada de esto.

Elige una frase de contraseña de verdad. OAUTH_PASSPHRASE es toda la puerta. Una suposición incorrecta le cuesta al atacante un segundo, y las suposiciones están serializadas, así que ejecutarlas en paralelo no ayuda, pero ninguna de esas cosas salva una frase de contraseña corta. Usa una larga que aún puedas escribir en un smartphone.

Bloquea SSH (caso 3). Una máquina alquilada con inicio de sesión por contraseña y una copia de tu correo es la peor combinación de este documento. Como root, antes que nada:

adduser mail && usermod -aG sudo mail
rsync --archive --chown=mail:mail ~/.ssh /home/mail
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/; s/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

Luego haz la instalación como mail, no como root.

Cierra los puertos que no usas (caso 3). Con un túnel no necesitas ningún puerto de entrada, así que:

sudo ufw allow OpenSSH && sudo ufw --force enable

Restringe quién puede acceder al conector. Si lo único que habla con tu servidor es un conector personalizado en una aplicación Claude, ese tráfico llega desde el rango de salida publicado de Anthropic, 160.79.104.0/21, y puedes rechazar todo lo demás en el túnel o el cortafuegos. No hagas esto si también usas Claude Code o Codex desde un portátil, ya que esos se conectan desde dondequiera que estés.

Haz copias de seguridad de los volúmenes, o acepta una resincronización. compose.yaml mantiene el maildir y el índice en volúmenes con nombre. Nada de lo que contienen es único — todo sigue en tu servidor de correo — pero volver a descargar un buzón grande lleva tiempo y molesta a los proveedores que limitan el ancho de banda.

Sabe lo que la frase de contraseña no protege. Protege la superficie MCP. No cifra nada en reposo. Consulta Seguridad.

Si prefieres terminar TLS tú mismo en un dominio que poseas, apunta un registro A a la máquina y pon Caddy delante. Añade compose.override.yaml:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
volumes:
  caddy_data:

# Caddyfile
mail.example.com {
    reverse_proxy your-mail-mcp:8080
}

Abre ambos puertos — el 80 no es opcional, Caddy lo usa para el desafío del certificado y la redirección HTTPS:

sudo ufw allow 80/tcp && sudo ufw allow 443/tcp

Caddy obtiene y renueva el certificado por sí mismo. Establece PUBLIC_URL al nombre de host y docker compose up -d.

El archivo de cuentas

Montado de solo lectura en /config/accounts.json (ver compose.yaml). JSON, analizado con encoding/json, expandido contra el entorno del proceso antes del análisis, de modo que ${VAR} en cualquier valor de cadena se reemplaza con la variable de entorno de ese nombre. Así es como los secretos se mantienen fuera del archivo:

{
  "accounts": [
    {
      "name": "work",
      "host": "imap.gmail.com",
      "user": "you@example.com",
      "password": "${WORK_PASS}"
    }
  ]
}

Claves por cuenta:

Un nombre de cuenta debe ser único. Se requiere al menos una cuenta; un array accounts vacío es un error de inicio.

Variables de entorno

CONFIG, MAILDIR e INDEX son obligatorias; el proceso se niega a arrancar sin ellas. PUBLIC_URL y OAUTH_PASSPHRASE son obligatorias para la capa de OAuth y el proceso también falla al arrancar sin ellas.

La imagen del contenedor ya establece cuatro de estas (Dockerfile): MAILDIR=/mail, INDEX=/index, CONFIG=/config/accounts.json, LISTEN_ADDR=:8080. compose.yaml no anula ninguna de ellas. Déjalas en paz a menos que también estés cambiando el montaje de volumen o el montaje de configuración correspondiente en compose.yaml — una anulación que no mueva el montaje con ella apuntará el servidor a una ruta vacía o inexistente.

Sin Docker

Los binarios de lanzamiento para Linux y macOS, amd64 y arm64, están en la página de lanzamientos, con sumas de verificación. El binario invoca a mbsync, notmuch y w3m, así que instala esos primero — brew install isync notmuch w3m en macOS, apt install isync notmuch w3m en Debian y Ubuntu. isync 1.4.4 o más reciente funciona.

Luego la misma configuración que el contenedor, con rutas de tu elección. Los volúmenes del contenedor empiezan como puntos de montaje, que la protección de maildir vacío lee como una primera ejecución genuina; un directorio normal que crees tú mismo se ve exactamente como un volumen ausente para esa misma protección, así que necesita INIT_MIRROR=1 para indicar que realmente se trata de una primera ejecución aquí:

mkdir -p mail index
CONFIG=./accounts.json MAILDIR=./mail INDEX=./index INIT_MIRROR=1 \
PUBLIC_URL=http://127.0.0.1:8080 OAUTH_PASSPHRASE=... \
WORK_PASS=... ./your-mail-mcp

Windows no es compatible: el manejo del maildir se apoya en la semántica del sistema de archivos Unix, y no hay mbsync al que invocar.

Compilarlo tú mismo

CI compila, prueba y publica cada imagen, así que nadie tiene que hacerlo — pero es un solo comando si quieres: docker build -t your-mail-mcp . para el contenedor, o go build para el binario (Go 1.27, con las tres herramientas anteriores en PATH para las pruebas).

Notas de proveedores

Las notas de iCloud provienen de la operación a largo plazo de un espejo iCloud real que precede a este servidor. Las notas de Gmail y Dovecot provienen de la documentación del proveedor y de la investigación del proyecto, y no todas han sido reverificadas a través de este servidor todavía.

• iCloud (imap.mail.me.com): el user de IMAP es el nombre corto — la parte antes de @icloud.com — no la dirección de correo completa. iCloud limita las conexiones IMAP simultáneas; por eso la configuración de mbsync generada fija PipelineDepth 1 para cada cuenta, y no es configurable.

• Gmail (imap.gmail.com): requiere una contraseña de aplicación, que a su vez requiere tener activada la verificación en dos pasos en la cuenta primero — Gmail no acepta la contraseña de la cuenta directamente a través de IMAP. Gmail también guarda una copia de prácticamente todo en [Gmail]/All Mail, por lo que el espejo de una cuenta de Gmail es aproximadamente el doble del tamaño que sugiere la lista de carpetas, ya que la mayoría de los mensajes existen tanto en su carpeta como en All Mail. El primer espejo de una cuenta de Gmail grande tarda horas, y Google también impone una cuota diaria de descarga IMAP (alrededor de 2.5 GB al día), por lo que una bandeja de entrada de varios gigabytes reparte su primer espejo a lo largo de varios días. Esto es normal: el servidor sigue reintentando según su programación y mbsync reanuda donde se detuvo. Establece SYNC_TIMEOUT a algo como 8h para el primer espejo para que una ejecución larga no se corte por el plazo predeterminado de una hora.

• Servidores Dovecot (muchos proveedores autoalojados y más pequeños) suelen prefijar los nombres de carpeta con INBOX. (p. ej., INBOX.Sent). Si folders muestra nombres de carpeta que no esperabas, normalmente esta es la razón.

Seguridad

Las contraseñas de las cuentas se suministran a través del entorno del proceso (${VAR} en accounts.json, o valores literales). Al iniciarse, el servidor las escribe en un archivo de configuración de mbsync generado en el disco dentro del contenedor, con modo de archivo 0600. Ese archivo no está cifrado. Cualquier cosa que pueda leer el entorno del contenedor, o ese archivo, puede leer las contraseñas en texto plano.

La protección en reposo — cifrado del disco, restringir quién puede ejecutar comandos dentro del contenedor, acceso al host — es responsabilidad del operador. Este servidor no afirma cifrar las credenciales en reposo, y no lo intenta.

La frase de contraseña de OAuth se comprueba en tiempo constante y protege todo el servidor con un único secreto compartido; no es un sistema de credenciales por usuario. Trata OAUTH_PASSPHRASE y las contraseñas de las cuentas de correo con el mismo cuidado.

Los resúmenes de hilos de search incluyen un nombre para mostrar de cada mensaje en un hilo coincidente, que controla el remitente. Un mensaje en una carpeta excluida por defecto (correo no deseado, papelera) puede poner su propio nombre elegido por el atacante frente a ti de esta manera, aunque su cuerpo nunca lo haga — search no obtiene ni muestra el cuerpo de un mensaje excluido. thread y show son rutas de lectura, no sujetas a esto: thread excluye las respuestas de correo no deseado/papelera por defecto (consulta la tabla de herramientas anterior), y show lee un único mensaje del que ya tienes el id. Esta fuga de nombres para mostrar en search no está corregida en esta versión.

Solución de problemas

"maildir ... is an empty plain directory, not a mount point: refusing to sync" — el servidor comprueba si tu maildir es un sistema de archivos montado. Un volumen montado que resulta estar vacío es una primera ejecución y se sincroniza sin necesidad de aceptación explícita, por lo que compose no necesita ningún paso adicional. Un directorio plano vacío es ambiguo: un maildir nuevo se ve exactamente igual que una ruta cuyo volumen nunca se montó, y sincronizar en el segundo re-descarga cada cuenta en un directorio que desaparece en cuanto arreglas el montaje. O bien monta el almacenamiento donde apunta MAILDIR, o establece INIT_MIRROR=1 si realmente está destinado a ser un directorio ordinario en este sistema de archivos.

"maildir ...: no such file or directory" — la ruta no existe en absoluto. Con compose eso significa que el volumen o el montaje de enlace falta en compose.yaml; ejecutando el binario directamente, significa que MAILDIR es incorrecto.

Comprueba el estado de sincronización por cuenta con la herramienta folders. Enumera cada cuenta configurada, su última hora de sincronización exitosa, su último error si lo hay, sus carpetas y las etiquetas en el índice. Una sola cuenta con una contraseña incorrecta o una contraseña específica de aplicación caducada no detiene a las demás — los fallos de sincronización están aislados por cuenta — pero aparecerá aquí como una línea de last error, no como silencio.

Exclusión de correo no deseado/papelera, dos formas de fallo diferentes:

• "special-use discovery: account NAME: ..." en los registros del contenedor significa que la conexión de inicio, el inicio de sesión o el LIST para esa cuenta fallaron por completo. Ante ese fallo no hay nombres de carpeta a los que recurrir para comparar, por lo que esa cuenta no tiene nada excluido en absoluto — ni siquiera por la lista de nombres en inglés integrada — hasta que se solucione el problema de conexión o se establezca exclude_folders para ella manualmente.

• Sin línea de error, pero folders sigue mostrando que no hay nada excluido significa que el LIST tuvo éxito — el servidor simplemente no anuncia los atributos \Junk/\Trash (sin soporte de RFC 6154 SPECIAL-USE) y sus nombres de carpeta no coinciden con la lista en inglés integrada (junk, spam, trash, deleted messages, deleted items, bulk mail). Este es el caso de bandeja de entrada localizada — una bandeja de entrada alemana o francesa, por ejemplo — y la solución es la misma: establece exclude_folders manualmente.

exclude_folders en accounts.json, p. ej., "exclude_folders": ["Papierkorb"], tiene prioridad sobre SPECIAL-USE y la lista integrada en todos los casos.