Około rok temu napisałem blog o tym, jak odzyskać kopie e-maili do archiwizacji i przeglądania, ale nie poruszyłem tematu faktycznego przechowywania e-maili ani powiązanych danych, a niedawno napisałem blog o przechowywaniu wszystkich danych wydarzeń (tj. kiedy e-mail został wysłany, otwarte, kliknięcia, odbicia, rezygnacje z subskrypcji itp.) w e-mailu w celu audytu, ale zdecydowałem się nie tworzyć wspierającego kodu.

Wraz ze wzrostem użycia e-maili w środowiskach regulacyjnych, zdecydowałem, że nadszedł czas na rozpoczęcie nowego projektu, który scali te wszystkie elementy razem, w tym przykłady kodu dotyczące przechowywania treści e-maila i wszystkich powiązanych danych. Przez następny rok będę kontynuować budowanie tego projektu z zamiarem stworzenia działającej aplikacji do przechowywania i przeglądania zarchiwizowanych e-maili i wszystkich informacji z logów produkowanych przez SparkPost. SparkPost nie ma systemu, który archiwizuje treść e-maila, ale umożliwia łatwe tworzenie platformy archiwizacyjnej.

W tej serii blogów opiszę proces, przez który przeszłam, aby przechować treść e-maila na S3 (Amazon’s Simple Store Service) i wszystkie odpowiednie dane z logów w MySQL do łatwego odniesienia krzyżowego. Dla produkcyjnych systemów archiwizacyjnych, które wymagają solidnych strategii tworzenia kopii zapasowych bazy danych, rozważ wdrożenie kompleksowego procesu tworzenia kopii zapasowych i przywracania PostgreSQL aby zapewnić właściwą ochronę danych archiwalnych. Ostatecznie, to jest punkt startowy do budowania aplikacji, która umożliwi łatwe wyszukiwanie zarchiwizowanych e-maili, a następnie wyświetlanie tych e-maili wraz z danymi wydarzeń (logiem). Kod dla tego projektu można znaleźć w następującym repozytorium GitHub: https://github.com/jeff-goldstein/PHPArchivePlatform

Ten pierwszy wpis w serii blogów opisze wyzwanie i przedstawia architekturę rozwiązania. Reszta blogów szczegółowo opisze części rozwiązania wraz z przykładami kodu.

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

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

2. Sprawić, by serwer e-mailowego przechowywał kopię

3. Sprawić, by serwer e-mailowego stworzył kopię do przechowania
   
   

Jeśli serwer e-mailowy dodaje elementy takie jak śledzenie linków lub śledzenie otwarć, nie możesz użyć opcji nr 1, ponieważ nie będzie odzwierciedlać zmian w śledzeniu otwarć/kliknięć.

Oznacza to, że serwer musi przechowywać e-mail lub jakoś zaoferować jego kopię do przechowania. Ponieważ SparkPost nie ma mechanizmu przechowywania treści e-maili, ale ma sposób na stworzenie kopii e-maila, sprawimy, że SparkPost wyśle duplikat e-maila do nas na S3.

Dokonuje tego poprzez użycie funkcji Archiwum SparkPost. Funkcja Archiwum SparkPost daje nadawcy możliwość polecenia SparkPost, aby wysłał duplikat e-maila do jednego lub więcej adresów e-mailowych i użył tych samych linków śledzących i otwartych co pierwotny. Dokumentacja SparkPost definiuje ich funkcję Archiwum w następujący sposób:

Odbiorcy znajdujący się na liście archiwalnej otrzymają dokładną kopię 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 archiwalnych

Jedyną różnicą w stosunku do e-maila RCPT TO jest to, że niektóre nagłówki będą inne, ponieważ docelowy adres dla e-maila archiwalnego jest inny, ale treść e-maila będzie dokładną kopią!

Jeśli chcesz uzyskać głębsze wyjaśnienie, oto link do dokumentacji SparkPost o tworzeniu duplikatu (lub archiwum) kopii e-maila.

Jako dodatkową uwagę, SparkPost rzeczywiście pozwala wysyłać e-maile do adresów cc, bcc i archiwalnych. W przypadku tego rozwiązania skupiamy się na adresach archiwalnych.

* Zauważ * Zarchiwizowane e-maile mogą być tworzone TYLKO podczas wstrzykiwania e-maili do SparkPost przez SMTP!

Teraz, gdy wiemy, jak uzyskać kopię pierwotnego e-maila, musimy spojrzeć na dane z logów, które są produkowane oraz niektóre subtelne niuanse w obrębie tych danych. SparkPost śledzi wszystko, co dzieje się na jego serwerach i oferuje te informacje dla Ciebie w formie wiadomości-wydarzeń. Te wydarzenia są przechowywane w SparkPost przez 10 dni i mogą być pobrane z serwera za pomocą RESTful API o nazwie wiadomości-wydarzenia, lub możesz sprawić, by SparkPost wysyłał te wydarzenia do dowolnej liczby aplikacji zbierających, które chcesz.  Mechanizm wysyłania odbywa się za pośrednictwem webhooków i jest wykonywany w czasie rzeczywistym.

Obecnie istnieją 14 różnych wydarzeń, które mogą się zdarzyć dla e-maila.  Oto lista obecnych wydarzeń:

• Bounce

• ClickDelay

• Delivery

• Generation Failure

• Generation Rejection

• Initial Open

• InjectionLink Unsubscribe

• List Unsubscribe

• Open

• Out of Band

• Policy RejectionSpam Complaint

  
  

* Śledź link dla aktualnego przewodnika referencyjnego z opisem każdego wydarzenia wraz z danymi, które są udostępniane dla każdego wydarzenia.

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

Bardzo ważnym wpisem wydarzenia wiadomości dla tego projektu jest transmission_id. Wszystkie wpisy wydarzenia wiadomości dla pierwotnego e-maila, e-maila archiwalnego oraz dowolnych adresów cc i bcc będą mieć ten sam transmission_id.

Istnieje również wspólny wpis zwany message_id który będzie mieć te same id dla każdego wpisu pierwotnego e-maila i e-maila archiwalnego. Jakiekolwiek adresy cc lub bcc będą miały własne id dla wpisu message_id .

Jak na razie wszystko wygląda dobrze i szczerze mówiąc, dość łatwo, ale teraz zaczyna się trudna część. Pamiętaj, aby otrzymać e-mail archiwalny, sprawiamy, by SparkPost wysłał duplikat pierwotnego e-maila do innego adresu e-mailowego, który odpowiada jakiejś skrzynce odbiorczej, do której masz dostęp. Ale aby zautomatyzować to rozwiązanie i przechowywać treść e-maila, zamierzam użyć innej funkcji SparkPost zwanej Inbound Email Relaying. Co to robi, to przejmuje wszystkie e-maile wysłane do określonej domeny i je przetwarza. Poprzez ich przetwarzanie, rozrywa e-mail na części i tworzy strukturę JSON, która jest następnie dostarczana do aplikacji za pośrednictwem webhooka. Zobacz Załącznik A dla przykładowego JSON.

Kiedy przyjrzysz się bardzo uważnie, zauważysz, że struktura JSON z pośrednictwa ma niezwykle ważne pole; to transmission_id. Chociaż wszystkie e-maile wychodzące mają transmission_id  z tym samym wpisem, który łączy wszystkie dane z pierwotnego e-maila, archiwum, cc, i bcc adresów; SparkPost nie ma możliwości wiedzieć, że e-mail przechwycony przez proces przychodzący jest powiązany z jakimikolwiek e-mailami wychodzącymi. Proces przychodzący po prostu wie, że e-mail został wysłany do określonej domeny i ma za zadanie przeanalizować e-mail. Tyle. Traktuje każdy e-mail wysłany do tej domeny w ten sam sposób, czy to odpowiedź od klienta, czy e-mail archiwalny wysłany przez SparkPost.

Więc trik polega na tym; jak skleić dane wychodzące z procesem przychodzącym, który właśnie przechwycił zarchiwizowaną wersję e-maila? To, co zdecydowałem się zrobić, to ukryć unikalne id w treści e-maila. Jak to się robi, zależy od Ciebie, ale po prostu stworzyłem pole wejściowe z włączonym tagiem ukrytym.

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

Dodaliśmy również to pole do bloku metadanych w nagłówku X-MSYS-API, który jest przekazywany do SparkPost podczas wstrzykiwania. Ten ukryty UID stanie się klejem całego procesu i jest główną częścią projektu, która zostanie szczegółowo omówiona w kolejnych postach na blogu.

Teraz, gdy mamy UID, który sklei ten projekt i rozumiemy dlaczego jest to konieczne, mogę zacząć budować wizję całego projektu i odpowiadających mu postów na blogu.

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

2. Przechwytywanie wszystkich danych wydarzeń wiadomości

3. Tworzenie aplikacji do przeglądania e-maila i wszystkich odpowiadających mu danych

   
   

Oto prosty schemat projektu:

Pierwszy drop kodu obejmie proces archiwizacji i przechowywanie e-maila na S3, podczas gdy drugi drop kodu obejmie przechowywanie wszystkich danych z logów wydarzeń wiadomości do MySQL. Możesz spodziewać się pierwszych dwóch dropów kodu i wpisów na blogu na początku 2019 roku.  Jeśli masz jakieś pytania lub sugestie, proszę, prześlij je dalej.

Happy Sending.

– Jeff

Załącznik A: