Guida alla migrazione della posta elettronica da locale a cloud
Uccello
28 giu 2020
1 min read
Punti Chiave
Bird Cloud è stato costruito sul provato motore Momentum MTA, offrendo ai clienti le prestazioni di un sistema on-prem maturo con i vantaggi aggiuntivi di una moderna piattaforma API email cloud.
Molti invii legacy si affidano ancora a Momentum o PowerMTA, e Bird fornisce un chiaro percorso di migrazione per entrambi: migrazione completa al cloud o instradamento ibrido attraverso nodi on-prem.
Migrando è necessario capire se si desidera:
eliminare tutta l'infrastruttura on-prem, oppure
continuare a utilizzare il proprio MTA per il pre-processing, l'instradamento o vincoli legacy.
Bird accetta solo iniezione SMTP autenticata attraverso le porte 587 o 2525 (TLS fortemente raccomandato). L'iniezione REST API è anche disponibile per la consegna diretta basata su JSON.
Opzione n. 1 (“cold turkey”) consente la completa dismissione degli MTA inviando direttamente a Bird tramite SMTP o REST, rimuovendo complessità e modernizzando l'architettura di invio.
Opzione n. 2 supporta ambienti ibridi: instradando flussi selezionati da Momentum o PMTA a Bird configurando domini in uscita con SMTP_Auth verso Bird.
Le configurazioni di PowerMTA e Momentum possono inoltrare il traffico a Bird in modo sicuro utilizzando TLS, SMTP_Auth basato su API-key e definizioni di instradamento.
I clienti che utilizzano script Lua avanzati, sostituzioni inline o filtraggio pre-consegna possono rimanere ibridi fino a quando la logica non viene rifattorizzata nei sistemi upstream.
Bird supporta BYOIP (Bring Your Own IP) per i clienti con un blocco contiguo /24, consentendo di mantenere la reputazione IP riscaldata e saltare il riscaldamento completo dell'IP.
Per gli utenti non-BYOIP, Bird fornisce un riscaldamento automatico dell'IP e raccomanda una migrazione graduale, iniziando con volumi ridotti e aumentando gradualmente il traffico.
Una configurazione corretta del dominio (DKIM, SPF, DMARC, domini di rimbalzo, domini di tracciamento) è essenziale per l'allineamento e una coesistenza fluida durante la migrazione.
Bird fornisce dati sugli eventi in tempo reale tramite webhook o Events API, consentendo automazione a valle, flussi ETL e ricostruzione in stile log se necessario.
Punti salienti del Q&A
Quali sono i due principali scenari di migrazione?
Disattiva completamente tutti gli MTA on-prem (Opzione #1) oppure mantieni una configurazione ibrida in cui parte del traffico viene instradato attraverso Momentum/PMTA prima di raggiungere Bird (Opzione #2).
Cosa determina se scegli l'Opzione #1 o l'Opzione #2?
La tua dipendenza dagli script Lua, dalla logica di preprocessing, dalle riscritture dei messaggi, dai requisiti di sicurezza o dai generatori che non possono inviare traffico autenticato sulla porta 587.
Bird accetta l'iniezione SMTP sulla porta 25?
No—Bird richiede l'iniezione SMTP tramite la porta 587 o 2525, autenticata con SMTP_Auth.
È necessario TLS?
Non strettamente necessario, ma fortemente raccomandato per l'inserimento di messaggi sicuri da generatori o MTAs on-prem.
Possono i mittenti utilizzare l'API REST invece di SMTP?
Sì—i mittenti possono inviare payload JSON tramite l'API REST delle Trasmissioni, semplificando spesso i flussi di lavoro e rimuovendo la necessità di generare messaggi SMTP grezzi.
Cos'è il programma BYOIP di Bird?
Un processo che consente ai clienti con un blocco contiguo /24 di migrare i loro IP esistenti in Bird, mantenendo la reputazione e saltando il riscaldamento.
E se BYOIP non è un'opzione?
Utilizza nuovi domini di invio (ad es., sp.tuodominio.com), esegui entrambi gli ambienti in parallelo e fai affidamento sul riscaldamento automatico dell'IP di Bird.
Come fai a instradare solo i flussi selezionati attraverso Bird in una configurazione ibrida?
Configurando i domini in uscita (Momentum) o le configurazioni di rollup/VMTAs (PowerMTA) che autenticano e consegnano all'endpoint SMTP di Bird.
Quali modifiche ai metadati sono necessarie quando si inietta tramite SMTP?
Aggiungi un
X-MSYS-APIheader contenente attributi comeip_pool,campaign, e qualsiasi metadata personalizzato gestito in precedenza tramite X-Headers.Cosa dovrebbe essere configurato nel DNS prima della migrazione?
Record DKIM, SPF, DMARC, domini di rimbalzo e domini di tracciamento per garantire l'allineamento del dominio e ridurre il rischio di consegna durante la transizione.
Come dovrebbe essere migrato il traffico verso Bird?
Gradualmente: inizia con un piccolo flusso, poi il 10%, poi il 20%, aumentando quotidianamente fino a quando tutto il traffico è stato spostato—simile alle migliori pratiche di riscaldamento IP.
Come possono i mittenti raccogliere dati sulla consegna e sull'engagement dopo la migrazione?
Utilizzando il sistema webhook in tempo reale di Bird o l'API Events; i collettori di webhook possono essere costruiti rapidamente e alimentare sistemi di archiviazione o ETL a valle.
Così tante volte, sentiamo la domanda: “Hai un playbook di qualche tipo che espone il processo per migrando da un'installazione on-premises a Bird”?
Certo, sì che ce l'abbiamo. Continua a leggere.
Prima, un po' di contesto. Il servizio Bird Cloud è stato creato nel 2014 grazie all'enorme successo della soluzione On-Premises Momentum MTA. Momentum è al centro del Bird Cloud, fornendo consegna ad alta velocità e gestione del traffico per migliaia di clienti nel servizio cloud. Per questo, Momentum riceve una grande parte della nostra attenzione ingegneristica, ma i risultati di quel lavoro sono spesso sepolti in miglioramenti delle prestazioni che non ricevono molta attenzione. I clienti Momentum vedono i benefici di questo lavoro ogni volta che viene pubblicata una nuova versione pubblica di Momentum.
Ciò NON significa che Bird sia semplicemente “Momentum nel Cloud”. MessageBird è molto di più e può avere vantaggi aggiuntivi per i clienti che scelgono di migrare o di usarli in un approccio ibrido. Questi vantaggi derivano dalla nostra moderna architettura API email basata sul cloud, che offre capacità non disponibili nelle soluzioni tradizionali on-premises. Inoltre, abbiamo reso molto facile per i clienti PowerMTA migrare o utilizzare PowerMTA con Bird in una configurazione ibrida. Il resto di questo documento descriverà in dettaglio come puoi migrare i tuoi flussi di messaggi da Momentum o PowerMTA al servizio Bird Cloud.
Ci sono davvero due scenari separati da considerare quando si migra a Bird da Momentum o PowerMTA.
Sei pronto a lasciare completamente il mondo on-premises, chiudere i tuoi centri dati fisici e non gestire più direttamente alcun MTA on-premises. Ciò significa eliminare Momentum o PowerMTA dal tuo deployment e inviare messaggi direttamente a SparkPost per la gestione dei messaggi. Prima di dismettere la tua infrastruttura on-premises, assicurati di avere backup completi del database di tutti i sistemi critici, specialmente se stai eseguendo database PostgreSQL che contengono dati storici importanti o configurazioni.
Hai motivo di mantenere una certa impronta on-premises per un motivo o l'altro. Alcune possibilità potrebbero essere:
flussi di consegna specifici che richiedono pre-processing in Momentum
divisione della capacità per esigenze di picco o recupero da disastri
sostenere i clienti legacy in PMTA mentre si spostano i nuovi clienti su SparkPost
…poi vuoi inoltrare gli altri messaggi a Bird per la gestione successiva dei messaggi.
In entrambi i casi, devi essere a conoscenza del fatto che Bird accetterà solo messaggi SMTP per la consegna che vengono iniettati attraverso la porta 587 o 2525 e utilizzano SMTP_Auth con un nome utente e una password specifici (Vedi la documentazione SMTP qui). Consigliamo vivamente di connetterti con una connessione TLS, ma non è strettamente obbligatoria. Se stai sostituendo completamente il tuo layer MTA (scenario 1), allora potresti anche voler considerare di utilizzare l'API REST delle Trasmissioni che può accettare messaggi su connessioni HTTPS. La documentazione su quell'API è qui.
Per le organizzazioni che mantengono un'infrastruttura on-premises che richiede capacità di email sicure, la nostra guida all'implementazione S/MIME per PowerMTA e Momentum fornisce istruzioni dettagliate per la configurazione della consegna di email crittografate.
Così tante volte, sentiamo la domanda: “Hai un playbook di qualche tipo che espone il processo per migrando da un'installazione on-premises a Bird”?
Certo, sì che ce l'abbiamo. Continua a leggere.
Prima, un po' di contesto. Il servizio Bird Cloud è stato creato nel 2014 grazie all'enorme successo della soluzione On-Premises Momentum MTA. Momentum è al centro del Bird Cloud, fornendo consegna ad alta velocità e gestione del traffico per migliaia di clienti nel servizio cloud. Per questo, Momentum riceve una grande parte della nostra attenzione ingegneristica, ma i risultati di quel lavoro sono spesso sepolti in miglioramenti delle prestazioni che non ricevono molta attenzione. I clienti Momentum vedono i benefici di questo lavoro ogni volta che viene pubblicata una nuova versione pubblica di Momentum.
Ciò NON significa che Bird sia semplicemente “Momentum nel Cloud”. MessageBird è molto di più e può avere vantaggi aggiuntivi per i clienti che scelgono di migrare o di usarli in un approccio ibrido. Questi vantaggi derivano dalla nostra moderna architettura API email basata sul cloud, che offre capacità non disponibili nelle soluzioni tradizionali on-premises. Inoltre, abbiamo reso molto facile per i clienti PowerMTA migrare o utilizzare PowerMTA con Bird in una configurazione ibrida. Il resto di questo documento descriverà in dettaglio come puoi migrare i tuoi flussi di messaggi da Momentum o PowerMTA al servizio Bird Cloud.
Ci sono davvero due scenari separati da considerare quando si migra a Bird da Momentum o PowerMTA.
Sei pronto a lasciare completamente il mondo on-premises, chiudere i tuoi centri dati fisici e non gestire più direttamente alcun MTA on-premises. Ciò significa eliminare Momentum o PowerMTA dal tuo deployment e inviare messaggi direttamente a SparkPost per la gestione dei messaggi. Prima di dismettere la tua infrastruttura on-premises, assicurati di avere backup completi del database di tutti i sistemi critici, specialmente se stai eseguendo database PostgreSQL che contengono dati storici importanti o configurazioni.
Hai motivo di mantenere una certa impronta on-premises per un motivo o l'altro. Alcune possibilità potrebbero essere:
flussi di consegna specifici che richiedono pre-processing in Momentum
divisione della capacità per esigenze di picco o recupero da disastri
sostenere i clienti legacy in PMTA mentre si spostano i nuovi clienti su SparkPost
…poi vuoi inoltrare gli altri messaggi a Bird per la gestione successiva dei messaggi.
In entrambi i casi, devi essere a conoscenza del fatto che Bird accetterà solo messaggi SMTP per la consegna che vengono iniettati attraverso la porta 587 o 2525 e utilizzano SMTP_Auth con un nome utente e una password specifici (Vedi la documentazione SMTP qui). Consigliamo vivamente di connetterti con una connessione TLS, ma non è strettamente obbligatoria. Se stai sostituendo completamente il tuo layer MTA (scenario 1), allora potresti anche voler considerare di utilizzare l'API REST delle Trasmissioni che può accettare messaggi su connessioni HTTPS. La documentazione su quell'API è qui.
Per le organizzazioni che mantengono un'infrastruttura on-premises che richiede capacità di email sicure, la nostra guida all'implementazione S/MIME per PowerMTA e Momentum fornisce istruzioni dettagliate per la configurazione della consegna di email crittografate.
Così tante volte, sentiamo la domanda: “Hai un playbook di qualche tipo che espone il processo per migrando da un'installazione on-premises a Bird”?
Certo, sì che ce l'abbiamo. Continua a leggere.
Prima, un po' di contesto. Il servizio Bird Cloud è stato creato nel 2014 grazie all'enorme successo della soluzione On-Premises Momentum MTA. Momentum è al centro del Bird Cloud, fornendo consegna ad alta velocità e gestione del traffico per migliaia di clienti nel servizio cloud. Per questo, Momentum riceve una grande parte della nostra attenzione ingegneristica, ma i risultati di quel lavoro sono spesso sepolti in miglioramenti delle prestazioni che non ricevono molta attenzione. I clienti Momentum vedono i benefici di questo lavoro ogni volta che viene pubblicata una nuova versione pubblica di Momentum.
Ciò NON significa che Bird sia semplicemente “Momentum nel Cloud”. MessageBird è molto di più e può avere vantaggi aggiuntivi per i clienti che scelgono di migrare o di usarli in un approccio ibrido. Questi vantaggi derivano dalla nostra moderna architettura API email basata sul cloud, che offre capacità non disponibili nelle soluzioni tradizionali on-premises. Inoltre, abbiamo reso molto facile per i clienti PowerMTA migrare o utilizzare PowerMTA con Bird in una configurazione ibrida. Il resto di questo documento descriverà in dettaglio come puoi migrare i tuoi flussi di messaggi da Momentum o PowerMTA al servizio Bird Cloud.
Ci sono davvero due scenari separati da considerare quando si migra a Bird da Momentum o PowerMTA.
Sei pronto a lasciare completamente il mondo on-premises, chiudere i tuoi centri dati fisici e non gestire più direttamente alcun MTA on-premises. Ciò significa eliminare Momentum o PowerMTA dal tuo deployment e inviare messaggi direttamente a SparkPost per la gestione dei messaggi. Prima di dismettere la tua infrastruttura on-premises, assicurati di avere backup completi del database di tutti i sistemi critici, specialmente se stai eseguendo database PostgreSQL che contengono dati storici importanti o configurazioni.
Hai motivo di mantenere una certa impronta on-premises per un motivo o l'altro. Alcune possibilità potrebbero essere:
flussi di consegna specifici che richiedono pre-processing in Momentum
divisione della capacità per esigenze di picco o recupero da disastri
sostenere i clienti legacy in PMTA mentre si spostano i nuovi clienti su SparkPost
…poi vuoi inoltrare gli altri messaggi a Bird per la gestione successiva dei messaggi.
In entrambi i casi, devi essere a conoscenza del fatto che Bird accetterà solo messaggi SMTP per la consegna che vengono iniettati attraverso la porta 587 o 2525 e utilizzano SMTP_Auth con un nome utente e una password specifici (Vedi la documentazione SMTP qui). Consigliamo vivamente di connetterti con una connessione TLS, ma non è strettamente obbligatoria. Se stai sostituendo completamente il tuo layer MTA (scenario 1), allora potresti anche voler considerare di utilizzare l'API REST delle Trasmissioni che può accettare messaggi su connessioni HTTPS. La documentazione su quell'API è qui.
Per le organizzazioni che mantengono un'infrastruttura on-premises che richiede capacità di email sicure, la nostra guida all'implementazione S/MIME per PowerMTA e Momentum fornisce istruzioni dettagliate per la configurazione della consegna di email crittografate.
Quale opzione devo scegliere?
Per capire se ti trovi nell'opzione #1 o nell'opzione #2, considera questi fattori:
Opzione | Meglio se tu | Requisito chiave | Compensazione |
|---|---|---|---|
Opzione #1: Migrazione completa al cloud | Può rimuovere tutti gli MTA on-prem | SMTP Auth su 587/2525 o REST API | Richiede la riconversione di qualsiasi logica avanzata on-prem |
Opzione #2: Routing ibrido | Necessita di supporto per l'elaborazione preliminare o per il legacy | Momentum o PowerMTA rimane online | Aggiunta complessità operativa |
Utilizzi il motore di scripting Lua di Momentum per qualcosa di più complicato rispetto al routing dei messaggi?
Lua è uno strumento di scripting completo per manipolare i messaggi in linea, ma la stragrande maggioranza dei nostri utenti lo utilizza solo per selezionare un binding per la consegna. Se è questo il caso, puoi modificare il tuo codice di generazione per aggiungere un attributo ip_pool all'intestazione X-MSYS-API e far sì che Bird assegni il percorso per te.
Se utilizzi Lua per fare cose più complicate come il filtro del corpo, le riscritture di Mail_From o i calcoli del ritmo dei messaggi, e non è fattibile spostare quella logica nella tua applicazione di iniezione, potresti voler considerare di passare al campo dell'Opzione #2.
Il tuo sistema di generazione è in grado di inviare messaggi sulla porta 587 utilizzando TLS e SMTP_Auth?
Alcuni sistemi di gestione delle campagne possono solo inviare email sulla porta 25 in chiaro. Questo crea un problema di sicurezza per Bird, quindi potresti voler considerare l'Opzione #2
Stai utilizzando la sintassi di sostituzione PowerMTA o altre modifiche ai messaggi in linea?
Se puoi spostare questa funzione nei tuoi generatori o utilizzare il Template Language di Bird, puoi ancora usare l'opzione 1, ma altrimenti potresti dover pensare di mantenere online un nodo PMTA per questa modifica del messaggio prima di inviarlo a Bird per la consegna.
Richiedi scansioni AV/AS in entrata prima dell'iniezione? Anche se questo è possibile in Momentum e PowerMTA, eBird presume che tu abbia già effettuato tutti quei controlli. Potresti voler considerare di farlo prima dell'iniezione.
Non importa quale strada prendi, è sicuro che influenzerà il tuo rapporto commerciale. Come puoi immaginare, questa non è la nostra prima esperienza. Assicurati di coinvolgere il tuo Manager Commerciale e il tuo Manager del Successo del Cliente in modo che possiamo aiutarti nei dettagli e assicurarci che tu stia ottenendo il miglior valore per il tuo denaro.
Per capire se ti trovi nell'opzione #1 o nell'opzione #2, considera questi fattori:
Opzione | Meglio se tu | Requisito chiave | Compensazione |
|---|---|---|---|
Opzione #1: Migrazione completa al cloud | Può rimuovere tutti gli MTA on-prem | SMTP Auth su 587/2525 o REST API | Richiede la riconversione di qualsiasi logica avanzata on-prem |
Opzione #2: Routing ibrido | Necessita di supporto per l'elaborazione preliminare o per il legacy | Momentum o PowerMTA rimane online | Aggiunta complessità operativa |
Utilizzi il motore di scripting Lua di Momentum per qualcosa di più complicato rispetto al routing dei messaggi?
Lua è uno strumento di scripting completo per manipolare i messaggi in linea, ma la stragrande maggioranza dei nostri utenti lo utilizza solo per selezionare un binding per la consegna. Se è questo il caso, puoi modificare il tuo codice di generazione per aggiungere un attributo ip_pool all'intestazione X-MSYS-API e far sì che Bird assegni il percorso per te.
Se utilizzi Lua per fare cose più complicate come il filtro del corpo, le riscritture di Mail_From o i calcoli del ritmo dei messaggi, e non è fattibile spostare quella logica nella tua applicazione di iniezione, potresti voler considerare di passare al campo dell'Opzione #2.
Il tuo sistema di generazione è in grado di inviare messaggi sulla porta 587 utilizzando TLS e SMTP_Auth?
Alcuni sistemi di gestione delle campagne possono solo inviare email sulla porta 25 in chiaro. Questo crea un problema di sicurezza per Bird, quindi potresti voler considerare l'Opzione #2
Stai utilizzando la sintassi di sostituzione PowerMTA o altre modifiche ai messaggi in linea?
Se puoi spostare questa funzione nei tuoi generatori o utilizzare il Template Language di Bird, puoi ancora usare l'opzione 1, ma altrimenti potresti dover pensare di mantenere online un nodo PMTA per questa modifica del messaggio prima di inviarlo a Bird per la consegna.
Richiedi scansioni AV/AS in entrata prima dell'iniezione? Anche se questo è possibile in Momentum e PowerMTA, eBird presume che tu abbia già effettuato tutti quei controlli. Potresti voler considerare di farlo prima dell'iniezione.
Non importa quale strada prendi, è sicuro che influenzerà il tuo rapporto commerciale. Come puoi immaginare, questa non è la nostra prima esperienza. Assicurati di coinvolgere il tuo Manager Commerciale e il tuo Manager del Successo del Cliente in modo che possiamo aiutarti nei dettagli e assicurarci che tu stia ottenendo il miglior valore per il tuo denaro.
Per capire se ti trovi nell'opzione #1 o nell'opzione #2, considera questi fattori:
Opzione | Meglio se tu | Requisito chiave | Compensazione |
|---|---|---|---|
Opzione #1: Migrazione completa al cloud | Può rimuovere tutti gli MTA on-prem | SMTP Auth su 587/2525 o REST API | Richiede la riconversione di qualsiasi logica avanzata on-prem |
Opzione #2: Routing ibrido | Necessita di supporto per l'elaborazione preliminare o per il legacy | Momentum o PowerMTA rimane online | Aggiunta complessità operativa |
Utilizzi il motore di scripting Lua di Momentum per qualcosa di più complicato rispetto al routing dei messaggi?
Lua è uno strumento di scripting completo per manipolare i messaggi in linea, ma la stragrande maggioranza dei nostri utenti lo utilizza solo per selezionare un binding per la consegna. Se è questo il caso, puoi modificare il tuo codice di generazione per aggiungere un attributo ip_pool all'intestazione X-MSYS-API e far sì che Bird assegni il percorso per te.
Se utilizzi Lua per fare cose più complicate come il filtro del corpo, le riscritture di Mail_From o i calcoli del ritmo dei messaggi, e non è fattibile spostare quella logica nella tua applicazione di iniezione, potresti voler considerare di passare al campo dell'Opzione #2.
Il tuo sistema di generazione è in grado di inviare messaggi sulla porta 587 utilizzando TLS e SMTP_Auth?
Alcuni sistemi di gestione delle campagne possono solo inviare email sulla porta 25 in chiaro. Questo crea un problema di sicurezza per Bird, quindi potresti voler considerare l'Opzione #2
Stai utilizzando la sintassi di sostituzione PowerMTA o altre modifiche ai messaggi in linea?
Se puoi spostare questa funzione nei tuoi generatori o utilizzare il Template Language di Bird, puoi ancora usare l'opzione 1, ma altrimenti potresti dover pensare di mantenere online un nodo PMTA per questa modifica del messaggio prima di inviarlo a Bird per la consegna.
Richiedi scansioni AV/AS in entrata prima dell'iniezione? Anche se questo è possibile in Momentum e PowerMTA, eBird presume che tu abbia già effettuato tutti quei controlli. Potresti voler considerare di farlo prima dell'iniezione.
Non importa quale strada prendi, è sicuro che influenzerà il tuo rapporto commerciale. Come puoi immaginare, questa non è la nostra prima esperienza. Assicurati di coinvolgere il tuo Manager Commerciale e il tuo Manager del Successo del Cliente in modo che possiamo aiutarti nei dettagli e assicurarci che tu stia ottenendo il miglior valore per il tuo denaro.
Per l'Opzione #1 Camp (Andare "a freddo"):
Supponiamo che tu sia d'accordo con l'opzione 1 e sia pronto a chiudere i tuoi MTA on-premises e hai deciso di continuare a utilizzare il metodo di iniezione SMTP, senza cambiare affatto i tuoi sistemi di creazione messaggi. I tuoi sistemi di generazione dovrebbero creare un messaggio SMTP completamente formattato, quindi inviarlo a Bird tramite TLS utilizzando SMTP_AUTH dove il nome utente e la password sono come descritto su questa pagina. Ricorda che la “password” è la chiave API che generi nel tuo account Bird con l'opzione di consegna SMTP attivata.
Se fai parte del gruppo dell'Opzione #1, considera di passare direttamente al REST API dal tuo sistema di generazione. Nella maggior parte dei casi, scopriamo che i sistemi di elaborazione dei clienti stanno già utilizzando JSON su HTTP e devono convertire in SMTP prima dell'iniezione. Puoi saltare quel passaggio e inviarlo direttamente a noi come un payload REST formattato in JSON.
Se scegli di iniettare con il REST API, potresti dover modificare un po' il tuo sistema di creazione dei contenuti, ma potrebbe valerne la pena. Puoi scoprire di più qui.
Una delle maggiori preoccupazioni che hanno i grandi ESP con una Migrazione è il Riscaldamento IP. Tipicamente hanno speso molti anni a curare con grande attenzione il loro inventario di indirizzi IP, quindi l'idea di abbandonare tutto quel lavoro è dolorosa. Bird ha sviluppato un processo Bring Your Own IP (BYOIP) che si occupa di quel problema. Se hai almeno un blocco CIDR /24 contiguo, Bird può utilizzare quegli IP esistenti per la consegna, risparmiandoti il dolore di doverli riscaldare di nuovo. Se sei in grado di approfittare di quell'opzione, puoi saltare la sezione qui sul riscaldamento IP.
Se senti di essere pronto per andare avanti, salta a “Rendere possibile”
Supponiamo che tu sia d'accordo con l'opzione 1 e sia pronto a chiudere i tuoi MTA on-premises e hai deciso di continuare a utilizzare il metodo di iniezione SMTP, senza cambiare affatto i tuoi sistemi di creazione messaggi. I tuoi sistemi di generazione dovrebbero creare un messaggio SMTP completamente formattato, quindi inviarlo a Bird tramite TLS utilizzando SMTP_AUTH dove il nome utente e la password sono come descritto su questa pagina. Ricorda che la “password” è la chiave API che generi nel tuo account Bird con l'opzione di consegna SMTP attivata.
Se fai parte del gruppo dell'Opzione #1, considera di passare direttamente al REST API dal tuo sistema di generazione. Nella maggior parte dei casi, scopriamo che i sistemi di elaborazione dei clienti stanno già utilizzando JSON su HTTP e devono convertire in SMTP prima dell'iniezione. Puoi saltare quel passaggio e inviarlo direttamente a noi come un payload REST formattato in JSON.
Se scegli di iniettare con il REST API, potresti dover modificare un po' il tuo sistema di creazione dei contenuti, ma potrebbe valerne la pena. Puoi scoprire di più qui.
Una delle maggiori preoccupazioni che hanno i grandi ESP con una Migrazione è il Riscaldamento IP. Tipicamente hanno speso molti anni a curare con grande attenzione il loro inventario di indirizzi IP, quindi l'idea di abbandonare tutto quel lavoro è dolorosa. Bird ha sviluppato un processo Bring Your Own IP (BYOIP) che si occupa di quel problema. Se hai almeno un blocco CIDR /24 contiguo, Bird può utilizzare quegli IP esistenti per la consegna, risparmiandoti il dolore di doverli riscaldare di nuovo. Se sei in grado di approfittare di quell'opzione, puoi saltare la sezione qui sul riscaldamento IP.
Se senti di essere pronto per andare avanti, salta a “Rendere possibile”
Supponiamo che tu sia d'accordo con l'opzione 1 e sia pronto a chiudere i tuoi MTA on-premises e hai deciso di continuare a utilizzare il metodo di iniezione SMTP, senza cambiare affatto i tuoi sistemi di creazione messaggi. I tuoi sistemi di generazione dovrebbero creare un messaggio SMTP completamente formattato, quindi inviarlo a Bird tramite TLS utilizzando SMTP_AUTH dove il nome utente e la password sono come descritto su questa pagina. Ricorda che la “password” è la chiave API che generi nel tuo account Bird con l'opzione di consegna SMTP attivata.
Se fai parte del gruppo dell'Opzione #1, considera di passare direttamente al REST API dal tuo sistema di generazione. Nella maggior parte dei casi, scopriamo che i sistemi di elaborazione dei clienti stanno già utilizzando JSON su HTTP e devono convertire in SMTP prima dell'iniezione. Puoi saltare quel passaggio e inviarlo direttamente a noi come un payload REST formattato in JSON.
Se scegli di iniettare con il REST API, potresti dover modificare un po' il tuo sistema di creazione dei contenuti, ma potrebbe valerne la pena. Puoi scoprire di più qui.
Una delle maggiori preoccupazioni che hanno i grandi ESP con una Migrazione è il Riscaldamento IP. Tipicamente hanno speso molti anni a curare con grande attenzione il loro inventario di indirizzi IP, quindi l'idea di abbandonare tutto quel lavoro è dolorosa. Bird ha sviluppato un processo Bring Your Own IP (BYOIP) che si occupa di quel problema. Se hai almeno un blocco CIDR /24 contiguo, Bird può utilizzare quegli IP esistenti per la consegna, risparmiandoti il dolore di doverli riscaldare di nuovo. Se sei in grado di approfittare di quell'opzione, puoi saltare la sezione qui sul riscaldamento IP.
Se senti di essere pronto per andare avanti, salta a “Rendere possibile”
Sfruttare l'Opzione #2 (pre-elaborazione on-premise):
Tuttavia, se fai parte del team Opzione #2, allora vorrai aggiungere alcune modifiche di configurazione al tuo deployment. Il modo meno doloroso per migrare alcune selezionate stream di messaggi da Momentum o PMTA a Bird pur continuando a utilizzare l'iniezione SMTP dai tuoi sistemi di generazione è aggiungere un percorso speciale nella tua configurazione.
Per Momentum:
Imposta una versione di Momentum > 3.6.23.
Installa un certificato SSL valido e apri la porta in uscita 587 affinché Momentum possa comunicare con Bird. Configura un dominio in uscita in modo da poter deviare un messaggio attraverso Momentum a Bird.
Con la configurazione qui sotto, qualsiasi messaggio che colpisce questa configurazione sarà deviato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti 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" }
Configura i binding che desideri deviare attraverso MessageBird con TLS e inviali al dominio che hai definito sopra.
Nota: il TLS non è strettamente necessario ma è una forte raccomandazione. Se il TLS non è possibile per qualche motivo, anche l'whitelisting delle chiavi API è una forte raccomandazione.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" }
Per PowerMTA:
Imposta una versione di PowerMTA > 4.5.0
Installa un certificato SSL valido e apri la porta in uscita 587 affinché PowerMTA possa comunicare con Bird.
Configura un percorso di dominio in uscita in modo da poter deviare un messaggio attraverso PowerMTA a Bird. Con la configurazione qui sotto, qualsiasi messaggio che colpisce questa configurazione sarà deviato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti lì. In PowerMTA, è anche qui che puoi impostare TLS. Nota che questo è anche documentato più completamente qui
<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. Configura i VMTAs che desideri deviare attraverso Bird con la configurazione {sparkpost} rollup che hai definito sopra.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Una volta che hai apportato quelle modifiche di configurazione, qualsiasi messaggio inviato al “binding” o “VMTA” selezionato dovrebbe essere deviato automaticamente attraverso Bird per la consegna.
Tuttavia, se fai parte del team Opzione #2, allora vorrai aggiungere alcune modifiche di configurazione al tuo deployment. Il modo meno doloroso per migrare alcune selezionate stream di messaggi da Momentum o PMTA a Bird pur continuando a utilizzare l'iniezione SMTP dai tuoi sistemi di generazione è aggiungere un percorso speciale nella tua configurazione.
Per Momentum:
Imposta una versione di Momentum > 3.6.23.
Installa un certificato SSL valido e apri la porta in uscita 587 affinché Momentum possa comunicare con Bird. Configura un dominio in uscita in modo da poter deviare un messaggio attraverso Momentum a Bird.
Con la configurazione qui sotto, qualsiasi messaggio che colpisce questa configurazione sarà deviato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti 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" }
Configura i binding che desideri deviare attraverso MessageBird con TLS e inviali al dominio che hai definito sopra.
Nota: il TLS non è strettamente necessario ma è una forte raccomandazione. Se il TLS non è possibile per qualche motivo, anche l'whitelisting delle chiavi API è una forte raccomandazione.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" }
Per PowerMTA:
Imposta una versione di PowerMTA > 4.5.0
Installa un certificato SSL valido e apri la porta in uscita 587 affinché PowerMTA possa comunicare con Bird.
Configura un percorso di dominio in uscita in modo da poter deviare un messaggio attraverso PowerMTA a Bird. Con la configurazione qui sotto, qualsiasi messaggio che colpisce questa configurazione sarà deviato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti lì. In PowerMTA, è anche qui che puoi impostare TLS. Nota che questo è anche documentato più completamente qui
<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. Configura i VMTAs che desideri deviare attraverso Bird con la configurazione {sparkpost} rollup che hai definito sopra.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Una volta che hai apportato quelle modifiche di configurazione, qualsiasi messaggio inviato al “binding” o “VMTA” selezionato dovrebbe essere deviato automaticamente attraverso Bird per la consegna.
Tuttavia, se fai parte del team Opzione #2, allora vorrai aggiungere alcune modifiche di configurazione al tuo deployment. Il modo meno doloroso per migrare alcune selezionate stream di messaggi da Momentum o PMTA a Bird pur continuando a utilizzare l'iniezione SMTP dai tuoi sistemi di generazione è aggiungere un percorso speciale nella tua configurazione.
Per Momentum:
Imposta una versione di Momentum > 3.6.23.
Installa un certificato SSL valido e apri la porta in uscita 587 affinché Momentum possa comunicare con Bird. Configura un dominio in uscita in modo da poter deviare un messaggio attraverso Momentum a Bird.
Con la configurazione qui sotto, qualsiasi messaggio che colpisce questa configurazione sarà deviato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti 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" }
Configura i binding che desideri deviare attraverso MessageBird con TLS e inviali al dominio che hai definito sopra.
Nota: il TLS non è strettamente necessario ma è una forte raccomandazione. Se il TLS non è possibile per qualche motivo, anche l'whitelisting delle chiavi API è una forte raccomandazione.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" }
Per PowerMTA:
Imposta una versione di PowerMTA > 4.5.0
Installa un certificato SSL valido e apri la porta in uscita 587 affinché PowerMTA possa comunicare con Bird.
Configura un percorso di dominio in uscita in modo da poter deviare un messaggio attraverso PowerMTA a Bird. Con la configurazione qui sotto, qualsiasi messaggio che colpisce questa configurazione sarà deviato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti lì. In PowerMTA, è anche qui che puoi impostare TLS. Nota che questo è anche documentato più completamente qui
<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. Configura i VMTAs che desideri deviare attraverso Bird con la configurazione {sparkpost} rollup che hai definito sopra.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Una volta che hai apportato quelle modifiche di configurazione, qualsiasi messaggio inviato al “binding” o “VMTA” selezionato dovrebbe essere deviato automaticamente attraverso Bird per la consegna.
Farlo accadere
Quando inizi a percorrere questa strada, non commettere l'errore di pensare che si tratti di un'operazione da un giorno all'altro. Facere questo in modo corretto richiederà del tempo e attenzione.
Configura il tuo account Bird e testalo completamente usando un subaccount di sviluppo in modo da poter filtrare quel traffico in seguito. Dovrai fare questo per entrambe le opzioni perché avrai bisogno della chiave API per la password SMTP_Auth in ogni caso.
Se stai utilizzando l'iniezione SMTP, pianifica di aggiungere un'intestazione X-MSYS-API per incorporare tutti i metadati e gli attributi del messaggio necessari. Qualsiasi X-Headers dovrebbe essere riscritto come metadato e dovresti includere anche gli attributi ip_pool e campagna. Un campione è disponibile qui
Se NON stai utilizzando BYOIP, assicurati di impostare domini di invio leggermente diversi da utilizzare con MessageBird in modo da poter eseguire entrambi gli ambienti in parallelo finché è necessario. Se il tuo dominio di invio corrente è mycompany.com, potresti impostare sp.mycompany.com specificamente per la consegna di Bird. Questo ti consente di migrare lentamente e con attenzione senza compromettere nessuno dei due domini.
Assicurati di avere un allineamento completo del dominio e le funzionalità di sicurezza abilitate. In DNS, imposta DKIM, SPF, DMARC, domini di rimbalzo e tracciamento in modo che sembrino tutti appartenere alla stessa organizzazione.
Configura Automatic IP Warmup sui tuoi IP_Pools definiti. Se stai utilizzando l'opzione BYOIP menzionata in precedenza, puoi ignorare il passaggio di riscaldamento.
Inizia con un flusso di messaggi e vai avanti da lì. Proprio come nel riscaldamento IP, non vuoi farlo tutto in una volta. Reindirizza prima qualche centinaio di messaggi, poi il 10% del volume, poi il 20% il giorno successivo e aumenta finché non hai trasferito tutto il volume. Se sei un ESP, seleziona un cliente con cui puoi lavorare e testa il processo con il loro feedback. Se tutto funziona bene, passa al successivo. Se incontri problemi, prenditi il tempo per risolverli e integrali nel processo per il successivo.
Automatizza il più possibile con le API. Oltre alle modifiche DNS, la configurazione di SparkPost può essere per lo più automatizzata con alcune chiamate API.
Quando inizi a percorrere questa strada, non commettere l'errore di pensare che si tratti di un'operazione da un giorno all'altro. Facere questo in modo corretto richiederà del tempo e attenzione.
Configura il tuo account Bird e testalo completamente usando un subaccount di sviluppo in modo da poter filtrare quel traffico in seguito. Dovrai fare questo per entrambe le opzioni perché avrai bisogno della chiave API per la password SMTP_Auth in ogni caso.
Se stai utilizzando l'iniezione SMTP, pianifica di aggiungere un'intestazione X-MSYS-API per incorporare tutti i metadati e gli attributi del messaggio necessari. Qualsiasi X-Headers dovrebbe essere riscritto come metadato e dovresti includere anche gli attributi ip_pool e campagna. Un campione è disponibile qui
Se NON stai utilizzando BYOIP, assicurati di impostare domini di invio leggermente diversi da utilizzare con MessageBird in modo da poter eseguire entrambi gli ambienti in parallelo finché è necessario. Se il tuo dominio di invio corrente è mycompany.com, potresti impostare sp.mycompany.com specificamente per la consegna di Bird. Questo ti consente di migrare lentamente e con attenzione senza compromettere nessuno dei due domini.
Assicurati di avere un allineamento completo del dominio e le funzionalità di sicurezza abilitate. In DNS, imposta DKIM, SPF, DMARC, domini di rimbalzo e tracciamento in modo che sembrino tutti appartenere alla stessa organizzazione.
Configura Automatic IP Warmup sui tuoi IP_Pools definiti. Se stai utilizzando l'opzione BYOIP menzionata in precedenza, puoi ignorare il passaggio di riscaldamento.
Inizia con un flusso di messaggi e vai avanti da lì. Proprio come nel riscaldamento IP, non vuoi farlo tutto in una volta. Reindirizza prima qualche centinaio di messaggi, poi il 10% del volume, poi il 20% il giorno successivo e aumenta finché non hai trasferito tutto il volume. Se sei un ESP, seleziona un cliente con cui puoi lavorare e testa il processo con il loro feedback. Se tutto funziona bene, passa al successivo. Se incontri problemi, prenditi il tempo per risolverli e integrali nel processo per il successivo.
Automatizza il più possibile con le API. Oltre alle modifiche DNS, la configurazione di SparkPost può essere per lo più automatizzata con alcune chiamate API.
Quando inizi a percorrere questa strada, non commettere l'errore di pensare che si tratti di un'operazione da un giorno all'altro. Facere questo in modo corretto richiederà del tempo e attenzione.
Configura il tuo account Bird e testalo completamente usando un subaccount di sviluppo in modo da poter filtrare quel traffico in seguito. Dovrai fare questo per entrambe le opzioni perché avrai bisogno della chiave API per la password SMTP_Auth in ogni caso.
Se stai utilizzando l'iniezione SMTP, pianifica di aggiungere un'intestazione X-MSYS-API per incorporare tutti i metadati e gli attributi del messaggio necessari. Qualsiasi X-Headers dovrebbe essere riscritto come metadato e dovresti includere anche gli attributi ip_pool e campagna. Un campione è disponibile qui
Se NON stai utilizzando BYOIP, assicurati di impostare domini di invio leggermente diversi da utilizzare con MessageBird in modo da poter eseguire entrambi gli ambienti in parallelo finché è necessario. Se il tuo dominio di invio corrente è mycompany.com, potresti impostare sp.mycompany.com specificamente per la consegna di Bird. Questo ti consente di migrare lentamente e con attenzione senza compromettere nessuno dei due domini.
Assicurati di avere un allineamento completo del dominio e le funzionalità di sicurezza abilitate. In DNS, imposta DKIM, SPF, DMARC, domini di rimbalzo e tracciamento in modo che sembrino tutti appartenere alla stessa organizzazione.
Configura Automatic IP Warmup sui tuoi IP_Pools definiti. Se stai utilizzando l'opzione BYOIP menzionata in precedenza, puoi ignorare il passaggio di riscaldamento.
Inizia con un flusso di messaggi e vai avanti da lì. Proprio come nel riscaldamento IP, non vuoi farlo tutto in una volta. Reindirizza prima qualche centinaio di messaggi, poi il 10% del volume, poi il 20% il giorno successivo e aumenta finché non hai trasferito tutto il volume. Se sei un ESP, seleziona un cliente con cui puoi lavorare e testa il processo con il loro feedback. Se tutto funziona bene, passa al successivo. Se incontri problemi, prenditi il tempo per risolverli e integrali nel processo per il successivo.
Automatizza il più possibile con le API. Oltre alle modifiche DNS, la configurazione di SparkPost può essere per lo più automatizzata con alcune chiamate API.
Raccolta dati dagli uccelli
MessageBird riporta la consegna dei messaggi in un feed di webhook o nell'API degli eventi del messaggio. L'accesso ai log di Bird in testo semplice non è possibile. Puoi recuperare questi dati nel tuo ambiente con un collettore di webhook o chiamando periodicamente l'API degli eventi e consumando i dati. Ti raccomandiamo di utilizzare i webhook e abbiamo alcune raccomandazioni su come farlo nel modo giusto. Nella sua forma più basilare, un collettore di webhook PHP può essere distribuito in poche righe di codice:
<?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)
Durante la sperimentazione, puoi provarli con collettori gratuiti come http://webhook.site/.
Una volta raccolti tutti i dati dei webhook, puoi leggerli in un archivio dati per un'elaborazione aggiuntiva. Ci sono anche modi per spingere i webhook attraverso servizi come StitchData e Segment.
Le stesse informazioni sono disponibili nell'API degli eventi se hai bisogno di PULL i dati e non puoi accettare i dati PUSH. Ecco un esempio di chiamata all'API degli eventi:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Quell'API è completamente documentata con esempi qui: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Se hai veramente bisogno dei dati dell'evento in un formato che assomiglia alla registrazione PMTA o Momentum, è possibile anche se impieghi un ulteriore codice di condizionamento. La buona notizia è che ci sono alcuni esempi da cui rubare già.
MessageBird riporta la consegna dei messaggi in un feed di webhook o nell'API degli eventi del messaggio. L'accesso ai log di Bird in testo semplice non è possibile. Puoi recuperare questi dati nel tuo ambiente con un collettore di webhook o chiamando periodicamente l'API degli eventi e consumando i dati. Ti raccomandiamo di utilizzare i webhook e abbiamo alcune raccomandazioni su come farlo nel modo giusto. Nella sua forma più basilare, un collettore di webhook PHP può essere distribuito in poche righe di codice:
<?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)
Durante la sperimentazione, puoi provarli con collettori gratuiti come http://webhook.site/.
Una volta raccolti tutti i dati dei webhook, puoi leggerli in un archivio dati per un'elaborazione aggiuntiva. Ci sono anche modi per spingere i webhook attraverso servizi come StitchData e Segment.
Le stesse informazioni sono disponibili nell'API degli eventi se hai bisogno di PULL i dati e non puoi accettare i dati PUSH. Ecco un esempio di chiamata all'API degli eventi:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Quell'API è completamente documentata con esempi qui: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Se hai veramente bisogno dei dati dell'evento in un formato che assomiglia alla registrazione PMTA o Momentum, è possibile anche se impieghi un ulteriore codice di condizionamento. La buona notizia è che ci sono alcuni esempi da cui rubare già.
MessageBird riporta la consegna dei messaggi in un feed di webhook o nell'API degli eventi del messaggio. L'accesso ai log di Bird in testo semplice non è possibile. Puoi recuperare questi dati nel tuo ambiente con un collettore di webhook o chiamando periodicamente l'API degli eventi e consumando i dati. Ti raccomandiamo di utilizzare i webhook e abbiamo alcune raccomandazioni su come farlo nel modo giusto. Nella sua forma più basilare, un collettore di webhook PHP può essere distribuito in poche righe di codice:
<?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)
Durante la sperimentazione, puoi provarli con collettori gratuiti come http://webhook.site/.
Una volta raccolti tutti i dati dei webhook, puoi leggerli in un archivio dati per un'elaborazione aggiuntiva. Ci sono anche modi per spingere i webhook attraverso servizi come StitchData e Segment.
Le stesse informazioni sono disponibili nell'API degli eventi se hai bisogno di PULL i dati e non puoi accettare i dati PUSH. Ecco un esempio di chiamata all'API degli eventi:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
Quell'API è completamente documentata con esempi qui: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Se hai veramente bisogno dei dati dell'evento in un formato che assomiglia alla registrazione PMTA o Momentum, è possibile anche se impieghi un ulteriore codice di condizionamento. La buona notizia è che ci sono alcuni esempi da cui rubare già.
Riepilogo
Assicurati di parlare con il tuo team di Vendite e Gestione del Successo. Abbiamo già fatto questo prima e possiamo aiutarti a farlo rapidamente e in modo conveniente.
Scopri se sei nel Campo #1 (in grado di passare completamente da On-Prem) o nel Campo #2 (Hai ancora bisogno di un MTA on-prem).
Registrati per un account di prova gratuito per valutare i dettagli dell'integrazione.
Se stai usando l'iniezione SMTP, scopri come ottenere i dati dell'intestazione e gli attributi del messaggio in un'intestazione X-MSYS-API.
Conferma se puoi utilizzare il nostro processo BYOIP.
Aggiorna il tuo DNS con nuovi domini se necessario.
Crea un piccolo campione per testare la tua migrazione. Potrebbe essere necessario modificare la tua configurazione.
Aumenta il volume finché tutto il traffico non è migrato
Se rientri nel Campo #1, puoi finalmente spegnere i tuoi MTA on-prem dopo che tutto il traffico è stato migrato.
Quando pianifichi modifiche al DNS per sistemi email ad alta capacità, fai attenzione alle potenziali sfide di scalabilità DNS di AWS che possono influenzare le prestazioni di consegna delle email su larga scala.
Assicurati di parlare con il tuo team di Vendite e Gestione del Successo. Abbiamo già fatto questo prima e possiamo aiutarti a farlo rapidamente e in modo conveniente.
Scopri se sei nel Campo #1 (in grado di passare completamente da On-Prem) o nel Campo #2 (Hai ancora bisogno di un MTA on-prem).
Registrati per un account di prova gratuito per valutare i dettagli dell'integrazione.
Se stai usando l'iniezione SMTP, scopri come ottenere i dati dell'intestazione e gli attributi del messaggio in un'intestazione X-MSYS-API.
Conferma se puoi utilizzare il nostro processo BYOIP.
Aggiorna il tuo DNS con nuovi domini se necessario.
Crea un piccolo campione per testare la tua migrazione. Potrebbe essere necessario modificare la tua configurazione.
Aumenta il volume finché tutto il traffico non è migrato
Se rientri nel Campo #1, puoi finalmente spegnere i tuoi MTA on-prem dopo che tutto il traffico è stato migrato.
Quando pianifichi modifiche al DNS per sistemi email ad alta capacità, fai attenzione alle potenziali sfide di scalabilità DNS di AWS che possono influenzare le prestazioni di consegna delle email su larga scala.
Assicurati di parlare con il tuo team di Vendite e Gestione del Successo. Abbiamo già fatto questo prima e possiamo aiutarti a farlo rapidamente e in modo conveniente.
Scopri se sei nel Campo #1 (in grado di passare completamente da On-Prem) o nel Campo #2 (Hai ancora bisogno di un MTA on-prem).
Registrati per un account di prova gratuito per valutare i dettagli dell'integrazione.
Se stai usando l'iniezione SMTP, scopri come ottenere i dati dell'intestazione e gli attributi del messaggio in un'intestazione X-MSYS-API.
Conferma se puoi utilizzare il nostro processo BYOIP.
Aggiorna il tuo DNS con nuovi domini se necessario.
Crea un piccolo campione per testare la tua migrazione. Potrebbe essere necessario modificare la tua configurazione.
Aumenta il volume finché tutto il traffico non è migrato
Se rientri nel Campo #1, puoi finalmente spegnere i tuoi MTA on-prem dopo che tutto il traffico è stato migrato.
Quando pianifichi modifiche al DNS per sistemi email ad alta capacità, fai attenzione alle potenziali sfide di scalabilità DNS di AWS che possono influenzare le prestazioni di consegna delle email su larga scala.
