Hermod: uma plataforma de e-mail para apoiar a comunicação institucional

Texto

(1)Henrique André Barbosa Bittencourt Dutra. Hermod: Uma plataforma de e-mail para apoiar a comunicação institucional. Brasil 2017.

(2)

(3) Henrique André Barbosa Bittencourt Dutra. Hermod: Uma plataforma de e-mail para apoiar a comunicação institucional. Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.. Universidade Federal do Rio Grande do Norte – UFRN Instituto Metrópole Digital – IMD Programa de Pós-Graduação em Engenharia de Software. Orientador: Dr. Sérgio Queiroz de Medeiros Coorientador: Dr. Uirá Kulesza. Brasil 2017.

(4) Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede. Dutra, Henrique Andre Barbosa Bittencourt. Hermod: Uma plataforma de e-mail para apoiar a comunicação institucional / Henrique Andre Barbosa Bittencourt Dutra. 2017. 95 f.: il. Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-graduação em Engenharia de Software. Natal, RN, 2017. Orientador: Prof. Dr. Sérgio Queiroz de Medeiros. Coorientador: Prof. Dr. Uirá Kulesza.. 1. Serviço de e-mail - Dissertação. 2. Middleware Dissertação. 3. Programação concorrente - Dissertação. I. Medeiros, Sérgio Queiroz de. II. Kulesza, Uirá. III. Título. RN/UF/BCZM. CDU 004.773.3.

(5) Henrique André Barbosa Bittencourt Dutra. Hermod: Uma plataforma de e-mail para apoiar a comunicação institucional Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software. Trabalho aprovado. Brasil, 24 de Agosto de 2017:. Dr. Sérgio Queiroz de Medeiros UFRN Presidente. Dr. Uirá Kulesza UFRN Examinador. Dr. Carlos Eduardo da Silva UFRN Examinador. Dr. Bruno Oliveira Silvestre UFG Examinador. Brasil 2017.

(6)

(7) “Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program. (Linus Torvalds, 1998).

(8)

(9) Resumo As organizações que oferecem serviços à sociedade, sejam elas públicas ou privadas, precisam com frequência estabelecer um canal de comunicação para enviar conteúdo, tais como notícias, ofertas de serviços ou outros tipos de informações. Entre as diversas formas de comunicação institucional, o serviço de e-mail possui papel predominante. Os Sistemas SIG – como são chamados os sistemas desenvolvidos pela SINFO/UFRN que utilizam a Arquitetura SIG como base — tornaram a tecnologia de e-mail como padrão para a comunicação institucional, devido ao baixo custo, facilidade de uso e a popularidade. A preocupação da SINFO em prover a comunicação institucional decorre das metas do Plano Diretor de Tecnologia da Informação (PDTI), onde uma das metas é prover os meios para melhoraria da comunicação institucional. Apesar do esforço da SINFO/UFRN, constantemente os usuários reclamavam que e-mails não estavam sendo entregues, o que gerou dúvida se os sistemas realmente conseguiam cumprir seu papel na comunicação institucional. Esta dissertação fez um estudo sobre o módulo de envio de e-mail da Arquitetura SIG onde foi possível expor os problemas deste módulo. Esta dissertação também apresenta o Hermod, uma plataforma de e-mail criada para apoiar as necessidades da comunicação institucional da UFRN. Essa plataforma propõe resolver os problemas que foram encontrados na solução de e-mail da Arquitetura SIG, atuando como um middleware oferecendo para outros sistemas (incluindo os Sistemas SIG) serviços de envio e rastreio de e-mail, por exemplo. A plataforma foi modelada pensando nos seguintes requisitos: interoperabilidade, alta disponibilidade, tolerância a falhas e elasticidade. Os experimentos atestaram que o Componente de envio de e-mail com a configuração de uma thread o tempo de envio é linear em relação ao número de mensagens. Este componente foi implementado através de um pool de threads, impedindo que o consumo de memória (monitorado pelo Zabbix) aumente na mesma proporção que a carga que o sistema recebe, fazendo com que o Hermod escale bem mesmo em situações de alta carga. Cada nó do cluster é independente e mesmo após falha em algum nó, o cluster continua disponível e recebendo requisições. Com a elasticidade através da análise da carga recebida, foi possível aumentar a vazão de e-mails enviados através da criação de instâncias em tempo de execução. Palavras-chave: Middleware. Programação concorrente. Serviço de e-mail..

(10)

(11) Abstract The organizations, either public or private, that offer services to society often need to establish a communication channel to send content such as news, service offers or other kinds of information. Among the variety of forms of institutional communication, the e-mail service has the uppermost value. The SIG Systems, as it usual to refer to the systems developed by SINFO/UFRN that use the SIG Architecture as base, use default e-mail technology to institutional communication due to low cost, ease of use and popularity. The concern of SINFO in provide the institutional communication runs from the Information Technology Master Plan (ITMP), where one of its goals is to provide the means to improvement of institutional communication. Despite the effort of SINFO/UFRN, the users constantly complain that the e-mails were not being delivered, which was the cause of doubt if the systems really could achieve their goal on the institutional communication. This dissertation made a study about the e-mail sending module of SIG Architecture where was possible to expose the problems of this module. This dissertation also presents Hermod, an e-mail platform created to support the necessities of UFRN institutional communication. The platform also intends to solve the problems that were found on the e-mail solution from SIG Architecture, acting as a middleware offering to other systems (including the SIG Systems) services of e-mail sending and tracking, for example. The platform was designed with the following requirements: interoperability, disponibility, fault tolerance and elasticity. The experiments verified that the E-mail Sending Component with the configuration of one thread has the sending time is linear with respect to the number of messages. This component was implemented through a pool of threads, preventing that the memory consumption (monitored by Zabbix) increases in the same way as the load received by the system, causing the Hermod to have a significant scale, even in high charge situations. Each node of cluster is independent and even after a failure in some node, the cluster remains available e receives requests. With the elasticity through received charge analysis, it was possible to enhance the flow rate of sended e-mails through the creation of instances in time of execution. Keywords: Middleware. Concurrent programming. Email service..

(12)

(13) Lista de ilustrações Figura 1 – Camadas da Arquitetura SIG . . . . . . . . . . . . . . . . . . . . . . . Figura 2 – Visão das camadas da Arquitetura SIG e visão geral do módulo de envio de e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 3 – Gráfico com o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 4 – Modelo básico da infraestrutura de e-mail . . . . . . . . . . . . . . . . Figura 5 – Estrutura do mail object . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 6 – Terminologia dos servidores durante um fluxo DSN . . . . . . . . . . . Figura 7 – Gráfico dos maiores provedores de e-mail na base da UFRN . . . . . . Figura 8 – Comparação do sistema de rota do JMS vs AMQP . . . . . . . . . . . Figura 9 – Comparação Máquina Virtual vs Docker Container . . . . . . . . . . . Figura 10 – Visão dos relacionamentos entre sistemas com o Hermod . . . . . . . . Figura 11 – Visão geral dos componentes internos do Hermod . . . . . . . . . . . . Figura 12 – Modelo de recursos do REST . . . . . . . . . . . . . . . . . . . . . . . Figura 13 – Relacionamento das classes de domínio na camada de serviços . . . . . Figura 14 – Filas em memória do módulo de envio da Arquitetura SIG . . . . . . . Figura 15 – Modelo de fila centralizada no Hermod . . . . . . . . . . . . . . . . . . Figura 16 – Balanceamento por LVS utilizado pela Arquitetura SIG . . . . . . . . . Figura 17 – Diagrama de classes do balanceador implementado no Hermod . . . . . Figura 18 – Diagrama de classes do modelo de restrição de servidores . . . . . . . . Figura 19 – Diagrama de classes do monitoramento de e-mail . . . . . . . . . . . . Figura 20 – Diagrama de classes da análise do DSN . . . . . . . . . . . . . . . . . . Figura 21 – Diagrama de classes envolvendo a conexão com o Rancher . . . . . . . Figura 22 – Teorema CAP proposto por Dr. Eric Brewer . . . . . . . . . . . . . . . Figura 23 – Diagrama de classes do Componente de persistência . . . . . . . . . . . Figura 24 – Organização dos componentes após a restruturação em microsserviços . Figura 25 – Cenário de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 26 – Gráfico comparativo entre os resultados da primeira fase do experimento. Valores até 160.000 e-mails . . . . . . . . . . . . . . . . . . . . . . . . . Figura 27 – Gráfico comparativo entre os resultados da primeira fase do experimento. Valores até 1 milhão de e-mails . . . . . . . . . . . . . . . . . . . . . . Figura 28 – Fórmula para encontrar o número ideal de threads . . . . . . . . . . . . Figura 29 – Testes de Load Average realizados com 1 núcleo de CPU . . . . . . . . Figura 30 – Testes de Load Average realizados com 5 núcleos de CPU . . . . . . . . Figura 31 – Testes de Load Average realizados com 10 núcleos de CPU . . . . . . .. 26 27 29 32 33 37 40 45 49 52 54 59 59 61 62 64 65 66 68 69 72 73 75 78 79 82 83 85 85 86 87.

(14)

(15) Lista de tabelas Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela. 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 10 –. Preço mensal do Mailchimp . . . . . . . . . . . . . . . . . . . . . . . . Preço mensal do GetResponse . . . . . . . . . . . . . . . . . . . . . . . Preço mensal do Locaweb SMTP . . . . . . . . . . . . . . . . . . . . . Teste de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dimensões aproximadas dos públicos de nosso interesse dentro da UFRN Teste parcial da primeira fase . . . . . . . . . . . . . . . . . . . . . . . Teste final da primeira fase . . . . . . . . . . . . . . . . . . . . . . . . Testes de duração realizados com 1 núcleo de CPU . . . . . . . . . . . Testes de duração realizados com 5 núcleos de CPU . . . . . . . . . . . Testes de duração realizados com 10 núcleos de CPU . . . . . . . . . .. 20 20 21 29 79 80 81 84 84 84.

(16)

(17) Lista de abreviaturas e siglas AGECOM. Agência de Comunicação. AMQP. Advanced Message Queuing Protocol. API. Application Programming Interface. ARPANET. Advanced Research Projects Agency Network. DKIM. DomainKeys Identified Mail. DMARC. Domain-based Message Authentication, Reporting & Conformance. DNS. Domain Name System. GPL. General Public License. IETF. Internet Engineering Task Force. JMS. Java Message Service. MQTT. Message Queuing Telemetry Transport. MTA. Mail Transfer Agent. MX. Mail Exchange. NFS. Network File System. REST. Representational State Transfer. RFC. Request for Comments. RMI. Remote Method Invocation. SIG. Sistema Integrado de Gestão. SINFO. Superintendência de Informática. SMTP. Simple Mail Transfer Protocol. SOA. Service-Oriented Architecture. SPF. Sender Policy Framework. UFRN. Universidade Federal do Rio Grande do Norte. VERP. Variable Envelope Return Path.

(18)

(19) Sumário 1. INTRODUÇÃO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. 1.1. Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20. 1.2. Objetivos. 1.3. Organização do trabalho. 2. MÓDULO DE ENVIO DE E-MAIL DA ARQUITETURA SIG . . . . 25. 2.1. Sistemas Integrados de Gestão da UFRN (SIG-UFRN) . . . . . . . . 25. 2.1.1. Arquitetura em camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 26. 2.2. Módulo de envio de e-mail da Arquitetura SIG . . . . . . . . . . . . 27. 2.2.1. Teste de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29. 3. FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 31. 3.1. E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. 3.1.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. 3.1.2. Arquitetura do e-mail na Internet . . . . . . . . . . . . . . . . . . . . . . 32. 3.1.3. Funcionamento do SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . 33. 3.1.4. Rastreio de e-mails enviados . . . . . . . . . . . . . . . . . . . . . . . . . 35. 3.1.4.1. Variable Envelope Return Path (VERP). 3.1.4.2. Delivery Status Notifications (DSN) . . . . . . . . . . . . . . . . . . . . . .. 3.1.5. Proteção contra SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39. 3.1.5.1. Boas práticas de envio em massa . . . . . . . . . . . . . . . . . . . . . . . .. 39. 3.1.5.2. Sistemas baseados em reputação . . . . . . . . . . . . . . . . . . . . . . . .. 42. 3.1.5.3. Sistemas baseados em quotas e blacklists . . . . . . . . . . . . . . . . . . . .. 43. 3.1.6. Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43. 3.2. Middleware orientado a mensagens (MOM) . . . . . . . . . . . . . . 43. 3.2.1. Java Message Service (JMS) . . . . . . . . . . . . . . . . . . . . . . . . . 44. 3.2.2. Advanced Message Queuing Protocol (AMQP) . . . . . . . . . . . . . . . 45. 3.2.3. Message Queue Telemetry Transport (MQTT) . . . . . . . . . . . . . . . 47. 3.2.4. Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48. 3.3. Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48. 3.3.1. Máquinas Virtuais. 3.3.2. Container Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49. 3.3.3. Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50. 4. HERMOD - UMA PLATAFORMA PARA SERVIÇOS DE E-MAIL . 51. 4.1. Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 . . . . . . . . . . . . . . . . . . . . . . . . . 23. . . . . . . . . . . . . . . . . . . . . 36 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48.

(20) 4.2.2.1. Primeiro protótipo . . Camada de serviços web Componente REST . . . Camada de negócio . . . Componente de fila . . .. 4.2.2.2. Componente de envio de e-mail. 4.2.2.3. Componente de buscar e-mail. 4.2.2.4. Componente de monitorar e-mail. 4.2.2.5. Componente de elasticidade . .. 4.2.3 4.2.3.1. Camada de dados . . . . . . . Componente de persistência . .. 4.2.3.2. Componente de motor de busca. 4.3. Segundo protótipo . . . . .. 5 5.1 5.2. TESTES DE DESEMPENHO E RESULTADOS . . . . . . . . . . . 79 Primeira fase do experimento . . . . . . . . . . . . . . . . . . . . . . . 80 Segunda fase do experimento . . . . . . . . . . . . . . . . . . . . . . . 82. 6 6.1 6.1.1 6.1.2. CONSIDERAÇÕES Contribuições . . . Limitações . . . . . Trabalhos futuros . .. 4.2 4.2.1 4.2.1.1. 4.2.2. REFERÊNCIAS. . . . . .. . . . . .. . . . . . .. FINAIS . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . .. . . . .. 51 57 58. 60 60 63 67 67 70. 72 74 75. 76. 89 90 91 91. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.

(21) 19. 1 Introdução Em grandes organizações e instituições é desafiador conseguir transmitir uma mensagem para seus inúmeros colaboradores com rapidez e abrangência. Para vencer o desafio da comunicação em massa uma das maneiras encontradas foi utilizar o e-mail como pode ser visto no estudo realizado por (TERRA, 2006). Nesse estudo, empresas como Microsoft1 , Catho2 e HSBC3 relataram quais ferramentas usavam no seu mix de comunicação, ou seja, o conjunto de ferramentas de comunicação usadas por elas. Um dos resultados obtidos foi que o e-mail obteve 100% de menção entre todos os participantes, portanto, podemos inferir que ele é uma ferramenta popular e efetiva quando se deseja atingir um volume de pessoas. Atualmente existem empresas especializadas em fornecer plataformas de e-mail como um serviço. Podemos citar algumas ferramentas comerciais que oferecem este tipo de plataforma, como por exemplo o Mailchimp4 , Locaweb SMTP 5 e GetResponse 6 . Tais ferramentas costumam oferecer envio e rastreabilidade de e-mails, relatórios, API de serviços para integração com sistemas externos e taxa de entregabilidade alta. Infelizmente não encontramos ferramentas opensource que ofereçam qualidade semelhante a estas ferramentas comerciais que foram citadas. Esse tipo de plataforma surgiu devido à demanda que existe nas organizações (privadas ou públicas) em manter contato com seu público e a dificuldade em criar uma infraestrutura adequada para realização dessa tarefa. Apesar de ser uma tecnologia simples, não é trivial conceber uma estrutura de servidores de e-mail juntamente com softwares apropriados que consigam entregar as mensagens aos destinatários com um bom índice de sucesso. Essas plataformas não funcionam como provedores de e-mail como Gmail, Yahoo ou Hotmail que fornecem uma caixa postal ao usuário. Elas focam em tentar fornecer garantias de que o e-mail enviado através da sua plataforma será entregue com sucesso a uma grande quantidade de destinatários, desde que não seja spam (mensagens não solicitadas ou indevidas).. 1 2 3 4 5 6. www.microsoft.com.br www.catho.com.br www.hsbc.com.br www.mailchimp.com www.locaweb.com.br/smtp-locaweb/ www.getresponse.com.

(22) 20. Capítulo 1. Introdução. 1.1 Motivação Os sistemas desenvolvidos pela Superintendência de Informática (SINFO)7 atravessam um momento de desconfiança por parte dos usuários em relação ao envio de e-mail. Entre os sistemas que foram desenvolvidos pela SINFO não existe um sistema que dê o suporte total para comunicação por e-mail, o que existe é um módulo simples dentro da arquitetura que os sistemas utilizam. Esse módulo não oferece garantias em relação à taxa de entrega e faz o envio das mensagens de maneira ineficiente. O capítulo 2 Módulo de envio de e-mail da Arquitetura SIG oferece mais detalhes sobre a solução que está em uso. Existem algumas reclamações de usuários no setor de suporte ao usuário da SINFO de que e-mails não são entregues, ou entregues com atraso, o que inviabiliza uma comunicação efetiva. Em uma busca realizado no sistema de chamados, identificamos vinte e quatro ocorrências desta natureza no período de abril de 2015 a fevereiro de 2017. Mas certamente existem mais, infelizmente a base de dados não está normalizada o suficiente para permitir um busca refinada. Além disso, o suporte atende também via e-mail e telefone, e infelizmente não possuíam registros antigos para realizar uma consulta. A desconfiança faz com que cada vez mais os usuários de reitorias e departamentos que precisam de uma comunicação efetiva via e-mail usem plataformas externas de email como as já citadas Mailchimp, GetResponse e Locaweb SMTP. Essas ferramentas conseguem garantir um taxa de entrega alta, porém a um custo financeiro elevado. Tabela 1 – Preço mensal do Mailchimp Qtd. de pessoas 54.001 - 56.000 56.001 - 58.000 58.001 - 60.000 60.001 - 75.000 75.001 - 80.000. Qtd de e-mails 672.000 696.000 720.000 900.000 960.000. Preço (Dólar) $300,00 USD $325,00 USD $350,00 USD $375,00 USD $400,00 USD. Tabela 2 – Preço mensal do GetResponse Qtd. de pessoas 1.000 5.000 10.000 Mais de 100.000. Preço (Dólar) $15,00 USD $49,00 USD $165,00 USD $999,00 USD. Atualmente os sistemas da SINFO geram aproximadamente 400.000 mil e-mails por mês e a base de usuários possui cerca de 213 mil pessoas (funcionários/alunos ativos e 7. O autor deste trabalho de mestrado é analista de sistemas da SINFO desde 2010 com cinco anos de experiência na equipe de desenvolvimento e atualmente faz parte da equipe de Infraestrutura de Sistemas, uma equipe criada para ser a interseção entre desenvolvimento e redes..

(23) 1.1. Motivação. 21. Tabela 3 – Preço mensal do Locaweb SMTP Qtd. de e-mails 100 250 500 1.000 2.000 3.000 5.000. Preço (Real) R$ 198,00 R$ 316,00 R$ 475,20 R$ 844,80 R$ 1.440,00 R$ 1.920,00 R$ 2.880,00. aposentados/ex-alunos). O número de e-mails enviados poderia ser muito maior se todos os departamentos da UFRN convergissem para os sistemas da SINFO, como por exemplo a Agência de comunicação (AGECOM) órgão responsável pela comunicação institucional dentro da instituição. No entanto, pela falta de confiança eles acabam usando essas plataformas externas. Dessa forma, se a SINFO não desenvolver uma plataforma de comunicação eficiente num futuro próximo ela também terá que contratar essas ferramentas para prover aos sistemas desenvolvidos internamente com um bom mecanismo de comunicação via e-mail, já que a solução atual não tem boa aceitação. As tabelas 1, 2 e 3 são um cotação8 dos valores praticados pelas plataformas Mailchimp, GetResponse e Locaweb SMTP, respectivamente. Analisando essas tabelas e adaptando para as necessidade da SINFO: o Mailchimp e GetResponse custariam mais de $999 Doláres/mês e o Locaweb SMTP 230 mil reais por mês. É um gasto público desnecessário já que a UFRN dispõe de mão de obra qualificada no desenvolvimento de sistemas. Além de tudo que já foi exposto, segundo o Plano Diretor de Tecnologia da Informação (PDTI)(UFRN/SINFO, 2015) a SINFO possui como meta Melhorar Comunicação Institucional e para isso deve “apoiar a melhoria das comunicações institucionais, seja para o público interno seja para o externo à UFRN” (UFRN/SINFO, 2015, p. 51). Isso ocorrerá através do desenvolvimento de sistemas, implantação de serviços e tudo mais que trouxer benefícios neste campo. Podemos concluir que de fato o uso de sistemas de informação voltados para comunicação institucional é bastante disseminado dentro da UFRN. Entretanto, apesar da importância para a gestão e do alto volume de e-mails que provam o quanto o e-mail é utilizado, os sistemas desenvolvidos internamente não são eficientes o bastante para essa tarefa. O desenvolvimento da Plataforma Hermod, proposta nesta dissertação, vai permitir que a SINFO cumpra as metas institucionais relacionadas a comunicação institucional.. 8. Cotação realizada em 02/08/2017.

(24) 22. Capítulo 1. Introdução. 1.2 Objetivos Este trabalho tem como objetivo geral desenvolver o Hermod, uma plataforma capaz de gerenciar o processo de comunicação institucional da UFRN através de uma plataforma que oferecerá serviços de e-mail a outros sistemas que foram desenvolvidos dentro da UFRN. Assim eles poderão usufruir dos recursos desta plataforma sem que seja necessário criar uma infraestrutura de servidores de e-mail. A plataforma propõe resolver os problemas que foram discutidos na seção 1.1 Motivação, desta forma ele irá atuar como um middleware oferecendo para outros sistemas serviços de envio e rastreio de e-mail, por exemplo. Outros objetivos gerais que guiam o desenvolvimento desta aplicação são: Interoperabilidade Atuar como um middleware para permitir a comunicação com outros sistemas através de uma plataforma independente para que sistemas construídos com outras linguagens possam integrar com o Hermod. Alta disponibilidade Através da replicação, executando o Hermod simultaneamente em diferentes locais. Tolerância a falhas A plataforma continua funcionando mesmo em caso de alguma falha inesperada. Elasticidade Capacidade de gerenciar o conjunto de servidores de e-mail em tempo de execução, podendo aumentar e diminuir a quantidade de servidores de acordo com a demanda. Para atingir o objetivo geral, os seguintes objetivos específicos precisam ser atingidos: • Extrair e analisar as reclamações e sugestões abertas dos usuários no sistema de chamados; • Identificar os problemas do módulo de envio da Arquitetura SIG; • Desenvolver uma plataforma resolvendo os problemas encontrados no módulo de envio da Arquitetura SIG; • A nova plataforma deve ser desenvolvida com as seguintes características como guia: interoperabilidade, alta disponibilidade, tolerância a falhas e elasticidade; • Avaliar a solução final confrontando com o módulo de envio da Arquitetura SIG..

(25) 1.3. Organização do trabalho. 23. Espera-se que com a criação deste projeto a SINFO e a UFRN atinjam as metas estabelecidas no PDTI (UFRN/SINFO, 2015) e o PDI (UFRN, 2010) — o PDI é avaliado de acordo com (MEC/CONAES, 2004). Outro benefício direto é poupar recursos públicos evitando a contratação de serviços de terceiros, como acontece atualmente em alguns setores da instituição pela falta de credibilidade da solução de envio de e-mail presente na Arquitetura SIG atualmente em uso.. 1.3 Organização do trabalho Esta dissertação contém, além do capítulo 1 que apresentamos a Introdução, possui também os seguintes capítulos conforme descritos a seguir. No Capítulo 2, Módulo de envio de e-mail da Arquitetura SIG, abordamos aspectos importantes para compreensão do problema e tecnologias que servirão de base teórica para implementação do projeto. No Capítulo 3, Fundamentação Teórica, abordamos aspectos importantes para compreensão do problema e tecnologias que servirão de base teórica para implementação do projeto. No Capítulo 4, Hermod - Uma plataforma para serviços de e-mail, descrevemos a concepção, implementação do projeto e decisões arquiteturais que nortearam o projeto. No Capítulo 5, Testes de desempenho e Resultados, apresentamos os resultados obtidos sobre diversos casos de testes do Hermod. No Capítulo 6, Considerações Finais, apresentamos as conclusões deste trabalho e perspectivas futuras..

(26)

(27) 25. 2 Módulo de envio de e-mail da Arquitetura SIG 2.1 Sistemas Integrados de Gestão da UFRN (SIG-UFRN) Antes do surgimento em 2004 dos Sistemas Integrados de Gestão da UFRN, ou Sistemas SIG, havia um cenário onde sistemas independentes sem integração de qualquer natureza entre eles, com custos elevados e que não atendiam as necessidades dos gestores (LINS, 2016). Os sistemas foram desenvolvidos utilizando tanto uma base de dados quanto uma estrutura de código em comum. Por isso, apesar de terem objetivos negociais distintos, eles possuem funcionalidades em comum, tais como citado em Lins (2016): acesso unificado com mesmo login e senha; padrão de visualização com mesma cor e aparência para todos os sistemas/módulos; personalização e parametrização, com comportamentos e restrições personalizadas e controle de permissão por meio de perfil do usuário. Essa estrutura de código em comum entre os Sistemas SIG é chamada pela equipe de desenvolvedores como Arquitetura SIG e funciona basicamente como um framework, facilitando a vida do desenvolvedor com várias funcionalidades já prontas, como as que foram citadas anteriormente. Além de outras dezenas de funcionalidades, a arquitetura possui um módulo para envio de e-mail, que é o objeto de análise desta seção. Segundo (UFRN/SINFO, 2010) a Arquitetura SIG foi modelada em uma arquitetura multicamadas (FOWLER et al., 2003) utilizando Java/JEE e um conjunto de frameworks auxiliares. Devido a heterogeneidade de processos e lógicas de negócios, a arquitetura foi modelada seguindo princípios arquiteturais que resultassem em segurança, privacidade, portabilidade, distribuição e reutilização. A arquitetura foi elaborada com as seguintes restrições (UFRN/SINFO, 2010): Interoperabilidade Integração entre os sistemas institucionais (SIPAC1 , SIGRH2 , SIGAA3 ). Por exemplo, o sistemas acadêmico (SIGAA) e o administrativo (SIPAC) necessitam de dados relacionados aos recursos humanos da instituição (SIGRH) para o correto funcionamento de diversas funcionalidades. Dessa forma, ao invés desses dados serem alimentados também no SIGAA e SIPAC, eles são recuperados dos dados lançados no SIGRH. Segurança A segurança é feita no nível de autenticação e autorização. A autenticação é 1 2 3. Sistema Integrado de Patrimônio, Administração e Contratos Sistema Integrado de Gestão de Recursos Humanos Sistema Integrado de Gestão de Atividades Acadêmicas.

(28) 26. Capítulo 2. Módulo de envio de e-mail da Arquitetura SIG. realizada baseada em usuário e senha. Já a autorização é implementada usando o conceito de usuários, papéis e subsistemas. Escalabilidade Os sistemas institucionais são utilizados por toda a universidade. Portanto, foi necessário desenvolver os sistemas de forma que eles fossem capazes de atender a uma variação de usuários lenta ou súbita. Alta Disponibilidade A utilização do sistema em funções administrativas, acadêmicas e de recursos humanos exige do mesmo uma alta disponibilidade, uma vez que os sistemas são utilizados para o auxílio à execução das diversas tarefas de cada área. Implementar Complexidade de Infra-Estrutura (Abstrair Complexidade) A arquitetura de software deve abstrair os elementos mais críticos/complexos do software, de forma a tornar o desenvolvimento dos subsistemas e seus respectivos casos de uso mais simples.. 2.1.1 Arquitetura em camadas A Aarquitetura SIG, elaborada para o desenvolvimento dos sistemas institucionais, utiliza a abordagem de separação em camadas (FOWLER et al., 2003). O intuito é não misturar as responsabilidades dos componentes dos sistemas, onde cada componente deve ter suas responsabilidades bem definidas. As camadas são utilizadas para realizar esta organização, agrupando os componentes com funcionalidades afins em camadas semelhantes (UFRN/SINFO, 2010). Figura 1 – Camadas da Arquitetura SIG. A Figura 1 apresenta como as camadas da arquitetura estão organizadas. A camada de Apresentação é utilizada para a exibição de informações em janelas ou páginas HTML..

(29) 2.2. Módulo de envio de e-mail da Arquitetura SIG. 27. É nela que há a manipulação de requisições do usuário e de requisições HTTP. Camada de Aplicação delega trabalho da camada de apresentação para a camada de domínio. Adiciona serviços (transações, por exemplo) ao sistema. Camada de Domínio/Negócio representa a lógica de negócio dos sistemas. A camada de Infra-Estrutura/Acesso a Dados permite a comunicação com a base de dados, disponibiliza serviços de mensagens como JMS (Java Message Service), etc.. 2.2 Módulo de envio de e-mail da Arquitetura SIG Entre os recursos que a Arquitetura SIG oferece estão o de envio de e-mails através de um módulo presente na camada de Domínio/Negócio. O funcionamento deste módulo consiste em oferecer uma estrutura de fila local que é armazenada em memória dentro do próprio sistema. Quando algum usuário ou evento de sistema dispara uma ação que deve ser enviado um e-mail, este e-mail é colocado nesta fila e aguarda até o momento de sua vez, quando é consumido e enviado. Um exemplo simplificado do que acabamos de descrever pode ser visto na figura 2. Esta figura mostra a Arquitetura SIG com suas camadas e onde o módulo de envio de e-mails está inserido. Também mostra uma visão geral do funcionamento do módulo de envio de e-mail. Figura 2 – Visão das camadas da Arquitetura SIG e visão geral do módulo de envio de e-mail. Na análise da solução de envios de e-mail pela Arquitetura SIG utilizada pela.

(30) 28. Capítulo 2. Módulo de envio de e-mail da Arquitetura SIG. UFRN buscamos identificar dois pontos: (i) identificar funcionalidades importantes que não foram implementadas; (ii) verificar os problemas desta solução. Além desta análise é importante identificar aspectos que prejudicam a taxa de entregabilidade. Essa análise é uma etapa importante neste trabalho pois ela norteará várias decisões na arquitetura do software que iremos desenvolver. Começando pelo ponto (i) percebemos que infelizmente o sistema atual não possui nenhuma capacidade de rastrear os e-mails enviados4 . Então o usuário não consegue saber se ocorreu alguma falha no sistema de envio, ou falha no servidor do destinatário, ou até mesmo quantos e-mails foram entregues aos destinatários. A lacuna dessa funcionalidade prejudica avaliação do quanto a instituição está conseguindo atingir seu público-alvo. Além disso, o sistema atual não possui funções que poderiam melhorar a qualidade da informação enviada. Por exemplo, se o remetente soubesse a taxa de e-mails que foram abertos de fato pelos destinatários, ele poderia traçar o perfil do seu público e mandar notícias de acordo com o perfil do público alvo. Isso aumentaria a efetividade da comunicação, uma vez que a chance do remetente ignorar o e-mail é menor. Em relação ao ponto (ii) analisamos o comportamento do módulo de envio da Arquitetura SIG em produção com a ajuda de ferramentas de software profiling 5 em conjunto com os logs produzidos pelo sistema e constatamos que: Single Thread Não existe qualquer tipo de programação concorrente. Se uma lista grande de e-mails deve ser enviada cada e-mail será processado de forma serial, ou seja, a entrega da mensagem ao servidor de e-mail é feita uma a uma. Perda da fila de e-mail Durante o envio dos e-mails, a fila é armazenada somente em memória. Se ocorrer alguma interrupção no sistema todos os e-mails que não foram processados são perdidos. Má distribuição entre as fila de e-mail Como dito, cada sistema possui sua própria fila de e-mails e também tem a responsabilidade de envia-los. Se a fila de e-mails fosse compartilhada, todos os sistemas (que usam a Arquitetura SIG) poderiam consumir da fila e enviar os e-mails dividindo o trabalho do envio. Registros ineficientes Cada envio realizado é armazenado em uma base de dados relacional. Devido ao volume alto de e-mails que são enviadas pelos sistemas, essa base de dados perde desempenho. Consultas simples tendem a levar minutos até serem completadas e isso inviabiliza o uso de consultas ao banco. 4. 5. Por padrão o SMTP não oferece nenhum mecanismo de rastreio, mas através de extensões do SMTP ou soluções alternativas é possível obter essa funcionalidade Uma forma de análise dinâmica do programa que permite quantificar por exemplo, o consumo de memória, threads, uso de CPU, o tempo de execução de métodos e outros..

(31) 2.2. Módulo de envio de e-mail da Arquitetura SIG. 29. Rastreio Não possui funcionalidades de rastreamento (tracking), não sabemos se o e-mail foi recebido pelo SMTP do destinatário ou a razão de não ser entregue. Consumo de memória Quando o e-mail a ser enviado possui anexos, isso pode aumentar significativamente o consumo de memória, e os mesmos irão consumir muita memória, impactando negativamente em todo o sistema. Muitas vezes o sistema degrada ao ponto de ficar temporariamente inacessível e só volta ao normal na medida que a fila de e-mail é consumida.. 2.2.1 Teste de desempenho Tabela 4 – Teste de desempenho 5 Núcleos e 1 Thread Qtd. de e-mails Tempo de envio 80.000 1h 02m 52s 40.000 11m 02s 1.000 2m 15s Figura 3 – Gráfico com o. Fizemos um teste de carga da solução atual fornecida pela Arquitetura SIG para medir o tempo que ele leva para entregar as mensagem até o servidor de e-mail da UFRN. O resultado do teste encontra-se na tabela 4 e tem como objetivo servir de parâmetro.

(32) 30. Capítulo 2. Módulo de envio de e-mail da Arquitetura SIG. para os futuros testes que realizaremos do Hermod. Quando a quantidade de e-mails a serem enviados passa de 40.000, o tempo que o sistema leva para conseguir enviar cresce consideravelmente. Para facilitar a visualização deste crescimento que apontamos plotamos na figura 3 os valores da tabela 4. É muito importante realizar uma comunicação com rapidez e esse comportamento de crescimento inviabiliza essa característica. Como a especificação do SMTP não faz garantias sobre o tempo de entrega de e-mail, o sistema precisa otimizar o tempo de entrega até servidor de e-mail — servidor de e-mail do remetente — para reduzir o impacto do tempo total de envio. O foco dos Sistemas SIG está muito voltado para o desenvolvimento do negócio, tais como informatização de processos, aplicação de regras de negócio e implementações de sugestões da comunidade. Por isso, quando um problema técnico não possui uma relação direta com o negócio; e ou o problema técnico não é aparente; essas questões demoram a ganhar uma solução e foi assim com o módulo de e-mail. É difícil um sistema contemplar bem a quantidade de processos que os SIGs realizam, então funcionalidades adjacentes não recebem o foco. É uma questão de prioridade e não cabe a este trabalho decidir se o modelo atual é certo ou errado. Entretanto, uma solução para o problema é retirar dos SIGs as funcionalidades de e-mail e criar um sistema separado para tal, dessa forma, a separação de negócios contribui para que um não sobreponha o interesse do outro..

(33) 31. 3 Fundamentação Teórica Este capítulo apresenta uma discussão sobre conceitos e tecnologias que estão relacionados ao trabalho. Começamos explicando sobre a infraestrutura de e-mail atual, suas limitações e como as organizações que oferecem serviços de e-mail tratam esses problemas. Também falaremos sobre duas tecnologias que resultaram em um impacto positivo no trabalho que são: middlewares orientados a mensagens e virtualização.. 3.1 E-mail Nesta seção iremos falar sobre os princípios, arquitetura, detalhes do protocolo SMTP (Simple Mail Transfer Protocol) e maneiras que os provedores de e-mail encontraram para proteção de spam. É importante dar um embasamento sobre este tema porque o e-mail é a tecnologia de base para o Hermod.. 3.1.1 Introdução Desde o surgimento da primeira especificação do protocolo de e-mail (SMTP) em 1982, a infraestrutura do e-mail mudou significativamente em escala e complexidade, saindo de uma pequena rede de computadores conectados entre laboratórios para se tornar um serviço com infraestrutura global. As mudanças que ocorreram durante esse período foram mais evolucionárias do que revolucionárias, para Crocker (2009), isso é reflexo do forte desejo de preservar tanto sua utilidade quanto a sua base instalada. Mudanças drásticas em protocolos, por exemplo, proporcionaria melhorias mas com uma grande chance de comprometer a compatibilidade com toda a infraestrutura existente, o que é impensável. Existem diversas normas técnicas — conhecidas como Request for Comments (RFC) — mantidas pela Internet Engineering Task Force (IETF) que regem toda a Internet, mas especificamente para infraestrutura de e-mail as mais básicas e estruturantes são: SMTP Simple Mail Transfer Protocol (RFC 0821, RFC 2821, RFC 5321) define como a mensagem é transportada pela Internet. IMF Internet Mail Format (RFC 0733, RFC 0822, RFC 2822, RFC 5322) define a estrutura da mensagem. MIME Multipurpose Internet Mail Extensions (RFC 2045) um aprimoramento a mensagem que permite adicionar anexos multimídia..

(34) 32. Capítulo 3. Fundamentação Teórica. 3.1.2 Arquitetura do e-mail na Internet A primeira arquitetura de rede padronizada (veja figura 4) definia uma infraestrutura simples onde se podia dividir entre a camada do usuário — composta por Message User Agents (MUA) que são os programas usados pelos clientes para enviar e receber mensagens — e uma segunda camada que seria o meio de transporte da mensagem, chamada de Message Handling Service (MHS) — composta por Message Transfer Agents (MTAs) que são os servidores de e-mail responsáveis por receber e entregar ao usuário uma mensagem. O MHS aceita uma mensagem de um usuário e a entrega para um ou mais usuários, criando uma ligação ponto-a-ponto entre MUAs. (CROCKER, 2009) Figura 4 – Modelo básico da infraestrutura de e-mail. O protocolo responsável pela comunicação entre servidores (MTA) e utilizado pelos usuários para enviar mensagens, isto é, a conexão entre o MUA e o servidor de envio é feita pelo protocolo Simple Mail Transfer Protocol (SMTP). (KLENSIN, 2008) A mensagem transportada recebe o nome de mail object (figura 5) e consiste em duas partes: envelope e conteúdo. O envelope é a primeira parte e consiste de um endereço de origem, também referido como return-path (para o qual os relatórios de erro de entrega devem ser dirigidas), um ou mais endereços de destinatários e uma seção opcional para indicar o uso de extensões do protocolo. O conteúdo, segunda parte do mail object, compreende o objeto que vai ser entregue ao destinatário. De acordo com Resnick (2008), ela possui duas seções: header (cabeçalho) — contém uma coleção de campos do tipo chave-valor — e body (corpo) — contém a mensagem escrita pelo remetente. Vale ressaltar que um dos cabeçalhos que pode ser definido na seção do conteúdo é o endereço do remetente. Dessa maneira, o e-mail transitado tem duas informações de destinatário — e elas podem ter valores diferentes —, uma que reside no envelope e outra.

(35) 3.1. E-mail. 33. que reside no cabeçalho do conteúdo. Para facilitar o entendimento e evitar confusão de significado, sempre que nós nos referirmos ao campo do destinatário, iremos seguir a seguinte nomenclatura: Envelope From remetente contido no envelope. Header From remetente contido no cabeçalho de conteúdo.. Figura 5 – Estrutura do mail object. 3.1.3 Funcionamento do SMTP Como dito no início deste capítulo o e-mail é a tecnologia base para o Hermod. O objetivo desta seção é mostrar como funciona a negociação do protocolo SMTP entre um cliente e um servidor de e-mail, porque é exatamente isso o que acontece quando uma mensagem de e-mail é enviada através da plataforma Hermod. O funcionamento do SMTP consiste de algumas fases e procedimentos. A listagem 3.1 é um exemplo básico para ilustrar o funcionamento do SMTP. Nela as linhas que contêm {C} são comandos enviados pelo cliente e {S} são respostas enviadas pelo servidor. Para facilitar a explicação da listagem 3.1 vamos separá-la em três fases. Listing 3.1 – Exemplo de uma comunicação com SMTP 1 2. { S }: 220 foo . com Simple Mail Transfer Service Ready { C }: EHLO bar . com.

(36) 34. 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25. Capítulo 3. Fundamentação Teórica. { S }: { S }: { S }: { S }: { S }: { C }: { S }: { C }: { S }: { C }: { S }: { C }: { S }: { C }: { C }: { C }: { C }: { C }: { C }: { C }: { S }: { C }: { S }:. 250 - foo . com greets bar . com 250 -8 BITMIME 250 - SIZE 250 - DSN 250 HELP MAIL FROM : < Smith@bar . com > 250 OK RCPT TO : < Jones@foo . com > 250 OK RCPT TO : < Green@foo . com > 550 No such user here RCPT TO : < Brown@foo . com > 250 OK DATA From : userfake@foo . com Subject : Mensagem de exemplo Somente um teste . Esta mensagem possui dois " from " diferentes . . 250 OK QUIT 221 foo . com Service closing transmission channel. A primeira fase é iniciar uma sessão (linha 1) e acontece depois que o cliente abre com sucesso uma conexão TCP (3-way handshake 1 ) com o servidor de e-mail e recebe uma mensagem contendo o status 220, indicando que o servidor está pronto para negociar o envio de e-mails. Após essa fase inicial, segue a identificação do cliente (linhas 2 a 7) através do comando EHLO/HELO. Os servidores modernos suportam o uso do EHLO, com este comando o cliente diz estar apto a usar extensões e solicita ao servidor que retorne uma lista com todas as extensões suportadas. Para servidores antigos, antes da criação de extensões, o comando usado é HELO. A terceira fase é o início da transação (linhas 8 à 25) onde o cliente passa ao servidor o object mail:. 1. O comando MAIL FROM:<return-path> é usado para designar a caixa postal de origem e é usado quando servidores precisam reportar erros de entrega ao destinatário. 2. Usando RCPT TO:<e-mail> é definido o destinatário. 3. Por último, o comando DATA <CRLF> define o conteúdo do e-mail. Como dito anteriormente, a RFC 5322 (RESNICK, 2008) é quem define o formato desse conteúdo. 1. Nome do processo que descreve como é realizada uma conexão TCP..

(37) 3.1. E-mail. 35. Na linha 8 e 17 podemos observar que o destinatário foi definido duas vezes e com valores diferentes. Como explicado na seção 3.1.2 Arquitetura do e-mail na Internet, a linha 8 é o Envelope From, enquanto a linha 17 é o Header From. Essa característica do SMTP e a falta de uma autenticação nativa permite que qualquer um possa enviar um e-mail como sendo uma outra pessoa já que os clientes de e-mail quando exibem a mensagem de e-mail mostram o remetente do Header From.. 3.1.4 Rastreio de e-mails enviados Saber se o e-mail enviado chegou até o destinatário ou se a mensagem foi enviada para um e-mail inválido é uma função importante para a realização da comunicação. Entretanto a especificação do SMTP não define uma forma do remetente obter a informação sobre a entrega do e-mail ou qualquer erro que ocorreu com a entrega do e-mail. A falta de rastreabilidade foi um dos problemas que enfrentamos durante o desenvolvimento do Hermod e esta seção representa as soluções que levamos em consideração para a resolução deste problema. Para contornar a deficiência da especificação do STMP em relação ao rastreio dos e-mails enviados, formas alternativas de obter essa informação foram criadas como Variable Envelope Return Path (VERP) e Delivery Status Notifications (DSN). Quando falamos sobre rastreio de e-mails um conceito importante é o e-mail bounced. Qualquer tipo de erro que comprometa a entrega da mensagem ao seu destinatário (destinatário não existe, falha de servidor, etc) é chamdo de e-mail bounced. Os bounces são retornos dos provedores aos endereços de e-mail que apresentam algum erro. Estes erros são classificados em dois grupos: (GEORGIEVA, 2012). Soft Bounces São erros temporários, que podem surgir por uma série de motivos, entre eles: caixa de entrada cheia, falhas temporárias de acesso, bloqueio por antivírus com proteção antispam, falhas temporárias de conexão, entre outros. Este tipo de erro não é grave, e muitas vezes uma nova tentativa de entrega é feita pois os destinatários podem estar passando só por um período ruim e logo voltam ao estado normal.. Hard Bounce Estes erros podem aparecer quando o e-mail não existe, uma conta é inativada ou por qualquer outro problema que faça a conta ser inacessível por muito tempo. Erros permanentes devem ser tratados com mais rigor do que os erros temporários, pois forçar o envio para e-mails com hard bounce pode fazer com o remetente seja taxado como um emissor de spam (mais detalhes sobre spam na seção 3.1.5 Proteção contra SPAM)..

(38) 36. Capítulo 3. Fundamentação Teórica. 3.1.4.1 Variable Envelope Return Path (VERP) Às vezes, uma mensagem de devolução (bounced mail) não identifica o endereço em que a mensagem não pôde ser entregue ou pode até deixar de incluir uma cópia original da mensagem. Outro problema é que essas mensagens historicamente foram feitas para um humano ler, sendo difícil fazer um parsing automático nelas pela falta de padronização. Esse e outros problemas (discutidos no RFC 1211) fazem com que a identificação das mensagens de devolução não fosse algo preciso. (BERNSTEIN, 1997) Esse problema afeta mais listas de discussão com muitos participantes, pois gerenciar tantas mensagens de devolução pode ser caótico. Diante desses problemas, foi criado o Variable Envelope Return Path (VERP), uma técnica antiga (1997) mas amplamente usada ainda hoje por softwares de listas eletrônicas de e-mail para habilitar automaticamente a detecção de endereços de e-mails que não podem ser entregues. A técnica consiste em fazer com que cada destinatário da mensagem veja um envelope com endereço de remetente diferente (Envelope from). (BERNSTEIN, 1997) Dessa forma, quando uma mensagem é enviada de [email protected] para a lista de discussão [email protected], o Envelope from muda para: [email protected]. Como pode ser visto, o formato do endereço fica sendo: listasw − owner − [remetente = dominio_remetente]@sof tware.br O @ do e-mail de origem é substituído por = e reinserido como parte do endereço eletrônico. Caso a mensagem falhe ao ser entregue quem vai receber a mensagem de devolução é esse endereço de e-mail. Essa forma de análise é útil porque ela não depende do conteúdo do e-mail de devolução ou de qualquer RFC normatizadora. O gerenciador da lista só precisa observar os e-mails que chegam no MTA com o padrão listasw-owner-* para capturar os e-mails que retornam por falha de entrega. A desvantagem dessa técnica é que todos e-mails enviados precisam ter o Envelope from reescrito e também precisa de uma configuração na infraestrutura de servidores, para fazer com que o padrão listasw-owner-* seja salvo para depois ser processado pela gerenciador da lista. (BERNSTEIN, 1997) 3.1.4.2 Delivery Status Notifications (DSN) O Delivery Status Notifications (DSN) é uma extensão que introduz a funcionalidade de notificar o remetente de uma mensagem (Envelope from) quando acontecem algumas dessas condições: não entrega, entrega atrasada ou entrega bem-sucedida. Existem duas normatizações que definem esta funcionalidade. Em Moore e Vaudreuil (2002) (RFC 3464).

(39) 3.1. E-mail. 37. é definido o formato da mensagem e (MOORE, 2003) (RFC 3461) especifica como será a atuação da mensagem dentro da infraestrutura de e-mail. Uma mensagem pode ser transmitida através de vários Message Transfer Agents (MTA) em seu caminho até um destinatário. Existe uma terminologia para designar cada servidor MTA que a mensagem passou (hop) durante seu translado: Original MTA é o MTA de saída do remetente, no qual a mensagem é despachada para o destinatário. Reporting MTA é o servidor que está relatando se a entrega foi bem-sucedido ou não. Received-From MTA é o servidor que repassou a mensagem para o Reporting MTA. Remote MTA Durante os saltos da mensagem entre os servidores, o Remote MTA é a aquele que representa o servidor de e-mail do destinatário.. Figura 6 – Terminologia dos servidores durante um fluxo DSN. A figura 6 é um exemplo que mostra o caminho que o e-mail percorre entre cada um dos servidores de e-mail. Neste exemplo o e-mail não pode ser entregue ao Remote MTA, assim o último servidor que o e-mail passou recebe a função de reportar uma notificação de erro ao remetente. Um DSN é uma mensagem que segue o formato definido pelo MIME (Multipurpose Internet Mail Extensions) sendo um especificação do multipart/report (um content-type definido na RFC 6522). Para facilitar o entendimento, vamos apresentar uma mensagem DSN real na listagem 3.2. Uma mensagem DSN segue o formato de um e-mail comum, mas com algumas peculiaridades: (a) Na linha 11 o cabeçalho do Content-Type é definido com o valor multipart/report e o parâmetro report-type com o valor delivery-status. Isso indica que este e-mail é um relatório DSN sobre a entrega do e-mail que foi enviado. (b) É obrigatório constar no relatório uma mensagem legível por humanos. As linhas 18 a 30 representa esse trecho..

(40) 38. Capítulo 3. Fundamentação Teórica. (c) Da linha 34 a 47 representa os campos definidos para o DSN. A utilidade desses campos é armazenas informações sobre a entrega. Abaixo alguns exemplos: Arrival-Date Data que a mensagem foi recebida pelo Remote MTA — último MTA que a mensagem passou. Status Código que informa o status da mensagem. Através desse código consigmos saber se foi um hard ou soft bouncer. Diagnostic-Code Uma explicação detalhada do erro emitido pelo Reporting MTA. Message-ID ID da mensagem original. Campo importante para identificar a mensagem. (d) Da linha 50 a 68 é uma cópia da mensagem original que foi enviado até o destinatário.. Listing 3.2 – Exemplo da primeira parte sobre DSN 1 2 3 4 5 6 7 8 9 10 11 12 13. Received : from mta . ufrn . br ( LHLO mta . ufrn . br ) (10.3.226.15) by mail . ufrn . br with LMTP ; Fri , 23 Sep 2016 18:12:02 -0300 ( BRT ) Received : by mta . ufrn . br ( Postfix ) id CC824142CBC ; Fri , 23 Sep 2016 18:14:23 -0300 ( BRT ) Date : Fri , 23 Sep 2016 18:14:23 -0300 ( BRT ) From : MAILER - DAEMON@mta . ufrn . br ( Mail Delivery System ) Subject : Successful Mail Delivery Report To : mailteste@info . ufrn . br Auto - Submitted : auto - replied MIME - Version : 1.0 Content - Type : multipart / report ; report - type = delivery - status ; boundary = " B46C5142CBB .1474665263/ mta . ufrn . br " Message - Id : <20160923211423. CC824142CBC@mta . ufrn . br >. 14 15. This is a MIME - encapsulated message .. 16 17 18 19. -- B46C5142CBB .1474665263/ mta . ufrn . br Content - Description : Notification Content - Type : text / plain ; charset = us - ascii. 20 21. This is the mail system at host mta . ufrn . br .. 22 23 24 25 26. Your message was successfully delivered to the destination ( s ) listed below . If the message was delivered to mailbox you will receive no further notifications . Otherwise you may still receive notifications of mail delivery errors from other systems .. 27 28. The mail system. 29 30 31. < henrique@info . ufrn . br >: delivery via mail . ufrn . br [10.3.226.17]:7025: 250 2.1.5 Delivery OK. 32 33 34 35. -- B46C5142CBB .1474665263/ mta . ufrn . br Content - Description : Delivery report Content - Type : message / delivery - status.

(41) 3.1. E-mail. 39. 36 37 38 39 40. Reporting - MTA : dns ; mta . ufrn . br X - Postfix - Queue - ID : B46C5142CBB X - Postfix - Sender : rfc822 ; mailteste@info . ufrn . br Arrival - Date : Fri , 23 Sep 2016 18:14:23 -0300 ( BRT ). 41 42 43 44 45 46 47. Final - Recipient : rfc822 ; henrique@info . ufrn . br Original - Recipient : rfc822 ; henrique@info . ufrn . br Action : relayed Status : 2.1.5 Remote - MTA : dns ; mail . ufrn . br Diagnostic - Code : smtp ; 250 2.1.5 Delivery OK. 48 49 50 51. -- B46C5142CBB .1474665263/ mta . ufrn . br Content - Description : Message Headers Content - Type : text / rfc822 - headers. 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67. Return - Path : < mailteste@info . ufrn . br > Received : from dmx1 . info . ufrn . br ( dmx1 . info . ufrn . br [10.3.156.14]) by mta . ufrn . br ( Postfix ) with ESMTP id B46C5142CBB for < henrique@info . ufrn . br >; Fri , 23 Sep 2016 18:14:23 -0300 ( BRT ) Received : from henrique - infra ( unknown [10.3.130.149]) by dmx1 . info . ufrn . br ( Postfix ) with ESMTP id 7 EBCF40E5BF7 for < henrique@info . ufrn . br >; Fri , 23 Sep 2016 18:13:09 -0300 ( BRT ) From : Henrique < mailteste@info . ufrn . br > Message - ID : <1921523223.1.1474665406559 @henrique - infra > Subject : Title here ! MIME - Version : 1.0 Content - Type : multipart / alternative ; boundary = " - - - -= _Part_0_1379724391 .1474665406543 " X - Hermod : 3830 fa66 -0282 -43 e1 -9 a4c -78 bc563dd411 heralt - id Date : Fri , 23 Sep 2016 18:14:23 -0300 ( BRT ). 68 69. -- B46C5142CBB .1474665263/ mta . ufrn . br - -. 3.1.5 Proteção contra SPAM O spam é um assunto sensível e foi um problema que enfrentamos com o módulo de envio da Arquitetura SIG (a Arquitetura SIG é discutida no capítulo 2 Módulo de envio de e-mail da Arquitetura SIG) e precisava ser tratada no Hermod. Para isso, procuramos entender como os grandes provedores de e-mail classificavam as mensagens como spam e quais atributos eles levavam em consideração. Na nossa pesquisa constatamos que os provedores de e-mail possuem regras e boas práticas que quando seguidas corretamente diminuem a chance de uma mensagem legítima ser tratada como spam (falso positivo). 3.1.5.1 Boas práticas de envio em massa No levantamento realizado no setor de suporte ao usuário da SINFO (citado na seção 1.1 Motivação) identificamos que parte da reclamações aconteciam porque os provedores.

(42) 40. Capítulo 3. Fundamentação Teórica. de e-mail classificavam como spam as mensagens enviadas pelos sistemas que utilizavam o módulo de envio da Arquitetura SIG. Então é preciso entender quais erros são cometidos para isso acontecer e buscar soluções para que o Hermod resolva este problema. Então passamos a pesquisar este problema para entender o porque dos e-mails enviados serem classificados como spam pelos provedores de e-mail. Isso acontece devido a problemas que existem na infraestrutura de e-mails da Internet e como os provedores de e-mail o contornam. Quando essa infraestrutura foi concebida não existiam preocupações relacionadas à segurança e ao envio indesejado de e-mails, e adotou-se o princípio de cooperação e confiança entre os participantes. Para evitar abusos dos participantes, esses provedores criaram mecanismos de classificação de e-mails para proteger os usuários, mas é possível que algumas mensagens legítimas (de bons emissores) sejam marcadas como spam senão tiver o tratamento adequado pelo remetente. Figura 7 – Gráfico dos maiores provedores de e-mail na base da UFRN. Pesquisamos as documentações do Google2 , Yahoo3 e Hotmail4 sobre práticas recomendadas para garantir que os e-mails enviados pelo Hermod sejam entregues aos usuários. Nossa pesquisa foi baseada nesses três provedores de e-mail porque são os domínios com mais frequentes entre os alunos/servidores na UFRN, como pode ser visto na figura 7. Cada requisito implementado aumenta a chance do e-mail ser entregue com sucesso ao destinatário. 2 3 4. https://support.google.com/mail/answer/81126?hl=pt https://ph.help.yahoo.com/kb/bulk-email-industry-standards-practices-sln3435.html https://mail.live.com/mail/services.aspx.

(43) 3.1. E-mail. 41. Autenticação e identificação Este aspecto envolve configuração de serviços e não tem relação com implementações em software, mas é importante para o sucesso da solução como um todo. A autenticação garante que as mensagens sejam classificadas corretamente. É provável que os e-mails sem autenticação sejam rejeitados ou colocados na pasta spam, devido ao alto risco de serem mensagens falsas usadas em golpes de phishing 5 . Abaixo, listamos os requisitos necessários a serem implementados na infraestrutura para que uma mensagem seja aceita como confiável pelos provedores de e-mail: • Assinar as mensagens com DomainKeys Identified Mail (DKIM) usando chaves de no mínimo 1024 bits. • Publicar um Registro Sender Policy Framework (SPF) no DNS. • Publicar um Registro Domain-based Message Authentication, Reporting & Conformance (DMARC) no DNS. • Publicar um registro de DNS reverso (PTR). O DNS reverso resolve um endereço IP para um nome de servidor. Pessoas que fazem spam costumam usar domínios genéricos (por exemplo domínios gratuitos) e estes domínios não costumam ter um DNS reverso definido. Por isso, remetentes que não definem um DNS reverso costumam ser bloqueados pelo provedores de e-mail. • Impedir Open Relay 6 e Open Proxy 7 Cancelamento de Recebimento Deixar claro para o usuário as maneiras dele cancelar o recebimento de e-mails oriundos do Hermod. Os e-mails enviados devem ter no corpo das mensagens um link destacado que leva os usuários a uma página que confirma o cancelamento da inscrição e mais nenhuma ação dos usuários deve ser necessária além da confirmação. Além disso, o Gmail tem um cabeçalho especial chamado List-Unsubscribe que deve apontar para um endereço de e-mail ou um URL no qual o usuário possa cancelar facilmente a inscrição. Formatação O conteúdo da mensagem também influencia no sucesso de entrega. As seguintes sugestões aumentam a taxa de entrega: • Todas as mensagens devem ser formatadas de acordo com RFC 5322 e, no caso de uso de HTML, com padrões HTML; 5. 6. 7. Uma forma de fraude eletrônica, caracterizada por tentativas de adquirir dados pessoais de diversos tipos; senhas, dados financeiros como número de cartões de crédito e outros dados pessoais. Open relay é um servidor de e-mail que aceita conexões de qualquer usuário da Internet e permite o envio de e-mails através dele. Assim como os open relays os open proxies também permitem a utilização ilícita. A diferença entre um e outro encontra-se na forma em que a conexão é efetuada. Enquanto os open relays permitem a utilização principalmente através da porta 25 (SMTP) os open proxies permitem conexões em portas diversas..

(44) 42. Capítulo 3. Fundamentação Teórica. • Utilizar o cabeçalho precedence com valor bulk; • O campo from do conteúdo da mensagem deve ser igual ao do envelope. Monitorar erros de envio Insistir em enviar mensagens para destinatários que não existem (hard bounce) ou que estão com a caixa postal cheia (soft bounce) resultará com que qualquer outra mensagem enviada pelo Hermod não seja mais entregue ou sofra atraso na entrega. Para os provedores de e-mail essa insistência é considerada um abuso. Esse assunto é discutido com mais detalhes na seção 3.1.4 Rastreio de e-mails enviados. Infelizmente nem a solução da Arquitetura SIG e nem a infraestrutura de servidores de e-mail da UFRN implementaram qualquer um desses mecanismos. Então isso justifica o motivo dos e-mails que são enviados pela Arquitetura SIG serem classificados como spam. Isso também traz uma consequência negativa para UFRN que é tratada como um mal remetente dentro da Internet e frequentemente é preciso solicitar aos mantenedores de blacklists (mais detalhes sobre blacklists na seção 3.1.5 Proteção contra SPAM) para removerem o IP da UFRN. Com o Hermod nosso objetivo não é burlar as regras para o envio de mensagens de spam, por isso seguir estas regras garante em primeiro lugar a segurança dos clientes que recebem nossas mensagens e por fim garante que nossa plataforma não cometa abusos de envio. Abaixo vamos falar de dois mecanismos que os provedores de e-mail costumam usar para proteção de spam: sistemas baseados em reputação e sistemas baseados em quotas e blacklists. 3.1.5.2 Sistemas baseados em reputação Sistemas baseados em reputação foram uma alternativa não oficial — não existe uma RFC que as normatize — que as prestadoras de serviço de e-mail, como Gmail e Yahoo encontraram para combater spams e mensagens falsas. Por se tratar de uma tecnologia fechada, nem sempre é possível obter os detalhes do seu funcionamento. Taylor (2006) descreve o primeiro mecanismo desse tipo desenvolvido pelo Google. Pela idade da publicação é quase certo que esse mecanismo já evoluiu desde então, mas é útil cita-lo aqui como exemplo de um mecanismo real. De acordo com Taylor (2006), o sistema de reputação do Gmail autentica o remetente com SPF e DKIM, e calcula a reputação do domínio autenticado. Para reputações acima de um limiar, o remetente é considerado bom e reputação abaixo de um certo limiar, o remetente é considerado ruim. Se o remetente é considerado bom, todas as mensagens do remetente são colocadas na caixa de entrada, caso contrário são colocadas na pasta de spam. Se a reputação é desconhecida, é feita uma avaliação estatística com um filtro de spam. (TAYLOR, 2006).

(45) 3.2. Middleware orientado a mensagens (MOM). 43. 3.1.5.3 Sistemas baseados em quotas e blacklists Outro mecanismo criado pelos provedores de e-mail para diminuir o volume de spam foi criar quotas de envio para limitar o volume de e-mails enviados por endereço IP ou por um endereço de correio eletrônico do remetente, por exemplo. Quando a quota do remetente é atingido, o provedor de e-mail realiza o bloqueio temporário do remetente e o notifica sobre o ocorrido. Caso o remetente continue enviando mensagens sem respeitar o bloqueio temporário, ele será taxado como um emissor de spam podendo sofrer um bloqueio permanente e ainda ser adicionado a alguma base pública de spam, conhecido como spam blacklists. Uma blacklist trata-se de uma lista de e-mails, domínios ou endereços IP, reconhecidamente fontes de spam. Geralmente, utiliza-se este recurso (blacklist) para bloquear os e-mails suspeitos de serem spam no servidor de e-mails.. 3.1.6 Considerações Esta seção fez uma introdução sobre o e-mail e sua arquitetura a fim de apresentar os conceitos necessários para entender como o Hermod deve utilizar esta tecnologia. Como dito antes o e-mail é a tecnologia de base para o Hermod. Além disso apresentamos dois problemas que o Hermod precisa resolver que é o rastreio de e-mails e lidar com as regras de spam que os provedores de e-mail possui. O que discutimos na seção 3.1.4 Rastreio de e-mails enviados será usado para a implementação de um componente no Hermod que será o responsável por gerenciar o rastreio dos e-mails. Os detalhes sobre o funcionamento e implementação deste componente estão descritos na seção 4.2.2.4 Componente de monitorar e-mail. Outro ponto desta seção que teve impacto sobre o desenvolvimento do Hermod foi a pesquisa realizada na seção 3.1.5 Proteção contra SPAM. Entendemos como funcionam as práticas dos provedores sobre classificar as mensagens como spam e como eles julgam que um remetente pode ser um spammer. A pesquisa sobre este item impactou sobre o desenvolvimento do Componente de envio de e-mail, através da implementação de regras de envio e inclusão de cabeçalhos especiais (detalhes na seção 4.2.2.2 Componente de envio de e-mail) e sobre o componente responsável por trazer elasticidade aos servidores de e-mail, aumentando ou diminuindo a quantidade de servidores acordo com a demanda (mais detalhes na seção 4.2.2.5 Componente de elasticidade).. 3.2 Middleware orientado a mensagens (MOM) No capítulo 2 foi feita uma análise do módulo de envio da Arquitetura SIG e um dos problemas apresentados foi Perda da fila de envio. Este era um problema que a plataforma.