Ongeveer een jaar geleden schreef ik een blog over hoe je kopieën van e-mails kunt ophalen voor archivering en bekijken, maar ik besprak niet het daadwerkelijke opslaan van de e-mail of gerelateerde gegevens. Onlangs schreef ik een blog over het opslaan van alle gebeurtenisgegevens (d.w.z. wanneer de e-mail werd verzonden, geopend, geklikt, bounced, afgemeld, enz.) op 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 alle elementen samenbrengt met codevoorbeelden over hoe je de e-mailinhoud en alle bijbehorende gegevens kunt opslaan. In het komende jaar zal ik blijven werken aan dit project met als doel het creëren van een werkende opslag- en weergaveapplicatie voor gearchiveerde e-mails en alle loggegevens die door SparkPost worden geproduceerd. SparkPost heeft geen systeem dat de e-mailinhoud archiveert, maar het maakt het vrij eenvoudig om een archiveringsplatform te bouwen.
In deze blogserie zal ik het proces beschrijven dat ik heb doorlopen om de e-mailinhoud op S3 (Amazon's Simple Store Service) op te slaan en alle relevante loggegevens in MySQL voor eenvoudige kruiskoppelingen. Uiteindelijk is dit het startpunt voor het bouwen van een applicatie waarmee je gemakkelijk naar gearchiveerde e-mails kunt zoeken en deze e-mails samen met de gebeurtenis- (log)gegevens kunt weergeven. De code voor dit project is te vinden in de volgende GitHub-repository: https://github.com/jeff-goldstein/PHPArchivePlatform
Deze eerste blogpost van de serie gaat de uitdaging beschrijven en een architectuur voor de oplossing uitzetten. De rest van de blogs zal delen van de oplossing gedetailleerd uitleggen, samen met codevoorbeelden.
De eerste stap in mijn proces was om uit te zoeken hoe ik een kopie van de e-mail naar de oorspronkelijke ontvanger kon verkrijgen. Om een kopie van de e-mailinhoud te bemachtigen, moet je:
De e-mailinhoud vastleggen voordat je de e-mail verstuurt
De e-mailserver een kopie laten opslaan
De e-mailserver een kopie voor jou laten maken om op te slaan
Als de e-mailserver items toevoegt zoals linktracking of opentracking, kun je #1 niet gebruiken, omdat het de open-/kliktracking niet zal weerspiegelen.
Dat betekent dat de server de e-mail moet opslaan of op de een of andere manier een kopie van die e-mail aan jou moet aanbieden voor opslag. Aangezien SparkPost geen opslagsysteem heeft voor e-mailinhouden, 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 die we op S3 kunnen opslaan.
Dit kan worden gedaan door gebruik te maken van de Archief-functie van SparkPost. De Archief-functie van SparkPost geeft de verzender de mogelijkheid om SparkPost te vertellen een duplicaat van de e-mail naar een of meer e-mailadressen te sturen en dezelfde tracking en open links te gebruiken als het origineel. De documentatie van SparkPost definieert hun Archief-functie op de volgende manier:
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 die zijn bedoeld voor de RCPT TO-ontvanger identiek zijn aan die in de archiefberichten.
De enige verschillen van de RCPT TO e-mail zijn dat sommige headers anders zullen zijn, omdat het doeladres voor de archiefe-mail anders is, maar de inhoud van de e-mail zal een exacte replica zijn!
Als je een diepere uitleg wilt, is hier een link naar de SparkPost documentatie over het maken van duplicaat- (of archief) kopieën van een e-mail.
Terzijde, SparkPost staat je daadwerkelijk toe om e-mails te versturen naar cc-, bcc- en archief-e-mailadressen. Voor deze oplossing concentreren we ons op de archiefadressen.
* Let op * Gearchiveerde e-mails kunnen ALLEEN worden gemaakt bij het injecteren van e-mails in SparkPost via SMTP!
Nu we weten hoe we een kopie van de oorspronkelijke e-mail kunnen bemachtigen, moeten we kijken naar de loggegevens 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 jou aan in de vorm van berichtgebeurtenissen. Die gebeurtenissen worden voor 10 dagen op SparkPost opgeslagen en kunnen via een RESTful API genaamd berichtgebeurtenissen van de server worden opgehaald, of je kunt SparkPost die gebeurtenissen laten pushen naar een aantal verzamelende applicaties die je wenst. Het push-mechanisme is via webhooks en gebeurt in realtime.
Momenteel zijn er 14 verschillende gebeurtenissen die een e-mail kunnen overkomen. Hier is een lijst van de huidige gebeurtenissen:
Bounce (Terugkaatsing)
ClickDelay (Klik Vertraging)
Delivery (Bezorging)
Generation Failure (Generatiefout)
Generation Rejection (Generatieafwijzing)
Initial Open (Eerste Open)
InjectionLink Unsubscribe (Afmelden via InjectieLink)
List Unsubscribe (Afmelden van Lijst)
Open (Openen)
Out of Band (Buiten Band)
Policy RejectionSpam Complaint (Beleid Afwijzing Spam Klacht)
* Volg deze link voor een up-to-date referentiegids voor een beschrijving van elke gebeurtenis samen met de gegevens die voor elke gebeurtenis worden gedeeld.
Elke gebeurtenis heeft tal van velden die overeenkomen met het type gebeurtenis. Sommige velden zoals de transmission_id zijn in elke gebeurtenis te vinden, maar andere velden kunnen meer specifiek voor een gebeurtenis zijn; bijvoorbeeld, alleen open- en klikgebeurtenissen hebben geotrackinginformatie.
Een zeer belangrijke invoer van berichtgebeurtenissen voor dit project is de transmission_id. Alle invoeren van berichtgebeurtenissen voor de originele e-mail, 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 originele e-mail en de gearchiveerde e-mail. Elke cc of bcc adressen zullen hun eigen id voor de message_id hebben.
Tot nu toe klinkt dit geweldig en eerlijk gezegd vrij eenvoudig, maar nu komt het uitdagende deel. Onthoud dat om de gearchiveerde e-mail te krijgen, we SparkPost een duplicaat van de originele e-mail naar een ander e-mailadres laten sturen dat overeenkomt met een inbox waartoe je toegang hebt. Maar om deze oplossing te automatiseren en de e-mailinhoud op te slaan, ga ik een andere functie van SparkPost gebruiken die Inbound Email Relaying wordt genoemd. Wat dat doet, is alle e-mails naar een specifiek domein nemen en deze verwerken. Door ze te verwerken wordt de e-mail uit elkaar gehaald en wordt een JSON-structuur gecreëerd die vervolgens via een webhook naar een applicatie wordt geleverd. Zie Bijlage A voor een voorbeeld-JSON.
Als je goed kijkt, zul je merken dat de JSON-structuur van de inbound relay een zeer belangrijk veld mist; de transmission_id. Terwijl alle uitgaande e-mails de transmission_id hebben met dezelfde invoer die alle gegevens van de originele e-mail, archief, cc en bcc-adressen bindt; heeft SparkPost geen manier om te weten dat de e-mail die door het inbound proces is vastgelegd, is gekoppeld aan een van de uitgaande e-mails. Het inbound proces weet simpelweg dat er een e-mail naar een specifiek domein is gestuurd en om de e-mail te verwerken. Dat is alles. Het zal elke e-mail die naar dat domein wordt gestuurd op dezelfde manier behandelen, of het nu een antwoord van een klant is of de archiefe-mail die door SparkPost wordt verzonden.
Dus de truc is: hoe verbind je de uitgaande gegevens met het inbound proces dat net de gearchiveerde versie van de e-mail heeft opgepikt? Wat ik besloot te doen, is een unieke id in de inhoud van de e-mail te verbergen. Hoe dit wordt gedaan, is aan jou, maar ik creëerde eenvoudig een invoerveld met de verborgen tag geactiveerd.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
Ik heb dat veld ook toegevoegd aan het metadata-blok van de X-MSYS-API header die tijdens de injectie naar SparkPost wordt gestuurd. Deze verborgen UID zal de lijm zijn voor het hele proces, en vormt een hoofdbestanddeel van het project dat in detail zal worden besproken in de volgende blogposts.
Nu we de UID hebben die dit project bijeen zal houden en begrijpen waarom het nodig is, kan ik beginnen met het opbouwen van de visie van het gehele project en bijbehorende blogposts.
Het vastleggen en opslaan van de gearchiveerde 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-release zal het archiefeerproces en het opslaan van de e-mail op S3 behandelen, terwijl de tweede code-release het opslaan van alle loggegevens van berichtgebeurtenissen in MySQL zal behandelen. Je kunt de eerste twee code-releases en blogposts verwachten ergens begin 2019. Als je vragen of suggesties hebt, zijn deze van harte welkom.
Veel succes met verzenden.
– Jeff
Bijlage A:
