Guide de migration des courriels sur site vers le cloud

Oiseau

28 juin 2020

Email

1 min read

Guide de migration des courriels sur site vers le cloud

Points Clés

    • Bird Cloud a été construit sur le moteur éprouvé Momentum MTA, offrant aux clients la performance d'un système sur site mature avec les avantages supplémentaires d'une plateforme API email cloud moderne.

    • De nombreux expéditeurs hérités dépendent encore de Momentum ou PowerMTA, et Bird offre une voie de migration claire pour les deux—migration complète vers le cloud ou routage hybride via des nœuds sur site.

    • La migration nécessite de comprendre si vous allez :

      1. éliminer toute l'infrastructure sur site, ou

      2. continuer à utiliser votre MTA pour le prétraitement, le routage ou les contraintes héritées.

    • Bird n'accepte que l'injection SMTP authentifiée via les ports 587 ou 2525 (TLS fortement recommandé). L'injection via REST API est également disponible pour une livraison directe basée sur JSON.

    • L'option n°1 (« sortie radicale ») permet la mise hors service complète des MTAs en envoyant directement à Bird via SMTP ou REST, supprimant la complexité et modernisant l'architecture d'envoi.

    • L'option n°2 prend en charge les environnements hybrides—en routant des flux sélectionnés de Momentum ou PMTA vers Bird en configurant les domaines de sortie avec SMTP_Auth vers Bird.

    • Les configurations de PowerMTA et Momentum peuvent transférer le trafic de manière sécurisée vers Bird en utilisant TLS, SMTP_Auth à base de clé API, et des définitions de route.

    • Les clients utilisant des scripts Lua avancés, des substitutions en ligne, ou des filtres de pré-livraison peuvent rester hybrides jusqu'à ce que la logique soit refondue dans les systèmes en amont.

    • Bird prend en charge BYOIP (Bring Your Own IP) pour les clients ayant un bloc continu /24, vous permettant de conserver la réputation IP échauffée et d'éviter une reprise complète de réchauffement IP.

    • Pour les utilisateurs non-BYOIP, Bird propose un réchauffement IP automatique, et recommande une migration progressive—en commençant par de petits volumes, puis en augmentant progressivement le trafic.

    • Une configuration correcte du domaine (DKIM, SPF, DMARC, domaines de rebond, domaines de suivi) est essentielle pour l'alignement et une coexistence harmonieuse pendant la migration.

    • Bird fournit des données d'événements en temps réel via des webhooks ou l'Events API, permettant l'automatisation en aval, les flux ETL, et la reconstruction de style journal si nécessaire.

Points forts des Q&A

  • Quels sont les deux principaux scénarios de migration ?

    Soit désactiver complètement tous les MTAs sur site (Option #1) ou maintenir une configuration hybride où une partie du trafic est routée via Momentum/PMTA avant d'atteindre Bird (Option #2).

  • Qu'est-ce qui détermine si vous choisissez l'Option #1 ou l'Option #2?

    Votre dépendance sur les scripts Lua, la logique de prétraitement, la réécriture de messages, les exigences de sécurité ou les générateurs qui ne peuvent pas envoyer de trafic authentifié via le port 587.

  • Bird accepte-t-il l'injection SMTP sur le port 25 ?

    Non—Bird nécessite l'injection SMTP via le port 587 ou 2525, authentifié avec SMTP_Auth.

  • TLS est-il requis ?

    Non strictement requis, mais fortement recommandé pour l'injection sécurisée de messages provenant soit de générateurs, soit de MTAs sur site.

  • Les expéditeurs peuvent-ils utiliser le REST API au lieu de SMTP?

    Oui—les expéditeurs peuvent envoyer des charges utiles JSON via l'API REST Transmissions, ce qui simplifie souvent les workflows et élimine la nécessité de générer des messages SMTP bruts.

  • Qu'est-ce que le programme BYOIP de Bird ?

    Un processus qui permet aux clients avec un bloc contigu /24 de migrer leurs IPs existantes dans Bird, en maintenant la réputation et en évitant l'étape de réchauffement.

  • Que se passe-t-il si BYOIP n'est pas une option ?

    Utilisez de nouveaux domaines d'envoi (par exemple, sp.votredomaine.com), exécutez les deux environnements en parallèle et fiez-vous au réchauffement automatique de l'IP de Bird.

  • Comment acheminer uniquement les flux sélectionnés via Bird dans une configuration hybride ?

    En configurant les domaines sortants (Momentum) ou les configurations de regroupement/VMTAs (PowerMTA) qui authentifient et livrent à l'endpoint SMTP de Bird.

  • Quelles modifications de métadonnées sont nécessaires lors de l'injection via SMTP ?

    Ajoutez un en-tête X-MSYS-API contenant des attributs comme ip_pool, campaign, et toutes métadonnées personnalisées précédemment gérées via les X-Headers.

  • Qu'est-ce qui doit être configuré dans le DNS avant la migration ?

    Les enregistrements DKIM, SPF, DMARC, domaines de rebond, et domaines de suivi pour garantir l'alignement des domaines et réduire le risque de délivrabilité pendant la transition.

  • Comment le trafic doit-il être migré vers Bird ?

    Progressivement : commencez avec un petit flux, puis 10 %, puis 20 %, en augmentant quotidiennement jusqu'à ce que tout le trafic soit déplacé—semblable aux meilleures pratiques de réchauffement des IP.

  • Comment les expéditeurs peuvent-ils collecter des données de livraison et d'engagement après la migration ?

    En utilisant le système de webhook en temps réel de Bird ou l'API des événements ; les collecteurs de webhook peuvent être construits rapidement et alimenter les systèmes de stockage en aval ou de traitement ETL.

Tant de fois, nous entendons la question : « Avez-vous un guide qui décrit le processus de migration d'une installation sur site vers Bird » ?

Eh bien oui, oui nous l'avons. Continuez à lire.

Tout d'abord, un peu d'histoire. Le service Bird Cloud a été créé en 2014 suite à l'énorme succès de la solution On-Premises Momentum MTA. Momentum est au cœur de Bird Cloud, fournissant une livraison à haute vitesse et un ajustement du trafic pour des milliers de clients sur le service cloud. Pour cette raison, Momentum reçoit une grande partie de notre attention en ingénierie, mais les résultats de ce travail sont souvent enfouis dans des améliorations de performances qui ne reçoivent pas beaucoup de publicité. Les clients 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. Ces avantages découlent de notre architecture API email basée sur le cloud, qui fournit des capacités non disponibles dans les solutions traditionnelles sur site. De plus, nous avons facilité la migration ou l'utilisation de PowerMTA avec Bird dans une configuration hybride également. 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. 

  1. Vous êtes prêt à quitter complètement le monde sur site, fermer vos centres de données physiques et ne plus gérer directement de MTA sur site. Cela signifie éliminer Momentum ou PowerMTA de votre déploiement et envoyer des messages directement à SparkPost pour la gestion des messages. Avant de désactiver votre infrastructure sur site, assurez-vous d'avoir des sauvegardes complètes de la base de données de tous les systèmes critiques, surtout si vous exécutez des bases de données PostgreSQL qui contiennent des données historiques ou des configurations importantes.

  2. Vous avez une raison de conserver une certaine empreinte sur site pour une raison quelconque. Certaines possibilités pourraient être :

  • des flux de livraison spécifiques qui nécessitent un pré-traitement dans Momentum

  • répartition de la capacité pour les besoins de récupération en cas d'urgence ou de pic

  • soutenir les clients hérités dans PMTA tout en transférant les nouveaux clients vers SparkPost

 …alors vous souhaitez transférer les autres messages vers Bird pour une gestion ultérieure des messages.  

Dans chaque situation, vous devez être conscient que Bird n'acceptera que les messages SMTP pour la livraison qui sont injectés sur les ports 587 ou 2525 et utilisent SMTP_Auth avec un nom d'utilisateur et un mot de passe spécifiques (Voir la documentation SMTP ici). Nous recommandons également vivement de se connecter avec une connexion TLS, mais ce n'est pas strictement nécessaire. Si vous remplacez entièrement 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 est ici.

Pour les organisations maintenant une infrastructure sur site nécessitant des capacités email sécurisées, notre guide d'implémentation S/MIME pour PowerMTA et Momentum fournit des instructions détaillées pour la configuration de la livraison d'email crypté.

Tant de fois, nous entendons la question : « Avez-vous un guide qui décrit le processus de migration d'une installation sur site vers Bird » ?

Eh bien oui, oui nous l'avons. Continuez à lire.

Tout d'abord, un peu d'histoire. Le service Bird Cloud a été créé en 2014 suite à l'énorme succès de la solution On-Premises Momentum MTA. Momentum est au cœur de Bird Cloud, fournissant une livraison à haute vitesse et un ajustement du trafic pour des milliers de clients sur le service cloud. Pour cette raison, Momentum reçoit une grande partie de notre attention en ingénierie, mais les résultats de ce travail sont souvent enfouis dans des améliorations de performances qui ne reçoivent pas beaucoup de publicité. Les clients 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. Ces avantages découlent de notre architecture API email basée sur le cloud, qui fournit des capacités non disponibles dans les solutions traditionnelles sur site. De plus, nous avons facilité la migration ou l'utilisation de PowerMTA avec Bird dans une configuration hybride également. 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. 

  1. Vous êtes prêt à quitter complètement le monde sur site, fermer vos centres de données physiques et ne plus gérer directement de MTA sur site. Cela signifie éliminer Momentum ou PowerMTA de votre déploiement et envoyer des messages directement à SparkPost pour la gestion des messages. Avant de désactiver votre infrastructure sur site, assurez-vous d'avoir des sauvegardes complètes de la base de données de tous les systèmes critiques, surtout si vous exécutez des bases de données PostgreSQL qui contiennent des données historiques ou des configurations importantes.

  2. Vous avez une raison de conserver une certaine empreinte sur site pour une raison quelconque. Certaines possibilités pourraient être :

  • des flux de livraison spécifiques qui nécessitent un pré-traitement dans Momentum

  • répartition de la capacité pour les besoins de récupération en cas d'urgence ou de pic

  • soutenir les clients hérités dans PMTA tout en transférant les nouveaux clients vers SparkPost

 …alors vous souhaitez transférer les autres messages vers Bird pour une gestion ultérieure des messages.  

Dans chaque situation, vous devez être conscient que Bird n'acceptera que les messages SMTP pour la livraison qui sont injectés sur les ports 587 ou 2525 et utilisent SMTP_Auth avec un nom d'utilisateur et un mot de passe spécifiques (Voir la documentation SMTP ici). Nous recommandons également vivement de se connecter avec une connexion TLS, mais ce n'est pas strictement nécessaire. Si vous remplacez entièrement 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 est ici.

Pour les organisations maintenant une infrastructure sur site nécessitant des capacités email sécurisées, notre guide d'implémentation S/MIME pour PowerMTA et Momentum fournit des instructions détaillées pour la configuration de la livraison d'email crypté.

Tant de fois, nous entendons la question : « Avez-vous un guide qui décrit le processus de migration d'une installation sur site vers Bird » ?

Eh bien oui, oui nous l'avons. Continuez à lire.

Tout d'abord, un peu d'histoire. Le service Bird Cloud a été créé en 2014 suite à l'énorme succès de la solution On-Premises Momentum MTA. Momentum est au cœur de Bird Cloud, fournissant une livraison à haute vitesse et un ajustement du trafic pour des milliers de clients sur le service cloud. Pour cette raison, Momentum reçoit une grande partie de notre attention en ingénierie, mais les résultats de ce travail sont souvent enfouis dans des améliorations de performances qui ne reçoivent pas beaucoup de publicité. Les clients 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. Ces avantages découlent de notre architecture API email basée sur le cloud, qui fournit des capacités non disponibles dans les solutions traditionnelles sur site. De plus, nous avons facilité la migration ou l'utilisation de PowerMTA avec Bird dans une configuration hybride également. 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. 

  1. Vous êtes prêt à quitter complètement le monde sur site, fermer vos centres de données physiques et ne plus gérer directement de MTA sur site. Cela signifie éliminer Momentum ou PowerMTA de votre déploiement et envoyer des messages directement à SparkPost pour la gestion des messages. Avant de désactiver votre infrastructure sur site, assurez-vous d'avoir des sauvegardes complètes de la base de données de tous les systèmes critiques, surtout si vous exécutez des bases de données PostgreSQL qui contiennent des données historiques ou des configurations importantes.

  2. Vous avez une raison de conserver une certaine empreinte sur site pour une raison quelconque. Certaines possibilités pourraient être :

  • des flux de livraison spécifiques qui nécessitent un pré-traitement dans Momentum

  • répartition de la capacité pour les besoins de récupération en cas d'urgence ou de pic

  • soutenir les clients hérités dans PMTA tout en transférant les nouveaux clients vers SparkPost

 …alors vous souhaitez transférer les autres messages vers Bird pour une gestion ultérieure des messages.  

Dans chaque situation, vous devez être conscient que Bird n'acceptera que les messages SMTP pour la livraison qui sont injectés sur les ports 587 ou 2525 et utilisent SMTP_Auth avec un nom d'utilisateur et un mot de passe spécifiques (Voir la documentation SMTP ici). Nous recommandons également vivement de se connecter avec une connexion TLS, mais ce n'est pas strictement nécessaire. Si vous remplacez entièrement 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 est ici.

Pour les organisations maintenant une infrastructure sur site nécessitant des capacités email sécurisées, notre guide d'implémentation S/MIME pour PowerMTA et Momentum fournit des instructions détaillées pour la configuration de la livraison d'email crypté.

Quelle option dois-je choisir?

Pour déterminer si vous êtes dans l'option #1 ou l'option #2, considérez ces facteurs :

Option

Idéal si vous

Exigence clé

Compromis

Option #1 : Migration complète vers le cloud

Pouvez supprimer tous les MTAs sur site

Auth SMTP sur 587/2525 ou REST API

Nécessite de refactoriser toute logique avancée sur site

Option #2 : Routage hybride

Nécessitez un pré-traitement ou un support legacy

Momentum ou PowerMTA reste en ligne

Complexité opérationnelle ajoutée


  • 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 un lien pour la livraison. Si c'est le cas, vous pouvez modifier votre code de génération pour ajouter un attribut ip_pool à l'en-tête X-MSYS-API et faire en sorte que Bird assigne l'itinéraire pour vous. 

    • Si vous utilisez Lua pour faire des choses plus compliquées comme le filtrage du corps, les réécritures de Mail_From, ou les calculs de cadence de messages, et qu'il n'est pas faisable de déplacer cette logique dans votre application d'injection, vous pouvez 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 envoyer le courrier que sur le port 25 en clair. Cela pose un problème de sécurité pour Bird donc vous pouvez envisager l'Option #2.

  • Utilisez-vous la syntaxe de substitution de PowerMTA ou une autre modification en ligne des messages ?

    • Si vous pouvez déplacer cette fonction vers vos générateurs ou utiliser le Template Language de Bird, alors vous pouvez toujours utiliser l'option 1, mais sinon, vous devrez peut-être penser à garder un nœud PMTA en ligne pour cette modification avant l'expédition à Bird pour la livraison.

  • Avez-vous besoin d'un scan 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 pouvez envisager de le faire avant l'injection.

Peu importe le chemin que vous choisissez, cela affectera sûrement votre relation commerciale. Comme vous pouvez l'imaginer, ce n'est pas notre première expérience. Assurez-vous d'inclure votre Gestionnaire de Compte Commercial et votre Gestionnaire de Réussite Client afin que nous puissions vous aider à traverser les détails et nous assurer que vous obtenez la meilleure valeur pour votre argent.

Pour déterminer si vous êtes dans l'option #1 ou l'option #2, considérez ces facteurs :

Option

Idéal si vous

Exigence clé

Compromis

Option #1 : Migration complète vers le cloud

Pouvez supprimer tous les MTAs sur site

Auth SMTP sur 587/2525 ou REST API

Nécessite de refactoriser toute logique avancée sur site

Option #2 : Routage hybride

Nécessitez un pré-traitement ou un support legacy

Momentum ou PowerMTA reste en ligne

Complexité opérationnelle ajoutée


  • 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 un lien pour la livraison. Si c'est le cas, vous pouvez modifier votre code de génération pour ajouter un attribut ip_pool à l'en-tête X-MSYS-API et faire en sorte que Bird assigne l'itinéraire pour vous. 

    • Si vous utilisez Lua pour faire des choses plus compliquées comme le filtrage du corps, les réécritures de Mail_From, ou les calculs de cadence de messages, et qu'il n'est pas faisable de déplacer cette logique dans votre application d'injection, vous pouvez 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 envoyer le courrier que sur le port 25 en clair. Cela pose un problème de sécurité pour Bird donc vous pouvez envisager l'Option #2.

  • Utilisez-vous la syntaxe de substitution de PowerMTA ou une autre modification en ligne des messages ?

    • Si vous pouvez déplacer cette fonction vers vos générateurs ou utiliser le Template Language de Bird, alors vous pouvez toujours utiliser l'option 1, mais sinon, vous devrez peut-être penser à garder un nœud PMTA en ligne pour cette modification avant l'expédition à Bird pour la livraison.

  • Avez-vous besoin d'un scan 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 pouvez envisager de le faire avant l'injection.

Peu importe le chemin que vous choisissez, cela affectera sûrement votre relation commerciale. Comme vous pouvez l'imaginer, ce n'est pas notre première expérience. Assurez-vous d'inclure votre Gestionnaire de Compte Commercial et votre Gestionnaire de Réussite Client afin que nous puissions vous aider à traverser les détails et nous assurer que vous obtenez la meilleure valeur pour votre argent.

Pour déterminer si vous êtes dans l'option #1 ou l'option #2, considérez ces facteurs :

Option

Idéal si vous

Exigence clé

Compromis

Option #1 : Migration complète vers le cloud

Pouvez supprimer tous les MTAs sur site

Auth SMTP sur 587/2525 ou REST API

Nécessite de refactoriser toute logique avancée sur site

Option #2 : Routage hybride

Nécessitez un pré-traitement ou un support legacy

Momentum ou PowerMTA reste en ligne

Complexité opérationnelle ajoutée


  • 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 un lien pour la livraison. Si c'est le cas, vous pouvez modifier votre code de génération pour ajouter un attribut ip_pool à l'en-tête X-MSYS-API et faire en sorte que Bird assigne l'itinéraire pour vous. 

    • Si vous utilisez Lua pour faire des choses plus compliquées comme le filtrage du corps, les réécritures de Mail_From, ou les calculs de cadence de messages, et qu'il n'est pas faisable de déplacer cette logique dans votre application d'injection, vous pouvez 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 envoyer le courrier que sur le port 25 en clair. Cela pose un problème de sécurité pour Bird donc vous pouvez envisager l'Option #2.

  • Utilisez-vous la syntaxe de substitution de PowerMTA ou une autre modification en ligne des messages ?

    • Si vous pouvez déplacer cette fonction vers vos générateurs ou utiliser le Template Language de Bird, alors vous pouvez toujours utiliser l'option 1, mais sinon, vous devrez peut-être penser à garder un nœud PMTA en ligne pour cette modification avant l'expédition à Bird pour la livraison.

  • Avez-vous besoin d'un scan 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 pouvez envisager de le faire avant l'injection.

Peu importe le chemin que vous choisissez, cela affectera sûrement votre relation commerciale. Comme vous pouvez l'imaginer, ce n'est pas notre première expérience. Assurez-vous d'inclure votre Gestionnaire de Compte Commercial et votre Gestionnaire de Réussite Client afin que nous puissions vous aider à traverser les détails et nous assurer que vous obtenez la meilleure valeur pour votre argent.

Pour l'option #1 Camp (Aller « cold turkey ») :

Supposons que vous êtes d'accord avec l'option 1 et que vous êtes prêt à fermer vos MTA locaux et que vous avez décidé de continuer à utiliser la méthode d'injection SMTP, sans changer vos systèmes de création de messages du tout.  Vos systèmes de génération devraient créer un message SMTP entièrement formaté, puis le pousser vers Bird via TLS en utilisant SMTP_AUTH où le nom d'utilisateur et le mot de passe sont décrits sur cette page. N'oubliez pas que le « mot de passe » est la clé API que vous générez dans votre compte Bird avec l'option de livraison SMTP activée.

Si vous êtes dans le camp de l'Option #1, envisagez de passer à l'API REST directement depuis votre système de génération. Dans la plupart des cas, nous constatons que les systèmes de traitement des clients utilisent déjà JSON sur HTTP et doivent convertir en SMTP avant l'injection. Vous pouvez sauter cette étape et nous l'envoyer directement sous la forme d'une charge utile REST formatée en JSON.

Si vous choisissez d'injecter avec l'API REST, vous devrez peut-être modifier un peu votre système de création de contenu, mais cela peut en valoir la peine.  Vous pouvez en savoir plus ici.

L'une des plus grandes préoccupations des grands ESP avec une Migration est le réchauffement des IP. En général, ils ont passé de nombreuses années à soigner leur inventaire d'adresses IP avec grand soin, donc l'idée d'abandonner tout ce travail est douloureuse. Bird a élaboré un processus Bring Your Own IP (BYOIP) qui résout ce problème. Si vous avez au moins un bloc CIDR continu /24, Bird peut utiliser ces IP existantes pour la livraison, ce qui vous évite la douleur de devoir les réchauffer à nouveau. Si vous êtes en mesure de profiter de cette option, vous pouvez sauter la section ici sur le réchauffement des IP.

Si vous pensez être prêt ici, passez à « Making it happen »

Supposons que vous êtes d'accord avec l'option 1 et que vous êtes prêt à fermer vos MTA locaux et que vous avez décidé de continuer à utiliser la méthode d'injection SMTP, sans changer vos systèmes de création de messages du tout.  Vos systèmes de génération devraient créer un message SMTP entièrement formaté, puis le pousser vers Bird via TLS en utilisant SMTP_AUTH où le nom d'utilisateur et le mot de passe sont décrits sur cette page. N'oubliez pas que le « mot de passe » est la clé API que vous générez dans votre compte Bird avec l'option de livraison SMTP activée.

Si vous êtes dans le camp de l'Option #1, envisagez de passer à l'API REST directement depuis votre système de génération. Dans la plupart des cas, nous constatons que les systèmes de traitement des clients utilisent déjà JSON sur HTTP et doivent convertir en SMTP avant l'injection. Vous pouvez sauter cette étape et nous l'envoyer directement sous la forme d'une charge utile REST formatée en JSON.

Si vous choisissez d'injecter avec l'API REST, vous devrez peut-être modifier un peu votre système de création de contenu, mais cela peut en valoir la peine.  Vous pouvez en savoir plus ici.

L'une des plus grandes préoccupations des grands ESP avec une Migration est le réchauffement des IP. En général, ils ont passé de nombreuses années à soigner leur inventaire d'adresses IP avec grand soin, donc l'idée d'abandonner tout ce travail est douloureuse. Bird a élaboré un processus Bring Your Own IP (BYOIP) qui résout ce problème. Si vous avez au moins un bloc CIDR continu /24, Bird peut utiliser ces IP existantes pour la livraison, ce qui vous évite la douleur de devoir les réchauffer à nouveau. Si vous êtes en mesure de profiter de cette option, vous pouvez sauter la section ici sur le réchauffement des IP.

Si vous pensez être prêt ici, passez à « Making it happen »

Supposons que vous êtes d'accord avec l'option 1 et que vous êtes prêt à fermer vos MTA locaux et que vous avez décidé de continuer à utiliser la méthode d'injection SMTP, sans changer vos systèmes de création de messages du tout.  Vos systèmes de génération devraient créer un message SMTP entièrement formaté, puis le pousser vers Bird via TLS en utilisant SMTP_AUTH où le nom d'utilisateur et le mot de passe sont décrits sur cette page. N'oubliez pas que le « mot de passe » est la clé API que vous générez dans votre compte Bird avec l'option de livraison SMTP activée.

Si vous êtes dans le camp de l'Option #1, envisagez de passer à l'API REST directement depuis votre système de génération. Dans la plupart des cas, nous constatons que les systèmes de traitement des clients utilisent déjà JSON sur HTTP et doivent convertir en SMTP avant l'injection. Vous pouvez sauter cette étape et nous l'envoyer directement sous la forme d'une charge utile REST formatée en JSON.

Si vous choisissez d'injecter avec l'API REST, vous devrez peut-être modifier un peu votre système de création de contenu, mais cela peut en valoir la peine.  Vous pouvez en savoir plus ici.

L'une des plus grandes préoccupations des grands ESP avec une Migration est le réchauffement des IP. En général, ils ont passé de nombreuses années à soigner leur inventaire d'adresses IP avec grand soin, donc l'idée d'abandonner tout ce travail est douloureuse. Bird a élaboré un processus Bring Your Own IP (BYOIP) qui résout ce problème. Si vous avez au moins un bloc CIDR continu /24, Bird peut utiliser ces IP existantes pour la livraison, ce qui vous évite la douleur de devoir les réchauffer à nouveau. Si vous êtes en mesure de profiter de cette option, vous pouvez sauter la section ici sur le réchauffement des IP.

Si vous pensez être prêt ici, passez à « Making it happen »

Exploiter l'option n°2 (prétraitement sur site) :

Si, cependant, vous êtes dans l'équipe Option #2, alors vous voudrez ajouter quelques modifications de configuration à votre déploiement. La manière la moins douloureuse de migrer certains flux de messages sélectionnés de Momentum ou PMTA vers Bird tout en utilisant l'injection SMTP de vos systèmes de génération est d'ajouter une route spéciale dans votre configuration.

Pour Momentum :

  1. Configurez une version de Momentum > 3.6.23. 

  2. Installez un certificat SSL valide et ouvrez le port sortant 587 afin que Momentum puisse communiquer avec Bird. Configurez un domaine sortant pour pouvoir envoyer un message via Momentum à Bird. 

  3. Avec la configuration ci-dessous, tout message atteignant cette configuration sera routé 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à.

    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"
}


  4. Configurez les liaisons que vous souhaitez relayer via MessageBird avec TLS et passez-les au domaine que vous avez défini ci-dessus.

    Note: TLS n'est pas strictement requis, mais est fortement recommandé. Si TLS n'est pas possible pour une raison quelconque, alors le whitelisting IP des clés API est également fortement recommandé.

    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 :

  1. Configurez une version de PowerMTA > 4.5.0

  2. Installez un certificat SSL valide et ouvrez le port sortant 587 afin que PowerMTA puisse communiquer avec Bird.

  3. Configurez un chemin de domaine sortant pour pouvoir envoyer un message via PowerMTA à Bird. Avec la configuration ci-dessous, tout message atteignant cette configuration sera routé 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à.  Dans PowerMTA, c'est aussi là que vous pouvez définir 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, tout message envoyé aux « liaisons » ou « VMTA » sélectionnés devrait être automatiquement routé via Bird pour livraison.  

Si, cependant, vous êtes dans l'équipe Option #2, alors vous voudrez ajouter quelques modifications de configuration à votre déploiement. La manière la moins douloureuse de migrer certains flux de messages sélectionnés de Momentum ou PMTA vers Bird tout en utilisant l'injection SMTP de vos systèmes de génération est d'ajouter une route spéciale dans votre configuration.

Pour Momentum :

  1. Configurez une version de Momentum > 3.6.23. 

  2. Installez un certificat SSL valide et ouvrez le port sortant 587 afin que Momentum puisse communiquer avec Bird. Configurez un domaine sortant pour pouvoir envoyer un message via Momentum à Bird. 

  3. Avec la configuration ci-dessous, tout message atteignant cette configuration sera routé 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à.

    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"
}


  4. Configurez les liaisons que vous souhaitez relayer via MessageBird avec TLS et passez-les au domaine que vous avez défini ci-dessus.

    Note: TLS n'est pas strictement requis, mais est fortement recommandé. Si TLS n'est pas possible pour une raison quelconque, alors le whitelisting IP des clés API est également fortement recommandé.

    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 :

  1. Configurez une version de PowerMTA > 4.5.0

  2. Installez un certificat SSL valide et ouvrez le port sortant 587 afin que PowerMTA puisse communiquer avec Bird.

  3. Configurez un chemin de domaine sortant pour pouvoir envoyer un message via PowerMTA à Bird. Avec la configuration ci-dessous, tout message atteignant cette configuration sera routé 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à.  Dans PowerMTA, c'est aussi là que vous pouvez définir 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, tout message envoyé aux « liaisons » ou « VMTA » sélectionnés devrait être automatiquement routé via Bird pour livraison.  

Si, cependant, vous êtes dans l'équipe Option #2, alors vous voudrez ajouter quelques modifications de configuration à votre déploiement. La manière la moins douloureuse de migrer certains flux de messages sélectionnés de Momentum ou PMTA vers Bird tout en utilisant l'injection SMTP de vos systèmes de génération est d'ajouter une route spéciale dans votre configuration.

Pour Momentum :

  1. Configurez une version de Momentum > 3.6.23. 

  2. Installez un certificat SSL valide et ouvrez le port sortant 587 afin que Momentum puisse communiquer avec Bird. Configurez un domaine sortant pour pouvoir envoyer un message via Momentum à Bird. 

  3. Avec la configuration ci-dessous, tout message atteignant cette configuration sera routé 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à.

    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"
}


  4. Configurez les liaisons que vous souhaitez relayer via MessageBird avec TLS et passez-les au domaine que vous avez défini ci-dessus.

    Note: TLS n'est pas strictement requis, mais est fortement recommandé. Si TLS n'est pas possible pour une raison quelconque, alors le whitelisting IP des clés API est également fortement recommandé.

    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 :

  1. Configurez une version de PowerMTA > 4.5.0

  2. Installez un certificat SSL valide et ouvrez le port sortant 587 afin que PowerMTA puisse communiquer avec Bird.

  3. Configurez un chemin de domaine sortant pour pouvoir envoyer un message via PowerMTA à Bird. Avec la configuration ci-dessous, tout message atteignant cette configuration sera routé 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à.  Dans PowerMTA, c'est aussi là que vous pouvez définir 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, tout message envoyé aux « liaisons » ou « VMTA » sélectionnés devrait être automatiquement routé via Bird pour livraison.  

Faire en sorte que cela se produise

Quand 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 des soins.  

  1. Configurez votre compte Bird et testez-le complètement en utilisant un sous-compte de développement afin de pouvoir filtrer ce trafic plus tard.  Vous devrez faire cela pour chaque option car vous aurez besoin de la clé API pour le mot de passe SMTP_Auth de toute façon.

  2. Si vous utilisez l'injection SMTP, prévoyez d'ajouter un en-tête X-MSYS-API pour incorporer toutes les métadonnées et attributs du message nécessaires.  Tous les X-Headers doivent être réécrits comme métadonnées et vous devriez inclure les attributs ip_pool et campagne également. Un exemple est disponible ici

  3. 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 avec Bird.  Cela vous permet de migrer lentement et avec précaution sans compromettre aucun des deux domaines.

  4. Assurez-vous que vous avez une pleine alignement de domaine et que les fonctionnalités de sécurité sont activées.  Dans le DNS, configurez DKIM, SPF, DMARC, les domaines de rebond et de suivi pour qu'ils semblent tous appartenir à la même organisation.

  5. Configurez Automatic IP Warmup sur vos IP_Pools définis.  Si vous utilisez l'option mentionnée précédemment BYOIP, vous pouvez ignorer l'étape de réchauffement.

  6. Commencez avec un flux de messages et avancez à partir de là.  Tout comme IP Warmup, vous ne voulez pas tout faire d'un coup. Redirigez quelques centaines de messages d'abord, puis 10 % du volume, puis 20 % le jour suivant et augmentez jusqu'à ce que vous ayez déplacé tout le volume. Si vous êtes un ESP, sélectionnez un client avec lequel vous pouvez travailler et testez le processus avec leurs retours.  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.

  7. Automatisez autant que possible avec des APIs.  En dehors des changements DNS, la configuration de SparkPost peut être en grande partie automatisée avec quelques appels API.

Quand 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 des soins.  

  1. Configurez votre compte Bird et testez-le complètement en utilisant un sous-compte de développement afin de pouvoir filtrer ce trafic plus tard.  Vous devrez faire cela pour chaque option car vous aurez besoin de la clé API pour le mot de passe SMTP_Auth de toute façon.

  2. Si vous utilisez l'injection SMTP, prévoyez d'ajouter un en-tête X-MSYS-API pour incorporer toutes les métadonnées et attributs du message nécessaires.  Tous les X-Headers doivent être réécrits comme métadonnées et vous devriez inclure les attributs ip_pool et campagne également. Un exemple est disponible ici

  3. 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 avec Bird.  Cela vous permet de migrer lentement et avec précaution sans compromettre aucun des deux domaines.

  4. Assurez-vous que vous avez une pleine alignement de domaine et que les fonctionnalités de sécurité sont activées.  Dans le DNS, configurez DKIM, SPF, DMARC, les domaines de rebond et de suivi pour qu'ils semblent tous appartenir à la même organisation.

  5. Configurez Automatic IP Warmup sur vos IP_Pools définis.  Si vous utilisez l'option mentionnée précédemment BYOIP, vous pouvez ignorer l'étape de réchauffement.

  6. Commencez avec un flux de messages et avancez à partir de là.  Tout comme IP Warmup, vous ne voulez pas tout faire d'un coup. Redirigez quelques centaines de messages d'abord, puis 10 % du volume, puis 20 % le jour suivant et augmentez jusqu'à ce que vous ayez déplacé tout le volume. Si vous êtes un ESP, sélectionnez un client avec lequel vous pouvez travailler et testez le processus avec leurs retours.  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.

  7. Automatisez autant que possible avec des APIs.  En dehors des changements DNS, la configuration de SparkPost peut être en grande partie automatisée avec quelques appels API.

Quand 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 des soins.  

  1. Configurez votre compte Bird et testez-le complètement en utilisant un sous-compte de développement afin de pouvoir filtrer ce trafic plus tard.  Vous devrez faire cela pour chaque option car vous aurez besoin de la clé API pour le mot de passe SMTP_Auth de toute façon.

  2. Si vous utilisez l'injection SMTP, prévoyez d'ajouter un en-tête X-MSYS-API pour incorporer toutes les métadonnées et attributs du message nécessaires.  Tous les X-Headers doivent être réécrits comme métadonnées et vous devriez inclure les attributs ip_pool et campagne également. Un exemple est disponible ici

  3. 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 avec Bird.  Cela vous permet de migrer lentement et avec précaution sans compromettre aucun des deux domaines.

  4. Assurez-vous que vous avez une pleine alignement de domaine et que les fonctionnalités de sécurité sont activées.  Dans le DNS, configurez DKIM, SPF, DMARC, les domaines de rebond et de suivi pour qu'ils semblent tous appartenir à la même organisation.

  5. Configurez Automatic IP Warmup sur vos IP_Pools définis.  Si vous utilisez l'option mentionnée précédemment BYOIP, vous pouvez ignorer l'étape de réchauffement.

  6. Commencez avec un flux de messages et avancez à partir de là.  Tout comme IP Warmup, vous ne voulez pas tout faire d'un coup. Redirigez quelques centaines de messages d'abord, puis 10 % du volume, puis 20 % le jour suivant et augmentez jusqu'à ce que vous ayez déplacé tout le volume. Si vous êtes un ESP, sélectionnez un client avec lequel vous pouvez travailler et testez le processus avec leurs retours.  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.

  7. Automatisez autant que possible avec des APIs.  En dehors des changements DNS, la configuration de SparkPost peut être en grande partie automatisée avec quelques appels API.

Collecte de données from Bird

MessageBird rapporte la livraison des messages dans un flux de webhooks ou dans l'API des événements de message. Accéder aux journaux en texte brut de Bird n'est tout simplement pas possible. 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 le faire. Sous 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);
    $timestamp = date("YmdHis") . $rnum;
    $filePath = './data/data_' . $timestamp . '.txt';
    // Handle duplicate filenames (edge case)
    if (file_exists($filePath)) {
        $baseName = basename($filePath, ".txt");
        $seq = 0;
        $ftail = substr($baseName, -2, 1);
        if ($ftail === "-") {
            $seq = (int)

Pendant que vous vous exercez, vous pouvez les essayer avec des collecteurs gratuits tels que http://webhook.site/.

Une fois que vous avez collecté toutes les données des webhooks, vous pouvez les lire dans un magasin de données pour un traitement supplémentaire. Il existe également des moyens de pousser les Webhooks via des services comme StitchData et Segment.

Les mêmes informations sont disponibles dans l'API des Événements si vous devez EXTRAIRE les données et ne pouvez pas accepter les données PUSH. Voici un exemple d'appel de l'API des Événements :
GET https://api.sparkpost.com/api/v1/events/message?/

recipients=recipient@example.com&templates=my-template&events

Cet API est entièrement documentée 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 des événements soient de retour dans une forme qui ressemble à la journalisation PMTA ou Momentum, c'est également possible si vous utilisez du code de conditionnement supplémentaire. La bonne nouvelle est qu'il y a quelques exemples déjà disponibles à emprunter.

MessageBird rapporte la livraison des messages dans un flux de webhooks ou dans l'API des événements de message. Accéder aux journaux en texte brut de Bird n'est tout simplement pas possible. 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 le faire. Sous 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);
    $timestamp = date("YmdHis") . $rnum;
    $filePath = './data/data_' . $timestamp . '.txt';
    // Handle duplicate filenames (edge case)
    if (file_exists($filePath)) {
        $baseName = basename($filePath, ".txt");
        $seq = 0;
        $ftail = substr($baseName, -2, 1);
        if ($ftail === "-") {
            $seq = (int)

Pendant que vous vous exercez, vous pouvez les essayer avec des collecteurs gratuits tels que http://webhook.site/.

Une fois que vous avez collecté toutes les données des webhooks, vous pouvez les lire dans un magasin de données pour un traitement supplémentaire. Il existe également des moyens de pousser les Webhooks via des services comme StitchData et Segment.

Les mêmes informations sont disponibles dans l'API des Événements si vous devez EXTRAIRE les données et ne pouvez pas accepter les données PUSH. Voici un exemple d'appel de l'API des Événements :
GET https://api.sparkpost.com/api/v1/events/message?/

recipients=recipient@example.com&templates=my-template&events

Cet API est entièrement documentée 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 des événements soient de retour dans une forme qui ressemble à la journalisation PMTA ou Momentum, c'est également possible si vous utilisez du code de conditionnement supplémentaire. La bonne nouvelle est qu'il y a quelques exemples déjà disponibles à emprunter.

MessageBird rapporte la livraison des messages dans un flux de webhooks ou dans l'API des événements de message. Accéder aux journaux en texte brut de Bird n'est tout simplement pas possible. 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 le faire. Sous 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);
    $timestamp = date("YmdHis") . $rnum;
    $filePath = './data/data_' . $timestamp . '.txt';
    // Handle duplicate filenames (edge case)
    if (file_exists($filePath)) {
        $baseName = basename($filePath, ".txt");
        $seq = 0;
        $ftail = substr($baseName, -2, 1);
        if ($ftail === "-") {
            $seq = (int)

Pendant que vous vous exercez, vous pouvez les essayer avec des collecteurs gratuits tels que http://webhook.site/.

Une fois que vous avez collecté toutes les données des webhooks, vous pouvez les lire dans un magasin de données pour un traitement supplémentaire. Il existe également des moyens de pousser les Webhooks via des services comme StitchData et Segment.

Les mêmes informations sont disponibles dans l'API des Événements si vous devez EXTRAIRE les données et ne pouvez pas accepter les données PUSH. Voici un exemple d'appel de l'API des Événements :
GET https://api.sparkpost.com/api/v1/events/message?/

recipients=recipient@example.com&templates=my-template&events

Cet API est entièrement documentée 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 des événements soient de retour dans une forme qui ressemble à la journalisation PMTA ou Momentum, c'est également possible si vous utilisez du code de conditionnement supplémentaire. La bonne nouvelle est qu'il y a quelques exemples déjà disponibles à emprunter.

Récapitulatif

Assurez-vous de parler à votre équipe de Ventes et de Gestion du Succès.  Nous l'avons déjà fait et pouvons vous aider à le faire rapidement et de manière rentable.

  1. Déterminez si vous êtes dans le Camp #1 (capable de passer entièrement de On-Prem) ou le Camp #2 (Besoin encore d'un certain MTA sur site).

  2. Inscrivez-vous à un compte de test gratuit pour évaluer les détails de l'intégration.

  3. Décidez des méthodes d'injection SMTP ou REST API.

  4. Si vous utilisez l'injection SMTP, découvrez comment obtenir les données d'en-tête et les attributs de message dans un en-tête X-MSYS-API.

  5. Confirmez si vous pouvez utiliser notre processus BYOIP.

  6. Mettez à jour votre DNS avec de nouveaux domaines si nécessaire.

  7. Créez un petit échantillon pour tester votre migration.  Vous devrez peut-être ajuster votre configuration.

  8. Augmentez progressivement le volume jusqu'à ce que tout le trafic soit migré.

  9. Si vous êtes dans le Camp #1, vous pouvez finalement arrêter vos MTA sur site après que tout le trafic est migré.

Lorsque vous planifiez des changements DNS pour des systèmes de messagerie à volume élevé, soyez conscient des défis potentiels de mise à l'échelle AWS DNS qui peuvent affecter les performances de livraison des e-mails à grande échelle.

Assurez-vous de parler à votre équipe de Ventes et de Gestion du Succès.  Nous l'avons déjà fait et pouvons vous aider à le faire rapidement et de manière rentable.

  1. Déterminez si vous êtes dans le Camp #1 (capable de passer entièrement de On-Prem) ou le Camp #2 (Besoin encore d'un certain MTA sur site).

  2. Inscrivez-vous à un compte de test gratuit pour évaluer les détails de l'intégration.

  3. Décidez des méthodes d'injection SMTP ou REST API.

  4. Si vous utilisez l'injection SMTP, découvrez comment obtenir les données d'en-tête et les attributs de message dans un en-tête X-MSYS-API.

  5. Confirmez si vous pouvez utiliser notre processus BYOIP.

  6. Mettez à jour votre DNS avec de nouveaux domaines si nécessaire.

  7. Créez un petit échantillon pour tester votre migration.  Vous devrez peut-être ajuster votre configuration.

  8. Augmentez progressivement le volume jusqu'à ce que tout le trafic soit migré.

  9. Si vous êtes dans le Camp #1, vous pouvez finalement arrêter vos MTA sur site après que tout le trafic est migré.

Lorsque vous planifiez des changements DNS pour des systèmes de messagerie à volume élevé, soyez conscient des défis potentiels de mise à l'échelle AWS DNS qui peuvent affecter les performances de livraison des e-mails à grande échelle.

Assurez-vous de parler à votre équipe de Ventes et de Gestion du Succès.  Nous l'avons déjà fait et pouvons vous aider à le faire rapidement et de manière rentable.

  1. Déterminez si vous êtes dans le Camp #1 (capable de passer entièrement de On-Prem) ou le Camp #2 (Besoin encore d'un certain MTA sur site).

  2. Inscrivez-vous à un compte de test gratuit pour évaluer les détails de l'intégration.

  3. Décidez des méthodes d'injection SMTP ou REST API.

  4. Si vous utilisez l'injection SMTP, découvrez comment obtenir les données d'en-tête et les attributs de message dans un en-tête X-MSYS-API.

  5. Confirmez si vous pouvez utiliser notre processus BYOIP.

  6. Mettez à jour votre DNS avec de nouveaux domaines si nécessaire.

  7. Créez un petit échantillon pour tester votre migration.  Vous devrez peut-être ajuster votre configuration.

  8. Augmentez progressivement le volume jusqu'à ce que tout le trafic soit migré.

  9. Si vous êtes dans le Camp #1, vous pouvez finalement arrêter vos MTA sur site après que tout le trafic est migré.

Lorsque vous planifiez des changements DNS pour des systèmes de messagerie à volume élevé, soyez conscient des défis potentiels de mise à l'échelle AWS DNS qui peuvent affecter les performances de livraison des e-mails à grande échelle.

Autres news

Lire la suite de cette catégorie

A person is standing at a desk while typing on a laptop.

La plateforme native AI complète qui évolue avec votre business.

Contactez les ventes

Commencez gratuitement

© 2025 Bird

Contactez le Support

A person is standing at a desk while typing on a laptop.

La plateforme native AI complète qui évolue avec votre business.

Contactez les ventes

Commencez gratuitement

© 2025 Bird

Contactez le Support

A person is standing at a desk while typing on a laptop.

La plateforme native AI complète qui évolue avec votre business.

Contactez les ventes

Commencez gratuitement

© 2025 Bird

Contactez le Support