Panduan Migrasi Email dari On-Premises ke Cloud
Burung
28 Jun 2020
1 min read
Poin Penting
Bird Cloud dibangun di atas mesin Momentum MTA yang teruji, memberikan pelanggan kinerja sistem on-prem yang matang dengan keuntungan tambahan dari platform API email cloud modern.
Banyak pengirim legacy masih bergantung pada Momentum atau PowerMTA, dan Bird menyediakan jalur migrasi yang jelas untuk keduanya—migrasi penuh ke cloud atau pengaturan hybrid melalui node on-prem.
Migrasi memerlukan pemahaman apakah Anda akan:
menghilangkan semua infrastruktur on-prem, atau
melanjutkan menggunakan MTA Anda untuk pra-pemrosesan, routing, atau batasan legacy.
Bird hanya menerima injeksi SMTP yang diautentikasi melalui port 587 atau 2525 (TLS sangat disarankan). Injeksi REST API juga tersedia untuk pengiriman berbasis JSON secara langsung.
Opsi #1 (“cold turkey”) memungkinkan penghapusan penuh MTAs dengan mengirim langsung ke Bird melalui SMTP atau REST, mengurangi kerumitan dan memodernisasi arsitektur pengiriman.
Opsi #2 mendukung lingkungan hybrid—merouting aliran tertentu dari Momentum atau PMTA ke Bird dengan mengonfigurasi domain keluar dengan SMTP_Auth ke Bird.
Konfigurasi PowerMTA dan Momentum dapat meneruskan lalu lintas ke Bird secara aman menggunakan TLS, SMTP_Auth berbasis API-key, dan definisi rute.
Pelanggan yang menggunakan skrip Lua tingkat lanjut, substitusi inline, atau penyaringan pre-delivery dapat tetap hybrid hingga logika di-refactor ke dalam sistem upstream.
Bird mendukung BYOIP (Bring Your Own IP) untuk pelanggan dengan blok /24 yang kontigu, memungkinkan Anda untuk mempertahankan reputasi IP yang telah dihangatkan dan melewati pemanasan IP penuh.
Untuk pengguna non-BYOIP, Bird menyediakan pemanasan IP otomatis, dan merekomendasikan migrasi bertahap—dimulai dengan volume kecil, lalu secara bertahap meningkatkan lalu lintas.
Pengaturan domain yang tepat (DKIM, SPF, DMARC, domain pantulan, domain pelacakan) sangat penting untuk keselarasan dan keberlangsungan yang mulus selama migrasi.
Bird menyediakan data acara waktu nyata melalui webhook atau Events API, memungkinkan otomatisasi hulu, aliran ETL, dan rekonstruksi gaya log jika diperlukan.
Sorotan Tanya jawab
Apa dua skenario migrasi utama?
Baik sepenuhnya menonaktifkan semua MTA di tempat (Opsi #1) atau mempertahankan setup hibrida di mana beberapa lalu lintas diarahkan melalui Momentum/PMTA sebelum mencapai Bird (Opsi #2).
Apa yang menentukan apakah Anda memilih Opsi #1 atau Opsi #2?
Ketergantungan Anda pada skrip Lua, logika pra-pemrosesan, penulisan ulang pesan, persyaratan keamanan, atau generator yang tidak dapat mengirim lalu lintas terautentikasi melalui port 587.
Apakah Bird menerima injeksi SMTP melalui port 25?
Tidak—Bird memerlukan injeksi SMTP melalui port 587 atau 2525, yang diautentikasi dengan SMTP_Auth.
Apakah TLS diperlukan?
Tidak secara ketat diperlukan, tetapi sangat dianjurkan untuk penyisipan pesan yang aman dari generator mana pun atau MTA lokal.
Bisakah pengirim menggunakan REST API alih-alih SMTP?
Ya—pengirim dapat mengirim muatan JSON melalui API REST Transmissions, sering kali menyederhanakan alur kerja dan menghilangkan kebutuhan untuk menghasilkan pesan SMTP mentah.
Apa itu program BYOIP Bird?
Sebuah proses yang memungkinkan pelanggan dengan blok /24 yang berurutan untuk memigrasikan IP yang ada ke Bird, mempertahankan reputasi dan melewati pemanasan.
Bagaimana jika BYOIP bukanlah opsi?
Gunakan domain pengiriman baru (misalnya, sp.domainguanda.com), jalankan kedua lingkungan secara paralel, dan bergantung pada pemanasan IP otomatis Bird.
Bagaimana cara Anda merutekan hanya aliran terpilih melalui Bird dalam pengaturan hibrida?
Dengan mengonfigurasi domain keluar (Momentum) atau konfigurasi rollup/VMTAs (PowerMTA) yang mengautentikasi dan mengirimkan ke titik akhir SMTP Bird.
Perubahan metadata apa yang diperlukan saat menyuntikkan melalui SMTP?
Tambahkan header
X-MSYS-APIyang berisi atribut sepertiip_pool,campaign, dan setiap metadata kustom yang sebelumnya ditangani melalui X-Headers.Apa yang harus dikonfigurasi di DNS sebelum migrasi?
Rekaman DKIM, SPF, DMARC, domain pengembalian, dan domain pelacakan untuk memastikan keselarasan domain dan mengurangi risiko pengiriman selama transisi.
Bagaimana lalu lintas seharusnya dipindahkan ke Bird?
Secara bertahap: mulai dengan aliran kecil, lalu 10%, kemudian 20%, meningkat setiap hari hingga semua lalu lintas telah berpindah—mirip dengan praktik terbaik pemanasan IP.
Bagaimana pengirim dapat mengumpulkan data pengiriman dan keterlibatan setelah migrasi?
Dengan menggunakan sistem webhook waktu nyata Bird atau API Events; pengumpul webhook dapat dibangun dengan cepat dan memberi umpan ke penyimpanan hulu atau sistem ETL.
Seringkali, kita mendengar pertanyaan, “Apakah Anda memiliki playbook semacam yang menjelaskan proses migrasi dari instalasi lokal ke Bird”?
Ya, tentu saja kami punya. Teruskan membaca.
Pertama, sedikit latar belakang. Layanan Cloud Bird diciptakan pada tahun 2014 berkat kesuksesan besar dari solusi On-Premises Momentum MTA. Momentum berada di inti Bird Cloud, menyediakan pengiriman berkecepatan tinggi dan pembentukan lalu lintas untuk ribuan pelanggan di layanan cloud. Karena ini, Momentum menerima sejumlah besar perhatian dari tim rekayasa kami, tetapi hasil dari pekerjaan itu sering kali terselubung dalam perbaikan kinerja yang tidak banyak diberitakan. Pelanggan Momentum merasakan manfaat dari pekerjaan ini setiap kali rilis publik baru dari Momentum diterbitkan.
Ini TIDAK berarti bahwa Bird hanyalah “Momentum di Cloud”. MessageBird jauh lebih dari itu dan dapat memiliki manfaat tambahan bagi pelanggan yang memilih untuk bermigrasi atau menggunakannya dalam pendekatan hibrida. Manfaat ini berasal dari arsitektur API email berbasis cloud kami yang modern, yang menyediakan kemampuan yang tidak tersedia dalam solusi on-premises tradisional. Selain itu, kami telah memudahkan pelanggan PowerMTA untuk bermigrasi atau menggunakan PowerMTA dengan Bird dalam konfigurasi hibrida juga. Sisa dokumen ini akan menjelaskan secara rinci bagaimana Anda dapat memigrasi aliran pesan Anda dari Momentum atau PowerMTA ke layanan Cloud Bird.
Ada dua skenario terpisah yang benar-benar perlu dipertimbangkan saat bermigrasi ke Bird dari Momentum atau PowerMTA.
Anda siap untuk meninggalkan dunia on-premises sepenuhnya, mematikan pusat data fisik Anda dan tidak lagi mengelola MTA on-premises secara langsung. Ini berarti menghilangkan Momentum atau PowerMTA dari deployment Anda dan mengirim pesan langsung ke SparkPost untuk penanganan pesan. Sebelum mematikan infrastruktur on-premises Anda, pastikan Anda memiliki cadangan database yang komprehensif dari semua sistem kritis, terutama jika Anda menjalankan database PostgreSQL yang berisi data atau konfigurasi historis yang penting.
Anda memiliki alasan untuk menjaga beberapa jejak on-premises karena satu dan lain hal. Beberapa kemungkinan mungkin adalah:
aliran pengiriman tertentu yang memerlukan pra-pemrosesan 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 lainnya ke Bird untuk penanganan pesan lebih lanjut.
Dalam situasi apapun, Anda perlu menyadari bahwa Bird hanya akan menerima pesan SMTP untuk pengiriman yang disuntikkan melalui port 587 atau 2525 dan menggunakan SMTP_Auth dengan nama pengguna dan kata sandi tertentu (Lihat dokumen SMTP di sini). Kami juga sangat merekomendasikan untuk menghubungkan dengan koneksi TLS, tetapi itu tidak wajib. Jika Anda mengganti lapisan MTA Anda sepenuhnya (skenario 1), maka Anda juga mungkin ingin mempertimbangkan untuk menggunakan Transmissions REST API yang dapat menerima pesan melalui koneksi HTTPS. Dokumentasi tentang API itu adalah di sini.
Untuk organisasi yang mempertahankan infrastruktur on-premises yang memerlukan kemampuan email yang aman, panduan implementasi S/MIME untuk PowerMTA dan Momentum kami menyediakan instruksi pengaturan yang terperinci untuk pengiriman email terenkripsi.
Seringkali, kita mendengar pertanyaan, “Apakah Anda memiliki playbook semacam yang menjelaskan proses migrasi dari instalasi lokal ke Bird”?
Ya, tentu saja kami punya. Teruskan membaca.
Pertama, sedikit latar belakang. Layanan Cloud Bird diciptakan pada tahun 2014 berkat kesuksesan besar dari solusi On-Premises Momentum MTA. Momentum berada di inti Bird Cloud, menyediakan pengiriman berkecepatan tinggi dan pembentukan lalu lintas untuk ribuan pelanggan di layanan cloud. Karena ini, Momentum menerima sejumlah besar perhatian dari tim rekayasa kami, tetapi hasil dari pekerjaan itu sering kali terselubung dalam perbaikan kinerja yang tidak banyak diberitakan. Pelanggan Momentum merasakan manfaat dari pekerjaan ini setiap kali rilis publik baru dari Momentum diterbitkan.
Ini TIDAK berarti bahwa Bird hanyalah “Momentum di Cloud”. MessageBird jauh lebih dari itu dan dapat memiliki manfaat tambahan bagi pelanggan yang memilih untuk bermigrasi atau menggunakannya dalam pendekatan hibrida. Manfaat ini berasal dari arsitektur API email berbasis cloud kami yang modern, yang menyediakan kemampuan yang tidak tersedia dalam solusi on-premises tradisional. Selain itu, kami telah memudahkan pelanggan PowerMTA untuk bermigrasi atau menggunakan PowerMTA dengan Bird dalam konfigurasi hibrida juga. Sisa dokumen ini akan menjelaskan secara rinci bagaimana Anda dapat memigrasi aliran pesan Anda dari Momentum atau PowerMTA ke layanan Cloud Bird.
Ada dua skenario terpisah yang benar-benar perlu dipertimbangkan saat bermigrasi ke Bird dari Momentum atau PowerMTA.
Anda siap untuk meninggalkan dunia on-premises sepenuhnya, mematikan pusat data fisik Anda dan tidak lagi mengelola MTA on-premises secara langsung. Ini berarti menghilangkan Momentum atau PowerMTA dari deployment Anda dan mengirim pesan langsung ke SparkPost untuk penanganan pesan. Sebelum mematikan infrastruktur on-premises Anda, pastikan Anda memiliki cadangan database yang komprehensif dari semua sistem kritis, terutama jika Anda menjalankan database PostgreSQL yang berisi data atau konfigurasi historis yang penting.
Anda memiliki alasan untuk menjaga beberapa jejak on-premises karena satu dan lain hal. Beberapa kemungkinan mungkin adalah:
aliran pengiriman tertentu yang memerlukan pra-pemrosesan 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 lainnya ke Bird untuk penanganan pesan lebih lanjut.
Dalam situasi apapun, Anda perlu menyadari bahwa Bird hanya akan menerima pesan SMTP untuk pengiriman yang disuntikkan melalui port 587 atau 2525 dan menggunakan SMTP_Auth dengan nama pengguna dan kata sandi tertentu (Lihat dokumen SMTP di sini). Kami juga sangat merekomendasikan untuk menghubungkan dengan koneksi TLS, tetapi itu tidak wajib. Jika Anda mengganti lapisan MTA Anda sepenuhnya (skenario 1), maka Anda juga mungkin ingin mempertimbangkan untuk menggunakan Transmissions REST API yang dapat menerima pesan melalui koneksi HTTPS. Dokumentasi tentang API itu adalah di sini.
Untuk organisasi yang mempertahankan infrastruktur on-premises yang memerlukan kemampuan email yang aman, panduan implementasi S/MIME untuk PowerMTA dan Momentum kami menyediakan instruksi pengaturan yang terperinci untuk pengiriman email terenkripsi.
Seringkali, kita mendengar pertanyaan, “Apakah Anda memiliki playbook semacam yang menjelaskan proses migrasi dari instalasi lokal ke Bird”?
Ya, tentu saja kami punya. Teruskan membaca.
Pertama, sedikit latar belakang. Layanan Cloud Bird diciptakan pada tahun 2014 berkat kesuksesan besar dari solusi On-Premises Momentum MTA. Momentum berada di inti Bird Cloud, menyediakan pengiriman berkecepatan tinggi dan pembentukan lalu lintas untuk ribuan pelanggan di layanan cloud. Karena ini, Momentum menerima sejumlah besar perhatian dari tim rekayasa kami, tetapi hasil dari pekerjaan itu sering kali terselubung dalam perbaikan kinerja yang tidak banyak diberitakan. Pelanggan Momentum merasakan manfaat dari pekerjaan ini setiap kali rilis publik baru dari Momentum diterbitkan.
Ini TIDAK berarti bahwa Bird hanyalah “Momentum di Cloud”. MessageBird jauh lebih dari itu dan dapat memiliki manfaat tambahan bagi pelanggan yang memilih untuk bermigrasi atau menggunakannya dalam pendekatan hibrida. Manfaat ini berasal dari arsitektur API email berbasis cloud kami yang modern, yang menyediakan kemampuan yang tidak tersedia dalam solusi on-premises tradisional. Selain itu, kami telah memudahkan pelanggan PowerMTA untuk bermigrasi atau menggunakan PowerMTA dengan Bird dalam konfigurasi hibrida juga. Sisa dokumen ini akan menjelaskan secara rinci bagaimana Anda dapat memigrasi aliran pesan Anda dari Momentum atau PowerMTA ke layanan Cloud Bird.
Ada dua skenario terpisah yang benar-benar perlu dipertimbangkan saat bermigrasi ke Bird dari Momentum atau PowerMTA.
Anda siap untuk meninggalkan dunia on-premises sepenuhnya, mematikan pusat data fisik Anda dan tidak lagi mengelola MTA on-premises secara langsung. Ini berarti menghilangkan Momentum atau PowerMTA dari deployment Anda dan mengirim pesan langsung ke SparkPost untuk penanganan pesan. Sebelum mematikan infrastruktur on-premises Anda, pastikan Anda memiliki cadangan database yang komprehensif dari semua sistem kritis, terutama jika Anda menjalankan database PostgreSQL yang berisi data atau konfigurasi historis yang penting.
Anda memiliki alasan untuk menjaga beberapa jejak on-premises karena satu dan lain hal. Beberapa kemungkinan mungkin adalah:
aliran pengiriman tertentu yang memerlukan pra-pemrosesan 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 lainnya ke Bird untuk penanganan pesan lebih lanjut.
Dalam situasi apapun, Anda perlu menyadari bahwa Bird hanya akan menerima pesan SMTP untuk pengiriman yang disuntikkan melalui port 587 atau 2525 dan menggunakan SMTP_Auth dengan nama pengguna dan kata sandi tertentu (Lihat dokumen SMTP di sini). Kami juga sangat merekomendasikan untuk menghubungkan dengan koneksi TLS, tetapi itu tidak wajib. Jika Anda mengganti lapisan MTA Anda sepenuhnya (skenario 1), maka Anda juga mungkin ingin mempertimbangkan untuk menggunakan Transmissions REST API yang dapat menerima pesan melalui koneksi HTTPS. Dokumentasi tentang API itu adalah di sini.
Untuk organisasi yang mempertahankan infrastruktur on-premises yang memerlukan kemampuan email yang aman, panduan implementasi S/MIME untuk PowerMTA dan Momentum kami menyediakan instruksi pengaturan yang terperinci untuk pengiriman email terenkripsi.
Opsi mana yang harus saya pilih?
Untuk mengetahui apakah Anda berada di opsi #1 atau opsi #2, pertimbangkan faktor-faktor ini:
Opsi | Terbaik jika Anda | Persyaratan kunci | Kompleksitas |
|---|---|---|---|
Opsi #1: Migrasi cloud penuh | Dapat menghapus semua MTA lokal | SMTP Auth melalui 587/2525 atau REST API | Memerlukan refactoring logika lokal yang maju |
Opsi #2: Routing hibrid | Perlu pra-pemrosesan atau dukungan warisan | Momentum atau PowerMTA tetap online | Menambah kompleksitas operasional |
Apakah Anda menggunakan mesin skrip Lua Momentum untuk sesuatu yang lebih rumit daripada routing pesan?
Lua adalah alat skrip komprehensif untuk memanipulasi pesan secara langsung, tetapi sebagian besar pengguna kami hanya menggunakannya untuk memilih pengikatan untuk pengiriman. Jika itu yang terjadi, Anda dapat memodifikasi kode generasi Anda untuk menambahkan atribut ip_pool ke header X-MSYS-API dan meminta Bird menetapkan rutenya untuk Anda.
Jika Anda menggunakan Lua untuk hal-hal yang lebih rumit seperti pemfilteran body, penulisan Mail_From, atau perhitungan ritme pesan, dan tidak mungkin untuk memindahkan logika tersebut ke dalam aplikasi penyuntikan Anda, Anda mungkin ingin mempertimbangkan untuk beralih ke opsi #2.
Apakah sistem generasi Anda mampu mengirim pesan melalui port 587 menggunakan TLS dan SMTP_Auth?
Beberapa sistem manajemen kampanye hanya dapat mengirim email melalui port 25 dalam teks tanpa enkripsi. Ini menyebabkan masalah keamanan untuk Bird, jadi Anda mungkin ingin mempertimbangkan opsi #2
Apakah Anda menggunakan sintaks substitusi PowerMTA atau modifikasi pesan dalam garis?
Jika Anda dapat memindahkan fungsi ini ke dalam generator Anda atau menggunakan Bahasa Template Bird, maka Anda masih dapat menggunakan opsi 1, tetapi jika tidak, Anda mungkin perlu mempertimbangkan untuk menjaga node PMTA tetap online untuk modifikasi pesan ini sebelum dikirim ke Bird untuk pengiriman.
Apakah Anda memerlukan pemindaian AV/AS masuk sebelum penyuntikan? Meskipun ini mungkin dilakukan di Momentum dan PowerMTA, eBird mengasumsikan Anda telah melakukan semua pemeriksaan tersebut. Anda mungkin ingin mempertimbangkan melakukan itu sebelum penyuntikan.
Tidak peduli jalan mana yang Anda pilih, pasti akan mempengaruhi hubungan komersial Anda. Seperti yang dapat Anda bayangkan, ini bukan pengalaman pertama kami. Pastikan untuk menghubungi Manajer Akun Komersial dan Manajer Kesuksesan Pelanggan Anda agar kami dapat membantu Anda melalui detailnya dan memastikan Anda mendapatkan nilai terbaik untuk uang Anda.
Untuk mengetahui apakah Anda berada di opsi #1 atau opsi #2, pertimbangkan faktor-faktor ini:
Opsi | Terbaik jika Anda | Persyaratan kunci | Kompleksitas |
|---|---|---|---|
Opsi #1: Migrasi cloud penuh | Dapat menghapus semua MTA lokal | SMTP Auth melalui 587/2525 atau REST API | Memerlukan refactoring logika lokal yang maju |
Opsi #2: Routing hibrid | Perlu pra-pemrosesan atau dukungan warisan | Momentum atau PowerMTA tetap online | Menambah kompleksitas operasional |
Apakah Anda menggunakan mesin skrip Lua Momentum untuk sesuatu yang lebih rumit daripada routing pesan?
Lua adalah alat skrip komprehensif untuk memanipulasi pesan secara langsung, tetapi sebagian besar pengguna kami hanya menggunakannya untuk memilih pengikatan untuk pengiriman. Jika itu yang terjadi, Anda dapat memodifikasi kode generasi Anda untuk menambahkan atribut ip_pool ke header X-MSYS-API dan meminta Bird menetapkan rutenya untuk Anda.
Jika Anda menggunakan Lua untuk hal-hal yang lebih rumit seperti pemfilteran body, penulisan Mail_From, atau perhitungan ritme pesan, dan tidak mungkin untuk memindahkan logika tersebut ke dalam aplikasi penyuntikan Anda, Anda mungkin ingin mempertimbangkan untuk beralih ke opsi #2.
Apakah sistem generasi Anda mampu mengirim pesan melalui port 587 menggunakan TLS dan SMTP_Auth?
Beberapa sistem manajemen kampanye hanya dapat mengirim email melalui port 25 dalam teks tanpa enkripsi. Ini menyebabkan masalah keamanan untuk Bird, jadi Anda mungkin ingin mempertimbangkan opsi #2
Apakah Anda menggunakan sintaks substitusi PowerMTA atau modifikasi pesan dalam garis?
Jika Anda dapat memindahkan fungsi ini ke dalam generator Anda atau menggunakan Bahasa Template Bird, maka Anda masih dapat menggunakan opsi 1, tetapi jika tidak, Anda mungkin perlu mempertimbangkan untuk menjaga node PMTA tetap online untuk modifikasi pesan ini sebelum dikirim ke Bird untuk pengiriman.
Apakah Anda memerlukan pemindaian AV/AS masuk sebelum penyuntikan? Meskipun ini mungkin dilakukan di Momentum dan PowerMTA, eBird mengasumsikan Anda telah melakukan semua pemeriksaan tersebut. Anda mungkin ingin mempertimbangkan melakukan itu sebelum penyuntikan.
Tidak peduli jalan mana yang Anda pilih, pasti akan mempengaruhi hubungan komersial Anda. Seperti yang dapat Anda bayangkan, ini bukan pengalaman pertama kami. Pastikan untuk menghubungi Manajer Akun Komersial dan Manajer Kesuksesan Pelanggan Anda agar kami dapat membantu Anda melalui detailnya dan memastikan Anda mendapatkan nilai terbaik untuk uang Anda.
Untuk mengetahui apakah Anda berada di opsi #1 atau opsi #2, pertimbangkan faktor-faktor ini:
Opsi | Terbaik jika Anda | Persyaratan kunci | Kompleksitas |
|---|---|---|---|
Opsi #1: Migrasi cloud penuh | Dapat menghapus semua MTA lokal | SMTP Auth melalui 587/2525 atau REST API | Memerlukan refactoring logika lokal yang maju |
Opsi #2: Routing hibrid | Perlu pra-pemrosesan atau dukungan warisan | Momentum atau PowerMTA tetap online | Menambah kompleksitas operasional |
Apakah Anda menggunakan mesin skrip Lua Momentum untuk sesuatu yang lebih rumit daripada routing pesan?
Lua adalah alat skrip komprehensif untuk memanipulasi pesan secara langsung, tetapi sebagian besar pengguna kami hanya menggunakannya untuk memilih pengikatan untuk pengiriman. Jika itu yang terjadi, Anda dapat memodifikasi kode generasi Anda untuk menambahkan atribut ip_pool ke header X-MSYS-API dan meminta Bird menetapkan rutenya untuk Anda.
Jika Anda menggunakan Lua untuk hal-hal yang lebih rumit seperti pemfilteran body, penulisan Mail_From, atau perhitungan ritme pesan, dan tidak mungkin untuk memindahkan logika tersebut ke dalam aplikasi penyuntikan Anda, Anda mungkin ingin mempertimbangkan untuk beralih ke opsi #2.
Apakah sistem generasi Anda mampu mengirim pesan melalui port 587 menggunakan TLS dan SMTP_Auth?
Beberapa sistem manajemen kampanye hanya dapat mengirim email melalui port 25 dalam teks tanpa enkripsi. Ini menyebabkan masalah keamanan untuk Bird, jadi Anda mungkin ingin mempertimbangkan opsi #2
Apakah Anda menggunakan sintaks substitusi PowerMTA atau modifikasi pesan dalam garis?
Jika Anda dapat memindahkan fungsi ini ke dalam generator Anda atau menggunakan Bahasa Template Bird, maka Anda masih dapat menggunakan opsi 1, tetapi jika tidak, Anda mungkin perlu mempertimbangkan untuk menjaga node PMTA tetap online untuk modifikasi pesan ini sebelum dikirim ke Bird untuk pengiriman.
Apakah Anda memerlukan pemindaian AV/AS masuk sebelum penyuntikan? Meskipun ini mungkin dilakukan di Momentum dan PowerMTA, eBird mengasumsikan Anda telah melakukan semua pemeriksaan tersebut. Anda mungkin ingin mempertimbangkan melakukan itu sebelum penyuntikan.
Tidak peduli jalan mana yang Anda pilih, pasti akan mempengaruhi hubungan komersial Anda. Seperti yang dapat Anda bayangkan, ini bukan pengalaman pertama kami. Pastikan untuk menghubungi Manajer Akun Komersial dan Manajer Kesuksesan Pelanggan Anda agar kami dapat membantu Anda melalui detailnya dan memastikan Anda mendapatkan nilai terbaik untuk uang Anda.
Untuk Opsi #1 Kamp (Berhenti sepenuhnya):
Anggaplah Anda setuju dengan opsi 1 dan Anda siap untuk mematikan MTA lokal Anda serta telah memutuskan untuk terus menggunakan metode injeksi SMTP, tanpa mengubah sistem pembuatan pesan Anda sama sekali. Sistem generasi Anda harus membuat pesan SMTP yang terformat sepenuhnya, lalu dorong ke Bird melalui TLS menggunakan SMTP_AUTH di mana nama pengguna dan kata sandi seperti yang dijelaskan di halaman ini. Ingatlah bahwa “kata sandi” adalah kunci API yang Anda buat di akun Bird Anda dengan opsi pengiriman SMTP diaktifkan.
Jika Anda berada di kelompok Opsi #1, pertimbangkan untuk beralih ke REST API langsung dari sistem generasi Anda. Dalam banyak kasus, kami menemukan bahwa sistem pemrosesan pelanggan sudah menggunakan JSON melalui HTTP dan harus mengonversinya ke SMTP sebelum injeksi. Anda dapat melewati langkah itu dan mengirimnya langsung kepada kami sebagai sebuah muatan REST yang terformat JSON.
Jika Anda memilih untuk menyuntikkan dengan REST API, Anda mungkin perlu sedikit mengubah sistem pembuatan konten Anda, tetapi itu mungkin sepadan. Anda dapat menemukan lebih banyak informasi di sini.
Salah satu kekhawatiran terbesar yang dimiliki ESP besar dengan Migrasi adalah Pemanasan IP. Biasanya mereka telah menghabiskan bertahun-tahun merawat inventaris alamat IP mereka dengan sangat hati-hati, jadi pemikiran untuk meninggalkan semua pekerjaan itu menyakitkan. Bird telah mengembangkan proses Bring Your Own IP (BYOIP) yang menangani masalah itu. Jika Anda memiliki setidaknya satu blok CIDR /24 yang berkelanjutan, Bird dapat menggunakan IP yang ada untuk pengiriman yang menghemat Anda dari rasa sakit untuk memanaskannya lagi. Jika Anda dapat memanfaatkan pilihan itu, Anda dapat melewatkan bagian di sini tentang pemanasan IP.
Jika Anda merasa siap untuk melanjutkan, langsung saja ke “Mewujudkannya”
Anggaplah Anda setuju dengan opsi 1 dan Anda siap untuk mematikan MTA lokal Anda serta telah memutuskan untuk terus menggunakan metode injeksi SMTP, tanpa mengubah sistem pembuatan pesan Anda sama sekali. Sistem generasi Anda harus membuat pesan SMTP yang terformat sepenuhnya, lalu dorong ke Bird melalui TLS menggunakan SMTP_AUTH di mana nama pengguna dan kata sandi seperti yang dijelaskan di halaman ini. Ingatlah bahwa “kata sandi” adalah kunci API yang Anda buat di akun Bird Anda dengan opsi pengiriman SMTP diaktifkan.
Jika Anda berada di kelompok Opsi #1, pertimbangkan untuk beralih ke REST API langsung dari sistem generasi Anda. Dalam banyak kasus, kami menemukan bahwa sistem pemrosesan pelanggan sudah menggunakan JSON melalui HTTP dan harus mengonversinya ke SMTP sebelum injeksi. Anda dapat melewati langkah itu dan mengirimnya langsung kepada kami sebagai sebuah muatan REST yang terformat JSON.
Jika Anda memilih untuk menyuntikkan dengan REST API, Anda mungkin perlu sedikit mengubah sistem pembuatan konten Anda, tetapi itu mungkin sepadan. Anda dapat menemukan lebih banyak informasi di sini.
Salah satu kekhawatiran terbesar yang dimiliki ESP besar dengan Migrasi adalah Pemanasan IP. Biasanya mereka telah menghabiskan bertahun-tahun merawat inventaris alamat IP mereka dengan sangat hati-hati, jadi pemikiran untuk meninggalkan semua pekerjaan itu menyakitkan. Bird telah mengembangkan proses Bring Your Own IP (BYOIP) yang menangani masalah itu. Jika Anda memiliki setidaknya satu blok CIDR /24 yang berkelanjutan, Bird dapat menggunakan IP yang ada untuk pengiriman yang menghemat Anda dari rasa sakit untuk memanaskannya lagi. Jika Anda dapat memanfaatkan pilihan itu, Anda dapat melewatkan bagian di sini tentang pemanasan IP.
Jika Anda merasa siap untuk melanjutkan, langsung saja ke “Mewujudkannya”
Anggaplah Anda setuju dengan opsi 1 dan Anda siap untuk mematikan MTA lokal Anda serta telah memutuskan untuk terus menggunakan metode injeksi SMTP, tanpa mengubah sistem pembuatan pesan Anda sama sekali. Sistem generasi Anda harus membuat pesan SMTP yang terformat sepenuhnya, lalu dorong ke Bird melalui TLS menggunakan SMTP_AUTH di mana nama pengguna dan kata sandi seperti yang dijelaskan di halaman ini. Ingatlah bahwa “kata sandi” adalah kunci API yang Anda buat di akun Bird Anda dengan opsi pengiriman SMTP diaktifkan.
Jika Anda berada di kelompok Opsi #1, pertimbangkan untuk beralih ke REST API langsung dari sistem generasi Anda. Dalam banyak kasus, kami menemukan bahwa sistem pemrosesan pelanggan sudah menggunakan JSON melalui HTTP dan harus mengonversinya ke SMTP sebelum injeksi. Anda dapat melewati langkah itu dan mengirimnya langsung kepada kami sebagai sebuah muatan REST yang terformat JSON.
Jika Anda memilih untuk menyuntikkan dengan REST API, Anda mungkin perlu sedikit mengubah sistem pembuatan konten Anda, tetapi itu mungkin sepadan. Anda dapat menemukan lebih banyak informasi di sini.
Salah satu kekhawatiran terbesar yang dimiliki ESP besar dengan Migrasi adalah Pemanasan IP. Biasanya mereka telah menghabiskan bertahun-tahun merawat inventaris alamat IP mereka dengan sangat hati-hati, jadi pemikiran untuk meninggalkan semua pekerjaan itu menyakitkan. Bird telah mengembangkan proses Bring Your Own IP (BYOIP) yang menangani masalah itu. Jika Anda memiliki setidaknya satu blok CIDR /24 yang berkelanjutan, Bird dapat menggunakan IP yang ada untuk pengiriman yang menghemat Anda dari rasa sakit untuk memanaskannya lagi. Jika Anda dapat memanfaatkan pilihan itu, Anda dapat melewatkan bagian di sini tentang pemanasan IP.
Jika Anda merasa siap untuk melanjutkan, langsung saja ke “Mewujudkannya”
Memanfaatkan Opsi #2 (pra-pemrosesan on-prem):
Namun, jika Anda berada di tim Opsi #2, maka Anda akan ingin menambahkan beberapa perubahan konfigurasi pada penerapan Anda. Cara paling tidak menyakitkan untuk memigrasikan beberapa aliran pesan terpilih dari Momentum atau PMTA ke Bird sambil tetap menggunakan injeksi SMTP dari sistem generasi Anda adalah dengan menambahkan jalur khusus di konfigurasi Anda.
Untuk Momentum:
Siapkan versi Momentum > 3.6.23.
Pasang 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 mengenai 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" }
Konfigurasikan ikatan yang ingin Anda relai melalui MessageBird dengan TLS dan gerbang ke domain yang Anda definisikan di atas.
Catatan: TLS tidak diwajibkan, tetapi merupakan rekomendasi yang kuat. Jika TLS tidak mungkin karena suatu alasan, maka whitelist IP untuk kunci API juga merupakan rekomendasi yang kuat.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
Pasang Sertifikat SSL yang valid dan buka port keluar 587 sehingga PowerMTA dapat berkomunikasi dengan Bird.
Konfigurasikan jalur domain keluar sehingga Anda dapat merutekan pesan melalui PowerMTA ke Bird. Dengan konfigurasi di bawah ini, setiap pesan yang mengenai 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, di sinilah Anda juga dapat mengatur TLS. Catatan, ini juga didokumentasikan 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. Konfigurasikan VMTAs yang ingin Anda relai melalui Bird dengan konfigurasi rollup {sparkpost} yang Anda definisikan di atas.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Setelah Anda melakukan perubahan konfigurasi itu, setiap pesan yang dikirim ke “binding” atau “VMTA” yang terpilih harus diarahkan secara otomatis melalui Bird untuk pengiriman.
Namun, jika Anda berada di tim Opsi #2, maka Anda akan ingin menambahkan beberapa perubahan konfigurasi pada penerapan Anda. Cara paling tidak menyakitkan untuk memigrasikan beberapa aliran pesan terpilih dari Momentum atau PMTA ke Bird sambil tetap menggunakan injeksi SMTP dari sistem generasi Anda adalah dengan menambahkan jalur khusus di konfigurasi Anda.
Untuk Momentum:
Siapkan versi Momentum > 3.6.23.
Pasang 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 mengenai 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" }
Konfigurasikan ikatan yang ingin Anda relai melalui MessageBird dengan TLS dan gerbang ke domain yang Anda definisikan di atas.
Catatan: TLS tidak diwajibkan, tetapi merupakan rekomendasi yang kuat. Jika TLS tidak mungkin karena suatu alasan, maka whitelist IP untuk kunci API juga merupakan rekomendasi yang kuat.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
Pasang Sertifikat SSL yang valid dan buka port keluar 587 sehingga PowerMTA dapat berkomunikasi dengan Bird.
Konfigurasikan jalur domain keluar sehingga Anda dapat merutekan pesan melalui PowerMTA ke Bird. Dengan konfigurasi di bawah ini, setiap pesan yang mengenai 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, di sinilah Anda juga dapat mengatur TLS. Catatan, ini juga didokumentasikan 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. Konfigurasikan VMTAs yang ingin Anda relai melalui Bird dengan konfigurasi rollup {sparkpost} yang Anda definisikan di atas.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Setelah Anda melakukan perubahan konfigurasi itu, setiap pesan yang dikirim ke “binding” atau “VMTA” yang terpilih harus diarahkan secara otomatis melalui Bird untuk pengiriman.
Namun, jika Anda berada di tim Opsi #2, maka Anda akan ingin menambahkan beberapa perubahan konfigurasi pada penerapan Anda. Cara paling tidak menyakitkan untuk memigrasikan beberapa aliran pesan terpilih dari Momentum atau PMTA ke Bird sambil tetap menggunakan injeksi SMTP dari sistem generasi Anda adalah dengan menambahkan jalur khusus di konfigurasi Anda.
Untuk Momentum:
Siapkan versi Momentum > 3.6.23.
Pasang 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 mengenai 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" }
Konfigurasikan ikatan yang ingin Anda relai melalui MessageBird dengan TLS dan gerbang ke domain yang Anda definisikan di atas.
Catatan: TLS tidak diwajibkan, tetapi merupakan rekomendasi yang kuat. Jika TLS tidak mungkin karena suatu alasan, maka whitelist IP untuk kunci API juga merupakan rekomendasi yang kuat.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
Pasang Sertifikat SSL yang valid dan buka port keluar 587 sehingga PowerMTA dapat berkomunikasi dengan Bird.
Konfigurasikan jalur domain keluar sehingga Anda dapat merutekan pesan melalui PowerMTA ke Bird. Dengan konfigurasi di bawah ini, setiap pesan yang mengenai 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, di sinilah Anda juga dapat mengatur TLS. Catatan, ini juga didokumentasikan 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. Konfigurasikan VMTAs yang ingin Anda relai melalui Bird dengan konfigurasi rollup {sparkpost} yang Anda definisikan di atas.
<virtual-mta SparkPostRelay> <domain *> queue-to {sparkpost} </domain> </virtual-mta>
Setelah Anda melakukan perubahan konfigurasi itu, setiap pesan yang dikirim ke “binding” atau “VMTA” yang terpilih harus diarahkan secara otomatis melalui Bird untuk pengiriman.
Mewujudkannya
Ketika Anda memulai perjalanan ini, jangan membuat kesalahan berpikir bahwa ini adalah operasi yang instan. Melakukan ini dengan benar akan membutuhkan waktu dan perhatian.
Siapkan akun Bird Anda dan lakukan pengujian penuh menggunakan subaccount pengembangan sehingga Anda dapat memfilter lalu lintas itu nanti. Anda perlu melakukan ini untuk kedua opsi karena Anda akan memerlukan kunci API untuk kata sandi SMTP_Auth apa pun.
Jika Anda menggunakan injeksi SMTP, rencanakan untuk menambahkan header X-MSYS-API untuk menggabungkan semua metadata dan atribut pesan yang diperlukan. Setiap X-Headers harus ditulis ulang sebagai metadata dan Anda juga harus menyertakan atribut ip_pool dan kampanye. Contoh tersedia di sini
Jika Anda TIDAK menggunakan BYOIP, maka Anda harus memastikan untuk mengatur domain pengiriman yang sedikit berbeda untuk digunakan dengan MessageBird sehingga Anda dapat menjalankan kedua lingkungan secara paralel selama diperlukan. 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 mengorbankan salah satu domain.
Pastikan Anda memiliki penyelarasan domain penuh dan fitur keamanan yang diaktifkan. Di DNS, atur DKIM, SPF, DMARC, domain bounce dan tracking sehingga semuanya terlihat seperti milik organisasi yang sama.
Konfigurasikan Pemanasan IP Otomatis pada IP_Pools yang telah Anda tentukan. Jika Anda menggunakan opsi BYOIP yang disebutkan sebelumnya, Anda dapat mengabaikan langkah pemanasan ini.
Mulailah dengan satu aliran pesan dan maju dari sana. Seperti pemanasan IP, Anda tidak ingin melakukan ini secara sekaligus. Alihkan beberapa ratus pesan terlebih dahulu, kemudian 10% dari volume, kemudian 20% pada hari berikutnya dan tingkatkan hingga Anda telah memindahkan semua volume. Jika Anda adalah ESP, pilih pelanggan yang dapat Anda ajak bekerja sama dan uji prosesnya dengan umpan balik mereka. Jika semuanya berjalan lancar, lanjutkan ke yang berikutnya. Jika Anda mengalami masalah, luangkan waktu untuk memperbaikinya dan masukkan ke dalam proses untuk yang berikutnya.
Otomatisasi sebanyak mungkin dengan API. Di luar perubahan DNS, konfigurasi SparkPost dapat sebagian besar diotomatisasi dengan beberapa panggilan API.
Ketika Anda memulai perjalanan ini, jangan membuat kesalahan berpikir bahwa ini adalah operasi yang instan. Melakukan ini dengan benar akan membutuhkan waktu dan perhatian.
Siapkan akun Bird Anda dan lakukan pengujian penuh menggunakan subaccount pengembangan sehingga Anda dapat memfilter lalu lintas itu nanti. Anda perlu melakukan ini untuk kedua opsi karena Anda akan memerlukan kunci API untuk kata sandi SMTP_Auth apa pun.
Jika Anda menggunakan injeksi SMTP, rencanakan untuk menambahkan header X-MSYS-API untuk menggabungkan semua metadata dan atribut pesan yang diperlukan. Setiap X-Headers harus ditulis ulang sebagai metadata dan Anda juga harus menyertakan atribut ip_pool dan kampanye. Contoh tersedia di sini
Jika Anda TIDAK menggunakan BYOIP, maka Anda harus memastikan untuk mengatur domain pengiriman yang sedikit berbeda untuk digunakan dengan MessageBird sehingga Anda dapat menjalankan kedua lingkungan secara paralel selama diperlukan. 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 mengorbankan salah satu domain.
Pastikan Anda memiliki penyelarasan domain penuh dan fitur keamanan yang diaktifkan. Di DNS, atur DKIM, SPF, DMARC, domain bounce dan tracking sehingga semuanya terlihat seperti milik organisasi yang sama.
Konfigurasikan Pemanasan IP Otomatis pada IP_Pools yang telah Anda tentukan. Jika Anda menggunakan opsi BYOIP yang disebutkan sebelumnya, Anda dapat mengabaikan langkah pemanasan ini.
Mulailah dengan satu aliran pesan dan maju dari sana. Seperti pemanasan IP, Anda tidak ingin melakukan ini secara sekaligus. Alihkan beberapa ratus pesan terlebih dahulu, kemudian 10% dari volume, kemudian 20% pada hari berikutnya dan tingkatkan hingga Anda telah memindahkan semua volume. Jika Anda adalah ESP, pilih pelanggan yang dapat Anda ajak bekerja sama dan uji prosesnya dengan umpan balik mereka. Jika semuanya berjalan lancar, lanjutkan ke yang berikutnya. Jika Anda mengalami masalah, luangkan waktu untuk memperbaikinya dan masukkan ke dalam proses untuk yang berikutnya.
Otomatisasi sebanyak mungkin dengan API. Di luar perubahan DNS, konfigurasi SparkPost dapat sebagian besar diotomatisasi dengan beberapa panggilan API.
Ketika Anda memulai perjalanan ini, jangan membuat kesalahan berpikir bahwa ini adalah operasi yang instan. Melakukan ini dengan benar akan membutuhkan waktu dan perhatian.
Siapkan akun Bird Anda dan lakukan pengujian penuh menggunakan subaccount pengembangan sehingga Anda dapat memfilter lalu lintas itu nanti. Anda perlu melakukan ini untuk kedua opsi karena Anda akan memerlukan kunci API untuk kata sandi SMTP_Auth apa pun.
Jika Anda menggunakan injeksi SMTP, rencanakan untuk menambahkan header X-MSYS-API untuk menggabungkan semua metadata dan atribut pesan yang diperlukan. Setiap X-Headers harus ditulis ulang sebagai metadata dan Anda juga harus menyertakan atribut ip_pool dan kampanye. Contoh tersedia di sini
Jika Anda TIDAK menggunakan BYOIP, maka Anda harus memastikan untuk mengatur domain pengiriman yang sedikit berbeda untuk digunakan dengan MessageBird sehingga Anda dapat menjalankan kedua lingkungan secara paralel selama diperlukan. 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 mengorbankan salah satu domain.
Pastikan Anda memiliki penyelarasan domain penuh dan fitur keamanan yang diaktifkan. Di DNS, atur DKIM, SPF, DMARC, domain bounce dan tracking sehingga semuanya terlihat seperti milik organisasi yang sama.
Konfigurasikan Pemanasan IP Otomatis pada IP_Pools yang telah Anda tentukan. Jika Anda menggunakan opsi BYOIP yang disebutkan sebelumnya, Anda dapat mengabaikan langkah pemanasan ini.
Mulailah dengan satu aliran pesan dan maju dari sana. Seperti pemanasan IP, Anda tidak ingin melakukan ini secara sekaligus. Alihkan beberapa ratus pesan terlebih dahulu, kemudian 10% dari volume, kemudian 20% pada hari berikutnya dan tingkatkan hingga Anda telah memindahkan semua volume. Jika Anda adalah ESP, pilih pelanggan yang dapat Anda ajak bekerja sama dan uji prosesnya dengan umpan balik mereka. Jika semuanya berjalan lancar, lanjutkan ke yang berikutnya. Jika Anda mengalami masalah, luangkan waktu untuk memperbaikinya dan masukkan ke dalam proses untuk yang berikutnya.
Otomatisasi sebanyak mungkin dengan API. Di luar perubahan DNS, konfigurasi SparkPost dapat sebagian besar diotomatisasi dengan beberapa panggilan API.
Pengumpulan Data dari Burung
Laporan MessageBird melaporkan pengiriman pesan dalam umpan webhook atau dalam API peristiwa pesan. Mengakses log teks biasa Bird memang tidak mungkin. Anda dapat menarik data ini kembali ke lingkungan Anda dengan pengumpul webhook atau dengan memanggil API Peristiwa secara berkala dan mengkonsumsi data tersebut. Kami merekomendasikan untuk menggunakan webhook dan memiliki beberapa rekomendasi untuk melakukannya dengan benar. Dalam bentuk paling dasar, pengumpul webhook PHP dapat diterapkan dalam beberapa baris kode:
<?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)
Saat Anda bereksperimen, Anda dapat mencobanya dengan pengumpul gratis seperti http://webhook.site/.
Setelah Anda mengumpulkan semua data webhook, Anda dapat membacanya ke dalam penyimpanan data untuk pemrosesan tambahan. Ada juga cara untuk mendorong Webhook melalui layanan seperti StitchData dan Segment.
Informasi yang sama tersedia dalam API Peristiwa jika Anda perlu MENARIK data dan tidak bisa menerima data PUSH. Berikut adalah contoh panggilan API Peristiwa:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
API tersebut sepenuhnya didokumentasikan dengan contoh di sini: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Jika Anda benar-benar memerlukan data peristiwa kembali dalam bentuk yang mirip dengan pencatatan PMTA atau Momentum, itu juga memungkinkan jika Anda menggunakan beberapa kode pengkondisian tambahan. Kabar baiknya adalah ada beberapa contoh untuk dicontoh dari sebelumnya.
Laporan MessageBird melaporkan pengiriman pesan dalam umpan webhook atau dalam API peristiwa pesan. Mengakses log teks biasa Bird memang tidak mungkin. Anda dapat menarik data ini kembali ke lingkungan Anda dengan pengumpul webhook atau dengan memanggil API Peristiwa secara berkala dan mengkonsumsi data tersebut. Kami merekomendasikan untuk menggunakan webhook dan memiliki beberapa rekomendasi untuk melakukannya dengan benar. Dalam bentuk paling dasar, pengumpul webhook PHP dapat diterapkan dalam beberapa baris kode:
<?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)
Saat Anda bereksperimen, Anda dapat mencobanya dengan pengumpul gratis seperti http://webhook.site/.
Setelah Anda mengumpulkan semua data webhook, Anda dapat membacanya ke dalam penyimpanan data untuk pemrosesan tambahan. Ada juga cara untuk mendorong Webhook melalui layanan seperti StitchData dan Segment.
Informasi yang sama tersedia dalam API Peristiwa jika Anda perlu MENARIK data dan tidak bisa menerima data PUSH. Berikut adalah contoh panggilan API Peristiwa:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
API tersebut sepenuhnya didokumentasikan dengan contoh di sini: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Jika Anda benar-benar memerlukan data peristiwa kembali dalam bentuk yang mirip dengan pencatatan PMTA atau Momentum, itu juga memungkinkan jika Anda menggunakan beberapa kode pengkondisian tambahan. Kabar baiknya adalah ada beberapa contoh untuk dicontoh dari sebelumnya.
Laporan MessageBird melaporkan pengiriman pesan dalam umpan webhook atau dalam API peristiwa pesan. Mengakses log teks biasa Bird memang tidak mungkin. Anda dapat menarik data ini kembali ke lingkungan Anda dengan pengumpul webhook atau dengan memanggil API Peristiwa secara berkala dan mengkonsumsi data tersebut. Kami merekomendasikan untuk menggunakan webhook dan memiliki beberapa rekomendasi untuk melakukannya dengan benar. Dalam bentuk paling dasar, pengumpul webhook PHP dapat diterapkan dalam beberapa baris kode:
<?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)
Saat Anda bereksperimen, Anda dapat mencobanya dengan pengumpul gratis seperti http://webhook.site/.
Setelah Anda mengumpulkan semua data webhook, Anda dapat membacanya ke dalam penyimpanan data untuk pemrosesan tambahan. Ada juga cara untuk mendorong Webhook melalui layanan seperti StitchData dan Segment.
Informasi yang sama tersedia dalam API Peristiwa jika Anda perlu MENARIK data dan tidak bisa menerima data PUSH. Berikut adalah contoh panggilan API Peristiwa:
GET https://api.sparkpost.com/api/v1/events/message?/
recipients=recipient@example.com&templates=my-template&events
API tersebut sepenuhnya didokumentasikan dengan contoh di sini: https://developers.sparkpost.com/api/events/#events-get-search-for-message-events
Jika Anda benar-benar memerlukan data peristiwa kembali dalam bentuk yang mirip dengan pencatatan PMTA atau Momentum, itu juga memungkinkan jika Anda menggunakan beberapa kode pengkondisian tambahan. Kabar baiknya adalah ada beberapa contoh untuk dicontoh dari sebelumnya.
Rekap
Pastikan Anda berbicara dengan tim Penjualan dan Manajemen Kesuksesan Anda. Kami sudah melakukan ini sebelumnya dan dapat membantu Anda melalui proses ini dengan cepat dan biaya yang efektif.
Ketahui apakah Anda berada di Kamp #1 (mampu berpindah sepenuhnya dari On-Prem) atau Kamp #2 (Masih memerlukan beberapa MTA on-prem).
Daftar untuk akun ujicoba gratis untuk mengevaluasi detail integrasi.
Jika Anda menggunakan injeksi SMTP, cari cara untuk mendapatkan data header dan atribut pesan ke dalam header X-MSYS-API.
Konfirmasi jika Anda dapat menggunakan proses BYOIP kami.
Perbarui DNS Anda dengan domain baru jika perlu.
Buat sampel kecil untuk menguji migrasi Anda. Anda mungkin perlu menyesuaikan konfigurasi Anda.
Naikkan volume sampai semua lalu lintas telah dimigrasikan.
Jika Anda masuk ke Kamp #1, Anda akhirnya dapat mematikannya MTA on-prem Anda setelah semua lalu lintas dimigrasikan.
Ketika merencanakan perubahan DNS untuk sistem email dengan volume tinggi, waspadalah terhadap tantangan penskalaan DNS AWS yang dapat mempengaruhi kinerja pengiriman email dalam skala besar.
Pastikan Anda berbicara dengan tim Penjualan dan Manajemen Kesuksesan Anda. Kami sudah melakukan ini sebelumnya dan dapat membantu Anda melalui proses ini dengan cepat dan biaya yang efektif.
Ketahui apakah Anda berada di Kamp #1 (mampu berpindah sepenuhnya dari On-Prem) atau Kamp #2 (Masih memerlukan beberapa MTA on-prem).
Daftar untuk akun ujicoba gratis untuk mengevaluasi detail integrasi.
Jika Anda menggunakan injeksi SMTP, cari cara untuk mendapatkan data header dan atribut pesan ke dalam header X-MSYS-API.
Konfirmasi jika Anda dapat menggunakan proses BYOIP kami.
Perbarui DNS Anda dengan domain baru jika perlu.
Buat sampel kecil untuk menguji migrasi Anda. Anda mungkin perlu menyesuaikan konfigurasi Anda.
Naikkan volume sampai semua lalu lintas telah dimigrasikan.
Jika Anda masuk ke Kamp #1, Anda akhirnya dapat mematikannya MTA on-prem Anda setelah semua lalu lintas dimigrasikan.
Ketika merencanakan perubahan DNS untuk sistem email dengan volume tinggi, waspadalah terhadap tantangan penskalaan DNS AWS yang dapat mempengaruhi kinerja pengiriman email dalam skala besar.
Pastikan Anda berbicara dengan tim Penjualan dan Manajemen Kesuksesan Anda. Kami sudah melakukan ini sebelumnya dan dapat membantu Anda melalui proses ini dengan cepat dan biaya yang efektif.
Ketahui apakah Anda berada di Kamp #1 (mampu berpindah sepenuhnya dari On-Prem) atau Kamp #2 (Masih memerlukan beberapa MTA on-prem).
Daftar untuk akun ujicoba gratis untuk mengevaluasi detail integrasi.
Jika Anda menggunakan injeksi SMTP, cari cara untuk mendapatkan data header dan atribut pesan ke dalam header X-MSYS-API.
Konfirmasi jika Anda dapat menggunakan proses BYOIP kami.
Perbarui DNS Anda dengan domain baru jika perlu.
Buat sampel kecil untuk menguji migrasi Anda. Anda mungkin perlu menyesuaikan konfigurasi Anda.
Naikkan volume sampai semua lalu lintas telah dimigrasikan.
Jika Anda masuk ke Kamp #1, Anda akhirnya dapat mematikannya MTA on-prem Anda setelah semua lalu lintas dimigrasikan.
Ketika merencanakan perubahan DNS untuk sistem email dengan volume tinggi, waspadalah terhadap tantangan penskalaan DNS AWS yang dapat mempengaruhi kinerja pengiriman email dalam skala besar.
