Muchas veces, escuchamos la pregunta: "¿Tienen algún tipo de manual que explique el proceso para migrar desde una instalación local a Bird"?
Pues sí, sí lo tenemos. Sigue leyendo.
Primero, un poco de historia. El servicio Cloud de Bird se creó en 2014 a partir del enorme éxito de la solución On-Premises Momentum MTA. Momentum está en el núcleo del Bird Cloud, proporcionando entrega de alta velocidad y modelado de tráfico para miles de clientes en el servicio en la nube. Debido a esto, Momentum recibe una gran parte de nuestra atención en ingeniería, pero los resultados de ese trabajo a menudo quedan enterrados en mejoras de rendimiento que no reciben mucha prensa. Los clientes de Momentum ven los beneficios de este trabajo cada vez que se publica una nueva versión pública de Momentum.
Esto NO significa que Bird sea solo “Momentum en la Nube”. MessageBird es mucho más que eso y puede tener beneficios añadidos para los clientes que eligen migrar o usarlos en un enfoque híbrido. Estos beneficios provienen de nuestra moderna arquitectura API de correo electrónico basada en la nube, que proporciona capacidades no disponibles en las soluciones tradicionales locales. Además, hemos facilitado muchísimo a los clientes de PowerMTA migrar o utilizar PowerMTA con Bird en una configuración híbrida también. El resto de este documento describirá en detalle cómo puedes migrar tus flujos de mensajes de Momentum o PowerMTA al servicio Bird Cloud.
Realmente hay dos escenarios separados a considerar al migrar a Bird desde Momentum o PowerMTA.
Estás listo para dejar el mundo local por completo, cerrar tus centros de datos físicos y ya no gestionar directamente ningún MTA local. Esto significa eliminar Momentum o PowerMTA de tu implementación y enviar mensajes directamente a SparkPost para el manejo de mensajes. Antes de desmantelar tu infraestructura local, asegúrate de tener completas copias de seguridad de la base de datos de todos los sistemas críticos, especialmente si estás ejecutando bases de datos PostgreSQL que contienen datos históricos importantes o configuraciones.
Tienes motivos para mantener cierta presencia local por una razón u otra. Algunas posibilidades podrían ser:
flujos de entrega específicos que requieren procesamiento previo en Momentum
división de capacidad para necesidades de recuperación ante aumentos súbitos o desastres
apoyar a clientes heredados en PMTA mientras se traslada a nuevos clientes a SparkPost
...entonces querrás enviar los otros mensajes a Bird para su manejo posterior de mensajes.
En cualquiera de las situaciones, debes tener en cuenta que Bird solo aceptará mensajes SMTP para entrega que se inyecten a través del puerto 587 o 2525 y usen SMTP_Auth con un nombre de usuario y contraseña específica (Consulta los documentos SMTP aquí). También recomendamos encarecidamente conectar con una conexión TLS, pero eso no es estrictamente necesario. Si estás reemplazando completamente tu capa MTA (escenario 1), entonces también podrías considerar usar la Transmissions REST API que puede aceptar mensajes a través de conexiones HTTPS. La documentación sobre esa API está aquí.
Para organizaciones que mantienen infraestructura local que requieren capacidades seguras de correo electrónico, nuestra guía de implementación S/MIME para PowerMTA y Momentum proporciona instrucciones detalladas de configuración para entrega de correo electrónico encriptado.
¿Qué opción elijo?
Para averiguar si estás en la opción #1 o la opción #2, considera estos factores:
¿Utilizas el motor de scripting Lua de Momentum para algo más complicado que el enrutamiento de mensajes?
Lua es una herramienta de script completa para manipular mensajes en línea, pero la gran mayoría de nuestros usuarios solo lo usan para seleccionar una vinculación para la entrega. Si ese es el caso, puedes modificar tu código de generación para añadir un atributo ip_pool al encabezado X-MSYS-API y hacer que Bird asigne la ruta por ti.
Si usas Lua para hacer cosas más complicadas como filtrado de cuerpo, reescrituras de Mail_From o cálculos de cadencia de mensajes, y no es factible mover esa lógica a tu aplicación de inyección, puedes considerar cambiarte al grupo de la Opción #2.
¿Es tu sistema de generación capaz de enviar mensajes por el puerto 587 usando TLS y SMTP_Auth?
Algunos sistemas de gestión de campañas solo pueden enviar correos por el puerto 25 en texto claro. Esto causa un problema de seguridad para Bird, así que quizás quieras considerar la Opción #2
¿Estás utilizando la sintaxis de sustitución de PowerMTA u otra modificación de mensajes en línea?
Si puedes mover esta función a tus generadores o usar el Lenguaje de Plantilla de Bird, entonces aún puedes usar la opción 1, pero de lo contrario, puede que necesites pensar en mantener un nodo PMTA en línea para esta modificación de mensajes antes de enviarlos a Bird para la entrega.
¿Requieres algún escaneo de AV/AS entrante antes de la inyección? Aunque esto es posible en Momentum y PowerMTA, eBird asume que ya has realizado todas esas verificaciones. Quizás quieras considerar hacerlo antes de la inyección.
No importa el camino que elijas, seguramente afectará tu relación comercial. Como puedes imaginar, no es nuestra primera experiencia en esto. Asegúrate de incluir a tu Gerente de Cuenta Comercial y al Gerente de Éxito del Cliente para que podamos ayudarte con los detalles y asegurarnos de que estás obteniendo el mejor valor por tu dinero.
Para Opción #1 Camp (Ir “cold turkey”):
Aprovechando la Opción #2 (on-prem pre-processing):
Sin embargo, si estás en el equipo Opción #2, entonces querrás agregar algunos cambios de configuración a tu implementación. La forma menos dolorosa de migrar algunos flujos de mensajes selectos de Momentum o PMTA a Bird mientras sigues utilizando la inyección SMTP de tus sistemas de generación es agregar una ruta especial en tu configuración.
Para Momentum:
Configura una versión de Momentum > 3.6.23.
Instala un certificado SSL válido y abre el puerto saliente 587 para que Momentum pueda comunicarse con Bird. Configura un dominio saliente para que puedas enrutar un mensaje a través de Momentum a Bird.
Con la configuración a continuación, cualquier mensaje que llegue a esta configuración será dirigido a smtp.sparkpostmail.com usando el puerto 587 y SMTP_Auth con el nombre de usuario y la contraseña definidos allí.
Configura las vinculaciones que deseas retransmitir a través de MessageBird con TLS y dirígelas al dominio que definiste anteriormente.
Nota: TLS no es estrictamente necesario, pero es una fuerte recomendación. Si TLS no es posible por alguna razón, entonces la lista blanca de IP para las claves API también es una fuerte recomendación.
Para PowerMTA:
Configura una versión de PowerMTA > 4.5.0
Instala un certificado SSL válido y abre el puerto saliente 587 para que PowerMTA pueda comunicarse con Bird.
Configura una ruta de dominio saliente para que puedas enrutar un mensaje a través de PowerMTA a Bird. Con la configuración a continuación, cualquier mensaje que llegue a esta configuración será dirigido a smtp.sparkpostmail.com usando el puerto 587 y SMTP_Auth con el nombre de usuario y la contraseña definidos allí. En PowerMTA, este también es el lugar donde puedes establecer TLS. Nota: esto también está documentado más completamente aquí
4. Configura las VMTAs que deseas retransmitir a través de Bird con la configuración {sparkpost} que definiste anteriormente.
Una vez que hayas realizado esos cambios de configuración, cualquier mensaje enviado al “binding” o “VMTA” seleccionado debería ser dirigido automáticamente a través de Bird para su entrega.
Haciéndolo realidad
Cuando comienzas en este camino, no cometas el error de pensar que esto es una operación de la noche a la mañana. Hacerlo bien tomará algo de tiempo y cuidado.
Configura tu cuenta de Bird y realiza pruebas completas usando una subcuenta de desarrollo para que puedas filtrar ese tráfico más tarde. Necesitarás hacer esto para cualquiera de las opciones porque necesitarás la clave API para la contraseña SMTP_Auth de cualquier manera.
Si estás utilizando inyección SMTP, planea agregar un encabezado X-MSYS-API para incorporar todos los metadatos y atributos de mensaje necesarios. Cualquier X-Headers debe ser reescrito como metadatos e incluir los atributos ip_pool y campaign también. Un ejemplo está disponible aquí
Si NO estás utilizando BYOIP, entonces deberías asegurarte de establecer dominios de envío ligeramente diferentes para usar con MessageBird para que puedas operar ambos entornos en paralelo por el tiempo que sea necesario. Si tu dominio de envío actual es mycompany.com, tal vez establece sp.mycompany.com específicamente para la entrega de Bird. Esto te permite migrar lenta y cuidadosamente sin comprometer ninguno de los dominios.
Asegúrate de tener la alineación completa de dominios y las funciones de seguridad habilitadas. En el DNS, configura DKIM, SPF, DMARC, dominios de rebote y seguimiento para que todos parezcan pertenecer a la misma organización.
Configura la Calentamiento Automático de IP en tus IP_Pools definidos. Si estás usando la opción BYOIP mencionada anteriormente, puedes ignorar el paso de calentamiento.
Comienza con un flujo de mensajes y avanza desde allí. Al igual que con el calentamiento de IP, no querrás hacer todo de una vez. Redirige unos pocos cientos de mensajes primero, luego el 10% del volumen, luego el 20% al día siguiente y aumenta hasta que hayas movido todo el volumen. Si eres un ESP, selecciona un cliente con el que puedas trabajar y prueba el proceso con su retroalimentación. Si todo funciona bien, pasa al siguiente. Si encuentras problemas, tómate el tiempo para solucionarlo e intégralo en el proceso para el siguiente.
Automatiza tanto como sea posible con APIs. Fuera de los cambios de DNS, la configuración de SparkPost puede ser mayormente automatizada con algunas llamadas API.
Recopilación de datos from Bird
MessageBird informa sobre la entrega de mensajes en un feed de webhooks o en la API de eventos de mensajes. Acceder a los logs de texto simple de Bird no es posible. Puedes recuperar estos datos de nuevo a tu entorno con un recolector de webhooks o llamando periódicamente a la Events API y consumiendo los datos. Recomendamos usar webhooks y tenemos algunas recomendaciones acerca de cómo hacerlo correctamente. En su forma más básica, un recolector de webhooks en PHP puede desplegarse en unas pocas líneas de código:
Mientras experimentas, puedes probarlos con recolectores gratuitos como http://webhook.site/.
Una vez que hayas recopilado todos los datos del webhook, puedes leer eso en un almacén de datos para un procesamiento adicional. También hay formas de enviar Webhooks a través de servicios como StitchData y Segment.
La misma información está disponible en la Events API si necesitas obtener los datos y no puedes aceptar datos PUSH. Aquí tienes un ejemplo de llamada de Events API:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Esa API está totalmente documentada con ejemplos aquí: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Si realmente necesitas los datos de eventos de nuevo en una forma que se parezca a los registros de PMTA o Momentum, eso también es posible si empleas algún código de acondicionamiento adicional. La buena noticia es que hay algunos ejemplos de los que ya se puede aprender.
Resumen
Asegúrate de hablar con tu equipo de Ventas y Gestión del Éxito. Hemos hecho esto antes y podemos ayudarte a realizarlo de manera rápida y económica.
Descubre si estás en el Campamento #1 (capaz de mudarte completamente de On-Prem) o en el Campamento #2 (Aún necesitas algo de MTA en on-prem).
Regístrate para obtener una cuenta de prueba gratuita para evaluar los detalles de la integración.
Si estás utilizando la inyección SMTP, averigua cómo obtener los datos de encabezado y los atributos del mensaje en un encabezado X-MSYS-API.
Confirma si puedes utilizar nuestro proceso BYOIP.
Actualiza tu DNS con nuevos dominios si es necesario.
Construye una pequeña muestra para probar tu migración. Puede que necesites ajustar tu configuración.
Incrementa el volumen hasta que todo el tráfico esté migrado
Si encajas en el Campamento #1, finalmente puedes apagar tus MTA en on-prem después de que todo el tráfico esté migrado.
Al planificar cambios de DNS para sistemas de correo electrónico de alto volumen, ten en cuenta los posibles desafíos de escalado de DNS de AWS que pueden afectar el rendimiento de la entrega de correos electrónicos a gran escala.
