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 ben niet ingegaan op het feitelijke 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, klikken, bounces, uitschrijvingen, enzovoort) van een e-mail voor auditdoeleinden, maar koos ervoor om geen ondersteunende code te maken.
Met de toename van e-mailgebruik in gereguleerde omgevingen, heb ik besloten dat het tijd is om een nieuw project te starten dat dit alles samenbrengt met codevoorbeelden over hoe je de e-mailinhoud en alle bijbehorende gegevens kunt opslaan. In het komende jaar zal ik doorgaan met het opbouwen van dit project met als doel een functionele opslag- en weergave-applicatie voor gearchiveerde e-mails en alle loginformatie die door SparkPost wordt geproduceerd te creëren. SparkPost heeft geen systeem dat de e-mailinhoud archiveert, maar het maken van een archiveringsplatform is vrij eenvoudig.
In deze blogserie zal ik het proces beschrijven dat ik doorlopen heb om de e-mailinhoud op S3 (Amazon’s Simple Store Service) op te slaan en alle relevante loggegevens op MySQL voor eenvoudige kruisverwijzing. Voor productiesystemen voor archivering die robuuste database-backupstrategieën vereisen, overweeg een uitgebreid PostgreSQL backup- en herstelproces te implementeren om ervoor te zorgen dat uw archiveringsgegevens goed beschermd zijn. Dit is uiteindelijk het beginpunt voor het bouwen van een applicatie waarmee eenvoudig gezocht kan worden in gearchiveerde e-mails en die e-mails samen met de evenement (log) gegevens weergegeven kan worden. De code voor dit project is te vinden in de volgende GitHub-repository: https://github.com/jeff-goldstein/PHPArchivePlatform
Deze eerste bijdrage aan de blogserie gaat de uitdaging beschrijven en een architectuur voor de oplossing schetsen. De rest van de blogs zullen delen van de oplossing in detail beschrijven samen met codevoorbeelden.
De eerste stap in mijn proces was uit te zoeken hoe ik een kopie van de e-mail die naar de oorspronkelijke ontvanger werd gestuurd, kon verkrijgen. Om een kopie van de e-mailinhoud te verkrijgen, moet je of:
De e-mailinhoud vastleggen voordat de e-mail wordt verzonden
De e-mailserver een kopie laten opslaan
De e-mailserver een kopie voor u laten maken om op te slaan
Als de e-mailserver items toevoegt zoals linktracking of opentracking, kunt u #1 niet gebruiken omdat het de wijzigingen in open/click tracking niet zal weergeven.
Dat betekent dat ofwel de server de e-mail moet opslaan of op de een of andere manier een kopie van die e-mail aan u moet aanbieden voor opslag. Aangezien SparkPost geen opslagmechanisme voor e-maillichamen heeft, maar wel een manier heeft om een kopie van de e-mail te maken, laten we SparkPost ons een duplicaat van de e-mail sturen zodat we het in S3 kunnen opslaan.
Dit wordt gedaan door gebruik te maken van de Archive-functie van SparkPost. De Archive-functie van SparkPost geeft de afzender de mogelijkheid om SparkPost te vertellen om een duplicaat van de e-mail naar één of meer e-mailadressen te sturen en dezelfde tracking- en openlinks te gebruiken als het origineel. SparkPost-documentatie definieert hun Archive-functie als volgt:
Ontvangers in de archieflijst zullen een exacte replica van het bericht ontvangen dat naar het RCPT TO-adres is gestuurd. In het bijzonder zullen alle gecodeerde links die bestemd zijn voor de RCPT TO-ontvanger identiek zijn in de archiefberichten
De enige verschillen met de RCPT TO-e-mail zijn dat sommige van de headers anders zullen zijn, aangezien het doeladres voor de archiverings-e-mail anders is, maar de inhoud van de e-mail zal een exacte replica zijn!
Als u een diepere uitleg wilt, volgt hier een link naar de SparkPost-documentatie over het maken van dubbele (of archief) kopieën van een e-mail.
Als een kanttekening, SparkPost stelt u eigenlijk in staat om e-mails te versturen naar cc, bcc, en archief e-mailadressen. Voor deze oplossing richten we ons op de archiefadressen.
* Let op * Gearchiveerde e-mails kunnen ALLEEN worden gemaakt wanneer e-mails in SparkPost via SMTP worden geïnjecteerd!
Nu we weten hoe we een kopie van de originele e-mail kunnen verkrijgen, moeten we naar de loggegevens kijken die worden geproduceerd en enkele van de subtiele nuances binnen die gegevens. SparkPost volgt alles wat er op zijn servers gebeurt en biedt die informatie aan u aan in de vorm van bericht-gebeurtenissen. Die gebeurtenissen worden gedurende 10 dagen op SparkPost opgeslagen en kunnen van de server worden gehaald via een RESTful API genaamd bericht-gebeurtenissen, of u kunt SparkPost die gebeurtenissen naar een willekeurig aantal verzamelapplicaties laten pushen die u wenst. Het pushmechanisme wordt gedaan via webhooks en gebeurt in real time.
Momenteel zijn er 14 verschillende gebeurtenissen die bij een e-mail kunnen optreden. Hier is een lijst van de huidige gebeurtenissen:
Bounce
ClickDelay
Levering
Generatiefout
Generatie afwijzing
Eerste Open
InjectieLink Uitschrijven
Lijst Uitschrijven
Openen
Buiten band
Beleid AfwijzingSpam Klacht
* Volg deze link voor een bijgewerkte referentiegids met een beschrijving van elke gebeurtenis samen met de gegevens die voor elke gebeurtenis worden gedeeld.
Elke gebeurtenis heeft talrijke velden die overeenkomen met het type gebeurtenis. Sommige velden zoals het transmission_id zijn te vinden in elke gebeurtenis, maar andere velden kunnen meer specifiek voor een gebeurtenis zijn; bijvoorbeeld, alleen open- en klikgebeurtenissen hebben geotaginformatie.
Een zeer belangrijk bericht-evenement-item voor dit project is de transmission_id. Alle bericht-evenement-items voor de originele e-mail, gearchiveerde e-mail en alle cc- en bcc-adressen zullen dezelfde transmission_id delen.
Er is ook een gemeenschappelijk item genaamd de message_id die dezelfde id zal hebben voor elk item van de originele e-mail en de gearchiveerde e-mail. Alle cc- of bcc-adressen krijgen hun eigen id voor het message_id-item.
Tot nu toe klinkt dit geweldig en eerlijk gezegd vrij eenvoudig, maar nu komt het uitdagende deel. Vergeet niet dat om de archief-e-mail te verkrijgen, we SparkPost een duplicaat van de originele e-mail naar een ander e-mailadres laten sturen dat overeenkomt met een inbox waarvoor u toegang heeft. Maar om deze oplossing te automatiseren en het e-maillichaam op te slaan, ga ik een andere functie van SparkPost gebruiken, namelijk Inbound Email Relaying. Wat dat doet, is alle e-mails die naar een specifiek domein worden gestuurd, opnemen en verwerken. Door ze te verwerken wordt de e-mail opgedeeld en wordt er een JSON-structuur gecreëerd die vervolgens naar een applicatie wordt gestuurd via een webhook. Zie Bijlage A voor een voorbeeld van JSON.
Als je heel goed kijkt, zul je merken dat in de JSON-structuur van de inkomende relais een zeer belangrijk veld ontbreekt; de transmission_id. Terwijl alle uitgaande e-mails de transmission_id hebben met dezelfde invoer die alle gegevens van de originele e-mail, het archief, de cc en bcc-adressen bindt; heeft SparkPost geen manier om te weten dat de e-mail die door het inkomende proces is vastgelegd, is gekoppeld aan een van de uitgaande e-mails. Het inkomende proces weet simpelweg dat een e-mail naar een specifiek domein is gestuurd en om de e-mail te parseren. Dat is het. Het behandelt elke e-mail die naar dat domein is verzonden op dezelfde manier, of het nu een antwoord van een klant is of de gearchiveerde e-mail die door SparkPost is verzonden.
Dus de truc is; hoe verbind je de uitgaande gegevens met het inkomende proces dat zojuist de gearchiveerde versie van de e-mail heeft opgepikt? Wat ik heb besloten te doen, is een unieke ID in de body van de e-mail verbergen. Hoe dit wordt gedaan, is aan jou, maar ik heb simpelweg een invoerveld gemaakt met het verborgen label ingeschakeld.
Ik heb dat veld ook toegevoegd in het metadata-blok van de X-MSYS-API-header die tijdens injectie aan SparkPost wordt doorgegeven. Deze verborgen UID zal uiteindelijk de lijm van het hele proces zijn en is een belangrijk onderdeel van het project en zal uitgebreid worden besproken in de volgende blogposts.
Nu we de UID hebben die dit project samenbrengt en begrijpen waarom het nodig is, kan ik beginnen met het bouwen van de visie van het gehele project en de bijbehorende blogberichten.
Het vastleggen en opslaan van de archief e-mail samen met een database-invoer voor zoeken/indexeren
Alle berichtgebegevens vastleggen
Een applicatie maken om de e-mail en alle bijbehorende gegevens te bekijken
Hier is een eenvoudig diagram van het project:
De eerste code-uitzending zal het archiveringsproces en het opslaan van de e-mail op S3 bestrijken, terwijl de tweede code-uitzending het opslaan van alle loggegevens van berichtgebeurtenissen in MySQL zal behandelen. U kunt de eerste twee codeuitzendingen en blogitems verwachten ergens begin 2019. Mocht u vragen of suggesties hebben, dan hoor ik ze graag.
Fijne verzending.
– Jeff
Bijlage A:
