Sering kali, kami mendengar pertanyaan, “Apakah Anda memiliki buku panduan yang menguraikan proses untuk beralih dari instalasi on-premise ke Bird”?
Ya, ya kami punya. Teruslah membaca.
Pertama, beberapa latar belakang. Layanan Bird Cloud dibuat pada tahun 2014 dari kesuksesan besar solusi Momentum MTA On-Premises. Momentum berada di inti dari Bird Cloud, menyediakan pengiriman berkecepatan tinggi dan shaping lalu lintas untuk ribuan pelanggan pada layanan cloud. Karena ini, Momentum mendapatkan banyak perhatian dari tim teknik kami, namun hasil dari pekerjaan tersebut sering tertanam dalam peningkatan kinerja yang tidak mendapatkan banyak publisitas. Pelanggan Momentum melihat manfaat dari pekerjaan ini setiap kali rilis publik baru dari Momentum dipublikasikan.
Ini tidak berarti bahwa Bird hanyalah “Momentum di Cloud”. MessageBird jauh lebih dari itu dan dapat memiliki manfaat tambahan bagi pelanggan yang memilih untuk beralih atau menggunakannya dalam pendekatan hibrida. Selain itu, kami telah membuatnya sangat mudah bagi pelanggan PowerMTA untuk beralih atau menggunakan PowerMTA dengan Bird dalam konfigurasi hibrida juga. Dokumen ini akan menjelaskan secara rinci bagaimana Anda dapat memigrasikan aliran pesan Anda dari Momentum atau PowerMTA ke layanan Bird Cloud.
Ada dua skenario yang benar-benar terpisah yang perlu dipertimbangkan saat bermigrasi ke Bird dari Momentum atau PowerMTA.
Anda siap meninggalkan dunia on-premises sepenuhnya, menutup pusat data fisik Anda dan tidak lagi mengelola MTA on-premises secara langsung. Ini berarti menghilangkan Momentum atau PowerMTA dari penerapan Anda dan mengirim pesan langsung ke SparkPost untuk penanganan pesan. Atau
Anda memiliki alasan untuk mempertahankan beberapa jejak on-premises untuk satu atau lain alasan. Beberapa kemungkinan mungkin:
aliran pengiriman spesifik yang memerlukan praproses di Momentum
pembagian kapasitas untuk kebutuhan lonjakan atau pemulihan bencana
mendukung pelanggan lama di PMTA sambil mengalihkan pelanggan baru ke SparkPost
...maka Anda ingin meneruskan pesan lain ke Bird untuk penanganan pesan selanjutnya.
Dalam kedua situasi tersebut, Anda perlu menyadari bahwa Bird hanya akan menerima pesan SMTP untuk pengiriman yang dimasukkan melalui port 587 atau 2525 dan menggunakan SMTP_Auth dengan nama pengguna dan kata sandi tertentu (Lihat dokumentasi SMTP di sini). Kami juga sangat menyarankan untuk terhubung dengan koneksi TLS, namun itu tidak secara ketat diperlukan. Jika Anda sepenuhnya menggantikan lapisan MTA Anda (skenario 1), maka Anda mungkin juga ingin mempertimbangkan untuk menggunakan Transmissions REST API yang dapat menerima pesan melalui koneksi HTTPS. Dokumentasi tentang API itu di sini.
Opsi mana yang harus saya pilih?
Untuk menentukan apakah Anda berada di opsi #1 atau opsi #2, pertimbangkan faktor-faktor berikut:
Apakah Anda menggunakan mesin skrip Lua dari Momentum untuk sesuatu yang lebih rumit daripada pemrosesan pesan?
Lua adalah alat skrip yang komprehensif untuk memanipulasi pesan secara langsung, tetapi sebagian besar pengguna kami hanya menggunakannya untuk memilih ikatan untuk pengiriman. Jika itu kasusnya, Anda dapat memodifikasi kode generasi Anda untuk menambahkan atribut ip_pool ke header X-MSYS-API dan mempersilakan Bird menetapkan rute untuk Anda.
Jika Anda menggunakan Lua untuk melakukan hal-hal yang lebih rumit seperti penyaringan tubuh, penulisan ulang Mail_From, atau perhitungan irama pesan, dan tidak memungkinkan untuk memindahkan logika tersebut ke dalam aplikasi penyuntik Anda, Anda mungkin ingin mempertimbangkan untuk beralih ke kubu Opsi #2.
Apakah sistem generasi Anda dapat mengirim pesan melalui port 587 menggunakan TLS dan SMTP_Auth?
Beberapa sistem manajemen kampanye hanya dapat mendorong surat keluar di port 25 dalam teks terang. Ini menyebabkan masalah keamanan untuk Bird sehingga Anda mungkin ingin mempertimbangkan Opsi #2
Apakah Anda menggunakan sintaks PowerMTA substitution atau modifikasi pesan dalam baris lainnya?
Jika Anda dapat memindahkan fungsi ini ke dalam generator Anda atau menggunakan Bird Template Language, maka Anda masih dapat menggunakan opsi 1, tetapi sebaliknya, Anda mungkin perlu mempertimbangkan untuk menjaga node PMTA tetap online untuk modifikasi pesan ini sebelum mengirimkannya ke Bird untuk pengiriman.
Apakah Anda memerlukan pemindaian AV/AS masuk sebelum injeksi? Meskipun ini dimungkinkan dalam Momentum dan PowerMTA, eBird menganggap Anda telah melakukan semua pemeriksaan tersebut. Anda mungkin ingin mempertimbangkan untuk melakukannya sebelum injeksi.
Bagaimanapun caranya, pasti akan mempengaruhi hubungan komersial Anda. Seperti yang Anda bayangkan, ini bukan rodeo pertama kami. Pastikan untuk melibatkan Manajer Akun Komersial dan Manajer Sukses Pelanggan Anda agar kami dapat membantu Anda dengan detailnya dan memastikan Anda mendapatkan nilai terbaik untuk uang Anda.
Untuk Opsi #1 Camp (Going “cold turkey”):
Memanfaatkan Opsi #2 (pemrosesan awal on-prem):
Namun, jika Anda berada di tim Opsi #2, maka Anda ingin menambahkan beberapa perubahan konfigurasi ke penerapan Anda. Cara termudah untuk memigrasikan beberapa aliran pesan yang dipilih dari Momentum atau PMTA ke Bird sambil tetap menggunakan injeksi SMTP dari sistem generasi Anda adalah dengan menambahkan rute khusus di konfigurasi Anda.
Untuk Momentum:
Siapkan versi Momentum > 3.6.23.
Instal Sertifikat SSL yang valid dan buka port keluar 587 sehingga Momentum dapat berkomunikasi dengan Bird. Konfigurasikan domain keluar sehingga Anda dapat merutekan pesan melalui Momentum ke Bird.
Dengan konfigurasi di bawah ini, setiap pesan yang menggunakan konfigurasi ini akan diarahkan ke smtp.sparkpostmail.com menggunakan port 587 dan SMTP_Auth dengan nama pengguna dan kata sandi yang ditentukan di sana.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" }
Konfigurasi pengikatan yang ingin Anda relay melalui MessageBird dengan TLS dan kirimkan ke domain yang telah Anda tetapkan di atas.
Catatan: TLS tidak wajib tetapi sangat dianjurkan. Jika TLS tidak memungkinkan karena alasan tertentu, maka IP whitelisting kunci API juga sangat dianjurkan.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" }
Untuk PowerMTA:
Siapkan versi PowerMTA > 4.5.0
Instal Sertifikat SSL yang valid dan buka port keluar 587 sehingga PowerMTA dapat berkomunikasi dengan Bird.
Konfigurasi jalur domain keluar sehingga Anda dapat merutekan pesan melalui PowerMTA ke Bird. Dengan konfigurasi di bawah ini, setiap pesan yang menggunakan konfigurasi ini akan diarahkan ke smtp.sparkpostmail.com menggunakan port 587 dan SMTP_Auth dengan nama pengguna dan kata sandi yang ditentukan di sana. Di PowerMTA, ini juga tempat Anda dapat mengatur TLS. Catatan ini juga dijelaskan lebih lengkap di sini
<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. Konfigurasi VMTA yang ingin Anda relay melalui Bird dengan config {sparkpost} rollup yang Anda tetapkan di atas.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Setelah Anda membuat perubahan konfigurasi tersebut, pesan apa pun yang dikirim ke "binding" atau "VMTA" yang dipilih akan diarahkan secara otomatis melalui Bird untuk pengiriman.
Mewujudkannya
Ketika Anda memulai di jalan ini, jangan membuat kesalahan dengan berpikir bahwa ini adalah operasi semalam. Melakukan ini dengan benar akan memerlukan waktu dan perhatian.
Siapkan akun Bird Anda dan lakukan uji coba sepenuhnya menggunakan subakun pengembangan sehingga Anda dapat menyaring lalu lintas tersebut nanti. Anda perlu melakukannya untuk kedua opsi karena Anda akan memerlukan kunci API untuk kata sandi SMTP_Auth.
Jika Anda menggunakan injeksi SMTP, rencanakan untuk menambahkan header X-MSYS-API untuk memasukkan semua metadata dan atribut pesan yang diperlukan. Setiap X-Headers harus ditulis ulang sebagai metadata dan Anda juga harus menyertakan atribut ip_pool dan campaign. Contoh tersedia di sini
Jika Anda TIDAK menggunakan BYOIP, maka Anda harus memastikan Anda mengatur domain pengiriman yang sedikit berbeda untuk digunakan dengan MessageBird sehingga Anda dapat menjalankan kedua lingkungan secara paralel selama dibutuhkan. Jika domain pengiriman Anda saat ini adalah mycompany.com, mungkin atur sp.mycompany.com khusus untuk pengiriman Bird. Ini memungkinkan Anda untuk bermigrasi secara perlahan dan hati-hati sambil tidak mengompromikan salah satu domain.
Pastikan Anda memiliki penyelarasan domain penuh dan fitur keamanan diaktifkan. Di DNS, atur DKIM, SPF, DMARC, domain bouncing, dan pelacakan sehingga mereka semua terlihat seperti milik organisasi yang sama.
Konfigurasikan Pemanasan IP Otomatis pada IP_Pools yang Anda tetapkan. Jika Anda menggunakan opsi BYOIP yang disebutkan sebelumnya, Anda dapat mengabaikan langkah pemanasan.
Mulailah dengan satu aliran pesan dan lanjutkan dari sana. Sama seperti Pemanasan IP, Anda tidak ingin melakukan semuanya sekaligus. Arahkan beberapa ratus pesan terlebih dahulu, lalu 10% dari volumenya, kemudian 20% hari berikutnya dan tingkatkan hingga Anda telah memindahkan seluruh volumenya. Jika Anda adalah ESP, pilih pelanggan yang dapat Anda ajak bekerja sama dan uji proses dengan umpan balik mereka. Jika semuanya berjalan dengan baik, lanjutkan ke yang berikutnya. Jika Anda menghadapi masalah, luangkan waktu untuk memperbaikinya dan masukkan ke dalam proses untuk yang berikutnya.
Otomatiskan sebisa mungkin dengan API. Di luar perubahan DNS, konfigurasi SparkPost sebagian besar bisa diotomatisasi dengan beberapa panggilan API.
Pengumpulan Data dari Bird
MessageBird melaporkan pengiriman pesan dalam feed webhooks atau dalam API peristiwa pesan. Akses ke Bird log teks biasa tidak mungkin. Anda dapat menarik kembali data ini ke lingkungan Anda dengan pengumpul webhooks atau dengan memanggil Events API secara berkala dan mengkonsumsi data tersebut. Kami merekomendasikan menggunakan webhooks dan memiliki beberapa rekomendasi untuk melakukannya dengan benar. Dalam bentuk yang paling dasar, pengumpul webhook PHP dapat diterapkan dalam beberapa baris kode:
<?php $verb = $_SERVER['REQUEST_METHOD']; jika ($verb == "POST") { $jsonStr = file_get_contents("php://input"); http_response_code(200); $rnum = rand(1000,9999); $t = date("YmdHis") . $rnum; $Jfile = './data/data_'.$t.'.txt'; jika (file_exists($Jfile)) { $fn = basename($Jfile,".txt"); $seq = 0; $ftail = substr($fn,-2,1); jika ($ftail == "-"){ $seq = substr($fn,-1); } $seq++; $Jfile = basename($Jfile,".txt")."-".$seq.".txt"; } $fh = fopen($Jfile, "w") or die("Unable to create file!"); fwrite($fh, $jsonStr); fclose($fh); } ?>
Saat Anda bereksperimen, Anda dapat mencobanya dengan pengumpul gratis seperti http://webhook.site/.
Setelah Anda mengumpulkan semua data webhook, Anda dapat membaca itu ke data store untuk pemrosesan tambahan. Ada juga cara untuk mendorong Webhooks melalui layanan seperti StitchData dan Segment.
Informasi yang sama tersedia di Events API jika Anda perlu menarik data dan tidak dapat menerima data PUSH. Ini adalah contoh panggilan Event API:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
API itu sepenuhnya didokumentasikan dengan sampel di sini: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Jika Anda benar-benar membutuhkan data peristiwa kembali dalam bentuk yang terlihat seperti PMTA atau logging Momentum, itu juga mungkin jika Anda menerapkan beberapa kode kondisi tambahan. Berita baiknya adalah ada beberapa contoh untuk dicuri yang sudah ada.
Ringkasan
Pastikan Anda berbicara dengan tim Sales dan Success Management Anda. Kami sudah pernah melakukan ini sebelumnya dan dapat membantu Anda dengan cepat dan hemat biaya.
Tentukan apakah Anda berada di Camp #1 (dapat sepenuhnya pindah dari On-Prem) atau Camp #2 (Masih membutuhkan beberapa on-prem MTA).
Daftar untuk akun uji gratis untuk mengevaluasi detail integrasi.
Jika Anda menggunakan injeksi SMTP, cari tahu cara mendapatkan data header dan atribut pesan ke dalam header X-MSYS-API.
Konfirmasi apakah Anda dapat menggunakan proses BYOIP kami.
Perbarui DNS Anda dengan domain baru jika diperlukan.
Bangun sampel kecil untuk menguji migrasi Anda. Anda mungkin perlu menyesuaikan konfigurasi Anda.
Tingkatkan volume hingga semua lalu lintas telah dimigrasikan.
Jika Anda berada di Camp #1, Anda akhirnya dapat mematikan on-prem MTA Anda setelah semua lalu lintas dimigrasikan.
