Plan de desmantelamiento de MailerSend
Actualizado el 22 de agosto de 2026.
Esta es la lista de verificación de migración autorizada para retirar MailerSend sin interrumpir silenciosamente las notificaciones de la iglesia. La página de Adiós, SendGrid de 2025 explica por qué se introdujo MailerSend; es contexto histórico, no evidencia de que cada consumidor listado siga activo.
Decisión actual
MailerSend debe permanecer disponible para reversión y para consumidores SMTP externos no verificados.
No cancele la cuenta, elimine los registros DNS, revoque las credenciales ni elimine
las variables protegidas todavía. El correo de la aplicación Portal actual y los flujos de correo
principales de Node-RED rocc-db-local utilizan la puerta de enlace de Cloudflare, pero las rutas
de Fiery, Bitwarden, Jamf y BillionMail no han superado todas las pruebas de reemplazo en vivo.
Cada ruta externa debe moverse de forma independiente y superar una prueba real de entrega y de ruta de fallo
antes de la retirada del proveedor.
Ningún valor de credencial pertenece a Git, documentación, tickets, salida de trabajos ni
cuerpos de correo electrónico de prueba. El código del repositorio puede nombrar las variables protegidas
MAILERSEND_API_KEY, MAILERSEND_FROM_EMAIL y MAILERSEND_FROM_NAME; los
valores permanecen en el límite de tiempo de ejecución aprobado.
Instantánea del estado de la migración
Esta instantánea registra la evidencia recopilada el 22 de agosto de 2026. Distingue el código actual de la rama predeterminada de la documentación histórica y las ramas de funcionalidades antiguas.
| Consumidor o control | Estado | Evidencia / puerta restante |
|---|---|---|
| Puerta de enlace de correo electrónico de Cloudflare | Base de producción activa | Terraform/OpenTofu gestiona el Worker, la Cola, los metadatos D1 de la bandeja de salida, las identidades de remitente/cliente, el límite diario de entrega de 400, el límite de 30 días de entrega de 2.300 y las alertas de presupuesto de la cuenta. El dominio del remitente de producción es cf.riveroaks.cc. |
| Correo de la aplicación Portal | Migrado | El código actual del Portal solo permite la puerta de enlace de Cloudflare. Se recibió un correo electrónico de prueba de producción. Aún se requieren análisis de entrega final y una ventana de observación de ciclo normal. |
| Flujo de gastos | Migrado con decisión de producto pendiente | El correo de contabilidad actual contiene un enlace de revisión autenticado del Portal a los recibos y W-9 almacenados; no adjunta el PDF de gastos generado. Confirme que este comportamiento de enlace de revisión sea aceptable antes de considerar completa la aceptación de gastos. Si se requiere un archivo adjunto por correo electrónico, agregue un diseño de archivo adjunto limitado antes de retirar la reversión de MailerSend. |
Correo de Node-RED rocc-db-local |
Migrado | El flujo principal rastreado solo usa la puerta de enlace de Cloudflare, y la verificación de deriva en vivo del 21 de agosto se aprobó. |
| Node-RED MPR y MDF | Limpieza de legado en revisión | MDF no tiene nodo SendGrid pero conservó un paquete no utilizado. MPR conservó un nodo SendGrid en una pestaña deshabilitada además de su paquete. La MR de infraestructura riveroaks/infra!266 elimina estos artefactos y agrega una verificación de regresión; el despliegue en vivo sigue siendo una liberación manual explícita. |
| Aplicación de Tareas | Aceptación de producción en curso | Se está promocionando un trabajo de humo de correo electrónico de producción protegido y limitado. Se requiere una ejecución de producción exitosa y un resultado de entrega final. |
| Copiadora Fiery | No migrado | ROCC-C5300S en 10.200.23.45 es accesible. Necesita un token SMTP dedicado de envío de correo electrónico de Cloudflare, una prueba real de adjunto de escaneo y una prueba de reversión de MailerSend. El SMTP directo omite intencionalmente los límites de la puerta de enlace para que el correo de la impresora mantenga la prioridad. |
| Bitwarden y Jamf | No verificado | La documentación histórica dice que ambos usan el inicio de sesión SMTP compartido de MailerSend. Verifique su configuración en vivo actual sin registrar valores de credenciales, luego migre o retire explícitamente cada remitente. |
| BillionMail | No verificado / inalcanzable | La dirección histórica 10.141.74.109 no respondió a HTTP ni HTTPS durante la auditoría del 22 de agosto. Confirme si la VM/servicio todavía existe y si queda algún llamador activo. |
| Sitio web de WordPress | Aplazado, no se encontró dependencia de código fuente | El repositorio canónico del sitio web no contiene referencias a MailerSend ni SendGrid. La configuración del plugin en tiempo de ejecución en 10.141.74.111 aún necesita un inventario de plugins SMTP/WordPress seguro para credenciales cuando se reanude el proyecto del sitio web. |
| Observabilidad de entrega | Código listo; credencial bloqueada | La CI de la puerta de enlace ahora admite recuentos agregados de eventos finales de Cloudflare sin datos de destinatario, asunto o cuerpo. Agregue un token protegido con ámbito de Lectura de Análisis de Zona, luego habilite el trabajo diario y conserve sus informes de 31 días. Hasta que se ejecute, el volumen exacto de entrega diaria es desconocido. |
La auditoría del repositorio canónico de la rama predeterminada no encontró ninguna implementación activa de MailerSend o SendGrid en Portal, Tareas, las aplicaciones de Cloudflare, el repositorio del sitio web, la API de Portal, las aplicaciones de iglesia/móviles, ni los servicios de soporte actuales. Los nombres heredados permanecen en pruebas, libros de contabilidad históricos, ayudantes de reversión y documentación; esas referencias no son prueba de una ruta de entrega activa.
Inventario de consumidores del repositorio
| Flujo de trabajo | Evidencia | Aceptación de migración |
|---|---|---|
| Notificaciones de sermones y producción para pastores | scripts/sermon-slide-notification-worker.py de Portal y sus pruebas de trabajador enfocadas |
Ambos correos electrónicos de destinatarios distintos se entregan a través del reemplazo; el contenido de éxito, atención, reintento y costo/tiempo de ejecución sigue siendo correcto. |
| Notificaciones de personal y recepción de soporte | dashboard/v2/support/submit.php, dashboard/v2/support/support.php de Portal y scripts de humo de soporte |
Un ticket sintético llega a la ruta de personal prevista; se verifican la confirmación del usuario y el comportamiento de fallo del proveedor sin crear tickets duplicados. |
| Recordatorios de llaveros, resúmenes, aprobaciones y reenvíos | Scripts de llaveros de Portal y manejadores de dashboard/v2/keys/ |
Las rutas de recordatorio, resumen, aprobación y reenvío se entregan una vez a los destinatarios revisados y conservan el estado de auditoría existente. |
| Alertas de monitoreo de Q-SYS y almacenamiento de archivos | Ayudantes de vigilancia/escucha de Q-SYS de Portal y scripts/files-storage-watch.php |
Se reciben notificaciones controladas de advertencia y recuperación; se conservan el comportamiento de deduplicación y enfriamiento. |
| Informes de gastos | Código común de gastos de Portal v1.1/v2 y el manejador del formulario de 2026 conservado | Una solicitud no productiva demuestra la entrega al remitente y al revisor, el manejo de archivos adjuntos/enlaces y la visibilidad de errores del proveedor. Retire el código de formulario obsoleto por separado en lugar de asumir que está inactivo. |
| Flujos de correo electrónico de Node-RED | Metadatos de instancias de infraestructura nodered/instances/rocc-db-local/flows.json |
Inventar el flujo en vivo por identificador de nodo estable, migrar un flujo a la vez y verificar el llamador real más la ruta de error de Node-RED. No copie las credenciales del flujo en el libro de contabilidad de migración. |
El inventario de código es un límite inferior. Los trabajos en tiempo de ejecución, las liberaciones de reversión y los dispositivos SMTP externos pueden seguir siendo consumidores incluso cuando el repositorio actual ya no los referencia.
Inventario de SMTP externo a verificar nuevamente
La documentación de 2025 identifica estos consumidores SMTP compartidos:
- Bitwarden;
- el flujo de escaneo a correo electrónico de la Copiadora Fiery;
- Jamf;
- BillionMail y los flujos de Node-RED que lo llaman;
- mensajes del administrador de Wi-Fi;
- mensajes semanales de acceso Wi-Fi de Planning Center;
- confirmaciones de llaveros.
Para cada sistema, registre solo el propietario, el nombre del host/servicio, el dominio del remitente, el estado del reemplazo, la fecha de prueba y el revisor. Confirme la configuración en vivo sin mostrar nombres de usuario, contraseñas, tokens, contenidos de mensajes ni un archivo de entorno completo. Una fila histórica no verificada no es permiso para eliminarla.
Capacidades de reemplazo requeridas
El reemplazo seleccionado debe admitir:
- las identidades de remitente actuales y el enrutamiento distinto de pastores/personal;
- entrega de API autenticada para correos electrónicos de aplicaciones y SMTP autenticado para dispositivos que no pueden usar una API;
- validación de certificados TLS y credenciales protegidas de mínimo privilegio;
- reintentos limitados con idempotencia o deduplicación del lado de la aplicación;
- visibilidad de rebotes, supresiones, quejas y fallos del proveedor;
- alineación SPF, DKIM y DMARC para cada dominio de remitente activo;
- registro operativo seguro de contenido con marcas de tiempo, IDs de solicitud del proveedor, latencia, clase de resultado y costo cuando corresponda;
- un propietario mensual documentado y un límite de gasto/volumen.
La elección del proveedor no se realiza intencionalmente en este inventario. El autoalojamiento de correo introduce la entregabilidad, el abuso, la reputación, el parcheo, la copia de seguridad y la propiedad de guardia que deben aceptarse explícitamente; no es automáticamente más seguro ni más barato que un proveedor administrado.
Secuencia de migración
- Asigne un propietario y un transporte de reemplazo para cada fila de repositorio y externa. Marque los consumidores activos desconocidos como bloqueadores.
- Configure el reemplazo en un límite de desarrollo protegido. Nunca clone valores de producción en desarrollo.
- Agregue configuración de aplicación neutral al proveedor manteniendo MailerSend como una ruta de reversión sellada. No envíe por duplicado el correo normal del usuario.
- Ejercite cada flujo de trabajo con destinatarios de prueba revisados. Verifique el destinatario, remitente, respuesta a, enlaces/adjuntos, latencia, registros y un fallo forzado.
- Mueva un flujo de trabajo de producción a la vez. Observe al menos un ciclo operativo normal y confirme que no queda actividad inexplicable de MailerSend.
- Busque en el código fuente actual, nombres de variables de GitLab, metadatos de OpenBao, definiciones de systemd/cron, metadatos de nodos de Node-RED e inventario de dispositivos sin mostrar valores. Inspeccione por separado el uso del proveedor y la actividad de rebotes/supresiones.
- Retire las credenciales de MailerSend de los consumidores activos, demuestre el rechazo de autenticación antigua y conserve un registro de reversión con límite de tiempo solo cuando la política lo requiera.
- Actualice SPF/DKIM/DMARC deliberadamente y verifique la alineación antes de retirar los registros DNS del proveedor antiguo.
- Cancele la suscripción/cuenta de MailerSend solo después de que el propietario apruebe el registro de evidencia y haya pasado la ventana de observación.
Evidencia de finalización
MailerSend se desmantela solo cuando todas las siguientes condiciones son verdaderas:
- [ ] Cada fila del repositorio tiene un reemplazo, un propietario de prueba, un corte de producción y un resultado de ruta de fallo.
- [ ] Cada consumidor SMTP documentado históricamente se verifica migrado o explícitamente retirado.
- [ ] El código fuente actual y los metadatos en tiempo de ejecución no contienen ningún consumidor activo de MailerSend.
- [ ] La actividad del proveedor permanece en cero durante la ventana de observación aprobada.
- [ ] Se verifican la propiedad de SPF, DKIM, DMARC, rebotes, supresiones, alertas y costos de reemplazo.
- [ ] Las credenciales antiguas son rechazadas y eliminadas de los límites activos de GitLab/OpenBao/host sin exponer sus valores.
- [ ] Los manuales de reversión e incidentes nombran el transporte de reemplazo.
- [ ] El propietario de la cuenta aprueba la cancelación del proveedor y registra la fecha.
Hasta que cada casilla esté completa, el estado correcto de la tarea es en curso, no desmantelado.