Budowanie systemu archiwizacji e-maili: wyzwania i oczywiście rozwiązanie – Część 1

Około roku temu napisałem bloga na temat pozyskiwania kopii e-maili w celach archiwalnych i przeglądowych, ale nie poruszyłem kwestii samego przechowywania e-maila lub powiązanych danych. Ostatnio napisałem bloga o przechowywaniu wszystkich danych o wydarzeniach (tj. kiedy e-mail został wysłany, otwarcia, kliknięcia, bounces, wypisania itp.) w e-mailu w celu audytu, ale zdecydowałem się nie tworzyć żadnego wspierającego kodu.

W związku ze wzrostem użycia e-maili w środowiskach regulacyjnych, postanowiłem, że nadszedł czas, aby rozpocząć nowy projekt, który zbierze to wszystko razem z próbkami kodu dotyczącymi tego, jak przechowywać treść e-maila i wszystkie jego powiązane dane. Przez następny rok będę kontynuował budowę tego projektu, mając na celu stworzenie działającej aplikacji do przechowywania i przeglądania archiwalnych e-maili oraz wszystkich informacji o logach generowanych przez SparkPost. SparkPost nie ma systemu, który archiwizuje treść e-maila, ale budowanie platformy archiwizacyjnej jest dość łatwe.

W tej serii blogów opiszę proces, przez który przeszedłem, aby przechować treść e-maila na S3 (Prosta Usługa Przechowywania Amazonu) i wszystkie odpowiednie dane logów w MySQL w celu łatwego krzyżowego odniesienia. Dla systemów archiwizacyjnych produkcyjnych, które wymagają solidnych strategii backupu bazy danych, rozważ wdrożenie kompleksowego procesu backupu i przywracania PostgreSQL, aby zapewnić odpowiednią ochronę danych archiwalnych. Ostatecznie jest to punkt wyjścia do budowy aplikacji, która umożliwi łatwe wyszukiwanie archiwalnych e-maili, a następnie wyświetlanie tych e-maili wraz z danymi o wydarzeniach (logami). Kod do tego projektu można znaleźć w następującym repozytorium GitHub: PHPArchivePlatform na GitHubie

Ten pierwszy wpis w serii blogów opisze wyzwanie i przedstawi architekturę rozwiązania. Pozostałe blogi szczegółowo opiszą części rozwiązania wraz z próbkami kodu.

Pierwszym krokiem w moim procesie było ustalenie, jak zamierzam uzyskać kopię e-maila wysłanego do pierwotnego odbiorcy. Aby uzyskać kopię treści e-maila, musisz:

Opcje przechwytywania treści e-maila

1. Przechwyć treść e-maila przed wysłaniem

2. Uzyskaj od serwera e-mail kopię

3. Niech serwer e-mail stworzy kopię, abyś mógł ją przechować

Jeśli serwer e-mail dodaje elementy takie jak śledzenie linków lub śledzenie otwarć, nie możesz użyć numeru 1, ponieważ nie odzwierciedli to zmian w śledzeniu otwarć/kliknięć.

To oznacza, że albo serwer musi przechować e-mail, albo jakoś zaoferować ci kopię tego e-maila do przechowania. Ponieważ SparkPost nie ma mechanizmu przechowywania treści e-maili, ale ma sposób na stworzenie kopii e-maila, poprosimy SparkPost o wysłanie nam duplikatu e-maila do przechowania w S3.

Realizuje się to przy użyciu funkcji archiwizacji SparkPost. Funkcja archiwizacji SparkPost daje nadawcy możliwość powiedzenia SparkPost, aby wysłał duplikat e-maila na jeden lub więcej adresów e-mail i używa tych samych śledzących i otwartych linków, co oryginał. Dokumentacja SparkPost definiuje ich funkcję archiwizacji w następujący sposób:

Odbiorcy na liście archiwalnej otrzymają dokładną replikę wiadomości, która została wysłana do adresu RCPT TO. W szczególności wszelkie zakodowane linki przeznaczone dla odbiorcy RCPT TO będą identyczne w archiwalnych wiadomościach

Jedynymi różnicami w porównaniu do e-maila RCPT TO są niektóre nagłówki, które będą inne, ponieważ adres docelowy dla archiwizowanego e-maila jest inny, ale treść e-maila będzie dokładną repliką!

Jeśli chcesz głębszego wyjaśnienia, oto link do dokumentacji SparkPost dotyczącej tworzenia duplikatów (lub archiwalnych) kopii e-maila.

To tylko uwaga, SparkPost rzeczywiście pozwala wysyłać e-maile na adresy cc, bcc i archiwizacyjne. Dla tego rozwiązania koncentrujemy się na adresach archiwizacyjnych.

* Uwaga * Archiwizowane e-maile mogą być TWORZONE TYLKO podczas wstrzykiwania e-maili do SparkPost za pośrednictwem SMTP!

Teraz, gdy wiemy, jak uzyskać kopię oryginalnego e-maila, musimy przyjrzeć się danym logów, które są generowane oraz niektórym subtelnym szczegółom w tych danych. SparkPost śledzi wszystko, co dzieje się na jego serwerach i udostępnia ci te informacje w postaci wydarzeń wiadomości. Te wydarzenia są przechowywane na SparkPost przez 10 dni i można je pobrać z serwera za pośrednictwem API RESTful zwanego wydarzeniami wiadomości, lub możesz poprosić SparkPost o przesłanie tych wydarzeń do dowolnej liczby aplikacji zbierających, które chcesz. Mechanizm push odbywa się za pomocą webhooków i jest realizowany w czasie rzeczywistym.

Obecnie istnieje 14 różnych wydarzeń, które mogą wystąpić w przypadku e-maila.  Oto lista aktualnych wydarzeń:

• Odbicie

• Opóźnienie kliknięcia

• Dostawa

• Błąd generacji

• Odrzucenie generacji

• Pierwsze otwarcie

• Wypisanie linku wstrzyknięcia

• Wypisanie z listy

• Otwarcie

• Poza pasmem

• Odrzucenie polityki, skarga na spam

  
  

* Śledź ten link, aby uzyskać aktualne informacje dotyczące opisu każdego wydarzenia wraz z danymi, które są udostępniane dla każdego wydarzenia.

Każde wydarzenie ma wiele pól, które odpowiadają typowi wydarzenia. Niektóre pola, takie jak transmission_id są obecne w każdym wydarzeniu, ale inne pola mogą być bardziej specyficzne dla danych wydarzenia; na przykład tylko wydarzenia otwarcia i kliknięcia mają informacje o geotagach.

Identyfikatory użyte w systemie archiwizacji

Bardzo ważnym wpisem wydarzenia wiadomości dla tego projektu jest transmission_id. Wszystkie wpisy wydarzeń wiadomości dla oryginalnego e-maila, archiwizowanego e-maila oraz jakichkolwiek adresów cc i bcc będą dzielić ten sam transmission_id.

Istnieje również wspólny wpis o nazwie message_id który będzie miał ten sam identyfikator dla każdej pozycji oryginalnego e-maila i archiwizowanego e-maila. Jakiekolwiek adresy cc lub bcc będą miały swój własny identyfikator dla pozycji message_id .

Jak na razie to brzmi świetnie i właściwie dość łatwo, ale teraz zaczyna się trudna część. Pamiętaj, aby uzyskać archiwizowany e-mail, mamy SparkPost, aby wysłał duplikat oryginalnego e-maila na inny adres e-mail, który odpowiada jakiejś skrzynce, do której masz dostęp. Ale aby zautomatyzować to rozwiązanie i przechować treść e-maila, zamierzam skorzystać z innej funkcji SparkPost, zwanej Wprowadzanie e-maili przychodzących. Co to robi, to bierze wszystkie e-maile wysłane na konkretną domenę i je przetwarza. Przez przetwarzanie, jasno określa wiadomość e-mail i tworzy strukturę JSON, która jest następnie dostarczana do aplikacji za pośrednictwem webhooku. Zobacz Załącznik A, aby zobaczyć przykładowy JSON.

Jeśli dokładnie się przyjrzysz, zauważysz, że struktura JSON z relay brakuje bardzo ważnego pola; transmission_id. Chociaż wszystkie e-maile wychodzące mają transmission_id z tym samym wpisem, który wiąże wszystkie dane z oryginalnego e-maila, archiwum, cc i bcc; SparkPost nie ma sposobu, aby wiedzieć, że e-mail przechwycony przez proces przychodzący jest połączony z jakimikolwiek e-mailami wychodzącymi. Proces przychodzący po prostu wie, że e-mail został wysłany do konkretnej domeny i żeby go sparsować. To wszystko. Będzie traktował każdy e-mail wysłany do tej domeny w ten sam sposób, czy to odpowiedź od klienta, czy archiwalny e-mail wysłany z SparkPost.

Więc sztuczka polega na tym, jak skleić dane wychodzące z procesem przychodzącym, który właśnie zdobył archiwalną wersję e-maila? Postanowiłem ukryć unikalny identyfikator w treści e-maila. Jak to się robi, to zależy od ciebie, ale ja po prostu stworzyłem pole formularza z włączonym polem ukrytym.

<input name="ArchiveCode" type="hidden" value="<<UID>>">

Dodano też to pole do bloku metadanych nagłówka X-MSYS-API, który jest przesyłany do SparkPost podczas wprowadzania. Ten ukryty UID stanie się klejem do całego procesu i jest kluczowym elementem projektu, który będzie omawiany szczegółowo w następnych wpisach na blogu.

Teraz, gdy mamy UID, który połączy ten projekt i rozumiemy, dlaczego jest to konieczne, mogę zacząć budować wizję ogólnego projektu i odpowiadających mu wpisów blogowych.

1. Przechwytywanie i przechowywanie archiwizowanego e-maila wraz z wpisem w bazie danych do wyszukiwania/indexowania

2. Przechwycenie wszystkich danych wydarzeń wiadomości

3. Stworzenie aplikacji do przeglądania e-maila i wszystkich powiązanych danych

Oto prosty diagram projektu:

Pierwsza partia kodu obejmie proces archiwizacji i przechowywania e-maila w S3, podczas gdy druga partia kodu obejmie przechowywanie wszystkich danych logów z wydarzeń wiadomości w MySQL. Możesz oczekiwać, że pierwsze dwa wpisy z kodem i wpisy na blogu będą dostępne wczesną wiosną 2019 r.  Jeśli masz jakieś pytania lub sugestie, proszę przekaż je dalej.

Szczęśliwego wysyłania.
– Jeff

Załącznik A: