Przewodnik po migracji e-maili z lokalnych rozwiązań do chmury

Ptak

28 cze 2020

Email

1 min read

Przewodnik po migracji e-maili z lokalnych rozwiązań do chmury

Najważniejsze informacje

    • Bird Cloud został zbudowany na sprawdzonym silniku Momentum MTA, oferując klientom wydajność dojrzałego systemu on-prem z dodatkowymi korzyściami nowoczesnej platformy API e-mail w chmurze.

    • Wielu starszych nadawców nadal polega na Momentum lub PowerMTA, a Bird zapewnia jasną ścieżkę migracji dla obu — pełna migracja do chmury lub hybrydowe routowanie przez węzły on-prem.

    • Migracja wymaga zrozumienia, czy zamierzasz:

      1. eliminować całą infrastrukturę on-prem, czy

      2. kontynuować korzystanie ze swojego MTA do wstępnego przetwarzania, routowania lub ograniczeń związanych z dziedzictwem.

    • Bird akceptuje tylko uwierzytelniony wstrzyknięcie SMTP przez porty 587 lub 2525 (zalecane jest silne TLS). Wstrzyknięcie API REST jest również dostępne do bezpośredniej dostawy opartej na JSON.

    • Opcja nr 1 (“zimny indyk”) umożliwia całkowite wycofanie MTAs poprzez wysyłanie bezpośrednio do Bird za pomocą SMTP lub REST, co eliminuje złożoność i modernizuje architekturę wysyłki.

    • Opcja nr 2 obsługuje środowiska hybrydowe — routowanie wybranych strumieni z Momentum lub PMTA do Bird przez skonfigurowanie domen wyjściowych z SMTP_Auth do Bird.

    • Konfiguracje PowerMTA i Momentum mogą bezpiecznie przesyłać ruch do Bird z wykorzystaniem TLS, SMTP_Auth opartego na kluczu API i definicji tras.

    • Klienci używający zaawansowanych skryptów Lua, substytucji inline lub filtracji przed dostawą mogą pozostać hybrydowi, dopóki logika nie zostanie przeorganizowana w systemach upstream.

    • Bird obsługuje BYOIP (Bring Your Own IP) dla klientów z ciągłym blokiem /24, umożliwiając zachowanie oceny reputacji IP oraz pominięcie pełnego rozgrzewania IP.

    • Dla użytkowników nie korzystających z BYOIP, Bird zapewnia automatyczne rozgrzewanie IP i zaleca stopniową migrację — zaczynając od małych objętości, a następnie stopniowo zwiększając ruch.

    • Poprawne skonfigurowanie domen (DKIM, SPF, DMARC, domeny bounce, domeny śledzące) jest kluczowe dla zgodności i płynnego współistnienia podczas migracji.

    • Bird zapewnia dane o zdarzeniach w czasie rzeczywistym za pomocą webhooków lub Events API, co umożliwia automatyzację downstream, przepływy ETL i rekonstrukcję w stylu logów, jeśli zajdzie taka potrzeba.

Podsumowanie pytań i odpowiedzi

  • Jakie są dwa główne scenariusze migracji?

    Albo całkowicie wyłącz wszystkie lokalne MTAs (Opcja #1), albo utrzymuj hybrydowe ustawienie, w którym część ruchu jest kierowana przez Momentum/PMTA przed dotarciem do Birda (Opcja #2).

  • Co decyduje o tym, czy wybierzesz opcję nr 1 czy opcję nr 2?

    Twoje poleganie na skryptach Lua, logice wstępnej obróbki, przepisach wiadomości, wymaganiach dotyczących bezpieczeństwa lub generatorach, które nie mogą wysyłać autoryzowanego ruchu przez port 587.

  • Czy Bird akceptuje wstrzyknięcia SMTP przez port 25?

    Nie—Bird wymaga wstrzykiwania SMTP przez port 587 lub 2525, uwierzytelnionego przy użyciu SMTP_Auth.

  • Czy TLS jest wymagany?

    Nie jest to ściśle wymagane, ale zdecydowanie zalecane do bezpiecznego wstrzykiwania wiadomości zarówno z generatorów, jak i lokalnych MTA.

  • Czy nadawcy mogą używać interfejsu API REST zamiast SMTP?

    Tak — nadawcy mogą wysyłać ładunki JSON za pośrednictwem Transmissions REST API, często upraszczając przepływy pracy i eliminując potrzebę generowania surowych wiadomości SMTP.

  • Czym jest program BYOIP Bird?

    Proces, który pozwala klientom posiadającym ciągły blok /24 na migrację ich istniejących IP do Bird, zachowując reputację i omijając rozgrzewanie.

  • Co jeśli BYOIP nie jest opcją?

    Użyj nowych domen wysyłkowych (np. sp.twojadomena.com), uruchom oba środowiska równolegle i polegaj na automatycznym podgrzewaniu adresów IP przez Bird.

  • Jak przekierować tylko wybrane strumienie przez Bird w hybrydowej konfiguracji?

    Konfigurując zewnętrzne domeny (Momentum) lub konfiguracje rollup/VMTAs (PowerMTA), które uwierzytelniają i dostarczają do punktu końcowego SMTP Bird.

  • Jakie zmiany metadanych są wymagane przy wstrzykiwaniu za pomocą SMTP?

    Dodaj nagłówek X-MSYS-API zawierający atrybuty takie jak ip_pool, campaign oraz wszelkie niestandardowe metadane, które były wcześniej obsługiwane przez X-Headers.

  • Co powinno być skonfigurowane w DNS przed migracją?

    Rekordy DKIM, SPF, DMARC, domeny zwrotne i domeny śledzące, aby zapewnić zgodność domen oraz zmniejszyć ryzyko dostarczalności podczas przejścia.

  • Jak należy przenieść ruch do Bird?

    Stopniowo: zacznij od małego strumienia, następnie 10%, potem 20%, zwiększając codziennie, aż cały ruch zostanie przeniesiony - podobnie jak w najlepszych praktykach podgrzewania IP.

  • Jak nadawcy mogą zbierać dane dotyczące dostawy i zaangażowania po migracji?

    Korzystając z systemu webhooków w czasie rzeczywistym Bird lub API zdarzeń; kolekcjonery webhooków można szybko zbudować i zasilać w dół systemy przechowywania lub ETL.

Tak wiele razy słyszymy pytanie: „Czy masz jakiś podręcznik, który przedstawia proces migracji z instalacji na miejscu do Bird”?

Oczywiście, że tak. Czytaj dalej.

Najpierw trochę tła. Usługa Bird Cloud została stworzona w 2014 roku w wyniku ogromnego sukcesu rozwiązania On-Premises Momentum MTA. Momentum znajduje się w sercu Bird Cloud, zapewniając dostarczanie z dużą prędkością i kształtowanie ruchu dla tysięcy klientów korzystających z usługi w chmurze. Z tego powodu Momentum otrzymuje dużą część naszej uwagi inżynieryjnej, ale wyniki tej pracy są często ukryte w poprawach wydajności, które nie zdobywają dużej uwagi w mediach. Klienci Momentum widzą korzyści z tej pracy za każdym razem, gdy publikowana jest nowa publiczna wersja Momentum.

To NIE oznacza, że Bird to po prostu „Momentum w chmurze”. MessageBird to znacznie więcej i może mieć dodatkowe korzyści dla klientów, którzy zdecydują się na migrację lub korzystanie z nich w podejściu hybrydowym. Korzyści te wynikają z naszej nowoczesnej architektury API e-mail opartej na chmurze, która zapewnia możliwości niedostępne w tradycyjnych rozwiązaniach na miejscu. Ponadto, ułatwiliśmy klientom PowerMTA migrację lub korzystanie z PowerMTA z Bird w konfiguracji hybrydowej. Reszta tego dokumentu szczegółowo opisze, jak możesz przenieść swoje strumienie wiadomości z Momentum lub PowerMTA do usługi Bird Cloud.

Istnieją naprawdę dwa oddzielne scenariusze do rozważenia podczas migracji do Bird z Momentum lub PowerMTA.

  1. Jesteś gotowy, aby całkowicie opuścić świat na miejscu, zamknąć swoje fizyczne centra danych i przestać bezpośrednio zarządzać jakimkolwiek lokalnym MTA. Oznacza to eliminację Momentum lub PowerMTA z Twojej implementacji i bezpośrednie wysyłanie wiadomości do SparkPost w celu obsługi wiadomości. Przed wycofaniem infrastruktury na miejscu upewnij się, że masz kompleksowe kopie zapasowe bazy danych wszystkich krytycznych systemów, szczególnie jeśli korzystasz z baz danych PostgreSQL, które zawierają ważne dane historyczne lub konfiguracje.

  2. Masz powód, aby zachować pewne lokalne zasoby z różnych powodów. Niektóre możliwości mogą obejmować:

  • sukcesywne strumienie dostawy, które wymagają wstępnego przetwarzania w Momentum

  • dzielenie pojemności dla potrzeb awaryjnego lub rozdzielczego przywracania

  • wspieranie klientów korzystających z PMTA podczas przesuwania nowych klientów do SparkPost

 …a następnie chcesz przekazać pozostałe wiadomości do Bird w celu dalszej obsługi wiadomości.

W obu sytuacjach musisz być świadomy, że Bird akceptuje tylko wiadomości SMTP do dostarczania, które są przesyłane przez port 587 lub 2525 i używają SMTP_Auth z określoną nazwą użytkownika i hasłem (Zobacz dokumentację SMTP tutaj). Zdecydowanie zalecamy również korzystanie z połączenia TLS, ale nie jest to ściśle wymagane. Jeśli całkowicie zastępujesz swoją warstwę MTA (scenariusz 1), wtedy możesz także rozważyć użycie REST API Transmissions, które może akceptować wiadomości przez połączenia HTTPS. Dokumentacja na temat tego API jest tutaj.

Dla organizacji utrzymujących lokalną infrastrukturę, która wymaga bezpiecznych możliwości e-mail, nasza instrukcja implementacji S/MIME dla PowerMTA i Momentum zawiera szczegółowe instrukcje dotyczące konfiguracji dostarczania zaszyfrowanych wiadomości e-mail.

Tak wiele razy słyszymy pytanie: „Czy masz jakiś podręcznik, który przedstawia proces migracji z instalacji na miejscu do Bird”?

Oczywiście, że tak. Czytaj dalej.

Najpierw trochę tła. Usługa Bird Cloud została stworzona w 2014 roku w wyniku ogromnego sukcesu rozwiązania On-Premises Momentum MTA. Momentum znajduje się w sercu Bird Cloud, zapewniając dostarczanie z dużą prędkością i kształtowanie ruchu dla tysięcy klientów korzystających z usługi w chmurze. Z tego powodu Momentum otrzymuje dużą część naszej uwagi inżynieryjnej, ale wyniki tej pracy są często ukryte w poprawach wydajności, które nie zdobywają dużej uwagi w mediach. Klienci Momentum widzą korzyści z tej pracy za każdym razem, gdy publikowana jest nowa publiczna wersja Momentum.

To NIE oznacza, że Bird to po prostu „Momentum w chmurze”. MessageBird to znacznie więcej i może mieć dodatkowe korzyści dla klientów, którzy zdecydują się na migrację lub korzystanie z nich w podejściu hybrydowym. Korzyści te wynikają z naszej nowoczesnej architektury API e-mail opartej na chmurze, która zapewnia możliwości niedostępne w tradycyjnych rozwiązaniach na miejscu. Ponadto, ułatwiliśmy klientom PowerMTA migrację lub korzystanie z PowerMTA z Bird w konfiguracji hybrydowej. Reszta tego dokumentu szczegółowo opisze, jak możesz przenieść swoje strumienie wiadomości z Momentum lub PowerMTA do usługi Bird Cloud.

Istnieją naprawdę dwa oddzielne scenariusze do rozważenia podczas migracji do Bird z Momentum lub PowerMTA.

  1. Jesteś gotowy, aby całkowicie opuścić świat na miejscu, zamknąć swoje fizyczne centra danych i przestać bezpośrednio zarządzać jakimkolwiek lokalnym MTA. Oznacza to eliminację Momentum lub PowerMTA z Twojej implementacji i bezpośrednie wysyłanie wiadomości do SparkPost w celu obsługi wiadomości. Przed wycofaniem infrastruktury na miejscu upewnij się, że masz kompleksowe kopie zapasowe bazy danych wszystkich krytycznych systemów, szczególnie jeśli korzystasz z baz danych PostgreSQL, które zawierają ważne dane historyczne lub konfiguracje.

  2. Masz powód, aby zachować pewne lokalne zasoby z różnych powodów. Niektóre możliwości mogą obejmować:

  • sukcesywne strumienie dostawy, które wymagają wstępnego przetwarzania w Momentum

  • dzielenie pojemności dla potrzeb awaryjnego lub rozdzielczego przywracania

  • wspieranie klientów korzystających z PMTA podczas przesuwania nowych klientów do SparkPost

 …a następnie chcesz przekazać pozostałe wiadomości do Bird w celu dalszej obsługi wiadomości.

W obu sytuacjach musisz być świadomy, że Bird akceptuje tylko wiadomości SMTP do dostarczania, które są przesyłane przez port 587 lub 2525 i używają SMTP_Auth z określoną nazwą użytkownika i hasłem (Zobacz dokumentację SMTP tutaj). Zdecydowanie zalecamy również korzystanie z połączenia TLS, ale nie jest to ściśle wymagane. Jeśli całkowicie zastępujesz swoją warstwę MTA (scenariusz 1), wtedy możesz także rozważyć użycie REST API Transmissions, które może akceptować wiadomości przez połączenia HTTPS. Dokumentacja na temat tego API jest tutaj.

Dla organizacji utrzymujących lokalną infrastrukturę, która wymaga bezpiecznych możliwości e-mail, nasza instrukcja implementacji S/MIME dla PowerMTA i Momentum zawiera szczegółowe instrukcje dotyczące konfiguracji dostarczania zaszyfrowanych wiadomości e-mail.

Tak wiele razy słyszymy pytanie: „Czy masz jakiś podręcznik, który przedstawia proces migracji z instalacji na miejscu do Bird”?

Oczywiście, że tak. Czytaj dalej.

Najpierw trochę tła. Usługa Bird Cloud została stworzona w 2014 roku w wyniku ogromnego sukcesu rozwiązania On-Premises Momentum MTA. Momentum znajduje się w sercu Bird Cloud, zapewniając dostarczanie z dużą prędkością i kształtowanie ruchu dla tysięcy klientów korzystających z usługi w chmurze. Z tego powodu Momentum otrzymuje dużą część naszej uwagi inżynieryjnej, ale wyniki tej pracy są często ukryte w poprawach wydajności, które nie zdobywają dużej uwagi w mediach. Klienci Momentum widzą korzyści z tej pracy za każdym razem, gdy publikowana jest nowa publiczna wersja Momentum.

To NIE oznacza, że Bird to po prostu „Momentum w chmurze”. MessageBird to znacznie więcej i może mieć dodatkowe korzyści dla klientów, którzy zdecydują się na migrację lub korzystanie z nich w podejściu hybrydowym. Korzyści te wynikają z naszej nowoczesnej architektury API e-mail opartej na chmurze, która zapewnia możliwości niedostępne w tradycyjnych rozwiązaniach na miejscu. Ponadto, ułatwiliśmy klientom PowerMTA migrację lub korzystanie z PowerMTA z Bird w konfiguracji hybrydowej. Reszta tego dokumentu szczegółowo opisze, jak możesz przenieść swoje strumienie wiadomości z Momentum lub PowerMTA do usługi Bird Cloud.

Istnieją naprawdę dwa oddzielne scenariusze do rozważenia podczas migracji do Bird z Momentum lub PowerMTA.

  1. Jesteś gotowy, aby całkowicie opuścić świat na miejscu, zamknąć swoje fizyczne centra danych i przestać bezpośrednio zarządzać jakimkolwiek lokalnym MTA. Oznacza to eliminację Momentum lub PowerMTA z Twojej implementacji i bezpośrednie wysyłanie wiadomości do SparkPost w celu obsługi wiadomości. Przed wycofaniem infrastruktury na miejscu upewnij się, że masz kompleksowe kopie zapasowe bazy danych wszystkich krytycznych systemów, szczególnie jeśli korzystasz z baz danych PostgreSQL, które zawierają ważne dane historyczne lub konfiguracje.

  2. Masz powód, aby zachować pewne lokalne zasoby z różnych powodów. Niektóre możliwości mogą obejmować:

  • sukcesywne strumienie dostawy, które wymagają wstępnego przetwarzania w Momentum

  • dzielenie pojemności dla potrzeb awaryjnego lub rozdzielczego przywracania

  • wspieranie klientów korzystających z PMTA podczas przesuwania nowych klientów do SparkPost

 …a następnie chcesz przekazać pozostałe wiadomości do Bird w celu dalszej obsługi wiadomości.

W obu sytuacjach musisz być świadomy, że Bird akceptuje tylko wiadomości SMTP do dostarczania, które są przesyłane przez port 587 lub 2525 i używają SMTP_Auth z określoną nazwą użytkownika i hasłem (Zobacz dokumentację SMTP tutaj). Zdecydowanie zalecamy również korzystanie z połączenia TLS, ale nie jest to ściśle wymagane. Jeśli całkowicie zastępujesz swoją warstwę MTA (scenariusz 1), wtedy możesz także rozważyć użycie REST API Transmissions, które może akceptować wiadomości przez połączenia HTTPS. Dokumentacja na temat tego API jest tutaj.

Dla organizacji utrzymujących lokalną infrastrukturę, która wymaga bezpiecznych możliwości e-mail, nasza instrukcja implementacji S/MIME dla PowerMTA i Momentum zawiera szczegółowe instrukcje dotyczące konfiguracji dostarczania zaszyfrowanych wiadomości e-mail.

Którą opcję mam wybrać?

Aby ustalić, czy jesteś w opcji #1 czy opcji #2, rozważ te czynniki:

Opcja

Najlepsza, jeśli

Kluczowy wymóg

Komplikacja

Opcja #1: Pełna migracja do chmury

Można usunąć wszystkie lokalne MTA

SMTP Auth na 587/2525 lub REST API

Wymaga refaktoryzacji zaawansowanej logiki lokalnej

Opcja #2: Hybrydowe routowanie

Wymagana wstępna obróbka lub wsparcie dla starszych systemów

Momentum lub PowerMTA pozostaje online

Dodana złożoność operacyjna


  • Czy używasz silnika skryptowego Lua w Momentum do czegokolwiek bardziej skomplikowanego niż routowanie wiadomości?

    • Lua to wszechstronne narzędzie skryptowe do manipulacji wiadomościami w locie, ale przeważająca większość naszych użytkowników używa go tylko do wyboru wiązania do dostarczania.  Jeśli tak jest, możesz zmodyfikować swój kod generacji, aby dodać atrybut ip_pool do nagłówka X-MSYS-API i pozwolić Bird przypisać trasę za Ciebie. 

    • Jeśli używasz Lua do robienia bardziej skomplikowanych rzeczy, takich jak filtrowanie treści, przekształcenia Mail_From, czy obliczenia kadencji wiadomości, i nie jest możliwe przeniesienie tej logiki do aplikacji wstrzykującej, warto rozważyć przejście do obozu opcji #2.

  • Czy Twój system generacji jest w stanie wysyłać wiadomości przez port 587 z użyciem TLS i SMTP_Auth?

    • Niektóre systemy zarządzania kampaniami mogą wysyłać wiadomości tylko przez port 25 w postaci niezaszyfrowanej. To powoduje problem z bezpieczeństwem dla Bird, więc warto rozważyć opcję #2

  • Czy używasz składni substytucji PowerMTA lub innych modyfikacji wiadomości w locie?

    • Jeśli możesz przenieść tę funkcję do swoich generatorów lub użyć Języka Szablonów Bird, to nadal możesz używać opcji 1, ale inaczej być może będziesz musiał pomyśleć o utrzymaniu węzła PMTA online do tej modyfikacji wiadomości przed jej wysłaniem do Bird w celu dostarczenia.

  • Czy potrzebujesz skanowania AV/AS przed wstrzyknięciem? Choć jest to możliwe w Momentum i PowerMTA, eBird zakłada, że już przeprowadziłeś wszystkie te kontrole.  Może warto to zrobić przed wstrzyknięciem.

Bez względu na to, którą drogę wybierzesz, z pewnością wpłynie to na Twoje relacje handlowe.  Jak możesz sobie wyobrazić, to nie jest nasza pierwsza wędrówka. Pamiętaj, aby zaangażować swojego Menedżera Konta Komercyjnego i Menedżera Sukcesu Klienta, abyśmy mogli pomóc Ci w szczegółach i upewnić się, że otrzymujesz najlepszą wartość za swoje pieniądze.

Aby ustalić, czy jesteś w opcji #1 czy opcji #2, rozważ te czynniki:

Opcja

Najlepsza, jeśli

Kluczowy wymóg

Komplikacja

Opcja #1: Pełna migracja do chmury

Można usunąć wszystkie lokalne MTA

SMTP Auth na 587/2525 lub REST API

Wymaga refaktoryzacji zaawansowanej logiki lokalnej

Opcja #2: Hybrydowe routowanie

Wymagana wstępna obróbka lub wsparcie dla starszych systemów

Momentum lub PowerMTA pozostaje online

Dodana złożoność operacyjna


  • Czy używasz silnika skryptowego Lua w Momentum do czegokolwiek bardziej skomplikowanego niż routowanie wiadomości?

    • Lua to wszechstronne narzędzie skryptowe do manipulacji wiadomościami w locie, ale przeważająca większość naszych użytkowników używa go tylko do wyboru wiązania do dostarczania.  Jeśli tak jest, możesz zmodyfikować swój kod generacji, aby dodać atrybut ip_pool do nagłówka X-MSYS-API i pozwolić Bird przypisać trasę za Ciebie. 

    • Jeśli używasz Lua do robienia bardziej skomplikowanych rzeczy, takich jak filtrowanie treści, przekształcenia Mail_From, czy obliczenia kadencji wiadomości, i nie jest możliwe przeniesienie tej logiki do aplikacji wstrzykującej, warto rozważyć przejście do obozu opcji #2.

  • Czy Twój system generacji jest w stanie wysyłać wiadomości przez port 587 z użyciem TLS i SMTP_Auth?

    • Niektóre systemy zarządzania kampaniami mogą wysyłać wiadomości tylko przez port 25 w postaci niezaszyfrowanej. To powoduje problem z bezpieczeństwem dla Bird, więc warto rozważyć opcję #2

  • Czy używasz składni substytucji PowerMTA lub innych modyfikacji wiadomości w locie?

    • Jeśli możesz przenieść tę funkcję do swoich generatorów lub użyć Języka Szablonów Bird, to nadal możesz używać opcji 1, ale inaczej być może będziesz musiał pomyśleć o utrzymaniu węzła PMTA online do tej modyfikacji wiadomości przed jej wysłaniem do Bird w celu dostarczenia.

  • Czy potrzebujesz skanowania AV/AS przed wstrzyknięciem? Choć jest to możliwe w Momentum i PowerMTA, eBird zakłada, że już przeprowadziłeś wszystkie te kontrole.  Może warto to zrobić przed wstrzyknięciem.

Bez względu na to, którą drogę wybierzesz, z pewnością wpłynie to na Twoje relacje handlowe.  Jak możesz sobie wyobrazić, to nie jest nasza pierwsza wędrówka. Pamiętaj, aby zaangażować swojego Menedżera Konta Komercyjnego i Menedżera Sukcesu Klienta, abyśmy mogli pomóc Ci w szczegółach i upewnić się, że otrzymujesz najlepszą wartość za swoje pieniądze.

Aby ustalić, czy jesteś w opcji #1 czy opcji #2, rozważ te czynniki:

Opcja

Najlepsza, jeśli

Kluczowy wymóg

Komplikacja

Opcja #1: Pełna migracja do chmury

Można usunąć wszystkie lokalne MTA

SMTP Auth na 587/2525 lub REST API

Wymaga refaktoryzacji zaawansowanej logiki lokalnej

Opcja #2: Hybrydowe routowanie

Wymagana wstępna obróbka lub wsparcie dla starszych systemów

Momentum lub PowerMTA pozostaje online

Dodana złożoność operacyjna


  • Czy używasz silnika skryptowego Lua w Momentum do czegokolwiek bardziej skomplikowanego niż routowanie wiadomości?

    • Lua to wszechstronne narzędzie skryptowe do manipulacji wiadomościami w locie, ale przeważająca większość naszych użytkowników używa go tylko do wyboru wiązania do dostarczania.  Jeśli tak jest, możesz zmodyfikować swój kod generacji, aby dodać atrybut ip_pool do nagłówka X-MSYS-API i pozwolić Bird przypisać trasę za Ciebie. 

    • Jeśli używasz Lua do robienia bardziej skomplikowanych rzeczy, takich jak filtrowanie treści, przekształcenia Mail_From, czy obliczenia kadencji wiadomości, i nie jest możliwe przeniesienie tej logiki do aplikacji wstrzykującej, warto rozważyć przejście do obozu opcji #2.

  • Czy Twój system generacji jest w stanie wysyłać wiadomości przez port 587 z użyciem TLS i SMTP_Auth?

    • Niektóre systemy zarządzania kampaniami mogą wysyłać wiadomości tylko przez port 25 w postaci niezaszyfrowanej. To powoduje problem z bezpieczeństwem dla Bird, więc warto rozważyć opcję #2

  • Czy używasz składni substytucji PowerMTA lub innych modyfikacji wiadomości w locie?

    • Jeśli możesz przenieść tę funkcję do swoich generatorów lub użyć Języka Szablonów Bird, to nadal możesz używać opcji 1, ale inaczej być może będziesz musiał pomyśleć o utrzymaniu węzła PMTA online do tej modyfikacji wiadomości przed jej wysłaniem do Bird w celu dostarczenia.

  • Czy potrzebujesz skanowania AV/AS przed wstrzyknięciem? Choć jest to możliwe w Momentum i PowerMTA, eBird zakłada, że już przeprowadziłeś wszystkie te kontrole.  Może warto to zrobić przed wstrzyknięciem.

Bez względu na to, którą drogę wybierzesz, z pewnością wpłynie to na Twoje relacje handlowe.  Jak możesz sobie wyobrazić, to nie jest nasza pierwsza wędrówka. Pamiętaj, aby zaangażować swojego Menedżera Konta Komercyjnego i Menedżera Sukcesu Klienta, abyśmy mogli pomóc Ci w szczegółach i upewnić się, że otrzymujesz najlepszą wartość za swoje pieniądze.

Dla opcji nr 1 oboz (idąc „na zimno”):

Załóżmy, że zgadzasz się na opcję 1 i jesteś gotów zamknąć swoje lokalne MTA oraz zdecydowałeś się nadal korzystać z metody wstrzykiwania SMTP, nie zmieniając w ogóle systemów tworzenia wiadomości.  Twoje systemy generacyjne powinny tworzyć w pełni sformatowaną wiadomość SMTP, a następnie przekazać ją do Bird przez TLS, używając SMTP_AUTH, gdzie nazwa użytkownika i hasło są opisane na tej stronie. Pamiętaj, że "hasło" to klucz API, który generujesz w swoim koncie Bird z włączoną opcją dostawy SMTP.

Jeśli jesteś w obozie Opcja #1, rozważ przejście do REST API bezpośrednio z systemu generacyjnego. W większości przypadków zauważamy, że systemy przetwarzające klientów już korzystają z JSON przez HTTP i muszą konwertować na SMTP przed wstrzyknięciem. Możesz pominąć ten krok i wysłać to do nas bezpośrednio jako sformatowany ładunek REST w formacie JSON.

Jeśli wybierzesz wstrzykiwanie za pomocą REST API, być może będziesz musiał nieco zmienić swój system tworzenia treści, ale może się to opłacić.  Możesz dowiedzieć się więcej tutaj.

Jednym z największych zmartwień dużych ESP jest Migracja związana z podgrzewaniem IP. Zazwyczaj spędzili wiele lat na starannym zarządzaniu swoim zapasem adresów IP, więc myśl o porzuceniu tej pracy jest bolesna. Bird opracował proces Bring Your Own IP (BYOIP), który rozwiązuje ten problem. Jeśli masz przynajmniej jeden ciągły blok /24 CIDR, Bird może wykorzystać te istniejące adresy IP do dostawy, co oszczędza Ci bólu związanego z koniecznością ich ponownego podgrzewania. Jeśli możesz skorzystać z tej opcji, możesz pominąć sekcję o podgrzewaniu IP.

Jeśli czujesz, że jesteś gotowy, przeskocz do „Jak to zrealizować”

Załóżmy, że zgadzasz się na opcję 1 i jesteś gotów zamknąć swoje lokalne MTA oraz zdecydowałeś się nadal korzystać z metody wstrzykiwania SMTP, nie zmieniając w ogóle systemów tworzenia wiadomości.  Twoje systemy generacyjne powinny tworzyć w pełni sformatowaną wiadomość SMTP, a następnie przekazać ją do Bird przez TLS, używając SMTP_AUTH, gdzie nazwa użytkownika i hasło są opisane na tej stronie. Pamiętaj, że "hasło" to klucz API, który generujesz w swoim koncie Bird z włączoną opcją dostawy SMTP.

Jeśli jesteś w obozie Opcja #1, rozważ przejście do REST API bezpośrednio z systemu generacyjnego. W większości przypadków zauważamy, że systemy przetwarzające klientów już korzystają z JSON przez HTTP i muszą konwertować na SMTP przed wstrzyknięciem. Możesz pominąć ten krok i wysłać to do nas bezpośrednio jako sformatowany ładunek REST w formacie JSON.

Jeśli wybierzesz wstrzykiwanie za pomocą REST API, być może będziesz musiał nieco zmienić swój system tworzenia treści, ale może się to opłacić.  Możesz dowiedzieć się więcej tutaj.

Jednym z największych zmartwień dużych ESP jest Migracja związana z podgrzewaniem IP. Zazwyczaj spędzili wiele lat na starannym zarządzaniu swoim zapasem adresów IP, więc myśl o porzuceniu tej pracy jest bolesna. Bird opracował proces Bring Your Own IP (BYOIP), który rozwiązuje ten problem. Jeśli masz przynajmniej jeden ciągły blok /24 CIDR, Bird może wykorzystać te istniejące adresy IP do dostawy, co oszczędza Ci bólu związanego z koniecznością ich ponownego podgrzewania. Jeśli możesz skorzystać z tej opcji, możesz pominąć sekcję o podgrzewaniu IP.

Jeśli czujesz, że jesteś gotowy, przeskocz do „Jak to zrealizować”

Załóżmy, że zgadzasz się na opcję 1 i jesteś gotów zamknąć swoje lokalne MTA oraz zdecydowałeś się nadal korzystać z metody wstrzykiwania SMTP, nie zmieniając w ogóle systemów tworzenia wiadomości.  Twoje systemy generacyjne powinny tworzyć w pełni sformatowaną wiadomość SMTP, a następnie przekazać ją do Bird przez TLS, używając SMTP_AUTH, gdzie nazwa użytkownika i hasło są opisane na tej stronie. Pamiętaj, że "hasło" to klucz API, który generujesz w swoim koncie Bird z włączoną opcją dostawy SMTP.

Jeśli jesteś w obozie Opcja #1, rozważ przejście do REST API bezpośrednio z systemu generacyjnego. W większości przypadków zauważamy, że systemy przetwarzające klientów już korzystają z JSON przez HTTP i muszą konwertować na SMTP przed wstrzyknięciem. Możesz pominąć ten krok i wysłać to do nas bezpośrednio jako sformatowany ładunek REST w formacie JSON.

Jeśli wybierzesz wstrzykiwanie za pomocą REST API, być może będziesz musiał nieco zmienić swój system tworzenia treści, ale może się to opłacić.  Możesz dowiedzieć się więcej tutaj.

Jednym z największych zmartwień dużych ESP jest Migracja związana z podgrzewaniem IP. Zazwyczaj spędzili wiele lat na starannym zarządzaniu swoim zapasem adresów IP, więc myśl o porzuceniu tej pracy jest bolesna. Bird opracował proces Bring Your Own IP (BYOIP), który rozwiązuje ten problem. Jeśli masz przynajmniej jeden ciągły blok /24 CIDR, Bird może wykorzystać te istniejące adresy IP do dostawy, co oszczędza Ci bólu związanego z koniecznością ich ponownego podgrzewania. Jeśli możesz skorzystać z tej opcji, możesz pominąć sekcję o podgrzewaniu IP.

Jeśli czujesz, że jesteś gotowy, przeskocz do „Jak to zrealizować”

Wykorzystując Opcję #2 (wstępne przetwarzanie na miejscu):

Jeśli jednak jesteś w zespole Opcja #2, wtedy będziesz chciał dodać pewne zmiany konfiguracyjne do Twojego wdrożenia. Najmniej bolesny sposób na migrację niektórych wybranych strumieni wiadomości z Momentum lub PMTA do Bird przy jednoczesnym korzystaniu z wstrzyknięcia SMTP z systemów generacyjnych polega na dodaniu specjalnej trasy w Twojej konfiguracji.

Dla Momentum:

  1. Ustaw wersję Momentum > 3.6.23. 

  2. Zainstaluj ważny certyfikat SSL i otwórz port 587, aby Momentum mogło komunikować się z Bird. Skonfiguruj domenę wyjściową, aby móc przesłać wiadomość przez Momentum do Bird. 

  3. W poniższej konfiguracji każda wiadomość trafiająca na tę konfigurację będzie kierowana do smtp.sparkpostmail.com za pomocą portu 587 oraz SMTP_Auth z nazwą użytkownika i hasłem zdefiniowanymi tam.

    outbound_smtp_auth { }
    Keep_Message_Dicts_In_Memory = true
    Domain "smtp.sparkpostmail.com" {
      Remote_SMTP_Port = "587"
      Outbound_SMTP_AUTH_Type = "LOGIN"
      Outbound_SMTP_AUTH_user = "SMTP_Injection"
      Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce"
    }


  4. Skonfiguruj powiązania, które chcesz przekazywać przez MessageBird z TLS i kieruj je do domeny, którą zdefiniowałeś powyżej.

    Uwaga: TLS nie jest ściśle wymagany, ale jest silnym zaleceniem. Jeśli TLS nie jest możliwy z jakiegoś powodu, również silnym zaleceniem jest biała lista kluczy API.

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

Dla PowerMTA:

  1. Ustaw wersję PowerMTA > 4.5.0

  2. Zainstaluj ważny certyfikat SSL i otwórz port 587, aby PowerMTA mógł komunikować się z Bird.

  3. Skonfiguruj ścieżkę domeny wyjściowej, aby móc przesłać wiadomość przez PowerMTA do Bird. W poniższej konfiguracji każda wiadomość trafiająca na tę konfigurację będzie kierowana do smtp.sparkpostmail.com za pomocą portu 587 oraz SMTP_Auth z nazwą użytkownika i hasłem zdefiniowanymi tam.  W PowerMTA to również tutaj możesz ustawić TLS. Uwaga, to jest również dokumentowane bardziej szczegółowo tutaj 

<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. Skonfiguruj VMTAs, które chcesz przekazywać przez Bird z konfiguracją {sparkpost} rollup, którą zdefiniowałeś powyżej.

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to {sparkpost}
  </domain>
</virtual-mta>

Gdy dokonasz tych zmian konfiguracyjnych, wszystkie wiadomości wysyłane do wybranej "wiążącej" lub "VMTA" powinny być automatycznie kierowane przez Bird w celu dostarczenia.  

Jeśli jednak jesteś w zespole Opcja #2, wtedy będziesz chciał dodać pewne zmiany konfiguracyjne do Twojego wdrożenia. Najmniej bolesny sposób na migrację niektórych wybranych strumieni wiadomości z Momentum lub PMTA do Bird przy jednoczesnym korzystaniu z wstrzyknięcia SMTP z systemów generacyjnych polega na dodaniu specjalnej trasy w Twojej konfiguracji.

Dla Momentum:

  1. Ustaw wersję Momentum > 3.6.23. 

  2. Zainstaluj ważny certyfikat SSL i otwórz port 587, aby Momentum mogło komunikować się z Bird. Skonfiguruj domenę wyjściową, aby móc przesłać wiadomość przez Momentum do Bird. 

  3. W poniższej konfiguracji każda wiadomość trafiająca na tę konfigurację będzie kierowana do smtp.sparkpostmail.com za pomocą portu 587 oraz SMTP_Auth z nazwą użytkownika i hasłem zdefiniowanymi tam.

    outbound_smtp_auth { }
    Keep_Message_Dicts_In_Memory = true
    Domain "smtp.sparkpostmail.com" {
      Remote_SMTP_Port = "587"
      Outbound_SMTP_AUTH_Type = "LOGIN"
      Outbound_SMTP_AUTH_user = "SMTP_Injection"
      Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce"
    }


  4. Skonfiguruj powiązania, które chcesz przekazywać przez MessageBird z TLS i kieruj je do domeny, którą zdefiniowałeś powyżej.

    Uwaga: TLS nie jest ściśle wymagany, ale jest silnym zaleceniem. Jeśli TLS nie jest możliwy z jakiegoś powodu, również silnym zaleceniem jest biała lista kluczy API.

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

Dla PowerMTA:

  1. Ustaw wersję PowerMTA > 4.5.0

  2. Zainstaluj ważny certyfikat SSL i otwórz port 587, aby PowerMTA mógł komunikować się z Bird.

  3. Skonfiguruj ścieżkę domeny wyjściowej, aby móc przesłać wiadomość przez PowerMTA do Bird. W poniższej konfiguracji każda wiadomość trafiająca na tę konfigurację będzie kierowana do smtp.sparkpostmail.com za pomocą portu 587 oraz SMTP_Auth z nazwą użytkownika i hasłem zdefiniowanymi tam.  W PowerMTA to również tutaj możesz ustawić TLS. Uwaga, to jest również dokumentowane bardziej szczegółowo tutaj 

<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. Skonfiguruj VMTAs, które chcesz przekazywać przez Bird z konfiguracją {sparkpost} rollup, którą zdefiniowałeś powyżej.

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to {sparkpost}
  </domain>
</virtual-mta>

Gdy dokonasz tych zmian konfiguracyjnych, wszystkie wiadomości wysyłane do wybranej "wiążącej" lub "VMTA" powinny być automatycznie kierowane przez Bird w celu dostarczenia.  

Jeśli jednak jesteś w zespole Opcja #2, wtedy będziesz chciał dodać pewne zmiany konfiguracyjne do Twojego wdrożenia. Najmniej bolesny sposób na migrację niektórych wybranych strumieni wiadomości z Momentum lub PMTA do Bird przy jednoczesnym korzystaniu z wstrzyknięcia SMTP z systemów generacyjnych polega na dodaniu specjalnej trasy w Twojej konfiguracji.

Dla Momentum:

  1. Ustaw wersję Momentum > 3.6.23. 

  2. Zainstaluj ważny certyfikat SSL i otwórz port 587, aby Momentum mogło komunikować się z Bird. Skonfiguruj domenę wyjściową, aby móc przesłać wiadomość przez Momentum do Bird. 

  3. W poniższej konfiguracji każda wiadomość trafiająca na tę konfigurację będzie kierowana do smtp.sparkpostmail.com za pomocą portu 587 oraz SMTP_Auth z nazwą użytkownika i hasłem zdefiniowanymi tam.

    outbound_smtp_auth { }
    Keep_Message_Dicts_In_Memory = true
    Domain "smtp.sparkpostmail.com" {
      Remote_SMTP_Port = "587"
      Outbound_SMTP_AUTH_Type = "LOGIN"
      Outbound_SMTP_AUTH_user = "SMTP_Injection"
      Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce"
    }


  4. Skonfiguruj powiązania, które chcesz przekazywać przez MessageBird z TLS i kieruj je do domeny, którą zdefiniowałeś powyżej.

    Uwaga: TLS nie jest ściśle wymagany, ale jest silnym zaleceniem. Jeśli TLS nie jest możliwy z jakiegoś powodu, również silnym zaleceniem jest biała lista kluczy API.

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

Dla PowerMTA:

  1. Ustaw wersję PowerMTA > 4.5.0

  2. Zainstaluj ważny certyfikat SSL i otwórz port 587, aby PowerMTA mógł komunikować się z Bird.

  3. Skonfiguruj ścieżkę domeny wyjściowej, aby móc przesłać wiadomość przez PowerMTA do Bird. W poniższej konfiguracji każda wiadomość trafiająca na tę konfigurację będzie kierowana do smtp.sparkpostmail.com za pomocą portu 587 oraz SMTP_Auth z nazwą użytkownika i hasłem zdefiniowanymi tam.  W PowerMTA to również tutaj możesz ustawić TLS. Uwaga, to jest również dokumentowane bardziej szczegółowo tutaj 

<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. Skonfiguruj VMTAs, które chcesz przekazywać przez Bird z konfiguracją {sparkpost} rollup, którą zdefiniowałeś powyżej.

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to {sparkpost}
  </domain>
</virtual-mta>

Gdy dokonasz tych zmian konfiguracyjnych, wszystkie wiadomości wysyłane do wybranej "wiążącej" lub "VMTA" powinny być automatycznie kierowane przez Bird w celu dostarczenia.  

Sprawić, aby się stało

Gdy zaczynasz iść tą drogą, nie popełnij błędu, myśląc, że to operacja na za jeden wieczór.  Zrobienie tego dobrze zajmie trochę czasu i staranności.  

  1. Utwórz swoje konto Bird i dokładnie przetestuj je, używając subkonta dewelopera subaccount, abyś mógł później filtrować ten ruch.  Będziesz musiał to zrobić w obu opcjach, ponieważ będziesz potrzebować klucza API dla hasła SMTP_Auth w obu przypadkach.

  2. Jeśli używasz wstrzykiwania SMTP, zaplanuj dodanie nagłówka X-MSYS-API, aby uwzględnić wszystkie metadane i atrybuty wiadomości, które są potrzebne.  Jakiekolwiek nagłówki X powinny być przepisane jako metadane, a także powinieneś uwzględnić atrybuty ip_pool i kampanii. Przykład jest dostępny tutaj.

  3. Jeśli nie używasz BYOIP, upewnij się, że konfigurujesz nieco różne domeny wysyłające do użycia z MessageBird, abyś mógł prowadzić oba środowiska równolegle tak długo, jak to potrzebne.  Jeśli twoja obecna domena wysyłająca to mycompany.com, może skonfiguruj sp.mycompany.com specjalnie do dostarczania Bird.  To pozwoli Ci na stopniową i ostrożną migrację, nie kompromitując żadnej z domen.

  4. Upewnij się, że masz pełną zgodność domen i włączone funkcje zabezpieczeń.  W DNS skonfiguruj DKIM, SPF, DMARC, domeny odbić i śledzenia, aby wszystkie wyglądały, jakby należały do tej samej organizacji.

  5. Skonfiguruj Automatyczne podgrzewanie IP na swoich zdefiniowanych IP_Pools.  Jeśli używasz wcześniej wspomnianej opcji BYOIP, możesz zignorować krok podgrzewania.

  6. Zacznij od jednego strumienia wiadomości i idź dalej od tego miejsca.  Podobnie jak przy podgrzewaniu IP, nie chcesz robić wszystkiego za jednym razem. Najpierw przekieruj kilka setek wiadomości, następnie 10% objętości, potem 20% następnego dnia i zwiększaj, aż przeniesiesz całą objętość. Jeśli jesteś ESP, wybierz klienta, z którym możesz współpracować i przetestuj proces z ich opinią.  Jeśli wszystko działa dobrze, przejdź do następnego. Jeśli napotkasz problemy, poświęć czas, aby je naprawić i uwzględnij to w procesie na kolejny raz.

  7. Automatyzuj tak dużo, jak to możliwe, z API.  Poza zmianami DNS, konfiguracja SparkPost może być w dużej mierze zautomatyzowana za pomocą kilku wywołań API.

Gdy zaczynasz iść tą drogą, nie popełnij błędu, myśląc, że to operacja na za jeden wieczór.  Zrobienie tego dobrze zajmie trochę czasu i staranności.  

  1. Utwórz swoje konto Bird i dokładnie przetestuj je, używając subkonta dewelopera subaccount, abyś mógł później filtrować ten ruch.  Będziesz musiał to zrobić w obu opcjach, ponieważ będziesz potrzebować klucza API dla hasła SMTP_Auth w obu przypadkach.

  2. Jeśli używasz wstrzykiwania SMTP, zaplanuj dodanie nagłówka X-MSYS-API, aby uwzględnić wszystkie metadane i atrybuty wiadomości, które są potrzebne.  Jakiekolwiek nagłówki X powinny być przepisane jako metadane, a także powinieneś uwzględnić atrybuty ip_pool i kampanii. Przykład jest dostępny tutaj.

  3. Jeśli nie używasz BYOIP, upewnij się, że konfigurujesz nieco różne domeny wysyłające do użycia z MessageBird, abyś mógł prowadzić oba środowiska równolegle tak długo, jak to potrzebne.  Jeśli twoja obecna domena wysyłająca to mycompany.com, może skonfiguruj sp.mycompany.com specjalnie do dostarczania Bird.  To pozwoli Ci na stopniową i ostrożną migrację, nie kompromitując żadnej z domen.

  4. Upewnij się, że masz pełną zgodność domen i włączone funkcje zabezpieczeń.  W DNS skonfiguruj DKIM, SPF, DMARC, domeny odbić i śledzenia, aby wszystkie wyglądały, jakby należały do tej samej organizacji.

  5. Skonfiguruj Automatyczne podgrzewanie IP na swoich zdefiniowanych IP_Pools.  Jeśli używasz wcześniej wspomnianej opcji BYOIP, możesz zignorować krok podgrzewania.

  6. Zacznij od jednego strumienia wiadomości i idź dalej od tego miejsca.  Podobnie jak przy podgrzewaniu IP, nie chcesz robić wszystkiego za jednym razem. Najpierw przekieruj kilka setek wiadomości, następnie 10% objętości, potem 20% następnego dnia i zwiększaj, aż przeniesiesz całą objętość. Jeśli jesteś ESP, wybierz klienta, z którym możesz współpracować i przetestuj proces z ich opinią.  Jeśli wszystko działa dobrze, przejdź do następnego. Jeśli napotkasz problemy, poświęć czas, aby je naprawić i uwzględnij to w procesie na kolejny raz.

  7. Automatyzuj tak dużo, jak to możliwe, z API.  Poza zmianami DNS, konfiguracja SparkPost może być w dużej mierze zautomatyzowana za pomocą kilku wywołań API.

Gdy zaczynasz iść tą drogą, nie popełnij błędu, myśląc, że to operacja na za jeden wieczór.  Zrobienie tego dobrze zajmie trochę czasu i staranności.  

  1. Utwórz swoje konto Bird i dokładnie przetestuj je, używając subkonta dewelopera subaccount, abyś mógł później filtrować ten ruch.  Będziesz musiał to zrobić w obu opcjach, ponieważ będziesz potrzebować klucza API dla hasła SMTP_Auth w obu przypadkach.

  2. Jeśli używasz wstrzykiwania SMTP, zaplanuj dodanie nagłówka X-MSYS-API, aby uwzględnić wszystkie metadane i atrybuty wiadomości, które są potrzebne.  Jakiekolwiek nagłówki X powinny być przepisane jako metadane, a także powinieneś uwzględnić atrybuty ip_pool i kampanii. Przykład jest dostępny tutaj.

  3. Jeśli nie używasz BYOIP, upewnij się, że konfigurujesz nieco różne domeny wysyłające do użycia z MessageBird, abyś mógł prowadzić oba środowiska równolegle tak długo, jak to potrzebne.  Jeśli twoja obecna domena wysyłająca to mycompany.com, może skonfiguruj sp.mycompany.com specjalnie do dostarczania Bird.  To pozwoli Ci na stopniową i ostrożną migrację, nie kompromitując żadnej z domen.

  4. Upewnij się, że masz pełną zgodność domen i włączone funkcje zabezpieczeń.  W DNS skonfiguruj DKIM, SPF, DMARC, domeny odbić i śledzenia, aby wszystkie wyglądały, jakby należały do tej samej organizacji.

  5. Skonfiguruj Automatyczne podgrzewanie IP na swoich zdefiniowanych IP_Pools.  Jeśli używasz wcześniej wspomnianej opcji BYOIP, możesz zignorować krok podgrzewania.

  6. Zacznij od jednego strumienia wiadomości i idź dalej od tego miejsca.  Podobnie jak przy podgrzewaniu IP, nie chcesz robić wszystkiego za jednym razem. Najpierw przekieruj kilka setek wiadomości, następnie 10% objętości, potem 20% następnego dnia i zwiększaj, aż przeniesiesz całą objętość. Jeśli jesteś ESP, wybierz klienta, z którym możesz współpracować i przetestuj proces z ich opinią.  Jeśli wszystko działa dobrze, przejdź do następnego. Jeśli napotkasz problemy, poświęć czas, aby je naprawić i uwzględnij to w procesie na kolejny raz.

  7. Automatyzuj tak dużo, jak to możliwe, z API.  Poza zmianami DNS, konfiguracja SparkPost może być w dużej mierze zautomatyzowana za pomocą kilku wywołań API.

Zbieranie danych od ptaków

MessageBird raportuje dostarczanie wiadomości w strumieniu webhooków lub w API zdarzeń wiadomości.  Uzyskanie dostępu do dzienników tekstowych Bird w formie zwykłej nie jest po prostu możliwe. Możesz pobrać te dane do swojego środowiska za pomocą kolektora webhooków lub okresowo wywołując API zdarzeń i konsumując dane.  Zalecamy korzystanie z webhooków i mamy kilka rekomendacji dotyczących ich prawidłowego stosowania.  W najprostszym przypadku kolektor webhooków w PHP można wdrożyć w kilku  linijkach kodu:

<?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)

Podczas gdy eksperymentujesz, możesz je wypróbować z darmowymi kolektorami takimi jak http://webhook.site/.

Gdy już zbierzesz wszystkie dane z webhooków, możesz je odczytać do magazynu danych w celu dodatkowego przetwarzania.  Istnieją również sposoby na przesyłanie Webhooków przez usługi takie jak StitchData i Segment.

Te same informacje są dostępne w API Zdarzeń, jeśli potrzebujesz PBYĆ danych i nie możesz akceptować danych PUSH.  Oto przykładowe wywołanie API Zdarzeń:
GET https://api.sparkpost.com/api/v1/events/message?/

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

To API jest w pełni udokumentowane z przykładami tutaj:  https://developers.sparkpost.com/api/events/#events-get-search-for-message-events

Jeśli naprawdę potrzebujesz danych o zdarzeniach z powrotem w formie, która wygląda jak logi PMTA lub Momentum, to również jest możliwe, jeśli zastosujesz dodatkowy kod warunkowy. Świetną wiadomością jest to, że już istnieje kilka przykładów, które można łatwo wykorzystać.

MessageBird raportuje dostarczanie wiadomości w strumieniu webhooków lub w API zdarzeń wiadomości.  Uzyskanie dostępu do dzienników tekstowych Bird w formie zwykłej nie jest po prostu możliwe. Możesz pobrać te dane do swojego środowiska za pomocą kolektora webhooków lub okresowo wywołując API zdarzeń i konsumując dane.  Zalecamy korzystanie z webhooków i mamy kilka rekomendacji dotyczących ich prawidłowego stosowania.  W najprostszym przypadku kolektor webhooków w PHP można wdrożyć w kilku  linijkach kodu:

<?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)

Podczas gdy eksperymentujesz, możesz je wypróbować z darmowymi kolektorami takimi jak http://webhook.site/.

Gdy już zbierzesz wszystkie dane z webhooków, możesz je odczytać do magazynu danych w celu dodatkowego przetwarzania.  Istnieją również sposoby na przesyłanie Webhooków przez usługi takie jak StitchData i Segment.

Te same informacje są dostępne w API Zdarzeń, jeśli potrzebujesz PBYĆ danych i nie możesz akceptować danych PUSH.  Oto przykładowe wywołanie API Zdarzeń:
GET https://api.sparkpost.com/api/v1/events/message?/

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

To API jest w pełni udokumentowane z przykładami tutaj:  https://developers.sparkpost.com/api/events/#events-get-search-for-message-events

Jeśli naprawdę potrzebujesz danych o zdarzeniach z powrotem w formie, która wygląda jak logi PMTA lub Momentum, to również jest możliwe, jeśli zastosujesz dodatkowy kod warunkowy. Świetną wiadomością jest to, że już istnieje kilka przykładów, które można łatwo wykorzystać.

MessageBird raportuje dostarczanie wiadomości w strumieniu webhooków lub w API zdarzeń wiadomości.  Uzyskanie dostępu do dzienników tekstowych Bird w formie zwykłej nie jest po prostu możliwe. Możesz pobrać te dane do swojego środowiska za pomocą kolektora webhooków lub okresowo wywołując API zdarzeń i konsumując dane.  Zalecamy korzystanie z webhooków i mamy kilka rekomendacji dotyczących ich prawidłowego stosowania.  W najprostszym przypadku kolektor webhooków w PHP można wdrożyć w kilku  linijkach kodu:

<?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)

Podczas gdy eksperymentujesz, możesz je wypróbować z darmowymi kolektorami takimi jak http://webhook.site/.

Gdy już zbierzesz wszystkie dane z webhooków, możesz je odczytać do magazynu danych w celu dodatkowego przetwarzania.  Istnieją również sposoby na przesyłanie Webhooków przez usługi takie jak StitchData i Segment.

Te same informacje są dostępne w API Zdarzeń, jeśli potrzebujesz PBYĆ danych i nie możesz akceptować danych PUSH.  Oto przykładowe wywołanie API Zdarzeń:
GET https://api.sparkpost.com/api/v1/events/message?/

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

To API jest w pełni udokumentowane z przykładami tutaj:  https://developers.sparkpost.com/api/events/#events-get-search-for-message-events

Jeśli naprawdę potrzebujesz danych o zdarzeniach z powrotem w formie, która wygląda jak logi PMTA lub Momentum, to również jest możliwe, jeśli zastosujesz dodatkowy kod warunkowy. Świetną wiadomością jest to, że już istnieje kilka przykładów, które można łatwo wykorzystać.

Podsumowanie

Upewnij się, że rozmawiasz z zespołem ds. sprzedaży i zarządzania sukcesem.  Robiliśmy to już wcześniej i możemy pomóc Ci w tym szybko i opłacalnie.

  1. Dowiedz się, czy jesteś w obozie #1 (zdolny do całkowitego przejścia z On-Prem) czy w obozie #2 (ciągle potrzebujesz kilku lokalnych MTA).

  2. Zarejestruj się na bezpłatne konto testowe, aby ocenić szczegóły integracji.

  3. Wybierz metody wstrzykiwania SMTP lub REST API.

  4. Jeśli używasz wstrzykiwania SMTP, dowiedz się, jak wprowadzić dane nagłówka i atrybuty wiadomości do nagłówka X-MSYS-API.

  5. Potwierdź, czy możesz skorzystać z naszego procesu BYOIP.

  6. Zaktualizuj swoje DNS z nowymi domenami, jeśli to konieczne.

  7. Zbuduj mały przykład, aby przetestować swoją migrację.  Możesz potrzebować dostosować swoją konfigurację.

  8. Zwiększaj wolumen, aż cały ruch zostanie migrowany

  9. Jeśli pasujesz do obozu #1, możesz w końcu zamknąć swoje lokalne MTA po migracji całego ruchu.

Planując zmiany DNS dla systemów e-mail o dużym wolumenie, bądź świadomy potencjalnych wyzwań skalowania DNS AWS, które mogą wpłynąć na wydajność dostarczania e-maili na dużą skalę.

Upewnij się, że rozmawiasz z zespołem ds. sprzedaży i zarządzania sukcesem.  Robiliśmy to już wcześniej i możemy pomóc Ci w tym szybko i opłacalnie.

  1. Dowiedz się, czy jesteś w obozie #1 (zdolny do całkowitego przejścia z On-Prem) czy w obozie #2 (ciągle potrzebujesz kilku lokalnych MTA).

  2. Zarejestruj się na bezpłatne konto testowe, aby ocenić szczegóły integracji.

  3. Wybierz metody wstrzykiwania SMTP lub REST API.

  4. Jeśli używasz wstrzykiwania SMTP, dowiedz się, jak wprowadzić dane nagłówka i atrybuty wiadomości do nagłówka X-MSYS-API.

  5. Potwierdź, czy możesz skorzystać z naszego procesu BYOIP.

  6. Zaktualizuj swoje DNS z nowymi domenami, jeśli to konieczne.

  7. Zbuduj mały przykład, aby przetestować swoją migrację.  Możesz potrzebować dostosować swoją konfigurację.

  8. Zwiększaj wolumen, aż cały ruch zostanie migrowany

  9. Jeśli pasujesz do obozu #1, możesz w końcu zamknąć swoje lokalne MTA po migracji całego ruchu.

Planując zmiany DNS dla systemów e-mail o dużym wolumenie, bądź świadomy potencjalnych wyzwań skalowania DNS AWS, które mogą wpłynąć na wydajność dostarczania e-maili na dużą skalę.

Upewnij się, że rozmawiasz z zespołem ds. sprzedaży i zarządzania sukcesem.  Robiliśmy to już wcześniej i możemy pomóc Ci w tym szybko i opłacalnie.

  1. Dowiedz się, czy jesteś w obozie #1 (zdolny do całkowitego przejścia z On-Prem) czy w obozie #2 (ciągle potrzebujesz kilku lokalnych MTA).

  2. Zarejestruj się na bezpłatne konto testowe, aby ocenić szczegóły integracji.

  3. Wybierz metody wstrzykiwania SMTP lub REST API.

  4. Jeśli używasz wstrzykiwania SMTP, dowiedz się, jak wprowadzić dane nagłówka i atrybuty wiadomości do nagłówka X-MSYS-API.

  5. Potwierdź, czy możesz skorzystać z naszego procesu BYOIP.

  6. Zaktualizuj swoje DNS z nowymi domenami, jeśli to konieczne.

  7. Zbuduj mały przykład, aby przetestować swoją migrację.  Możesz potrzebować dostosować swoją konfigurację.

  8. Zwiększaj wolumen, aż cały ruch zostanie migrowany

  9. Jeśli pasujesz do obozu #1, możesz w końcu zamknąć swoje lokalne MTA po migracji całego ruchu.

Planując zmiany DNS dla systemów e-mail o dużym wolumenie, bądź świadomy potencjalnych wyzwań skalowania DNS AWS, które mogą wpłynąć na wydajność dostarczania e-maili na dużą skalę.

Inne wiadomości

Przeczytaj więcej z tej kategorii

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

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.

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

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.