Met de toename van e-mailgebruik in gereguleerde omgevingen, heb ik besloten dat het tijd is om een nieuw project te starten dat al deze elementen samenbrengt met codevoorbeelden over hoe de e-mailtekst en alle bijbehorende gegevens kunnen worden opgeslagen.
Ongeveer een jaar geleden schreef ik een blog over hoe je kopieën van e-mails kunt ophalen voor archivering en weergave, maar ik ging niet in op het daadwerkelijke opslaan van de e-mail of gerelateerde gegevens. Onlangs schreef ik een blog over het opslaan van alle evenementgegevens (d.w.z. wanneer de e-mail werd verzonden, geopend, geklikt, bounces, afmeldingen, enz.) van een e-mail voor auditdoeleinden, maar koos ervoor om geen ondersteunende code te maken.
Met de toenemende e-mailgebruik in gereguleerde omgevingen, heb ik besloten dat het tijd is om een nieuw project te starten dat al deze elementen samenbrengt met codevoorbeelden over hoe de e-mailtekst en alle bijbehorende gegevens kunnen worden opgeslagen. In het komende jaar zal ik verder bouwen aan dit project met als doel het creëren van een functionele opslag- en kijkapplicatie voor gearchiveerde e-mails en alle loginformatie die wordt geproduceerd door SparkPost. SparkPost heeft geen systeem dat de e-mailtekst archiveert, maar maakt het bouwen van een archiveringsplatform behoorlijk eenvoudig.
In deze blogserie beschrijf ik het proces dat ik heb doorlopen om de e-mailtekst op S3 (Amazon’s Simple Store Service) op te slaan en alle relevante loggegevens in MySQL voor eenvoudige kruisverwijzing. Voor productiesystemen voor archivering die robuuste database-backupstrategieën vereisen, overweeg een uitgebreide PostgreSQL backup en herstelproces te implementeren om ervoor te zorgen dat uw archiveringsgegevens goed beschermd zijn. Uiteindelijk is dit het startpunt voor het bouwen van een applicatie waarmee eenvoudig kan worden gezocht in gearchiveerde e-mails en deze vervolgens samen met de loggegevens kan worden weergegeven. De code voor dit project is te vinden in de volgende GitHub-repository: PHPArchivePlatform op GitHub
Deze eerste post in de blogserie gaat de uitdaging beschrijven en een architectuur voor de oplossing uiteenzetten. De rest van de blogs zal delen van de oplossing in detail weergeven, samen met codevoorbeelden.
De eerste stap in mijn proces was om uit te zoeken hoe ik een kopie van de naar de oorspronkelijke ontvanger verzonden e-mail kon verkrijgen. Om een kopie van de e-mailtekst te verkrijgen, moet u het volgende doen:
De e-mailtekst vastleggen voordat u de e-mail verzendt
De e-mailserver een kopie laten opslaan
Laten de e-mailserver een kopie voor u maken om op te slaan
Als de e-mailserver items toevoegt zoals linktracking of opentracking, kunt u nummer 1 niet gebruiken omdat het de open/klik-trackingwijzigingen niet weergeeft.
Dat betekent dat de server ofwel de e-mail moet opslaan of op een of andere manier een kopie van die e-mail aan u moet aanbieden voor opslag. Aangezien SparkPost geen opslagmechanisme heeft voor e-mailteksten, maar wel een manier om een kopie van de e-mail te maken, zullen we SparkPost een duplicaat van de e-mail laten sturen voor opslag in S3.
Dit gebeurt door gebruik te maken van de Archief-functie van SparkPost. De Archief-functie van SparkPost geeft de verzender de mogelijkheid om SparkPost te vertellen om een duplicaat van de e-mail naar een of meer e-mailadressen te sturen en dezelfde tracking- en openlinks te gebruiken als het origineel. De documentatie van SparkPost definieert hun Archief-functie als volgt:
Ontvangers in de archieflijst ontvangen een exacte replica van het bericht dat naar het RCPT TO-adres is verzonden. In het bijzonder zullen alle gecodeerde links bedoeld voor de RCPT TO-ontvanger identiek zijn in de archiefberichten
De enige verschillen ten opzichte van de RCPT TO-e-mail zijn dat sommige kopteksten anders zullen zijn omdat het doeladres voor de archiveringsmail anders is, maar de inhoud van de e-mail zal een exacte replica zijn!
Als u een diepere uitleg wilt, volgt u deze link naar de documentatie van SparkPost over het maken van duplicaten (of archief) kopieën van een e-mail.
Als bijzaak, SparkPost kunt daadwerkelijk e-mails verzenden naar cc, bcc en archief e-mailadressen. Voor deze oplossing richten we ons op de archieaadressen.
* Opmerking * Gearchiveerde e-mails kunnen ALLEEN worden aangemaakt wanneer e-mails in SparkPost worden geïnjecteerd via SMTP!
Nu we weten hoe we een kopie van de oorspronkelijke e-mail kunnen verkrijgen, moeten we kijken naar de loggegevens die worden geproduceerd en enkele van de subtiele nuances binnen die gegevens. SparkPost volgt alles wat er gebeurt op zijn servers en biedt die informatie aan in de vorm van berichtgebeurtenissen. Die gebeurtenissen worden 10 dagen lang op SparkPost opgeslagen en kunnen van de server worden gehaald via een RESTful API, genaamd berichtgebeurtenissen, of u kunt SparkPost laten die gebeurtenissen pushen naar verschillende verzamelapplicaties die u wenst. Het pushmechanisme wordt in realtime uitgevoerd via webhooks.
Er zijn momenteel 14 verschillende gebeurtenissen die zich bij een e-mail kunnen voordoen. Hier is een lijst van de huidige gebeurtenissen:
Bounce
ClickDelay
Delivery
Generation Failure
Generation Rejection
Initial Open
InjectionLink Unsubscribe
List Unsubscribe
Open
Out of Band
Policy RejectionSpam Complaint
* Volg deze link voor een actuele referentiegids voor een beschrijving van elke gebeurtenis, samen met de gegevens die voor elke gebeurtenis worden gedeeld.
Elke gebeurtenis heeft talloze velden die overeenkomen met het type gebeurtenis. Sommige velden zoals de transmission_id zijn in elke gebeurtenis te vinden, maar andere velden kunnen specifieker voor de gebeurtenis zijn; bijvoorbeeld, alleen open- en klikgebeurtenissen hebben geotag-informatie.
Een zeer belangrijke invoer van berichtengebeurtenissen voor dit project is de transmission_id. Alle invoers van berichtengebeurtenissen voor de oorspronkelijke e-mail, de gearchiveerde e-mail, en alle cc en bcc adressen zullen dezelfde transmission_id delen.
Er is ook een gemeenschappelijke invoer genaamd de message_id die dezelfde id zal hebben voor elke invoer van de oorspronkelijke e-mail en de gearchiveerde e-mail. Elk cc- of bcc-adres zal zijn eigen id hebben voor de message_id invoer.
Tot zover klinkt dit geweldig en eigenlijk vrij eenvoudig, maar nu komt het uitdagende gedeelte. Onthoud, om de archiefe-mail te verkrijgen, laten we SparkPost een duplicaat van de oorspronkelijke e-mail naar een ander e-mailadres sturen, dat overeenkomt met een inbox waartoe u toegang heeft. Maar om deze oplossing te automatiseren en de e-mailtekst op te slaan, ga ik een andere functie van SparkPost gebruiken, genaamd Inbound Email Relaying. Wat dat doet, is alle e-mails die naar een specifiek domein worden verzonden, ontvangen en verwerken. Door ze te verwerken, haalt het de e-mail uit elkaar en maakt een JSON-structuur aan die vervolgens via een webhook naar een applicatie wordt verzonden. Zie Appendix A voor een voorbeeld van JSON.
Als u goed kijkt, zult u merken dat de JSON-structuur van de binnenkomende relay een heel belangrijk veld mist; de transmission_id. Terwijl alle uitgaande e-mails de transmission_id met dezelfde invoer hebben, die alle gegevens van de oorspronkelijke e-mail, archief, cc, en bcc adressen samen bindt; heeft SparkPost geen manier om te weten dat de e-mail die door het binnenkomende proces is vastgelegd, is verbonden met een van de uitgaande e-mails. Het binnenkomende proces weet simpelweg dat er een e-mail is verzonden naar een specifiek domein en de e-mail moet worden geparseerd. Dat is alles. Het behandelt elke e-mail die naar dat domein wordt verzonden op dezelfde manier, of het nu een antwoord van een klant is of de archiefe-mail die door SparkPost is verzonden.
Dus, de truc is; hoe verbind je de uitgaande gegevens met het binnenkomende proces dat net de gearchiveerde versie van de e-mail heeft gepakt? Wat ik heb besloten is een unieke id in de body van de e-mail te verbergen. Hoe dit wordt gedaan, is aan u, maar ik heb simpelweg een invoerveld met de verborgen tag gecreëerd.
Ik heb dat veld ook toegevoegd in het metadata-blok van de X-MSYS-API-header die tijdens injectie naar SparkPost wordt verzonden. Deze verborgen UID wordt de lijm van het hele proces, en is een hoofdcomponent van het project en zal in de volgende blogposts uitvoerig besproken worden.
Nu we de UID hebben die dit project samenbrengt en begrijpen waarom het nodig is, kan ik beginnen met het opbouwen van de visie van het algehele project en de bijbehorende blogposts.
Vastleggen en opslaan van de archiefe-mail met een database-invoer voor zoeken/indexering
Alle berichtengegevens vastleggen
Een applicatie maken om de e-mail en alle bijbehorende gegevens te bekijken
Hier is een eenvoudig diagram van het project:
De eerste codeversie zal het archiveringsproces en het opslaan van de e-mail op S3 behandelen, terwijl de tweede codeversie het opslaan van alle loggegevens van berichtengebeurtenissen in MySQL zal behandelen. U kunt de eerste twee codeversies en blogposts verwachten ergens begin 2019. Als u vragen of suggesties heeft, laat het me gerust weten.
Gelukkig Verzenden.
– Jeff
Bijlage A:
