Saltar a contenido

Plan de desmantelamiento de MailerSend

Actualizado el 11 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 sigue siendo una dependencia de producción activa. No cancele la cuenta, elimine los registros DNS, revoque las credenciales ni elimine las variables protegidas todavía. Una auditoría acotada del repositorio encontró tanto consumidores de API como consumidores SMTP documentados históricamente. Cada ruta debe moverse independientemente y pasar una prueba real de entrega y ruta de fallo antes de la retirada del proveedor.

Ningún valor de credencial pertenece a Git, documentación, tickets, salida de trabajos o 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.

Inventario de consumidores del repositorio

Flujo de trabajo Evidencia Aceptación de migración
Notificaciones para el pastor de diapositivas de sermones y notificaciones de producción scripts/sermon-slide-notification-worker.py del 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.
Recepción de soporte y notificaciones al personal dashboard/v2/support/submit.php, dashboard/v2/support/support.php del portal y scripts de prueba 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 del 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 del portal y scripts/files-storage-watch.php Se reciben notificaciones controladas de advertencia y recuperación; se conservan la deduplicación y el comportamiento de enfriamiento.
Informes de gastos Código común de gastos v1.1/v2 del portal y el manejador de formularios retenido de 2026 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 nodered/instances/rocc-db-local/flows.json de la infraestructura Inventar el flujo activo 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 registro de migración.

El inventario de código es un límite inferior. Los trabajos en tiempo de ejecución, las versiones 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 de SMTP compartidos:

  • Bitwarden;
  • el flujo de trabajo de escaneo a correo electrónico de la Copistería Fiery;
  • Jamf;
  • BillionMail y los flujos de trabajo 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 de host/servicio, el dominio del remitente, el estado del reemplazo, la fecha de prueba y el revisor. Confirme la configuración activa sin mostrar nombres de usuario, contraseñas, tokens, contenido de mensajes o 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 de destinatarios de pastor/personal distinto;
  • 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 acotados 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. La auto-hospedaje de correo introduce la entregabilidad, el abuso, la reputación, la aplicación de parches, la copia de seguridad y la propiedad en guardia que deben aceptarse explícitamente; no es automáticamente más seguro o más barato que un proveedor administrado.

Secuencia de migración

  1. Asigne un propietario y un transporte de reemplazo para cada fila de repositorio y externa. Marque los consumidores activos desconocidos como bloqueadores.
  2. Configure el reemplazo en un límite de desarrollo protegido. Nunca copie valores de producción en desarrollo.
  3. Agregue configuración de aplicación neutral al proveedor mientras mantiene MailerSend como una ruta de reversión sellada. No envíe correos electrónicos de usuarios normales por duplicado.
  4. Ejercite cada flujo de trabajo con destinatarios de prueba revisados. Verifique el destinatario, remitente, responder a, enlaces/archivos adjuntos, latencia, registros y un fallo forzado.
  5. 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.
  6. 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.
  7. Elimine las credenciales de MailerSend de los consumidores activos, demuestre el rechazo de la autenticación antigua y conserve un registro de reversión con límite de tiempo solo cuando la política lo requiera.
  8. Actualice SPF/DKIM/DMARC deliberadamente y verifique la alineación antes de eliminar los registros DNS del proveedor antiguo.
  9. Cancele la suscripción/cuenta de MailerSend solo después de que un 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, propietario de prueba, cambio a producción y 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 los rebotes, supresiones, alertas y costos de SPF, DKIM, DMARC 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 progreso, no desmantelado.