Molte volte, sentiamo la domanda: "Avete una sorta di manuale che descrive il processo per migrare da un'installazione on-premises a Bird"?
Sì, assolutamente sì. Continua a leggere.
Prima, un po' di retroscena. Il servizio Bird Cloud è stato creato nel 2014 a causa dell'enorme successo della soluzione On-Premises Momentum MTA. Momentum si trova al cuore del Bird Cloud, fornendo consegna ad alta velocità e modellazione del traffico per migliaia di clienti sul servizio cloud. A causa di ciò, 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 pubblicità. I clienti di Momentum vedono i benefici di questo lavoro ogni volta che viene pubblicata una nuova versione pubblica di Momentum.
Questo non significa che Bird sia semplicemente "Momentum in the Cloud". MessageBird è molto di più e può offrire benefici aggiuntivi ai clienti che scelgono di migrare o utilizzare una configurazione ibrida. Questi benefici derivano dalla nostra moderna architettura API e-mail basata su cloud, che offre capacità non disponibili nelle soluzioni on-premises tradizionali. 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 realmente 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 data center fisici e non gestire più direttamente alcun MTA on-premises. Questo 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 del database completi di tutti i sistemi critici, specialmente se stai eseguendo database PostgreSQL che contengono dati storici o configurazioni importanti.
Hai motivo di mantenere una parte dell'infrastruttura on-premises per qualche motivo. Alcune possibilità potrebbero essere:
flussi di consegna specifici che richiedono pre-elaborazione in Momentum
divisione di capacità per esigenze di ripetizione o recupero da disastri
supporto clienti legacy in PMTA mentre si spostano nuovi clienti su SparkPost
...allora vuoi inoltrare gli altri messaggi a Bird per la gestione successiva dei messaggi.
In entrambi i casi, devi essere consapevole che Bird accetterà solo messaggi SMTP per la consegna che sono iniettati su porta 587 o 2525 e utilizzano SMTP_Auth con un nome utente e una password specifici (Vedi documentazione SMTP qui). Consigliamo vivamente di connettersi con una connessione TLS, ma non è strettamente necessario. Se stai sostituendo completamente il tuo livello MTA (scenario 1), allora potresti anche considerare di utilizzare l'API Transmissions REST 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à e-mail sicure, la nostra guida all'implementazione del S/MIME per PowerMTA e Momentum fornisce istruzioni dettagliate per la configurazione della consegna e-mail criptata.
Quale opzione scelgo?
Per capire se ti trovi nell'opzione #1 o nell'opzione #2, considera questi fattori:
Usi il motore di scripting Lua di Momentum per qualcosa di più complicato del semplice instradamento 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 vincolo 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 consigliamo Bird per assegnare il percorso per te.
Se utilizzi Lua per fare cose più complicate come il filtraggio del corpo, le riscritture di Mail_From o i calcoli della cadenza del messaggio, e non è fattibile spostare quella logica nella tua applicazione di iniezione, potresti voler considerare di cambiare al campo Opzione #2.
Il tuo sistema di generazione è in grado di inviare messaggi sulla porta 587 utilizzando TLS e SMTP_Auth?
Alcuni sistemi di gestione campagne possono inviare mail solo sulla porta 25 in testo semplice. Questo causa un problema di sicurezza per Bird quindi potresti voler considerare l'opzione #2
Stai usando la sintassi di sostituzione di PowerMTA o altre modifiche in linea del messaggio?
Se puoi spostare questa funzione nei tuoi generatori o usare il Template Language di Bird, puoi ancora usare l'opzione 1, ma altrimenti, potresti dover pensare a mantenere un nodo PMTA online per questa modifica del messaggio prima di inviarlo a Bird per la consegna.
Richiedi una scansione AV/AS in entrata prima dell'iniezione? Mentre questo è possibile in Momentum e PowerMTA, eBird presume che tu abbia già eseguito tutti quei controlli. Potresti voler considerare di farlo prima dell'iniezione.
Qualunque sia la tua scelta, influenzerà sicuramente il tuo rapporto commerciale. Come puoi immaginare, non è la nostra prima volta. Assicurati di coinvolgere il tuo Commercial Account Manager e il Customer Success Manager in modo che possiamo aiutarti nei dettagli e assicurarci che tu ottenga il miglior valore per il tuo denaro.
Per l'Opzione #1 Camp (metodo "cold turkey"):
Sfruttando l'Opzione #2 (pre-elaborazione on-prem):
Se, tuttavia, fai parte del team Opzione #2, allora vorrai apportare alcune modifiche di configurazione al tuo deployment. Il modo meno doloroso per migrare alcuni flussi di messaggi selezionati da Momentum o PMTA a Bird pur utilizzando l'iniezione SMTP dai tuoi sistemi di generazione è aggiungere una route speciale nella tua configurazione.
Per Momentum:
Configura una versione di Momentum > 3.6.23.
Installa un certificato SSL valido e apri la porta 587 in uscita in modo che Momentum possa comunicare con Bird. Configura un dominio in uscita in modo da poter instradare un messaggio tramite Momentum a Bird.
Con la configurazione seguente, qualsiasi messaggio che raggiunge questa configurazione verrà instradato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti lì.
Configura le associazioni che vuoi trasmettere tramite MessageBird con TLS e instradale al dominio che hai definito sopra.
Nota: TLS non è strettamente necessario ma è una raccomandazione forte. Se TLS non è possibile per qualche motivo, allora il whitelisting degli indirizzi IP delle chiavi API è anche una forte raccomandazione.
Per PowerMTA:
Configura una versione di PowerMTA > 4.5.0
Installa un certificato SSL valido e apri la porta 587 in uscita in modo che PowerMTA possa comunicare con Bird.
Configura un percorso di dominio in uscita in modo da poter instradare un messaggio tramite PowerMTA a Bird. Con la configurazione seguente, qualsiasi messaggio che raggiunge questa configurazione verrà instradato a smtp.sparkpostmail.com utilizzando la porta 587 e SMTP_Auth con il nome utente e la password definiti lì. In PowerMTA, questo è anche il luogo dove puoi impostare TLS. Nota che questo è anche documentato più ampiamente qui
4. Configura i VMTAs che vuoi trasmettere tramite Bird con la configurazione di rollup {sparkpost} che hai definito sopra.
Una volta che hai apportato quelle modifiche di configurazione, qualsiasi messaggio inviato alla 'binding' o 'VMTA' selezionata dovrebbe essere instradato automaticamente tramite Bird per la consegna.
Far accadere le cose
Quando inizi su questa strada, non fare l'errore di pensare che sia un'operazione da una notte. Fare questo bene richiederà del tempo e cura.
Configura il tuo account Bird e testa completamente usando un sottoconto di sviluppo così da poter filtrare il traffico successivamente. Dovrai farlo per entrambe le opzioni perché avrai bisogno della chiave API per la password SMTP_Auth in ogni caso.
Se stai usando 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 metadati e dovresti includere anche gli attributi ip_pool e campaign. Un esempio è disponibile qui
Se NON stai usando BYOIP, assicurati di configurare domini di invio leggermente diversi per l'uso con MessageBird in modo da poter gestire entrambi gli ambienti in parallelo per tutto il tempo necessario. Se il tuo dominio di invio corrente è mycompany.com, magari imposta sp.mycompany.com specificamente per la consegna Bird. Questo ti permette di migrare lentamente e con attenzione senza compromettere nessuno dei domini.
Assicurati di avere il pieno allineamento del dominio e le funzionalità di sicurezza abilitate. Nel DNS, configura DKIM, SPF, DMARC, domini di rimbalzo e tracciamento in modo che sembrino tutti appartenere alla stessa organizzazione.
Configura il Risveglio Automatico IP sui tuoi IP_Pools definiti. Se stai usando l'opzione precedentemente menzionata BYOIP, puoi ignorare il passaggio di risveglio.
Inizia con un flusso di messaggi e procedi da lì. Proprio come il Risveglio IP, non vuoi fare tutto in una volta. Reindirizza prima alcune centinaia di messaggi, poi il 10% del volume, poi il 20% il giorno seguente ed aumenta fino a che 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 prossimo.
Automatizza il più possibile con le API. Oltre ai cambiamenti DNS, la configurazione SparkPost può essere principalmente automatizzata con alcune chiamate API.
Raccolta dati da Bird
MessageBird riporta la consegna dei messaggi in un feed di webhook o nell'API degli eventi dei messaggi. Accedere ai log di testo semplice di Bird non è semplicemente possibile. È possibile recuperare questi dati nel proprio ambiente con un collettore di webhook o chiamando periodicamente l'Events API e consumando i dati. Consigliamo di utilizzare webhooks e abbiamo alcune raccomandazioni su come farlo correttamente. Nella sua forma più basilare, un collettore di webhook PHP può essere implementato in poche righe di codice:
Durante l'esperimentazione, puoi provarli con collettori gratuiti come http://webhook.site/.
Una volta raccolti tutti i dati dei webhook, puoi leggerli in un archivio dati per ulteriori elaborazioni. Ci sono anche modi per inviare Webhooks tramite servizi come StitchData e Segment.
Le stesse informazioni sono disponibili nell'Events API se hai bisogno di PULL dei dati e non puoi accettare dati PUSH. Ecco un esempio di chiamata all'Event API:
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 davvero bisogno che i dati degli eventi tornino in una forma che sembri il logging di PMTA o Momentum, ciò è possibile anche se impieghi un po' di codice di condizionamento aggiuntivo. La buona notizia è che ci sono alcuni esempi da cui rubare già.
Riepilogo
Assicurati di parlare con il tuo team di Sales and Success Management. L'abbiamo fatto in precedenza e possiamo aiutarti a farlo rapidamente ed efficacemente in termini di costi.
Scopri se sei nel Camp #1 (in grado di spostarti completamente da On-Prem) o nel Camp #2 (hai ancora bisogno di un po' di MTA on-prem).
Iscriviti per un account di prova gratuito per valutare i dettagli dell'integrazione.
Se stai usando l'iniezione SMTP, scopri come ottenere i dati dell'header e gli attributi del messaggio in un header X-MSYS-API.
Conferma se puoi usare il nostro processo BYOIP.
Aggiorna il tuo DNS con nuovi domini se necessario.
Costruisci un piccolo campione per testare la tua migrazione. Potresti dover regolare la tua configurazione.
Aumenta il volume fino a quando tutto il traffico è migrato.
Se rientri nel Camp #1, puoi finalmente spegnere i tuoi MTA on-prem dopo che tutto il traffico è stato migrato.
Quando pianifichi modifiche al DNS per sistemi di email ad alto volume, sii consapevole delle potenziali sfide di scalabilità DNS di AWS che possono influenzare le prestazioni di consegna delle email su larga scala.
