Nous entendons souvent la question : « Avez-vous un guide pratique d'une sorte qui décrit le processus de migration d'une installation sur site vers Bird » ?
Eh bien oui, nous en avons un. Continuez à lire.
Tout d'abord, un peu d'histoire. Le service Bird Cloud a été créé en 2014 à partir de l'énorme succès de la solution On-Premises Momentum MTA. Momentum est au cœur de Bird Cloud, assurant une livraison à grande vitesse et une gestion du trafic pour des milliers de clients sur le service cloud. À cause de cela, Momentum reçoit une grande partie de l'attention de notre ingénierie, mais les résultats de ce travail sont souvent enfouis dans des améliorations de performance qui ne reçoivent pas beaucoup de presse. Les clients de Momentum voient les avantages de ce travail chaque fois qu'une nouvelle version publique de Momentum est publiée.
Cela ne signifie PAS que Bird est simplement « Momentum dans le Cloud ». MessageBird est bien plus que cela et peut offrir des avantages supplémentaires aux clients qui choisissent de migrer ou de les utiliser dans une approche hybride. De plus, nous avons facilité la migration des clients PowerMTA ou l'utilisation de PowerMTA avec Bird dans une configuration hybride. Le reste de ce document décrira en détail comment vous pouvez migrer vos flux de messages de Momentum ou PowerMTA vers le service Bird Cloud.
Il y a vraiment deux scénarios distincts à considérer lors de la migration vers Bird à partir de Momentum ou PowerMTA.
Vous êtes prêt à quitter complètement le monde sur site, fermer vos centres de données physiques et ne plus gérer directement aucun MTA sur site. Cela signifie éliminer Momentum ou PowerMTA de votre déploiement et envoyer des messages directement à SparkPost pour la gestion des messages. Ou
Vous avez des raisons de conserver une présence sur site pour une raison ou une autre. Certaines possibilités pourraient être :
des flux de livraison spécifiques nécessitant un prétraitement dans Momentum
une répartition de la capacité pour les besoins de débordement ou de reprise après sinistre
un soutien aux anciens clients sur PMTA tout en transférant les nouveaux clients vers SparkPost
…vous souhaitez alors transférer les autres messages vers Bird pour la gestion continue des messages.
Dans les deux situations, vous devez être conscient que Bird n'acceptera que les messages SMTP pour la livraison qui sont injectés via le port 587 ou 2525 et utilisent SMTP_Auth avec un nom d'utilisateur et un mot de passe spécifiques (Voir les documents SMTP ici). Nous recommandons également fortement de se connecter avec une connexion TLS, mais cela n'est pas strictement nécessaire. Si vous remplacez complètement votre couche MTA (scénario 1), vous pouvez également envisager d'utiliser l'API REST Transmissions qui peut accepter des messages via des connexions HTTPS. La documentation sur cette API se trouve ici.
Quelle option dois-je choisir?
Pour déterminer si vous êtes dans l'option #1 ou l'option #2, considérez ces facteurs :
Utilisez-vous le moteur de script Lua de Momentum pour quelque chose de plus compliqué que le routage de messages ?
Lua est un outil de script complet pour manipuler les messages en ligne, mais la grande majorité de nos utilisateurs l'utilisent uniquement pour sélectionner une liaison pour la livraison. Dans ce cas, vous pouvez modifier votre code de génération pour ajouter un attribut ip_pool à l'entête X-MSYS-API et laisser Bird assigner la route pour vous.
Si vous utilisez Lua pour des tâches plus compliquées comme le filtrage du corps, les réécritures Mail_From, ou les calculs de cadence de message, et qu'il n'est pas faisable de déplacer cette logique dans votre application d'injection, vous devriez envisager de passer au camp de l'Option #2.
Votre système de génération est-il capable d'envoyer des messages sur le port 587 en utilisant TLS et SMTP_Auth ?
Certains systèmes de gestion de campagnes ne peuvent pousser le courrier que sur le port 25 en clair. Cela pose un problème de sécurité pour Bird, donc vous pourriez envisager l'Option #2
Utilisez-vous la syntaxe de substitution PowerMTA ou d'autres modifications de message en ligne ?
Si vous pouvez déplacer cette fonction dans vos générateurs ou utiliser le Langage de Modèle Bird, vous pouvez toujours utiliser l'option 1, mais sinon, vous pourriez avoir besoin de maintenir un nœud PMTA en ligne pour cette modification de message avant de l'expédier à Bird pour la livraison.
Avez-vous besoin d'un balayage AV/AS entrant avant l'injection ? Bien que cela soit possible dans Momentum et PowerMTA, eBird suppose que vous avez déjà effectué toutes ces vérifications. Vous pourriez vouloir considérer de le faire avant l'injection.
Quoi que vous choisissiez, cela affectera certainement votre relation commerciale. Comme vous pouvez l'imaginer, ce n'est pas notre premier rodéo. Assurez-vous de faire participer votre Responsable de Compte Commercial et votre Responsable du Succès Client afin que nous puissions vous aider à travers les détails et nous assurer que vous obtenez le meilleur rapport qualité-prix.
Pour l'Option #1 Camp (Fait « cold turkey ») :
Exploitation de l'Option #2 (prétraitement sur site) :
Si, toutefois, vous êtes dans l’équipe Option #2, alors vous voudrez apporter quelques modifications de configuration à votre déploiement. La façon la moins douloureuse de migrer certains flux de messages sélectionnés de Momentum ou PMTA vers Bird tout en utilisant toujours l'injection SMTP de vos systèmes de génération est d'ajouter une route spéciale dans votre configuration.
Pour Momentum :
Configurez une version de Momentum > 3.6.23.
Installez un certificat SSL valide et ouvrez le port sortant 587 pour que Momentum puisse dialoguer avec Bird. Configurez un domaine sortant afin que vous puissiez acheminer un message à travers Momentum vers Bird.
Avec la configuration ci-dessous, tout message atteignant cette configuration sera acheminé vers smtp.sparkpostmail.com en utilisant le port 587 et SMTP_Auth avec le nom d'utilisateur et le mot de passe définis là-bas. outbound_smtp_auth { } Keep_Message_Dicts_In_Memory = true Domain "smtp.sparkpostmail.com" { Remote_SMTP_Port = "587" Outbound_SMTP_AUTH_Type = "LOGIN" Outbound_SMTP_AUTH_user = "SMTP_Injection" Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce" }
Configurez les liaisons que vous souhaitez relayer via MessageBird avec TLS et passerelles vers le domaine que vous avez défini ci-dessus.
Remarque : TLS n'est pas strictement requis mais est fortement recommandé. Si TLS n'est pas possible pour une raison quelconque, alors la liste blanche IP des clés API est également fortement recommandée.binding “CustomerA-Outbound” { Gateway = "smtp-demo.sparkpostelite.com" TLS = "required" TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt" TLS_Key = "/etc/pki/tls/certs/trymsys.net.key" TLS_Ciphers = "DEFAULT" }
Pour PowerMTA :
Configurez une version de PowerMTA > 4.5.0
Installez un certificat SSL valide et ouvrez le port sortant 587 pour que PowerMTA puisse dialoguer avec Bird.
Configurez un chemin de domaine sortant afin que vous puissiez acheminer un message à travers PowerMTA vers Bird. Avec la configuration ci-dessous, tout message atteignant cette configuration sera acheminé vers smtp.sparkpostmail.com en utilisant le port 587 et SMTP_Auth avec le nom d'utilisateur et le mot de passe définis là-bas. Dans PowerMTA, c'est également là que vous pouvez configurer TLS. Notez que cela est également documenté plus en détail ici
<domain sparkpost.rollup> use-unencrypted-plain-auth yes auth-username SMTP_Injection auth-password YourAPIKeygoesherewhenyougenerateit route smtp.sparkpostmail.com:587 use-starttls yes require-starttls yes max-smtp-out 10 </domain>
4. Configurez les VMTAs que vous souhaitez relayer via Bird avec la configuration {sparkpost} rollup que vous avez définie ci-dessus.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Une fois que vous avez apporté ces modifications de configuration, tous les messages envoyés à la "liaison" ou "VMTA" sélectionnée devraient être automatiquement acheminés via Bird pour la livraison.
Rendre cela possible
Lorsque vous commencez sur cette voie, ne faites pas l'erreur de penser que c'est une opération du jour au lendemain. Faire cela correctement prendra du temps et de l'attention.
Configurez votre compte Bird et testez-le entièrement en utilisant un sous-compte de développement pour pouvoir filtrer ce trafic plus tard. Vous devrez le faire pour chaque option car vous aurez besoin de la clé API pour le mot de passe SMTP_Auth dans tous les cas.
Si vous utilisez l'injection SMTP, prévoyez d'ajouter un en-tête X-MSYS-API pour intégrer tous les métadonnées et attributs de message nécessaires. Tous les X-Headers devraient être réécrits en tant que métadonnées et vous devriez inclure les attributs ip_pool et campagne également. Un exemple est disponible ici
Si vous n'utilisez PAS BYOIP, alors vous devriez vous assurer de configurer des domaines d'envoi légèrement différents pour une utilisation avec MessageBird afin de pouvoir faire fonctionner les deux environnements en parallèle aussi longtemps que nécessaire. Si votre domaine d'envoi actuel est mycompany.com, peut-être configurer sp.mycompany.com spécifiquement pour la livraison Bird. Cela vous permet de migrer lentement et prudemment sans compromettre l'un ou l'autre des domaines.
Assurez-vous que vous disposez de l'alignement complet du domaine et des fonctionnalités de sécurité activées. Dans le DNS, configurez DKIM, SPF, DMARC, et des domaines de rebond et de suivi pour qu'ils semblent tous appartenir à la même organisation.
Configurez l'augmentation automatique des IP sur vos IP_Pools définis. Si vous utilisez l'option BYOIP mentionnée précédemment, vous pouvez ignorer l'étape de préchauffage.
Commencez avec un flux de messages et avancez à partir de là. Tout comme le préchauffage des IP, vous ne voulez pas tout faire en même temps. Redirigez d'abord quelques centaines de messages, puis 10% du volume, puis 20% le jour suivant et augmentez jusqu'à ce que vous ayez transféré tout le volume. Si vous êtes un ESP, sélectionnez un client avec lequel vous pouvez travailler et testez le processus avec leur retour. Si tout fonctionne bien, passez au suivant. Si vous rencontrez des problèmes, prenez le temps de les résoudre et intégrez-les dans le processus pour le suivant.
Automatisez autant que possible avec les API. Mis à part les changements DNS, la configuration SparkPost peut être principalement automatisée avec quelques appels d'API.
Collecte de données de Bird
MessageBird signale la livraison de messages dans un flux de webhooks ou dans l'API d'événements de messages. Accéder aux journaux en texte brut de Bird est tout simplement impossible. Vous pouvez récupérer ces données dans votre environnement avec un collecteur de webhooks ou en appelant périodiquement l'API des événements et en consommant les données. Nous recommandons d'utiliser les webhooks et avons quelques recommandations pour bien faire cela. Dans sa forme la plus basique, un collecteur de webhook PHP peut être déployé en quelques lignes de code :
<?php $verb = $_SERVER['REQUEST_METHOD']; if ($verb == "POST") { $jsonStr = file_get_contents("php://input"); http_response_code(200); $rnum = rand(1000,9999); $t = date("YmdHis") . $rnum; $Jfile = './data/data_'.$t.'.txt'; if (file_exists($Jfile)) { $fn = basename($Jfile,".txt"); $seq = 0; $ftail = substr($fn,-2,1); if ($ftail == "-"){ $seq = substr($fn,-1); } $seq++; $Jfile = basename($Jfile,".txt")."-".$seq.".txt"; } $fh = fopen($Jfile, "w") or die("Unable to create file!"); fwrite($fh, $jsonStr); fclose($fh); } ?>
Pendant que vous expérimentez, vous pouvez les essayer avec des collecteurs gratuits tels que http://webhook.site/.
Une fois que vous avez collecté toutes les données de webhook, vous pouvez les lire dans une base de données pour un traitement supplémentaire. Il existe également des moyens de pousser des webhooks via des services comme StitchData et Segment.
Les mêmes informations sont disponibles dans l' Events API si vous avez besoin de TIRER les données et ne pouvez pas accepter les données PUSH. Voici un exemple d'appel API d'événement :
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Cet API est entièrement documenté avec des exemples ici : https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Si vous avez vraiment besoin que les données d'événement soient de retour sous une forme qui ressemble à PMTA ou Momentum logging, c'est également possible si vous employez un code de conditionnement supplémentaire. La bonne nouvelle est qu'il existe quelques exemples déjà prêts à être utilisés.
Récapitulatif
Assurez-vous de parler à votre équipe de gestion des ventes et du succès. Nous avons déjà fait cela auparavant et pouvons vous aider à le faire rapidement et de manière rentable.
Déterminez si vous appartenez au Camp #1 (capable de passer entièrement de On-Prem) ou au Camp #2 (a encore besoin de certains MTA sur site).
Inscrivez-vous pour un compte de test gratuit pour évaluer les détails de l'intégration.
Si vous utilisez l'injection SMTP, déterminez comment obtenir les données d'en-tête et les attributs de message dans un en-tête X-MSYS-API.
Confirmez si vous pouvez utiliser notre processus BYOIP.
Mettez à jour votre DNS avec de nouveaux domaines si nécessaire.
Créez un petit échantillon pour tester votre migration. Vous devrez peut-être ajuster votre configuration.
Augmentez progressivement le volume jusqu'à ce que tout le trafic soit migré
Si vous appartenez au Camp #1, vous pouvez enfin arrêter vos MTA sur site après que tout le trafic soit migré.
