Około rok temu napisałem blog o tym, jak uzyskać kopie e-maili do archiwizacji i przeglądania, ale nie poruszyłem tematu faktycznego przechowywania e-maili ani powiązanych danych. Niedawno napisałem blog o przechowywaniu wszystkich danych dotyczących zdarzeń (np. kiedy e-mail został wysłany, otwarcia, kliknięcia, odbicia, wypisania się itd.) na e-mailu w celu audytu, ale zdecydowałem się nie tworzyć żadnego wspomagającego kodu.

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

W tej serii blogów opiszę proces, przez który przeszedłem, aby przechowywać treść e-maili na S3 (Simple Store Service Amazon) oraz wszystkie istotne dane logów w MySQL w celu łatwego odniesienia się do nich. Dla systemów archiwizacji produkcyjnych, które wymagają solidnych strategii tworzenia kopii zapasowych baz danych, rozważ wdrożenie kompleksowego procesu backupu i przywracania w PostgreSQL w celu ochrony danych archiwalnych. Ostatecznie jest to punkt wyjścia do zbudowania aplikacji, która umożliwi łatwe wyszukiwanie zarchiwizowanych e-maili, a następnie wyświetlanie tych e-maili wraz z danymi zdarzeń (logi). Kod tego projektu można znaleźć w następującym repozytorium GitHub: PHPArchivePlatform on GitHub

Ten pierwszy wpis w serii blogów opisuje wyzwanie i nakreśla architekturę rozwiązania. Reszta blogów będzie szczegółowo opisywać części rozwiązania wraz z przykładowymi kodami.

Pierwszym krokiem mojego procesu było ustalenie, jak uzyskać kopię e-maila wysłanego do pierwotnego adresata. Aby uzyskać kopię treści e-maila, musisz:

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

2. Zlecić serwerowi e-maili przechowanie kopii

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

Jeżeli serwer e-maili dodaje elementy takie jak śledzenie linków czy otwarć, nie możesz użyć #1, ponieważ nie odda to zmian związanych ze śledzeniem otwarć/kliknięć.

Oznacza to, że serwer musi przechowywać e-mail lub w jakiś sposób dostarczyć kopię e-maila do przechowania. Skoro SparkPost nie posiada mechanizmu przechowywania treści e-maili, ale ma sposób na utworzenie kopii e-maila, będziemy prosić SparkPost o wysłanie nam duplikatu e-maila do przechowania w S3.

Jest to realizowane przy użyciu ArcFeature SparkPost. Funkcja Archiwum SparkPost pozwala nadawcy poinstruować SparkPost, aby wysłał duplikat e-maila na jeden lub więcej adresów e-mail oraz użył tych samych linków śledzących i otwarć, co oryginał. Dokumentacja SparkPost definiuje ich funkcję archiwum w następujący sposób:

Odbiorcy na liście archiwalnej otrzymają 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 archiwalnych

Jedynymi różnicami w porównaniu z e-mailem RCPT TO są różnice w nagłówkach, ponieważ docelowy adres e-mail archiwizacji 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 kopii (lub archiwizowania) e-maila.

Na marginesie, SparkPost faktycznie pozwala na wysyłanie e-maili na adresy cc, bcc oraz archiwalne. Dla tego rozwiązania skupiamy się na adresach archiwalnych.

* Wskazówka * Zarchiwizowane e-maile można utworzyć TYLKO podczas wprowadzania e-maili do SparkPost przez SMTP!

Teraz, gdy wiemy, jak uzyskać kopię oryginalnego e-maila, musimy przyjrzeć się danym logów, które są generowane, oraz niektórym subtelnościom w tych danych. SparkPost śledzi wszystko, co dzieje się na jego serwerach, i udostępnia te informacje w formie message-events. Te zdarzenia są przechowywane na SparkPost przez 10 dni i można je pobrać z serwera za pomocą RESTful API o nazwie message-events, lub SparkPost może przesyłać te zdarzenia do dowolnej liczby aplikacji zbierających. Mechanizm przesyłania jest realizowany za pomocą webhooks i odbywa się w czasie rzeczywistym.

Obecnie istnieje 14 różnych zdarzeń, które mogą mieć miejsce w e-mailu.  Oto lista obecnych zdarzeń:

• Bounce

• ClickDelay

• Delivery

• Generation Failure

• Generation Rejection

• Initial Open

• InjectionLink Unsubscribe

• List Unsubscribe

• Open

• Out of Band

• Policy RejectionSpam Complaint

  
  

* Skorzystaj z tego linku do aktualnego przewodnika referencyjnego, który opisuje każde zdarzenie wraz z danymi udostępnionymi dla każdego zdarzenia.

Każde zdarzenie ma liczne pola dopasowane do rodzaju zdarzenia. Niektóre pola, takie jak transmission_id są obecne w każdym zdarzeniu, ale inne pola mogą być bardziej specyficzne dla zdarzenia; na przykład, tylko otwarte i kliknięte zdarzenia zawierają informacje o geotagach.

Bardzo ważnym rekordem zdarzeń wiadomości w tym projekcie jest transmission_id. Wszystkie rekordy zdarzeń wiadomości dla oryginalnego e-maila, zarchiwizowanego e-maila oraz wszelkich adresów cc i bcc będą miały wspólny transmission_id.

Jest również wspólny rekord o nazwie message_id który będzie miał ten sam id dla każdego wpisu oryginalnego e-maila i zarchiwizowanego e-maila. Wszelkie adresy cc lub bcc będą miały własny id dla wpisu message_id.

Do tej pory wszystko wydaje się świetne, a mówiąc szczerze stosunkowo łatwe, ale teraz zaczynają się trudności. Pamiętaj, aby uzyskać archiwalny e-mail, poprosiliśmy SparkPost o wysłanie duplikatu oryginalnego e-maila na inny adres e-mail, który odpowiada jakiemuś skrzynce odbiorczej, do której masz dostęp. Ale aby zautomatyzować to rozwiązanie i przechowywać treść e-maila, będę używał innej funkcji SparkPost o nazwie Inbound Email Relaying. Co to robi, to przetwarza wszystkie e-maile wysyłane na określoną domenę. Przez przetwarzanie rozbija e-mail na części i tworzy strukturę JSON, która następnie jest dostarczana do aplikacji za pośrednictwem webhooka. Zobacz Załącznik A dla przykładowego JSON.

Jeżeli przyjrzycie się bardzo dokładnie, zauważycie, że struktura JSON z procesu odbioru brakuje bardzo ważnego pola; transmission_id. Podczas gdy wszystkie wychodzące e-maile mają transmission_id z tym samym wpisem, który łączy wszystkie dane z oryginalnego e-maila, archiwum, cc i bcc adresów; SparkPost nie ma sposobu na poznanie, że e-mail przechwycony przez proces wejściowy jest połączony z jakimkolwiek z wychodzących e-maili. Proces odbioru po prostu wie, że e-mail został wysłany na określoną domenę i do jej analizy. I tyle. Traktuje wszelkie e-maile wysyłane na tę domenę w ten sam sposób, czy to odpowiedź od klienta, czy archiwum e-mail wysłane przez SparkPost.

Więc pytanie jest: jak połączyć dane wyjściowe z procesem wejściowym, który właśnie przejął zarchiwizowaną wersję e-maila? To, co zdecydowałem się zrobić, to ukryć unikalny identyfikator w treści e-maila. Jak to się robi, zależy od Ciebie, ale po prostu utworzyłem pole wejściowe z włączoną tagiem ukrytym.

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

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

Kiedy posiadamy UID, który będzie łączył ten projekt, rozumiem dlaczego jest to konieczne, mogę zacząć budować wizję ogólnego projektu i odpowiadających postów na blogu.

1. Przechwytywanie i przechowywanie archiwalnego e-maila wraz z wpisem w bazie danych w celu wyszukiwania/indeksowania

2. Przechwytywanie wszystkich danych zdarzeń wiadomości

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

   
   

Oto prosty diagram project:

Pierwszy zrzut kodu będzie obejmować proces archiwizacji i przechowywanie e-mailu na S3, podczas gdy drugi zrzut kodu będzie obejmować przechowywanie wszystkich danych logów z wydarzeń wiadomości w MySQL. Możesz spodziewać się pierwszych dwóch zrzutów kodu i wpisów blogowych na początku 2019.  Jeśli masz jakiekolwiek pytania lub sugestie, śmiało przekaż je.

Wesołych Wysłań.

– Jeff

Załącznik A: