Około rok 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 powiązanych danych, a niedawno napisałem blog o przechowywaniu wszystkich danych dotyczących zdarzeń (tj. kiedy e-mail został wysłany, otwarcia, kliknięcia, odbicia, rezygnacje z subskrypcji itp.) dla celów audytu, ale postanowiłem nie tworzyć żadnego wspierającego kodu.

Wraz ze wzrostem korzystania z e-maili w środowiskach regulacyjnych postanowiłem, że nadszedł czas, aby rozpocząć nowy projekt, który połączy to wszystko z przykładowymi kodami, jak przechowywać treść e-maila i wszystkie powiązane dane. W ciągu najbliższego roku będę kontynuować budowanie tego projektu z zamiarem stworzenia działającej aplikacji do przechowywania i przeglądania zarchiwizowanych e-maili oraz wszystkich informacji dziennika generowanych przez SparkPost. SparkPost nie posiada systemu do archiwizowania treści e-maili, ale umożliwia w miarę łatwe zbudowanie platformy archiwizacyjnej.

W tej serii blogów opiszę proces, który przeszedłem, aby przechowywać treść e-maila w S3 (Amazon’s Simple Store Service) oraz wszystkie odpowiednie dane dziennika w MySQL, dla łatwego ich odwoływania. Ostatecznie jest to punkt wyjścia dla tworzenia aplikacji, która umożliwi łatwe przeszukiwanie zarchiwizowanych e-maili oraz wyświetlanie tych e-maili wraz z danymi zdarzeń (dziennika). Kod do tego projektu można znaleźć w następującym repozytorium GitHub: https://github.com/jeff-goldstein/PHPArchivePlatform

Pierwszy wpis z serii blogów opisze wyzwanie i przedstawi architekturę rozwiązania. Pozostałe wpisy na blogu będą szczegółowo opisywać części rozwiązania wraz z przykładami kodów.

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

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

2. Skłonić serwer e-maila do przechowania kopii

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

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

To oznacza, że albo serwer musi przechowywać e-mail, albo w jakiś sposób umożliwić Ci uzyskanie kopii tego e-maila do przechowania. Ponieważ SparkPost nie posiada mechanizmu do przechowywania treści e-maili, ale umożliwia utworzenie kopii e-maila, pozwolimy więc SparkPostowi przesłać nam duplikat e-maila do przechowania w S3.

Jest to realizowane za pomocą funkcji archiwizacji SparkPost. Funkcja archiwizacji SparkPost daje nadawcy możliwość poinformowania SparkPost, aby przesłał duplikat e-maila na jeden lub więcej adresów e-mail oraz używał tych samych linków śledzenia i otwarć jak oryginał. Dokumentacja SparkPost definiuje funkcję archiwizacji w następujący sposób:

Odbiorcy na liście archiwów otrzymają dokładną kopię wiadomości, która została wysłana do adresu RCPT TO. W szczególności wszystkie 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ż adres docelowy e-maila archiwizacyjnego jest inny, ale treść e-maila będzie dokładną kopią!

Jeśli chcesz uzyskać głębsze wyjaśnienia, oto link do dokumentacji SparkPost na temat tworzenia kopii (lub archiwalnych) e-maila.

Jako notka poboczna, SparkPost faktycznie pozwala na wysyłanie e-maili na adresy cc, bcc i archiwalne. W tym rozwiązaniu skupiamy się na adresach archiwalnych.

* Uwaga * E-maile archiwalne 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 dziennika, które są generowane i niektórym subtelnym różnicom w tych danych. SparkPost śledzi wszystko, co dzieje się na jego serwerach i udostępnia te informacje za pomocą zdarzeń wiadomości. Te zdarzenia są przechowywane na SparkPost przez 10 dni i mogą być pobrane z serwera za pomocą APIn REST-owego o nazwie message-events, lub można poprosić SparkPost o przesyłanie tych zdarzeń do dowolnej liczby aplikacji zbierających, które chcesz. Mechanizm przesyłania odbywa się za pośrednictwem webhooks i w czasie rzeczywistym.

Obecnie istnieje 14 różnych zdarzeń, które mogą się wydarzyć na e-mailu. Oto lista aktualnych zdarzeń:

• Bounce

• ClickDelay

• Delivery

• Generation Failure

• Generation Rejection

• Initial Open

• InjectionLink Unsubscribe

• List Unsubscribe

• Open

• Out of Band

• Policy RejectionSpam Complaint

  
  

* Śledź ten link w celu uzyskania aktualnego przewodnika po referencjach z opisem każdego zdarzenia i danymi, które są udostępniane dla każdego zdarzenia.

Każde zdarzenie ma liczne pola, które odpowiadają typowi zdarzenia. Niektóre pola jak transmission_id są zawarte w każdym zdarzeniu, ale inne pola mogą być bardziej specyficzne dla zdarzenia; przykładowo, tylko otwarcie i kliknięcie mają informacje o geotagach.

Bardzo ważnym wpisem zdarzenia wiadomości do tego projektu jest transmission_id. Wszystkie wpisy zdarzeń wiadomości dla oryginalnego e-maila, zarchiwizowanego e-maila oraz dowolnych adresów cc i bcc będą miały ten sam transmission_id.

Istnieje również wspólny wpis zwany message_id, który będzie miał ten sam identyfikator dla każdego wpisu oryginalnego e-maila i zarchiwizowanego e-maila. Wszelkie adresy cc lub bcc będą miały własny identyfikator dla wpisu message_id.

Jak dotąd brzmi to świetnie i szczerze dość łatwo, ale teraz nadchodzi trudna część. Pamiętajmy, aby uzyskać archiwalny e-mail, pozwalamy SparkPostowi przesłać duplikat oryginalnego e-maila na inny adres e-mail odpowiadający skrzynce odbiorczej do której masz dostęp. Ale aby zautomatyzować to rozwiązanie i przechowywać treść e-maila, wykorzystam inną funkcję SparkPostu zwaną Inbound Email Relaying. To co robi, to przejmuje wszystkie e-maile wysyłane na konkretną domenę i przetwarza je. Przetwarzając je, rozbiera e-mail i tworzy strukturę JSON, która jest następnie dostarczana do aplikacji za pomocą webhooks. Zobacz Załącznik A dla przykładowego JSON.

Jeśli przyjrzysz się uważnie, zauważysz, że struktura JSON z przekaźnika odbierającego brakuje bardzo ważnego pola; transmission_id. Podczas gdy wszystkie wiadomości wychodzące mają transmission_id z tym samym wpisem, który łączy wszystkie dane z oryginalnego e-maila, archiwum, cc i bcc; SparkPost nie ma możliwości wiedzieć, że e-mail przechwycony przez proces odbierający jest połączony z dowolnymi wiadomościami wychodzącymi. Proces odbierający po prostu wie, że e-mail został wysłany na specyficzną domenę i ma przeanalizować e-mail. I to wszystko. Traktuje każdy e-mail wysłany na tę domenę w ten sam sposób, bez względu na to, czy jest to odpowiedź od klienta, czy e-mail archiwalny przesłany przez SparkPost.

Więc trik polega na tym, jak połączyć dane wychodzące z procesem odbierającym, który właśnie przechwycił zarchiwizowaną wersję e-maila? Postanowiłem ukryć unikalny identyfikator w treści e-maila. Jak zostanie to zrealizowane, zależy od Ciebie, ale po prostu stworzyłem pole wejściowe z włączonym tagiem ukrytym.

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

Dodałem również to pole do bloku metadanych nagłówka X-MSYS-API, który jest przekazywany do SparkPost podczas wstrzykiwania. Ten ukryty UID będzie klejem dla całego procesu i jest głównym składnikiem projektu, który będzie szczegółowo omówiony w kolejnych wpisach na blogu.

Teraz, gdy mamy UID, który połączy ten projekt i zrozumieliśmy, dlaczego jest on niezbędny, mogę zacząć budować wizję całego projektu oraz odpowiadających wpisów na blogu.

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

2. Przechwycenie wszystkich danych zdarzeń wiadomości

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

   
   

Oto prosty diagram projektu:

Pierwszy fragment kodu obejmie proces archiwizacji i przechowywanie e-maila na S3, podczas gdy drugi fragment kodu obejmie przechowywanie wszystkich danych dziennika z message-events w MySQL. Możesz spodziewać się pierwszych dwóch fragmentów kodu i wpisów na blogu na początku 2019 roku.  Jeśli masz jakiekolwiek pytania lub sugestie, śmiało przekazuj je dalej.

Wesołych wysyłek.

– Jeff

Aneks A: