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.
Business in a box.
Ontdek onze oplossingen.
Praat met ons verkoopteam
Ongeveer een jaar geleden schreef ik een blog over hoe je kopieën van e-mails kunt ophalen voor archivering en weergave, maar ik heb het opslaan van de e-mail of gerelateerde gegevens niet besproken. Onlangs schreef ik een blog over het opslaan van alle gebeurtenisgegevens (d.w.z. wanneer de e-mail is verzonden, geopend, geklikt, gebounced, uitgeschreven, enz.) op een e-mail voor controle, maar koos ervoor om geen ondersteunende code te maken.
Met de toename van het e-mailgebruik in gereguleerde omgevingen, heb ik besloten dat het tijd is om een nieuw project te starten dat alles samenbrengt met codevoorbeelden over hoe je de e-mailtekst en alle bijbehorende gegevens kunt opslaan. In het komende jaar zal ik doorgaan met het opbouwen van dit project met als doel het creëren van een werkende opslag- en weergaveapplicatie voor gearchiveerde e-mails en alle loginformatie geproduceerd door SparkPost. SparkPost heeft geen systeem dat de e-mailtekst archiveert, maar maakt het bouwen van een archiveringsplatform vrij eenvoudig.
In deze blogreeks zal ik het proces beschrijven dat ik heb doorlopen om de e-mailtekst op te slaan op S3 (Amazon's Simple Store Service) en alle relevante loggegevens in MySQL voor eenvoudige kruisverwijzing. Dit is uiteindelijk het beginpunt voor het bouwen van een applicatie die eenvoudig zoeken naar gearchiveerde e-mails mogelijk maakt, deze e-mails weergeeft samen met de gebeurtenis(log)gegevens. De code voor dit project is te vinden in de volgende GitHub-repository: https://github.com/jeff-goldstein/PHPArchivePlatform
Dit eerste deel van de blogreeks gaat de uitdaging beschrijven en een architectuur voor de oplossing opzetten. De rest van de blogs zal de verschillende delen van de oplossing gedetailleerd beschrijven samen met codevoorbeelden.
De eerste stap in mijn proces was om uit te zoeken hoe ik een kopie van de e-mail die naar de oorspronkelijke ontvanger is verzonden, zou verkrijgen. Om een kopie van de e-mailtekst te verkrijgen, moet je het volgende doen:
De e-mailtekst vastleggen voordat de e-mail wordt verzonden
De e-mailserver een kopie laten opslaan
De e-mailserver een kopie voor je laten maken om op te slaan
Als de e-mailserver items zoals linktracking of opent tracking toevoegt, kun je optie 1 niet gebruiken, omdat het de open/klik tracking wijzigingen niet weergeeft.
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 je moet aanbieden voor opslag. Aangezien SparkPost geen opslagmechanisme voor e-mailteksten heeft, maar wel een manier om een kopie van de e-mail te maken, laten we SparkPost ons een duplicaat van de e-mail sturen zodat we deze in S3 kunnen opslaan.
Dit gebeurt met behulp van de Archive-functie van SparkPost. De Archive-functie van SparkPost geeft de afzender de mogelijkheid om SparkPost een duplicaat van de e-mail naar een of meer e-mailadressen te laten sturen en dezelfde tracking- en open links te gebruiken als het origineel. De documentatie van SparkPost definieert hun Archive-functie als volgt:
Ontvangers in de archieflijst zullen een exacte replica ontvangen van het bericht dat naar het RCPT TO-adres is verzonden. Met name alle gecodeerde links bedoeld voor de RCPT TO-ontvanger zullen identiek zijn in de archiefberichten.
De enige verschillen met de RCPT TO-email zijn dat sommige headers anders zullen zijn omdat het doeladres voor de archiefmail verschillend is, maar de tekst van de e-mail zal een exacte replica zijn!
Als je een diepere uitleg wilt, hier is een link naar de SparkPost-documentatie over het maken van duplicaat- (of archief-)kopieën van een e-mail.
Als een zijnoot staat SparkPost je eigenlijk toe om e-mails te verzenden naar cc-, bcc- en archief-e-mailadressen. Voor deze oplossing richten we ons op de archiefadressen.
* Opmerking * Gearchiveerde e-mails kunnen ENKEL 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 verkrijgen, moeten we kijken naar de loggegevens die worden geproduceerd en enkele 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 gedurende 10 dagen opgeslagen op SparkPost en kunnen van de server worden gehaald via een RESTful API genaamd message-events, of je kunt SparkPost die gebeurtenissen naar een willekeurig aantal verzameltoepassingen laten pushen. Dit pushmechanisme gebeurt via webhooks en gebeurt in realtime.
Momenteel zijn er 14 verschillende gebeurtenissen die bij een e-mail kunnen plaatsvinden. 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 Rejection Spam Complaint
* 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 talrijke velden die overeenkomen met het gebeurtenistype. Sommige velden zoals de transmission_id worden in elke gebeurtenis gevonden, maar andere velden kunnen meer gebeurtenisspecifiek zijn; bijvoorbeeld, alleen open en klikgebeurtenissen hebben geotag-informatie.
Een zeer belangrijke berichtgebeurtenis voor dit project is de transmission_id. Alle berichtgebeurtenisvermeldingen voor de oorspronkelijke e-mail, de gearchiveerde email en alle cc en bcc adressen zullen dezelfde transmission_id delen.
Er is ook een gemeenschappelijke vermelding genaamd de message_id die hetzelfde id zal hebben voor elke vermelding van de oorspronkelijke e-mail en de gearchiveerde e-mail. Eventuele cc of bcc adressen zullen hun eigen id hebben voor de message_id vermelding.
Tot zover klinkt dit geweldig en eerlijk gezegd redelijk eenvoudig, maar nu komt het uitdagende deel. Vergeet niet dat, om de gearchiveerde e-mail te krijgen, we SparkPost een duplicaat van de oorspronkelijke e-mail laten sturen naar een ander e-mailadres dat overeenkomt met een inbox waartoe je toegang hebt. 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 gestuurd ontvangen en verwerken. Door ze te verwerken, wordt de e-mail uit elkaar gehaald en er wordt een JSON-structuur van gemaakt die vervolgens via een webhook aan een toepassing wordt geleverd. Zie Appendix A voor een voorbeeld JSON.
Als je goed kijkt, zul je merken dat de JSON-structuur van de inkomende 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 oorspronkelijke e-mail, archief, cc, en bcc adressen bindt, heeft SparkPost geen manier om te weten dat de e-mail die door het inkomende proces is vastgelegd, is verbonden met een van de uitgaande e-mails. Het inkomende proces weet eenvoudigweg dat een e-mail naar een specifiek domein is verzonden en moet de email parseren. Dat is het. 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 archiefmail die door SparkPost is verzonden.
Dus de truc is; hoe verbind je de uitgaande gegevens met het inkomende proces dat net de gearchiveerde versie van de e-mail heeft ontvangen? Wat ik heb besloten te doen is een unieke id te verbergen in de tekst van de e-mail. Hoe dit wordt gedaan, is aan jou, maar ik heb gewoon een invoerveld gemaakt met het verborgen tag ingeschakeld.
Ik heb dat veld ook toegevoegd aan het metadata-blok van de X-MSYS-API-header die tijdens injectie aan SparkPost wordt doorgegeven. Deze verborgen UID zal uiteindelijk de schakel zijn in het hele proces en is een hoofdcomponent van het project, en zal uitgebreid worden besproken in de volgende blogposts.
Nu we de UID hebben die dit project bij elkaar zal brengen en begrijpen waarom het nodig is, kan ik beginnen met het opbouwen van de visie van het algehele project en bijbehorende blogs.
Het vastleggen en opslaan van de archief-e-mail samen met een databasevermelding 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 archiveringsproces en het opslaan van de e-mail op S3 omvatten, terwijl de tweede code release het opslaan van alle loggegevens van message-events in MySQL zal behandelen. Je kunt de eerste twee code releases en blogs ergens in het begin van 2019 verwachten. Als je vragen of suggesties hebt, neem ze dan gerust mee.
Vrolijk Verzenden.
– Jeff
Bijlage A:
