Talvez você pense à primeira vista "O que é essa pergunta? O que é um e-mail é bem claro!". O que a partir de uma perspectiva típica do usuário inicialmente é certamente simples, correto e compreensível de responder, pode sob pontos de vista mais técnicos (e também de conformidade) tornar-se uma questão complicada. Especialmente quando se trata do arquivamento de e-mails e da questão do original de um e-mail. A administração financeira verifica o arquivamento de e-mails do contribuinte, entre outros, com base nos critérios de regularidade do GoBD, segundo os quais a restauração do original de cada e-mail arquivado deve ser possível.

Naturalmente, o Benno MailArchiv dispõe desde a primeira hora da possibilidade de exibir cada e-mail arquivado em sua forma original. Para isso, a e-mail arquivada no formato nativo RFC 822 é recuperada do arquivo, desempacotada e apresentada como "código-fonte". Nem isso é algo especial, nem explica a nossa pergunta inicial. Afinal, é arquivado o que vem do servidor de e-mail ou da caixa de correio do usuário e precisa ser arquivado.

Originais e exemplares de e-mail

Mas o que acontece se, em vez de um único original relevante de um e-mail, houver dois, três ou até mais exemplares? Estamos falando aqui, evidentemente, expressamente não de simples duplicatas, ou seja, por exemplo, e-mails de uma caixa de correio recuperados várias vezes ou algo semelhante. Reconhecer duplicatas de e-mail (ou duplicatas) é uma das tarefas mais elementares de uma solução de arquivamento de e-mail. O Benno MailArchiv domina isso há tanto tempo quanto a exibição de e-mails em sua forma original.

„Vários originais relevantes do mesmo e-mail? Impossível!“ você diz? Não em ambientes complexos, como os encontrados em grandes empresas de hospedagem e provedores de serviços de nuvem (CSPs) na prática. Aqui, os e-mails chegam várias vezes ao „funil de processamento“ do Benno MailArchiv devido a circunstâncias condicionadas pela infraestrutura.

Os fatos descritos abaixo são relativamente fáceis de entender do ponto de vista técnico. No entanto, o arquivamento de e-mails em conformidade com a lei é muito mais do que apenas uma representação técnica ou implementação de requisitos (GoBD e Compliance). É uma solução de TI em um campo de tensão entre os interesses dos usuários, requisitos legais e possivelmente requisitos gerais de conformidade.

Convidamos você a discutir conosco o que é um e-mail (ou talvez não seja). Possivelmente, sua visão sobre algo tão trivial como e-mails mudará após ler este artigo. Escreva-nos um e-mail ou use a função de comentários no final desta postagem para nos contar sua opinião sobre isso.

Arquivar e-mails, do ponto de vista técnico, é uma tarefa relativamente simples. Existem (em linhas gerais) caixas de correio do usuário, servidores de e-mail e caminhos de transporte. Tudo isso está equipado com interfaces correspondentes. A partir das respectivas condições locais, surgem frequentemente várias possibilidades de arquivar e-mails (de maneira adequada às exigências pertinentes).

Arquivamento de e-mail no local ou em casa

Uma arquivamento de e-mail configurada no modo on premise é frequentemente caracterizada pelo fato de que todos os e-mails a serem arquivados são sempre e sem exceção arquivados pelo mesmo caminho ou pelo mesmo mecanismo escolhido. Embora a entrega de e-mail para o arquivo possa ser individual para cada cliente e seu ambiente de TI, é possível constatar que o caminho de todos os e-mails em instalações on premise (uma vez definido e configurado) é de fato sempre o mesmo. Uma vez que a conexão ao arquivo de e-mail seja concluída, tudo o mais funciona como se fosse automático. Todos os e-mails a serem arquivados seguem sempre o mesmo caminho. Um tamanho serve para todos.

A vantagem desta situação é a uniformidade. A entrega de e-mail para o arquivo ocorre de acordo com um esquema bem definido. Normalmente, não há exceções a isso. Duplicatas de e-mail são, portanto, amplamente excluídas. O restante, ou seja, a exclusão de quaisquer duplicatas reais, é realizado pela detecção de duplicatas do Benno MailArchiv no momento do arquivamento.

Arquivamento de e-mail na nuvem

Uma imagem completamente diferente é frequentemente vista em ambientes grandes e complexos. Assim, por exemplo, especialmente nas infraestruturas de grandes provedores de hospedagem e nuvem. Devido a uma variedade de circunstâncias possíveis (diferentes rotas de transporte de e-mail, diferentes servidores de transporte de e-mail (MTAs) e diferentes estratégias de alimentação para o arquivo (ativamente por SMTP ou passivamente por IMAP ou POP3, etc.)), ocorre aqui repetidamente que o mesmo e-mail é transportado por diferentes caminhos várias vezes para o arquivo e, assim, aguarda arquivamento múltiplo.

Especialmente diferentes caminhos de transporte de e-mail e MTAs fazem com que os e-mails transportados sejam fornecidos com cabeçalhos de transporte específicos do caminho, dependendo do caminho percorrido. Se um e-mail concreto chegar várias vezes ao arquivo por caminhos diferentes e for fornecido com cabeçalhos diferentes (o que é inevitável com MTAs diferentes), diferentes e-mails serão entregues para arquivamento do ponto de vista da detecção de duplicatas.

Vejamos isso mais de perto com a ajuda de um exemplo:

Em uma infraestrutura complexa, um e-mail concreto 'M' é entregue ao Benno MailArchiv para arquivamento por três caminhos diferentes. Durante o transporte de cada uma das três cópias deste e-mail (M1, M2, M3) por caminhos diferentes, são registrados cabeçalhos diferentes para cada cópia do e-mail. As cópias do e-mail são idênticas em conteúdo, ou seja, da perspectiva da mensagem ou texto do usuário. No entanto, elas se distinguem formalmente e tecnicamente pelos cabeçalhos diferentes de forma inequívoca.

Os cabeçalhos fazem a diferença

Do ponto de vista da detecção de duplicatas ou duplicados do Benno MailArchiv, trata-se de três e-mails diferentes, M1, M2 e M3, sem dúvida. Durante o arquivamento, uma soma de verificação SHA256 é gerada para cada e-mail entregue. Devido aos cabeçalhos diferentes (dos exemplares de e-mail idênticos), resultam necessariamente três somas de verificação diferentes "C1", "C2" e "C3" para os diferentes exemplares. Assim, os três exemplares do mesmo e-mail são considerados diferentes pelo Benno MailArchiv. Eles também seriam arquivados individualmente como tal. Isso, por sua vez, teria a consequência de que, do ponto de vista do usuário (ou seja, relacionado ao conteúdo puramente informativo do e-mail), parece que há três e-mails idênticos no arquivo. Ao pesquisar o conteúdo da mensagem, os três exemplares de e-mail seriam encontrados e exibidos.

Em tal ambiente, a detecção convencional de duplicatas não faz sentido. Quem quer encontrar várias e-mails (de acordo com o conteúdo da mensagem) iguais ao procurar? E como podemos garantir que apenas uma das três instâncias de e-mail seja arquivada?

Complexidade requer soluções simples

É sabido que a complexidade é mais bem compensada pela simplicidade interna e soluções simples do que por construções complexas de soluções.

Se investigarmos mais a fundo, descobriremos que um e-mail já é exclusivamente identificável pelos cabeçalhos abaixo e, adicionalmente, pelo seu texto de mensagem:

  • Envelope-From – X-REAL-MAILFROM
  • Envelope-To – X-REAL-RCPTTO
  • Return-Path
  • Assunto
  • ID da Mensagem
  • Data
  • De
  • Para
  • Cópia
  • Corpo

Naturalmente, surgem especialmente durante o transporte via SMTP cabeçalhos específicos adicionais (os chamados Received-Header) no e-mail. Os conteúdos desses Received-Headers dependem do caminho de transporte real do respectivo e-mail. Isso significa que, se dois e-mails M1 e M2 são idênticos em relação aos cabeçalhos mencionados anteriormente (não específicos ao transporte), trata-se definitivamente do mesmo e-mail – independentemente de quais e quantos cabeçalhos condicionados ao transporte ainda estão contidos no e-mail.

Conclusão: O caminho de transporte pode causar cabeçalhos adicionais. Com isso, um e-mail se torna um e-mail com várias cópias não idênticas. Os cabeçalhos condicionados ao transporte não são importantes para a clareza da mensagem ou conteúdo do e-mail (sua presença apenas documenta o caminho de transporte percorrido).

Além disso, não são apenas os cabeçalhos Received, mas também as assinaturas DKIM (e outros elementos) que não estão diretamente relacionados ao conteúdo do e-mail. Esses cabeçalhos podem ser atribuídos ao envelope de um e-mail.

Assim, a solução para a situação com várias cópias de e-mail, que são tecnicamente diferentes, mas idênticas em conteúdo, está próxima: enquanto por razões de conformidade a soma de verificação sobre todo o e-mail é obrigatória, uma segunda soma de verificação, baseada exclusivamente nos componentes de e-mail mencionados acima, resolve o dilema de forma simples e eficaz.

Prática versus critérios formais e conformidade

Alguns temas podem ser resolvidos de forma elegante por meio de soluções técnicas. No entanto, algumas soluções práticas falham no dia a dia devido a aspectos formais. Aqui também é apropriado examinar mais de perto, pois a conformidade, infelizmente, precede a praticidade em relação ao arquivamento de e-mails:

O arquivamento de e-mails em conformidade com o GoBD requer a capacidade de restaurar qualquer e-mail em seu estado original do arquivo. Cada e-mail deve ser exibida incluindo todos os cabeçalhos, anexos, etc., ou seja, praticamente no "texto-fonte da mensagem", e deve ser possível verificar se houve alguma manipulação. Concretamente, com base na soma de verificação mencionada acima em todo o e-mail, a consistência ou integridade de um e-mail arquivado, bem como de todo o conteúdo do arquivo, pode ser verificada.

Voltando ao nosso exemplo: se várias e-mails textualmente ou conteudisticamente idênticas M1, M2 e M3 (no sentido acima mencionado de diferentes exemplares da mesma e-mail) forem submetidas ao arquivamento, surge a questão de como proceder com os exemplares de e-mail diferentes em termos de cabeçalhos.

Uma visão sobre os aspectos jurídicos desta situação

Partimos do princípio de que, do ponto de vista jurídico, não há nenhuma obrigação de que várias versões de um e-mail sejam arquivadas, especialmente se elas diferirem apenas em relação aos cabeçalhos de e-mail incluídos. No entanto, como não se pode excluir a possibilidade de que diferentes círculos defendam diferentes interpretações jurídicas, é possível que nossa suposição não seja unanimemente aceita ou seja juridicamente incorreta.

Para evitar um possível dilema (jurídico), deveriam, portanto, ser arquivados (numa abordagem pragmática) todos os exemplares do e-mail em questão (no nosso exemplo M1, M2, M3).

Considerando a situação de forma puramente formal, estamos lidando com várias instâncias de e-mail no sentido do nosso exemplo como e-mails diferentes. Mesmo que as diferenças entre eles sejam de natureza técnica e o valor prático das diferenças entre eles no dia a dia não exista ou seja mínimo, formalmente estamos lidando com e-mails diferentes. Isso pode ser imediatamente verificado pelas somas de verificação diferentes.

Qualquer insegurança jurídica pode ser simplesmente excluída arquivando todas as instâncias de e-mail. Mesmo que seja tecnicamente viável com base no procedimento descrito acima com duas somas de verificação diferentes por e-mail, por exemplo, arquivar apenas a primeira instância de uma série de instâncias de e-mail

Para alcançar aqui uma solução segura para o operador, aconselhamos discutir este assunto com um conselheiro jurídico de sua escolha antes da implementação. Só depois de ter discutido e decidido sobre a forma concreta de implementação da detecção de duplicatas, a implementação deve ser realizada de acordo.

Por enquanto, partimos do pressuposto de que pode ser legalmente suficiente poder aplicar a detecção simplificada de duplicatas, ou seja, arquivar apenas uma das várias instâncias de e-mail que chegam. Com base nos requisitos da GoBD, a criação de uma documentação de processo está fora de questão e é obrigatória. Neste contexto, partimos do pressuposto de que a explicação ou registro do fato de que apenas uma instância de e-mail é arquivada deve ser suficiente para alcançar um arquivamento seguro.

A decisão sobre o tipo de detecção de duplicatas aplicada e, portanto, a responsabilidade perante a administração financeira cabe unicamente e exclusivamente ao operador.

O que é um e-mail?

É um e-mail agora cada exemplar, mesmo que dois exemplares sejam diferentes apenas por um único cabeçalho de transporte que, por sua vez, não contribui para aumentar o valor da informação da mensagem? É um e-mail, portanto, classificado puramente de acordo com os critérios formais? Ou é um e-mail uma mensagem entre dois ou mais usuários, cujo elemento essencial (e também relevante para o arquivamento em conformidade com a GoBD) é a própria mensagem? São os cabeçalhos de e-mail (que geralmente permanecem ocultos para o usuário) também em relação à GoBD não tão importantes (mesmo que sejam arquivados como parte do e-mail original)?

O que exatamente é um e-mail, permanece em aberto por algum tempo neste sentido.

Agora você tem a palavra, caro leitor! Envie-nos um e-mail ou um comentário sobre sua visão da natureza e do escopo de um e-mail.

Aviso Legal / Exclusão de Responsabilidade / Disclaimer

Esta contribuição não constitui aconselhamento jurídico. Serve apenas para informação geral. Não assumimos responsabilidade pela exatidão ou completude das informações. Qualquer responsabilidade é excluída.