Około roku temu napisałem blog o tym, jak pobierać kopie e-maili do archiwizacji i przeglądania, ale nie poruszyłem tematu faktycznego przechowywania e-maila ani pokrewnych danych. Niedawno napisałem blog o przechowywaniu wszystkich danych związanych z wydarzeniami (tj. kiedy e-mail został wysłany, otwarty, kliknięty, odbity, wypisany itp.) dla celów audytowych, ale zdecydowałem się nie tworzyć żadnego wspierającego kodu.

W związku z rosnącym użyciem e-maili w środowiskach regulacyjnych, postanowiłem, że nadszedł czas, aby rozpocząć nowy projekt, który połączy te elementy i przedstawi przykłady kodu, jak przechowywać treść e-maila i wszystkie powiązane dane. W ciągu następnego roku będę kontynuował rozwijanie tego projektu z zamiarem stworzenia działającej aplikacji do przechowywania i przeglądania archiwalnych e-maili oraz wszystkich informacji logowania produkowanych przez SparkPost. SparkPost nie posiada systemu archiwizacji treści e-maila, ale ułatwia budowę platformy archiwizacyjnej.

W tej serii blogów opiszę proces, który przeszedłem, aby przechowywać treść e-maila na S3 (Amazon’s Simple Store Service) i wszystkie istotne dane logowania w MySQL, aby ułatwić odniesienia krzyżowe. Dla produkcyjnych systemów archiwizacyjnych, które wymagają skutecznych strategii tworzenia kopii zapasowych baz danych, rozważ implementację kompleksowego procesu tworzenia i przywracania kopii zapasowych PostgreSQL aby zapewnić właściwą ochronę danych archiwizacyjnych. Ostatecznie jest to punkt startowy do stworzenia aplikacji, która umożliwi łatwe wyszukiwanie archiwalnych e-maili, a następnie ich wyświetlanie wraz z danymi dotyczącymi wydarzeń (logów). Kod do tego projektu można znaleźć w następującym repozytorium GitHub: https://github.com/jeff-goldstein/PHPArchivePlatform

Ten pierwszy wpis z serii blogów będzie opisywał wyzwanie i przedstawiał architekturę rozwiązania. Reszta wpisów będzie szczegółowo opisywać części rozwiązania oraz przykłady kodu.

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

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

2. Skłonić serwer e-mail do przechowywania kopii

3. Poprosić serwer e-mail o utworzenie kopii do przechowania
   
   

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

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

Odbywa się to za pomocą funkcji Archive SparkPost. Funkcja Archive SparkPost umożliwia nadawcy poinformowanie SparkPost o wysłaniu duplikatu e-maila do jednego lub więcej adresów e-mail i użycie tych samych linków śledzenia i otwarć co oryginał. Dokumentacja SparkPost definiuje ich funkcję Archive w następujący sposób:

Odbiorcy znajdujący się na liście archiwizacji otrzymują dokładną replikę wiadomości, która została wysłana na adres RCPT TO. W szczególności, wszelkie zakodowane linki przeznaczone dla odbiorcy RCPT TO będą identyczne w wiadomościach z archiwum

Jedyną różnicą w stosunku do e-maila RCPT TO są inne nagłówki, ponieważ docelowy adres dla archiwizacji różni się, ale treść e-maila jest dokładną repliką!

Jeśli chcesz dokładniejszego wyjaśnienia, tutaj jest link do dokumentacji SparkPost na temat tworzenia duplikatów (lub archiwizacji) kopii e-maila.

Jako uwaga na marginesie, SparkPost rzeczywiście pozwala wysyłać e-maile na adresy cc, bcc i archiwalne. W tym rozwiązaniu koncentrujemy się na adresach archiwalnych.

* Uwaga * Archiwalne e-maile mogą być TWORZONE TYLKO podczas wprowadzania e-maili do SparkPost za pomocą SMTP!

Teraz gdy wiemy, jak uzyskać kopię oryginalnego e-maila, musimy przyjrzeć się danym logów, które są produkowane i niektórym subtelnym niuansom w tych danych. SparkPost śledzi wszystko, co dzieje się na jego serwerach, i udostępnia te informacje w formie zdarzeń wiadomości. Te zdarzenia są przechowywane w SparkPost przez 10 dni i mogą być pobierane z serwera poprzez API RESTful o nazwie message-events lub możesz zlecić SparkPost przesyłanie tych zdarzeń do dowolnej liczby aplikacji zbierających, które sobie zażyczysz. Mechanizm otrzymywania odbywa się za pośrednictwem webhooków w czasie rzeczywistym.

Obecnie istnieją 14 różne wydarzenia, które mogą wystąpić w odniesieniu do e-maila. Oto lista bieżących wydarzeń:

• Bounce

• ClickDelay

• Delivery

• Generation Failure

• Generation Rejection

• Initial Open

• InjectionLink Unsubscribe

• List Unsubscribe

• Open

• Out of Band

• Policy RejectionSpam Complaint

  
  

* Śledź ten link dla aktualnych przewodników referencyjnych opisujących każde wydarzenie oraz dane, które są udostępniane dla każdego wydarzenia.

Każde wydarzenie ma liczne pola pasujące do typu wydarzenia. Niektóre pola, takie jak transmission_id są obecne w każdym wydarzeniu, inne pola mogą być bardziej specyficzne dla wydarzeń; na przykład, tylko wydarzenia otwarcia i kliknięcia mają informacje o geotagu.

Bardzo ważnym wpisem dotyczącym zdarzenia wiadomości dla tego projektu jest transmission_id. Wszystkie wpisy wydarzeń wiadomości dla oryginalnego e-maila, e-maila zarchiwizowanego oraz wszelkich adresów cc i bcc będą dzielić to samo transmission_id.

Istnieje również wspólne wejście o nazwie message_id które będzie miało to samo ID dla każdego wpisu dla oryginalnego e-maila i zarchiwizowanego e-maila. Wszelkie adresy cc lub bcc będą miały własne ID dla entry message_id.

Na razie brzmi to świetnie i szczerze mówiąc dość łatwo, ale teraz nadchodzi trudniejsza część. Pamiętaj, aby uzyskać e-mail z archiwum, musimy nakazać SparkPost, aby wysłać duplikat oryginalnego e-maila na inny adres e-mail, który odpowiada pewnej skrzynce odbiorczej, do której masz dostęp. Jednak aby zautomatyzować to rozwiązanie i przechowywać treść e-maila, użyję innej funkcji SparkPost o nazwie Inbound Email Relaying. Co się przez to rozumie, to że wszystkie e-maile wysyłane do określonej domeny są przetwarzane. W trakcie przetwarzania zamieniają e-mail na strukturę JSON, która jest dostarczana do aplikacji za pośrednictwem webhooka. Zobacz załącznik A dla przykładowego JSON.

Jeśli przyjrzysz się naprawdę uważnie, zauważysz, że struktura JSON z inbound relay brakuje bardzo ważnego pola; transmission_id. Podczas gdy wszystkie wiadomości wychodzące mają transmisję_id  z tym samym wejściem, które wiąże wszystkie dane z oryginalnego e-maila, archiwizowanego e-maila, cc i bcc; SparkPost nie ma jak wiedzieć, że e-mail przechwycony poprzez proces przychodzący jest powiązany z którymkolwiek z e-maili wychodzących. Proces przychodzący wie po prostu, że e-mail został wysłany do określonej domeny i przetwarza e-mail. I to wszystko. Traktuje każdy e-mail wysłany na tę domenę w ten sam sposób, niezależnie od tego, czy jest to odpowiedź od klienta, czy e-mail archiwizacyjny wysłany z SparkPost.

Sztuczka polega na tym, jak powiązać dane wychodzące z procesem przychodzącym, który właśnie pobrał zarchiwizowaną wersję e-maila? Zdecydowałem się ukryć unikalne ID w treści e-maila. Sposób, w jaki to robię, należy do Ciebie, ale po prostu stworzyłem polę input z włączonym tagiem ukrycia.

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

Dodałem również to pole do bloku metadanych nagłówka X-MSYS-API, które jest przekazywane do SparkPost podczas injekcji. Ten ukryty UID stanie się spoiwem całego procesu i jest głównym elementem projektu, który będzie szczegółowo omówiony w kolejnych wpisach na blogu.

Teraz, gdy mamy UID, który zepnie ten projekt razem i rozumiemy, dlaczego jest to konieczne, mogę zacząć budować wizję całościowego projektu i odpowiadających mu wpisów na blogu.

1. Przechwytywanie i przechowywanie zarchiwizowanego e-maila wraz z wpisem do bazy danych do wyszukiwania/indeksowania

2. Przechwycenie wszystkich danych zdarzeń wiadomości

3. Stworzenie aplikacji, która pozwoli na przeglądanie e-maila i wszystkich powiązanych danych

   
   

Oto prosty schemat projektu:

Pierwsza wersja kodu obejmie proces archiwizacji i przechowywanie e-maila na S3, podczas gdy druga wersja kodu zajmie się przechowywaniem wszystkich danych logowania z message-events w MySQL. Możesz spodziewać się pierwszych dwóch wersji kodu i wpisów na blogu na początku 2019 roku.  Jeśli masz jakiekolwiek pytania lub sugestie, śmiało, przekaż je.

Radosnego wysyłania.

– Jeff

Aneks A: