Sistema de leitura de caixa de email

Contexto Geral do Projeto

Requisitos: Acesso para plataforma controlado com nível de acesso. Nível de acesso definido por grupo de usuário (Admin, nivel 1, nivel2, etc), onde grupos de usuários podem ser criados ou modificados Mudança de regras de nível de acesso através da plataforma Regras de nível de acesso por grupo deve ser customizado por cada tipo de ação / url disponível na plataforma Na autenticação da plataforma, opção cadastro público (onde pode ser desativado nas configurações do administrador) e recuperar senha. O cadastro público deve enviar email para o usuário com link e / ou código para validar o email cadastrado. O mesmo deve ser feito em caso de recuperar senha. Cadastro de caixas email: Registrar múltiplas caixas de email, de diversos provedores. Configuração de cada caixa deve uportar os tipos de autenticação: Básica (endereço e senha simples) OAuth2 dos principais provedores (Microsoft Outlook, Gmail) Permitir configuração total do servidor smtp, imap e suas respectivas portas e forma criptografia (ssl, tls, etc). Pré-carregar dados de conexão conhecidos para os principais provedores. Exemplo, se usado um endereço do gmail, detectar automatico e pré-configurar os dados como smtp: smtp.gmail.com, porta 587, criptografia TLS. Imap: imap.gmail.com, porta 993, criptografia SSL. Em caso de autenticação OAuth2, após a autenticação manual pelo usuário, um token de acesso é gerado que tem duração limitada, onde o tempo varia de alguns minutos a algumas horas, dependendo do provedor. O sistema deve também requisitar os "refresh tokens" do provedor, armazenar-los e então periodicamente usar este refresh token para renovar os tokens de acesso das caixas de email. Caso os tokens expirem e/ou o sistema não consiga realizar a conexão, o sistema deve notificar, via emails e webhook, das falhas detectadas. Nenhuma senha deve ser armazenada em forma de texto, todas devem ser criptografadas. Para autenticação básica, a criptografia precisa usar uma seed para a criptografia gerada de forma aleatória, para cada caixa, sendo possível desfazer a criptografia no momento de conexão com o protocolo smtp/imap. Teste de conexão, tanto smtp disparando um email para a caixa configurada, quanto imap, lendo e informando as pastas presentes na caixa leitura de emails: definir quais pastas o sistema deve ler os emails de forma íntegra (não só endereço, assunto e conteúdo, mas todos os metadados fornecidos pelo protocolo) definir quais pastas representam a caixa de spam (pois cada provedor fornece um nome para pasta spam diferente, fora do padrão) a plataforma deve registrar todos os emails, seus metadados e seu conteúdo, e em qual caixa e de qual pasta, caso caiam nas pastas definidas para leitura e nas pastas definidas para spam. O Registro é importante, para que fique eternizado na plataforma, mesmo que o email seja excluído e/ou movido no servidor do provedor, ou até mesmo o provedor seja desativado. A plataforma deve permitir o usuário listar, pesquisar, visualizar todos os emails, organizados por caixas e suas respectivas pastas. Emails identificados como SPAM, o usuário deve ter a opção de excluir o email permanentemente ou mover para alguma das pastas presentes na caixa do email (não necessariamente as configuradas para leitura). Todo email lido pelo sistema deve gerar um identificador único (UUID). Respostas de email também devem ter seu uuid único e armazenar o uuid de quem está respondendo. Uma vez que um email é recebido, o sistema deve ser capaz de gerar uma thread deste email. Isto é, identificar todos os emails que respondem a este email inicial, e também emails que respondem as respostas do email inicial. Por exemplo, devemos ser capaz de saber se o email é um email "novo" ou resposta a email via API e Webhook. A Thread do email também deve ser acessível de forma íntegra através da API. Desta forma, as aplicações clientes podem requisitar todos os emails em suas respectivas ordem de disparo. Toda e qualquer atividade com email, deve gerar eventos e disparar para os clientes registrados no Webhook. Por exemplo, um email foi recebido, o evento de novo email deve ser disparado contendo os metadados do email. Dessa forma os clientes podem decidir ou não entre requisitar via api os dados completos do email, como seu conteúdo, tanto em texto plano como html. Caso o email seja respondido, o evento de novo email também deve ser disparado, mas também identificado que é uma resposta, para qual email e o ID da thread do email. Cabe ao cliente registrado decidir o que fazer com este email via api, seja obter os dados do email ou obter toda a thread até o momento via api. O sistema deve tratar os diversos tipos de codificação e charset presentes no conteúdo do email, preservando todos os caracteres e acentuação no formato final de UTF-8. Este requisito é importante, pois a mensagem do email deve ser possível de ser armazenada, de forma íntegra, em base de dados utilizando codificação UTF8MB4, como o MySQL. Disparo de Email: O sistema deve permitir disparar emails. Tanto para um único destinatário, quanto para vários destinatários, vários endereços em cópia, e também, endereços de cópia em sombra. O sistema deve saber identificar se o email foi devidamente entregue ao provedor, e utilizar de mecanismos (como pixel ou outra técnica), para identificar se o email foi aberto e lido. Também armazenar quando e quantas vezes o email foi aberto e lido. O disparo também deve ser disponível via API, e também disparar eventos, notificando os clientes registrados no webhook. Campanhas de Email em Massa: O sistema deve permitir o cadastro de campanhas de email. Isto é, uma vez fornecido o domínio ou lista de endereços de email, o mesmo deve ser capaz de disparar emails em massa. Obviamente, da mesma forma que emails individuais, cada email deve ter toda a informação de sua entrega, abertura e leitura registrada. O sistema também deve registrar o progresso da campanha - total de emails a serem disparado, emails já disparados, emails que falharam em serem disparados, e armazenamento total dos erros ocorridos. Também notificar via webhook o progresso da campanha do email, desde seu início até seu fim. Como já mencionado, a campanha de email em massa também deve ser registrada e configurada via API. Sistema de Webhook e API: Como mencionado diversas vezes antes, é crucial o sistema ter webhook e interface API sólido, pois seu uso primário será como um microserviço. Ele deve ser capaz de: Registrar clientes e suas respectivas urls dos endpoints para receber todos os eventos disparados do sistema. Sempre usando headers de autenticação como Bearer tokens, gerados aleatoriamente, e outro mecanismo avançado de autenticação como JWT Acesso a API também deve ter autenticação dos clientes com Bearer tokens e/ou JWT. Através da API, os cliente poderão listar todas as caixas, listar as pastas de cada caixa, quantidade de emails em cada caixa e pasta, e obviamente, obter emails das pastas configuradas para leitura. Obter as threads de emails, obter as campanhas de email e seus progressos. Como já mencionado, o disparo de emails e registro de campanhas de email também devem ser expostos via api.

Categoria TI e Programação
Subcategoria Programação
Qual é o alcance do projeto? Criar um novo site personalizado
Isso é um projeto ou uma posição de trabalho? Um projeto
Disponibilidade requerida Conforme necessário
Integrações de API Outros (Outras APIs)
Funções necessárias Desenvolvedor

Prazo de Entrega: 31 de Agosto de 2024

Habilidades necessárias