Około roku temu napisałem bloga na temat pobierania kopii e-maili do archiwizacji i przeglądania, ale nie omówiłem właściwego przechowywania e-maili ani związanych z nimi danych, a ostatnio napisałem blog na temat przechowywania wszystkich danych o wydarzeniach (tj. kiedy e-mail został wysłany, otwarcia, kliknięcia, odbicia, wypisania się itp.) związanych z e-mailem w celu audytu, ale postanowiłem nie tworzyć żadnego kodu wspomagającego.
Ze względu na wzrost użycia e-maili w środowiskach regulacyjnych, postanowiłem, że nadszedł czas, aby rozpocząć nowy projekt, który połączy wszystkie te elementy z przykładowymi kodami dotyczącymi przechowywania treści e-maila i wszystkich związanych z nim danych. W ciągu następnego roku będę kontynuować rozwój tego projektu, mając na celu stworzenie działającej aplikacji do przechowywania i przeglądania archiwalnych e-maili oraz wszystkich informacji logowanych generowanych przez SparkPost. SparkPost nie ma systemu, który archiwizuje treść e-maila, ale ułatwia budowę platformy archiwizacji.
W tej serii blogów opiszę proces, przez który przeszedłem, aby przechować treść e-maila na S3 (Amazon Simple Store Service) i wszystkie odpowiednie dane logów w MySQL w celu łatwego odniesienia. Ostatecznie, to jest punkt wyjścia do budowy aplikacji, która umożliwi łatwe przeszukiwanie archiwalnych e-maili, a następnie wyświetlanie tych e-maili wraz z danymi o wydarzeniach (log). Kod dla tego projektu można znaleźć w następującym repozytorium GitHub: https://github.com/jeff-goldstein/PHPArchivePlatform
Ten pierwszy wpis serii blogów opisze wyzwanie i przedstawi architekturę rozwiązania. Pozostałe blogi szczegółowo opiszą części rozwiązania wraz z przykładami kodu.
Pierwszym krokiem w moim procesie było ustalenie, w jaki sposób uzyskam kopię e-maila wysłanego do pierwotnego odbiorcy. Aby uzyskać kopię treści e-maila, musisz:
Przechwycić treść e-maila przed jego wysłaniem
Uzyskać od serwera e-mailowego przechowanie kopii
Sprawić, aby serwer e-mailowy utworzył dla Ciebie kopię do przechowania
Jeżeli serwer e-mailowy dodaje elementy takie jak śledzenie linków lub otwarć, nie możesz użyć #1, ponieważ nie będzie odzwierciedlać zmian śledzenia 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 do przechowywania treści e-maili, ale posiada sposób na utworzenie kopii e-maila, poprosimy SparkPost o wysłanie nam duplikatu e-maila do przechowania w S3.
To realizuje się za pomocą funkcji Archiwum SparkPost. Funkcja Archiwum SparkPost umożliwia nadawcy poinformowanie SparkPost, aby wysłać duplikat e-maila na jeden lub więcej adresów e-mail i użyć tych samych linków śledzenia i otwarcia, co oryginał. Dokumentacja SparkPost opisuje ich funkcję Archiwum w następujący sposób:
Odbiorcy na liście archiwum otrzymają dokładną replikę wiadomości, która została wysłana na adres RCPT TO. W szczególności wszystkie zakodowane linki przeznaczone dla odbiorcy RCPT TO będą identyczne w wiadomościach archiwalnych
Jedynymi różnicami w porównaniu do e-maila RCPT TO są pewne nagłówki, które będą różne, ponieważ adres docelowy dla e-maila archiwizującego 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.
Jako uwaga, SparkPost pozwala na wysyłanie e-maili na adresy cc, bcc i archiwalne. W tym rozwiązaniu koncentrujemy się na adresach archiwalnych.
* Uwaga * Wysłane e-maile mogą być TWORZONE TYLKO podczas wstrzykiwania 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 subtelnym niuansom w tych danych. SparkPost śledzi wszystko, co dzieje się na jego serwerach i oferuje Ci te informacje w postaci zdarzeń wiadomości. Zdarzenia te są przechowywane w SparkPost przez 10 dni i mogą być pobierane z serwera za pośrednictwem interfejsu API RESTful o nazwie zdarzenia wiadomości, lub możesz poprosić SparkPost o przesyłanie tych zdarzeń do dowolnej liczby aplikacji zbierających, które chcesz. Mechanizm push działa za pomocą webhooków i jest realizowany w czasie rzeczywistym.
Obecnie istnieje 14 różnych zdarzeń, które mogą wystąpić w przypadku e-maila. Oto lista obecnych zdarzeń:
Odbicie
Opóźnienie kliknięcia
Dostarczenie
Niepowodzenie generacji
Odmowa generacji
Pierwsze otwarcie
Wypisanie z linku injekcji
Wypisanie z listy
Otwarcie
Poza pasmem
Odmowa polityki - skarga na spam
* Postępuj zgodnie z tym linkiem, aby uzyskać aktualny przewodnik dotyczący opisu każdego zdarzenia wraz z danymi, które są udostępniane dla każdego zdarzenia.
Każde zdarzenie zawiera liczne pola odpowiadające typowi 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 zdarzenia otwarcia i kliknięcia mają informacje geotagowe.
Jednym bardzo ważnym wpisem zdarzenia wiadomości w tym projekcie jest transmission_id. Wszystkie wpisy zdarzeń wiadomości dla oryginalnego e-maila, archiwalnego e-maila i wszelkich adresów cc i bcc podzielą ten sam transmission_id.
Istnieje również wspólny wpis o nazwie message_id który będzie miał ten sam identyfikator dla każdego wpisu oryginalnego e-maila i archiwalnego e-maila. Wszelkie adresy cc lub bcc będą miały swój własny identyfikator dla wpisu message_id .
Jak dotąd brzmi to świetnie i szczerze mówiąc dość łatwo, ale teraz jest trudna część. Pamiętaj, aby uzyskać e-mail archiwalny, prosimy SparkPost o wysłanie duplikatu oryginalnego e-maila na inny adres e-mail, który odpowiada niektóremu skrzynce pocztowej, do której masz dostęp. Ale aby zautomatyzować to rozwiązanie i przechować treść e-maila, zamierzam wykorzystać inną funkcję SparkPost o nazwie Inbound Email Relaying. To, co to robi, to przyjmuje wszystkie e-maile wysyłane na konkretną domenę i przetwarza je. Przez przetwarzanie rozdziela e-mail i tworzy strukturę JSON, która jest następnie dostarczana do aplikacji za pośrednictwem webhooka. Zobacz Dodatek A, aby zobaczyć przykład JSON.
Jeśli przyjrzysz się uważnie, zauważysz, że struktura JSON z abrangancia jest pozbawiona 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; SparkPost nie ma sposobu, aby wiedzieć, że e-mail uchwycony przez proces przychodzący jest połączony z jakimkolwiek z wychodzących e-maili. Proces przychodzący po prostu wie, że e-mail został wysłany do określonej domeny i ma za zadanie analizować e-mail. To tyle. Traktuje jakikolwiek e-mail wysłany do tej domeny w ten sam sposób, niezależnie od tego, czy jest to odpowiedź od klienta, czy e-mail archiwalny wysłany przez SparkPost.
Więc sztuczka polega na tym, jak połączyć dane wychodzące z procesem przychodzącym, który właśnie przechwycił archiwalną wersję e-maila? Co postanowiłem zrobić, to ukryć unikalny identyfikator w treści e-maila. Jak to zrobić zależy od Ciebie, ale ja po prostu stworzyłem pole wejściowe z włączonym tagiem ukrytym.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Dodano także to pole do bloku metadanych nagłówka X-MSYS-API, który jest przekazywany do SparkPost podczas wstrzykiwania. Ten ukryty UID stanie się spoiwem do całego procesu i jest głównym komponentem projektu, o którym szczegółowo będziemy omawiać 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 wpisów na blogu.
Przechwytywanie i przechowywanie e-maila archiwalnego wraz z wpisem do bazy danych w celu przeszukiwania/indeksowania
Przechwytywanie wszystkich danych zdarzeń wiadomości
Utworzenie aplikacji do przeglądania e-maila i wszystkich powiązanych danych
Oto prosty diagram projektu:
Pierwszy zrzut kodu obejmie proces archiwizacji i przechowywania e-maila 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 na blogu wkrótce na początku 2019. Jeśli masz jakiekolwiek pytania lub sugestie, nie wahaj się przesłać ich do nas.
Szczęśliwego wysyłania.
– Jeff
Dodatek A:
