Construindo um Sistema de Arquivamento de E-mails: Os Desafios e, Claro, a Solução – Parte 1

Há cerca de um ano, escrevi um blog

blog

Com o aumento do uso de emails em ambientes regulatórios, decidi que é hora de iniciar um novo projeto que reúna tudo isso com exemplos de código sobre como armazenar o corpo do email e todos os dados associados. Ao longo do próximo ano, continuarei a trabalhar neste projeto com o objetivo de criar uma aplicação de armazenamento e visualização para emails arquivados e todas as informações de log produzidas pelo SparkPost. O SparkPost não possui um sistema que arquive o corpo do email, mas facilita bastante a construção de uma plataforma de arquivamento.

Nesta série de blogs, descreverei o processo que segui para armazenar o corpo do email no S3 (Serviço de Armazenamento Simples da Amazon) e todos os dados relevantes de log no MySQL para fácil referência cruzada. Para sistemas de arquivamento de produção que exigem estratégias robustas de backup de banco de dados, considere implementar um processo de backup e restauração do PostgreSQL

PHPArchivePlatform no GitHub

Esta primeira entrada da série de blogs vai descrever o desafio e traçar uma arquitetura para a solução. O restante dos blogs detalhará partes da solução juntamente com exemplos de código.

O primeiro passo do meu processo foi descobrir como obter uma cópia do email enviado ao destinatário original. Para obter uma cópia do corpo do email, você precisa:

Opções de Captura do Corpo do Email

1. Capturar o corpo do email antes de enviar o email

2. Fazer o servidor de email armazenar uma cópia

3. Fazer o servidor de email criar uma cópia para você armazenar

Se o servidor de email estiver adicionando itens como rastreamento de links ou rastreamento de aberturas, você não pode usar #1 porque não refletirá as mudanças no rastreamento de abertura/clique.

Isso significa que ou o servidor deve armazenar o email ou, de alguma forma, oferecer uma cópia desse email para você armazenar. Como o SparkPost não possui um mecanismo de armazenamento para os corpos de email, mas tem uma maneira de criar uma cópia do email, faremos com que o SparkPost nos envie um duplicado do email para que possamos armazená-lo no S3.

Isso é feito utilizando o recurso de Arquivo do SparkPost. O recurso de Arquivo do SparkPost permite ao remetente informar ao SparkPost para enviar um duplicado do email para um ou mais endereços de email e usar os mesmos links de rastreamento e abertura que o original. A documentação do SparkPost define seu recurso de Arquivo da seguinte maneira:

Os destinatários na lista de arquivo receberão uma réplica exata da mensagem que foi enviada para o endereço RCPT TO. Em particular, quaisquer links codificados destinados ao destinatário RCPT TO serão idênticos nas mensagens de arquivo

As únicas diferenças em relação ao email RCPT TO são que alguns dos cabeçalhos serão diferentes, já que o endereço de destino para o email de arquivamento é diferente, mas o corpo do email será uma réplica exata!

Se você quiser uma explicação mais profunda, aqui está um link para a documentação do SparkPost

Como uma observação, o SparkPost realmente permite que você envie emails para endereços de cc, bcc e arquivo. Para esta solução, estamos focados nos endereços de arquivo.

* Aviso * Emails arquivados PODEM ser criados SOMENTE ao injetar emails no SparkPost via SMTP!

Agora que sabemos como obter uma cópia do email original, precisamos olhar os dados de log que são produzidos e algumas das sutilezas dentro desses dados. O SparkPost rastreia tudo o que acontece em seus servidores e oferece essas informações a você na forma de eventos de mensagem. Esses eventos são armazenados no SparkPost por 10 dias e podem ser extraídos do servidor através de uma API RESTful chamada eventos de mensagem, ou você pode fazer com que o SparkPost envie esses eventos para qualquer número de aplicativos de coleta que desejar. O mecanismo de envio é feito através de webhooks e é realizado em tempo real.

Atualmente, existem 14 eventos diferentes que podem acontecer a um email.  Aqui está uma lista dos eventos atuais:

• Retorno

• CliquearDelay

• Entrega

• Falha na Geração

• Rejeição na Geração

• Abertura Inicial

• Inscrição via InjectionLink

• Cancelar Inscrição de Lista

• Abertura

• Fora de Banda

• Rejeição de Política/Queixa de Spam

  
  

* Siga este link

Cada evento possui numerosos campos que correspondem ao tipo de evento. Alguns campos, como o transmission_id são encontrados em todos os eventos, mas outros campos podem ser mais específicos do evento; por exemplo, apenas eventos de abertura e clique têm informações de geotag.

Identificadores Usados no Sistema de Arquivamento

Uma entrada de evento de mensagem muito importante para este projeto é o transmission_id. Todas as entradas de evento de mensagem para o email original, email arquivado e quaisquer endereços de cc e bcc compartilharão o mesmo transmission_id.

Há também uma entrada comum chamada message_id que terá o mesmo id para cada entrada do email original e do email arquivado. Todos os endereços cc ou bcc terão seu próprio id para a entrada message_id .

Até agora, isso parece ótimo e, francamente, bastante fácil, mas agora vem a parte desafiadora. Lembre-se, para obter o email de arquivo, fazemos com que o SparkPost envie um duplicado do email original para outro endereço de email correspondente a alguma caixa de entrada que você tenha acesso. Mas para automatizar essa solução e armazenar o corpo do email, vou usar outro recurso do SparkPost chamado Encaminhamento de Email de Entrada. Isso o que faz, é pegar todos os emails enviados a um domínio específico e processá-los. Ao processá-los, ele separa o email e cria uma estrutura JSON que é então entregue a um aplicativo via um webhook. Veja o Apêndice A para um exemplo de JSON.

Se você olhar cuidadosamente, notará que a estrutura JSON do relay de entrada está faltando um campo muito importante; o transmission_id. Embora todos os emails de saída tenham o transmission_id com a mesma entrada que vincula todos os dados do email original, arquivado, endereços de cc e bcc; o SparkPost não tem como saber que o email capturado pelo processo de entrada está conectado a qualquer um dos emails de saída. O processo de entrada simplesmente sabe que um email foi enviado para um domínio específico e que deve analisar o email. É isso. Ele tratará qualquer email enviado para aquele domínio da mesma maneira, seja uma resposta de um cliente ou o email de arquivamento enviado do SparkPost.

Portanto, o truque é; como você cola os dados de saída ao processo de entrada que acabou de capturar a versão arquivada do email? O que decidi fazer foi esconder um id único no corpo do email. Como isso é feito, depende de você, mas eu simplesmente criei um campo de entrada com a tag oculta ativada.

<input name="ArchiveCode" type="hidden" value="<<UID>>">

Também adicionei esse campo ao bloco de metadados do cabeçalho X-MSYS-API que é passado para o SparkPost durante a injeção. Este UID oculto será o vínculo de toda a operação, e é um componente principal do projeto que será discutido em profundidade nos próximos posts do blog.

Agora que temos o UID que unirá este projeto e entendemos por que é necessário, posso começar a construir a visão geral do projeto e dos correspondentes posts do blog.

1. Capturando e armazenando o email de arquivamento junto com uma entrada de banco de dados para pesquisa/indexação

2. Capturar todos os dados de eventos de mensagem

3. Criar uma aplicação para visualizar o email e todos os dados correspondentes

Aqui está um diagrama simples do projeto:

A primeira parte do código cobrirá o processo de arquivamento e armazenamento do email no S3, enquanto a segunda parte do código cobrirá o armazenamento de todos os dados de log dos eventos de mensagem no MySQL. Você pode esperar as duas primeiras partes do código e as entradas do blog em algum momento no início de 2019.  Se você tiver alguma dúvida ou sugestão, sinta-se à vontade para enviá-las.

Feliz Envio.
– Jeff

Apêndice A: