Postfix com SPF,DKIM e DMARC - Redes de Computadores · utilizados para recuperação pelo agente...
Transcript of Postfix com SPF,DKIM e DMARC - Redes de Computadores · utilizados para recuperação pelo agente...
UNIVERSIDADE FEDERAL DE SANTA MARIACÓLEGIO TÉCNICO INDUSTRIAL DE SANTA MARIACURSO SUPERIOR DE TECNOLOGIA EM REDES DE
COMPUTADORES
ESTUDO DE UM SISTEMA DE E-MAILUTILIZANDO POSTFIX COM SPF, DKIM E
DMARC
TRABALHO DE GRADUAÇÃO
Luciano Silva da Silva
Santa Maria, RS, Brasil
2014
ESTUDO DE UM SISTEMA DE E-MAIL UTILIZANDOPOSTFIX COM SPF, DKIM E DMARC
Luciano Silva da Silva
Trabalho de Graduação apresentado ao Curso Superior de Tecnologia emRedes de Computadores da Universidade Federal de Santa Maria (UFSM, RS),
como requisito parcial para a obtenção do grau deTecnólogo em Redes de Computadores
Orientador: Prof. Dr. Renato Preigschadt de Azevedo
Santa Maria, RS, Brasil
2014
Silva, Luciano Silva da
ESTUDO DE UM SISTEMA DE E-MAIL UTILIZANDO POST-FIX COM SPF, DKIM E DMARC / por Luciano Silva da Silva. – 2014.
41 f.: il.; 30 cm.
Orientador: Renato Preigschadt de AzevedoMonografia (Graduação) - Universidade Federal de Santa Maria,
Cólegio Técnico Industrial de Santa Maria, Curso Superior de Tecnolo-gia em Redes de Computadores, RS, 2014.
1. E-mail. 2. Postfix. 3. SPF. 4. DKIM. 5. DMARC. I. Azevedo ,Renato Preigschadt de. II. Título.
c© 2014Todos os direitos autorais reservados a Luciano Silva da Silva. A reprodução de partes ou dotodo deste trabalho só poderá ser feita mediante a citação da fonte.E-mail: [email protected]
Universidade Federal de Santa MariaCólegio Técnico Industrial de Santa Maria
Curso Superior de Tecnologia em Redes de Computadores
A Comissão Examinadora, abaixo assinada,aprova o Trabalho de Graduação
ESTUDO DE UM SISTEMA DE E-MAIL UTILIZANDO POSTFIX COMSPF, DKIM E DMARC
elaborado porLuciano Silva da Silva
como requisito parcial para obtenção do grau deTecnólogo em Redes de Computadores
COMISSÃO EXAMINADORA:
Renato Preigschadt de Azevedo , Dr.(Presidente/Orientador)
Simone Regina Ceolin, Dra. (UFSM)
Rodrigo Castro Gil, Ms. (UFSM)
Santa Maria, 11 de Dezembro de 2014.
RESUMO
Trabalho de GraduaçãoCurso Superior de Tecnologia em Redes de Computadores
Universidade Federal de Santa Maria
ESTUDO DE UM SISTEMA DE E-MAIL UTILIZANDO POSTFIX COM SPF, DKIME DMARC
AUTOR: LUCIANO SILVA DA SILVAORIENTADOR: RENATO PREIGSCHADT DE AZEVEDO
Local da Defesa e Data: Santa Maria, 11 de Dezembro de 2014.
A comunicação por e-mail remota dos primórdios da internet e é uma das aplicaçõesmais importantes e de maior uso em rede de computadores. Com a disseminação do uso dainternet e do e-mail, tem sido um problema para os administradores de rede na classificaçãodeste tipo de correspondência eletrônica. E-mails não desejados caracterizados como SPAMgeram um tráfego desnecessário na rede além de uma sobrecarga nos servidores. Este trabalhoapresenta um configuração de um sistema de envio e recebimento de e-mail mostrando o fun-cionamento dos protocolos envolvidos no transporte da mensagem como SMTP e ESMTP, narecuperação de mensagem como os protocolos POP3 e IMAP e construção e formato da mensa-gem como o MIME. Aspectos de segurança no e-mail como PGP e S/MIME assim como tecno-logias para redução de e-mail indesejados em nível de domínio como SPF, DKIM e DMARC.É realizado uma implantação de um agente de transferência de e-mails com o software Post-fix e Courier com a configuração para uso com autenticação SASL, uso dos protocolos POP3e IMAP, uso de camada de segurança TLS além de aplicação de DKIM em e-mails enviadosatravés do software open-dkim e aplicação de política SPF para verificação dos e-mails recebi-dos. A instalação dentro da organização utilizando ferramentas com código aberto permite umaeconomia e segurança de um modo eficiente e didático para o administrador de rede.
Palavras-chave: E-mail. Postfix. SPF. DKIM. DMARC.
ABSTRACT
Undergraduate Final WorkBachelor Thesis
Federal University of Santa Maria
STUDY OF A SYSTEM OF E-MAIL USING POSTFIX WITH SPF, DKIM ANDDMARC
AUTHOR: LUCIANO SILVA DA SILVAADVISOR: RENATO PREIGSCHADT DE AZEVEDO
Defense Place and Date: Santa Maria, December 11st, 2014.
The remote communication by e-mail of the internet beginning and is one of the mostimportant applications and greater use of computer network. With the widespread use of theInternet and email, has been a problem for network administrators in the classification of suchelectronic mail. Emails unwanted characterized as SPAM generate unnecessary network trafficand a burden on the servers. This paper presents a configuration of a sending and receiving e-mail system showing the operation of the protocols involved in the transport of the message asSMTP and ESMTP, the message of recovery as the POP3 and IMAP protocols, construction andmessage format as MIME . Safety aspects in the email as PGP and S / MIME and technologiesto reduce unwanted email at the domain level as SPF, DKIM and DMARC. It held a deploymentof a mail transfer agent with Postfix and Courier software with the configuration for use withSASL authentication, using the POP3 and IMAP protocols, use of TLS security layer as well asDKIM application in emails sent through the open-dkim software and SPF policy enforcementfor verification of incoming mail. The installation within the organization using tools withopen source allows an economy and security of an efficient and didactic way for the networkadministrator.
Keywords: e-mail,SPF,DKIM,DMARC.
LISTA DE FIGURAS
Figura 2.1 – Cabeçalhos relacionados ao transporte de mensagens . . . . . . . . . . . . . . . . . . . . . . 17Figura 2.2 – Outros cabeçalhos definidos de mensagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figura 2.3 – Modelo básico de assinatura do PGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figura 2.4 – Modelo básico encriptação do PGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figura 2.5 – Exemplo de assintatura dkim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figura 2.6 – Fluxo de envio com utilização do DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figura 3.1 – Principais tipos de registros de recursos do DNS para IPV4 . . . . . . . . . . . . . . . . 23Figura 4.1 – Teste Básico de configuração de DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figura 4.2 – Parte do arquivo de Log referente ao envio de um e-mail. . . . . . . . . . . . . . . . . . . . 27Figura 4.3 – Captura de trafégo de rede com Wireshark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 4.4 – Transformação de string para base64. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 4.5 – Captura de tráfego com Wireshark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 4.6 – Captura de tráfego com Wireshark com STARTTLS. . . . . . . . . . . . . . . . . . . . . . . . 30Figura 4.7 – Sessão típica de acesso e recuperação por POP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 4.8 – Assinatura DKIM no cabeçalho de um e-mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figura 4.9 – SPF validando o email recebido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
LISTA DE ABREVIATURAS E SIGLAS
ASCII American Standard Code for Information Interchange
BIND Berkeley Internet Name Domain
BIT BInary digiT ou Dígito Binário
BNF Backus-Naur Form
DMARC Domain-based Message Authentication, Reporting and Conformance
DNS Domain Name System
DKIM DomainKeys Identified Mail
FQDN Full-qualified domain name
IMAP Internet Message Access Protocol
ISC Internet Software Consortium
HTML HyperText Markup Language Linguagem de Marcação de Hipertexto
LDAP Lightweight Directory Access Protocol
MD5 Message-Digest algorithm 5
MIME Multipurpose Internet Mail Extensions
MDA Agente de Entrega de e-mail
MTA Agente de Tranferência de e-mail
MTU Agente de Usuário de e-mail
MX Mail eXchange
PGP Pretty Good Privacy
POP3 Post Office Protocol 3
RBL Real Time Blacklist
RFC Request for Comments
SASL Simple Authentication and Security Layer
SHA1 Secure Hash Algorithm 1
SMTP Simple Mail Transfer Protocol
SPF Sender Policy framework
TCP Protocolo de controle de transmissão
TLS Transport Layer Security
TXT Texto Puro
XML eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 REVISÃO BIBLIOGRAFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1 Protocolo SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Protocolo ESMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Protocolo POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Protocolo IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 Formato Padrão do E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.7 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8 SMIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.10DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.11DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 FERRAMENTAS E MATERIAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 POSTFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Courier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 SPAMASSASSIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1 AMBIENTE DE TESTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.1 Teste configuração DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2 Instalação do PostFix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Proteção TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 Protocolos POP3 e IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5 Configurando o DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6 Configurando o SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11
1 INTRODUÇÃO
A comunicação por e-mail remota dos primórdios da internet e é uma das aplicações
mais importantes e de maior uso em rede de computadores. Inicialmente planejada para troca
de mensagens de textos e de arquivos, a longo do tempo possibilitou o seu uso para envio de
mídia como fotos, hiperlinks, textos formatados em HTML, etc (TANENBAUM, 2003).
Com o a disseminação do uso da internet, o uso e-mail também se difundiu, destacando-
se a modalidade de mala direta, ou seja, envio de um e-mail para muitos destinatários, tem sido
um problema para os administradores de rede na classificação deste tipo de correspondência
eletrônica. E-mails não desejados caracterizados como SPAM geram um tráfego desnecessário
na rede além de uma sobrecarga nos servidores.
Muitas iniciativas tem sido tomadas de modo a regularizar a comunicação por e-mail.
Aspectos como autorização, confiabilidade e segurança vem sendo elaborados de modo a me-
lhorar o funcionamento.
No ano de 2014, o governo brasileiro publicou a Portaria Interministerial número 141
que dispõe sobre comunicações de dados da Administração Pública Federal direta, autárquica
e fundacional onde serviços de fornecedores privados ou entidades fornecedores deve adotar o
e-PING – Padrões de Interoperabilidade do Governo Eletrônico(BRASIL, 2014a).
O e-PING define um conjunto mínimo de premissas, políticas e especificações técni-
cas que regulamentam a utilização da Tecnologia de Informação e Comunicação com vários
itens referentes a troca de mensagem entre usuários por e-mail abordados no presente traba-
lho(BRASIL, 2014b).
O trabalho atual faz um estudo sobre o funcionamento do e-mail de modo a servir de
base para futuros trabalhos na área.
No capítulo 2 será revisado formato básico de um mensagem de e-mail e o MIME as-
sim como a estrutura e protocolos necessários para sua manipulação e transporte como SMTP,
ESMTP, POP3 e IMAP. As principais tecnologias de segurança aplicadas ao e-mail como PGP
e S/MIME e em nível de domínio como SPF,DKIM e DMARC são revisadas nesta seção. No
capítulo 3 será abordado as principais ferramentas ou softwares que utilizam os recursos apre-
sentados na seção anterior como o serviço de nome BIND, o MTA Postfix, o Courier e SASL.
No capítulo 4 tem-se um estudo de caso onde o processo de instalação é realizado a partir das
condições básicas de funcionamento de um sistema de envio de e-mail até a configuração mais
12
avançado mostrando, na medida possível, testes de funcionamento e análises de tráfego de rede
de modo que o administrador possa ter uma visão ampla do funcionamento deste sistema além
de estar incluso no Apêndice A todo o roteiro de configuração segmentado em partes.
13
2 REVISÃO BIBLIOGRAFICA
Neste Capítulo será visto os principais protocolos utilizados para troca de mensagem de
e-mail como o SMTP e o ESMTP, utilizado para transferência entre servidores e, POP e IMAP
utilizados para recuperação pelo agente de usuário de sua caixa postal no servidor. Será visto
o formato padrão de e-mail e o MIME que permite o uso de caracteres especiais. A nível de
segurança será visto o uso do PGP e do S/MIME assim como o uso do SPF, DKIM e DMARC
que são utilizados em nível de domínio.
2.1 Protocolo SMTP
O protocolo Simple Mail Transfer Protocol (SMTP) é um protocolo elaborado para per-
mitir a troca de mensagens entre Agentes de Usuário (MTU) e Agentes de Transferência de
e-mails (MTA) ou entre MTAs. Este agente deve rodar como um programa residente chamado
de daemon e esperar conexões TCP na porta 25 do sistema ou estar em condições de conectar
na porta 25 caso for solicitado a entrega de um e-mail para um host. Este protocolo permite que
o host onde o serviço rode tanto opere como servidor, no caso de receber uma conexão de host
externo quanto cliente no caso do serviço conectar um host externo. Estabelecida a conexão
cliente e servidor se comunicarão através do STMP que estabelece um conjunto de palavras em
caracteres ASCII que servem de comandos por parte cliente e uma resposta do servidor baseado
em um valor numérico e sequência de caracteres de explicação para proceder a transmissão do
e-mail(TANENBAUM, 2003).
As operações básicas por parte do cliente são:
HELO nomedocliente: Serve para identificação do Agente de transferência cliente.
MAIL FROM: sender : Indentifica o usuário no cliente que deseja enviar o e-mail.
RCPT TO: recipient : Indentifica a conta do usuário que deve ser enviado o e-mail
DATA : Inicia o envio do corpo do e-mail, como poderá conter muitos retorno de linhas, o aviso
do fim do envio será avisado através <CRLF>.<CRLF> (retorno de linha, ponto final seguido
de retorno de linha).
QUIT : Finaliza a sessão SMTP.
Há outros comandos que pode ser usados como:
RSET: Aborta a transmissão corrente do e-mail sem contudo fechar a sessão
VRFY recipient : Verifica se existe o destinatário recipient.
14
NOOP: Nenhuma operação será executada, sua utilização é para checar se a sessão ainda em
aberta.
Por outro lado há um grande número de resposta por parte do servidor, (conforme
anexo). As respostas comuns de operação são:
211: Situação do sistema.
220: Pronto para operação.
250: Resposta positiva a pedido feito pelo cliente.
354: Pede a cliente que inicie a transmissão do e-mail
2.2 Protocolo ESMTP
O Extended SMTP ou ESMTP é uma derivação do protocoloco original SMTP no qual
adiciona funcionalidades mantendo a compatibilidade ao STMP existente. Os recursos do
ESMTP são ativados quando o MTA cliente utiliza o comando EHLO, ao contrário do HELO
que indica que o MTA do cliente não tem suporte a este protocolo. Entre as opções mais co-
muns pode-se citar:
SIZE: Permite que o servidor diga para o cliente qual o tamanho máximo permitido para envio.
NOTIFY: O servidor habilita o uso do parâmetro NOTIFY.
CHUNKING: Indica que o servidor aceita o comando BDAT que é usado como alternativa ao
comand DATA diferenciando pelo fato de definir um valor em bytes para transmissão. Quando
o tamanho da mensagem for igual ao valor citado, o servidor assume que a transmissão foi
completada.
PIPELINING: Em uma transmissão normal, tanto cliente quanto servidor tem que esperar a
respostas mútuas para prosseguirem o diálogo o que pode aumentar demasiadamente o tempo
da comunicação. Com este comando ativado será permitido ao cliente fazer vários comandos
sem esperar por resposta para cada comando.
AUTH mecanismo: Permite ao cliente autenticar no servidor. O mecanismo pode ser PLAIN,
LOGIN, CRAM-MD5, DIGEST-MD5 e outros e são estabelecidos pelo servidor.
8BITMIME: Possibilita o cliente enviar o corpo da mensagem ao servidor em 8 bits ao contra-
rio de enviar nativamente em 7 bits do caracteres ASCII.
STARTTLS: Este comando indica que o servidor permite a comunicação por TLS. Se o cliente
15
usar este comando e havendo permissão por parte do servidor será iniciada uma comunicação
por TLS embora os comandos continuem em ESMTP.
2.3 Protocolo POP3
O Post Office Protocol 3 ou protocolo POP3 assim como o IMAP que será visto no pró-
ximo tópico são protocolos de recuperação de e-mail, ou seja, eles são utilizados pelo Agente
de e-mail do usuário de forma a transferir ou copiar o e-mail de sua caixa postal para outro
local. Também depende de daemon de sistema esperando conexões TCP na porta 110 e requer
autenticação para acesso a caixa postal. Estabelecida a conexão o primeiro estado é do auto-
rização (MYERS, 1996) onde o usuário é identificado. Se for aprovado, o estado seguinte é
de transação. Por fim após o comando de saída há o estado adaptação onde são executados os
comandos como apagar mensagens. Os principais comandos são:
USER user: Identificação do usuário.
PASS password: Senha do usuário
STAT: Mostra o número total de mensagens e tamanho total ocupado.
LIST n: Sem o parâmetro “n” lista todas mensagem na caixa postal com o tamanho de cada
mensagem armazenada.
RETR n: Faz com que o conteúdo da mensagem “n” seja transmitido pela conexão.
QUIT: finaliza a sessão POP3
DELE n: Apaga a mensagem “n” após a finalização da sessão POP3.
RSET: Reinicia a sessão POP3 sem executar operações como apagar mensagens.
TOP n x: Assim como o comando RETR permite transmitir o cabeçalho e “x” linhas do corpo
da mensagem “n”.
NOOP: Apenas para manter a conexão aberta.
Além da transmissão em si do dado solicitado, as respostas do servidor seguem o padrão:
+OK mensagen: O comando solicitado foi executado com sucesso.
-ERR mensagem: Ocorreu um erro no comando anterior.
16
2.4 Protocolo IMAP
O (TANENBAUM, 2003) Internet Message Access Protocol ou IMAP assim como o
POP3 é um protocolo de recuperação porém com mais recursos, mas também significativa-
mente mais complexo (KUROSE, 2010). O IMAP segue as mesmas condições do POP3 com a
diferença principal de aguardar conexões na porta 143 e guardar as mensagens no servidor de
modo que o usuário possa acessar suas mensagens de qualquer computador. O IMAP também
permite que possa criar e organizar as mensagens em diferentes pastas assim como marcar as
mensagens como lida, respondida, marcada, apagada, rascunho e recente(CRISPIN, 1994). Os
comandos do cliente de IMAP iniciam com um identificador chamado tag e para cada novo
comando deve ter uma tag diferente. As respostas do servidor podem iniciar com “*” chama-
das untag ou iniciarem com a "tag" quando for solicitado por comando do cliente seguidos dos
parametros.
OK: Indica sucesso
NO: Indica falha
BAD: Indica erro como comando não reconhecido ou erro de sintaxe.
2.5 Formato Padrão do E-Mail
Com semelhança a uma carta de correio onde é necessário o preenchimento de campos
como remetente, destinatário, endereço e outros, o formato foi planejado para a mensagem de
de e-mail contém também campos como estes chamados de cabeçalhos. “De modo semelhante,
quando uma mensagem de e-mail é enviada, um cabeçalho contendo informações periféricas
antecede o corpo da mensagem em si.(KUROSE, 2010).”
"Cada campo de cabeçalho consiste em um única linha de texto ASCII contendo o nome do
campo, um sinal de dois pontos e, normalmente, um valor.(TANENBAUM, 2003)"
Desde modo, são empregado cabeçalhos para auxiliarem no transporte da mensagem como na
figura 2.1.
Há outros cabeçalhos como na Figura 2.2 destinados a outras funções.
Ainda há a permissão de criação de novos cabeçalhos desde que estes comecem com os
caracteres "X-". Estes cabeçalhos serão utilizados pelo programa MTU do usuário ou mesmo
pelos MTA adicionando alguma informação específica.
17
Figura 2.1 – Cabeçalhos relacionados ao transporte de mensagensFonte: (TANENBAUM, 2003)
Figura 2.2 – Outros cabeçalhos definidos de mensagens.Fonte: (TANENBAUM, 2003)
2.6 MIME
Com a limitação do protocolo SMTP em trabalhar com caracteres ASCII foi necessário a
criação do Multipurpose Internet Mail Extensions (MIME) que permite enviar outros caracteres
além dos contidos na tabela ASCII assim como enviar outros tipos de formato como arquivos,
imagens e o outros.
Os cabeçalhos incluídos pelo MIME são:
MIME-Version: Identifica a versão do MIME, sua ausência indica que é uma mensagem de
texto simples.
Content-Description: Ajuda a identificar a mensagem.
Content-Id: Assim com o cabeçalho message-Id, é um número exclusivo para referencias deste
item.
Content-Transfer-Encoding: Define o formato que o conteúdo será transferido pelo mensagem.
Os valores possível são: "BASE64", "QUOTED-PRINTABLE", "8BIT", "7BIT", "BINARY",
"x-token"(BORESTEIN, 1992) onde os mais significativos é o base64. "esse esquema, grupos
de 24 bits são divididos em até quartro unidades de 6bits, com cada unidade sendo enviada
com um caractere ASCII válido"(TANENBAUM, 2003) e quoted-printable que trate-se de um
código ASCII onde todo caractere cujo valor ultrapasse o 127, máximo desda codificação, seja
substituído por um sinal de igual e pelo valor do carácter como dois dígitos hexadecimais.
Content-Type: No formato de um tipo e subtipo separados por uma barra, especifica a conteúdo
18
da transmissão que pode ser por exemplo: Text, Image, Video, Application, entre outros. Um
tipo muito utilizado é o multipart/alternative que especifica que a mensagem contém mais de
uma parte, com início e o fim de cada parte claramente delimitados. Com este cabeçalho vem a
tag boundary que define um sequência de caracteres que será a separação de cada parte.
2.7 PGP
Criado por Phil Zimmerman o Pretty Good Privacy (PGP) é uma ferramenta que permite
privacidade, autenticação, assinatura digital e compactação de forma integrada com o e-mail
apartir do uso de chaves públicas e privadas, criptografia e compactação(TANENBAUM, 2003).
Apartir de um par de chaves público-privadas, para se criar uma assinatura para uma mensagem
em texto plano, é realizado um hash 1 como MD5 ou SHA1 obtendo o digest da mensagem.
Este digest é encriptado com a chave privada do remetente e adicionado ao corpo da mensagem
como pode ser visto na Figura 2.3.
Figura 2.3 – Modelo básico de assinatura do PGP.Fonte: (ZIMMERMANN, 2010)
Na Figura 2.4 pode ser visto o envio de uma mensagem criptografada. Para o remetente
enviar a mensagem, é gerada um chave de sessão aleatória com o qual é criptografado o con-
teúdo da mensagem. Com a chave pública do destinatário é encriptada esta chave e adicionado
a mensagem criptografada inicial.
1 hash ou função de hash é um algortimo de dispersão que obtêm uma um valor quase exclusivo ou o maisindividual possível apartir de um entrada que pode ser uma mensagem
19
Figura 2.4 – Modelo básico encriptação do PGP.Fonte: (ZIMMERMANN, 2010)
2.8 SMIME
Assim como o PGP, o Secure/Multipurpose Internet Mail Extensions (S/MIME) se pro-
põe a mesmas funcionalidades como autenticação, integridade da mensagem, assinatura digital
e privacidade aproveitando a estrutura disponível pelo MIME. O S/MIME foi programado para
ser usado tanto pelos agentes de usuário quanto agentes de transferência quanto por páginas
HTTP que também utilizam o MIME para comunicação.
2.9 SPF
Sender Policy framework (SPF) é uma abordagem diferente para evitar a falsificação
de e-mails através da verificação se o servidor de origem do e-mail é autorizado pelo domínio
que é realizado através de uma consulta DNS deste domínio. Basicamente o SPF permite: ao
administrador de um domínio definir uma política onde são designadas os hosts com autorização
para envio de e-mail, e quais não são autorizados; e ao administrador de um serviço de e-
mail estabelecer critérios de aceitação de mensagens baseados na checagem das políticas do
domínio(ANTISPAM.BR, 2014).
O registro SPF é uma entrada do tipo TXT no servidor de nomes para determinado
domínio onde deve iniciar com o parâmetro v=spf1 seguido de definições da política SPF. Caso
o servidor permite, o registro pode ser do tipo SPF. Um exemplo seria de registro SPF seria:
exemplo.com. IN TXT "v=spf1 a mx ip4:192.168.0.0/24 -all"
Neste exemplo tem-se que para o dominío exemplo.com os registros do tipo "a", "mx"ou
pertencentes a rede 192.168.0.0/24 estão autorizados e enviar e-mail em nome deste domínio.
A cláusula -all"indica que nenhum outro host poderá enviar em nome deste host. O parametro
20
"all"deve ser o último parametro sob pena de nenhum outro parametro posterior será validado.
Os qualificadores possíveis são:
• "+":(Pass) - Válido (valor padrão)
• -":(Fail) - Inválido
• "~":(Softfail) - Inválido Leve
• "?":(Neutral) - Neutro
E há outros opções que poderiam ser incluídas como "include", "ptr", "redirect"e "ipv6".
(WONG, 2006)
Caso o MTA trabalhe com e-mails redirecionados, é necessário que o relay reescreva o
endereço do remetente no envelope e encapsule o endereço original em um processo chamado
Sender Rewriting Scheme (SRS).
2.10 DKIM
DomainKeys Identified Mail (DKIM) assim o SPF permite uma validação de um e-mail
enviado de um domínio com o adicional de acrescentar assinaturas digitais permitindo que o
MTA receptor possa confirmar o e-mail recebido. Assim como o S/MIME e PGP que utiliza-
vam assinaturas no corpo do e-mail e requerer a chave pública do remetente, o DKIM coloca
assinatura como um registro TXT específico no DNS do domínio. Mas enquanto o S/MINE
e PGP não necessitam de intervenção do administrador de rede, o DKIM foi projetado para
prover controle sobre o endereços deste domínio (FENTON, 2007) além de outras vantagens
como: não envolve outras partes como no caso de um certificado CA, a verificação se fará ape-
nas entre os domínios envolvidos. Não é necessário atualizações no clientes do e-mail, o uso
se dará de forma transparente para os usuários finais. E permite que sejam utilizados múltiplas
chaves para o mesmo domínio através do uso de selector.
Na Figura 2.5 tem um exemplo da aplicação do DKIM. Apartir da numeração das linhas
a esquerda, pode ser visto na linha 1 os campos de versão, algoritmo usado, seletor e dominio.
Na linha 2 tem-se o tipo de algoritmo aplicado com a canonização, método de busca da chave
pública e o domínio de assinatura. Na linha 5 encontra-se a assinatura em si em codificada em
base64.
21
Figura 2.5 – Exemplo de assintatura dkimFonte: (ALLMAN, 2007)
2.11 DMARC
Domain-based Message Authentication, Reporting and Conformance (DMARC) assim
como o SPF e DKIM atua a nível da gerência de um domínio de rede mas enquanto que o
SPF define quais os hosts do domínio estão habilitados a enviar e-mail e o DKIM assina as
mensagens enviadas, o DMARC define uma política que deve ser utilizada pelo receptor. O
DMARC não invalida as tecnologias SPF e DKIM e sim utiliza-as (DMARC.ORG, 2014).
Figura 2.6 – Fluxo de envio com utilização do DMARCFonte: www.dmarc.org
O funcionamento é similar aos processos anteriores de busca de informações por con-
sulta ao dominio DNS. Como pode-se ver na figura 2.6, os parâmetros DMARC são aplicados
ao MTA que esta enviando. O MTA que recebe o e-mail fará suas verificações padrões em
"Standard Validation Tests" assim como verificação DKIM em "Retrieve Verfied DKIM Do-
mains", SPF em "Retrieve Envelope From via SPF" e DMARC com auxilio da uma consulta
22
TXT a um domínio DNS para validação, método de recuperação da chave pública e identidade
assinante.
O DMARC estabelece uma política que pode ser: rejeição onde o receptor descartará
toda mensagem que não passar no testes de validação; quarentena onde o receptor colocará os
e-mails não validados recebidos em uma uma situação transição; ou nenhuma onde o receptor
não tomará nenhuma ação com as mensagens não validadas recebidas, a não de reportagem ao
emissor (KUCHERAWY, 2014). Na Figura 2.6 pode ser visto a aplicação da política em "Apply
Appropriate DMARC Policy". Não é necessário dizer que as mensagens validadas não devem
sofrer quaisquer restrição e serão entregues normalmente (KUCHERAWY, 2014).
Mesmo que somente as tags referentes a versão e a política seja exigidas para o fun-
cionamento (SUPPORT.GOOGLE.COM, 2014), há uma série de recursos uteis que deve ser
utilizados pelo administrador de rede. O protocolo estabelece uma cota para análise no qual
será aplicada a política definida que vai de 0%, onde nenhum e-mail será aplicada a política,
a 100% onde a política será aplicada todos os e-mails. Este contexto é extremamente útil
para o processo de implantação ou ciclo de implantação do DMARC em um domínio (SUP-
PORT.GOOGLE.COM, 2014).
O DMARC tem o recurso de enviar relatórios diários (KUCHERAWY, 2014) ao ad-
ministrador do dominio em formato XML, um formato adequado à relatórios, ao endereço de
e-mail do proprietário do domínio descrito no registro DMARC através de um e-mail, indepen-
dente da política e cota adotada. Há ainda a opção de um relatório com informações forenses
através de uma tag específica (WWW.ZYTRAX.COM, 2014). Embora esta tecnologia seja em-
pregada em alguns site como AOL2,Gmail3, Hotmail4,Yahoo5 (DMARC.ORG, 2014) a edição
das normas pela RFC esta em modo rascunho na data de apresentação deste trabalho.
Neste Capítulo foi visto os principais protocolos responsáveis pela transferência de men-
sagens de e-mail entre servidores como o SMTP e o ESMTP, ou entre cliente e e caixa postal
como o POP3 e IMAP assim como a composição do e-mail formado por cabeçalhos específicos
e o corpo do e-mail Foi visto ferramentas de segurança como o PGP e o S/MIME e também
ferramentas de segurança em nível de domínio como o SPF, DKIM e o DMARC.
2 http://www.aol.com/3 https://mail.google.com/4 https://www.hotmail.com/5 https://mail.yahoo.com
23
3 FERRAMENTAS E MATERIAIS
Neste Capitulo será apresentada as principais ferramentas utilizadas para um sistema
de e-mail e quais tecnologias implementam-as. O uso do BIND como serviço de nomes de
domínio, o Postfix como o principal coluna do sistema de mensagens com suas características
principais. O Courier como a implementação do protocolo de recuperação, SASL mecanismo
de autenticação e uma visão geral sobre Spamassassin.
3.1 DNS
O formato de comunicação em redes de computadores que utilizam o protocolo TCP/IP é
um formato numérico denominado endereço de rede que pode ser ipv4 ou ipv6 ou ainda ambos
em um estado de transição, cada host possui um endereço. A dificuldades de memorização
dos valores númericos foi uma das razões para do DNS. O DNS é um serviço hierárquico e
distribuído em redes de computadores destinado a tradução dos endereços de rede para um
formato baseado em caracteres denominado Full-qualified domain name (FQDN) composto do
nome do host, ponto e o nome completo do domínio.
A consulta DNS se dá através de uma requisição do cliente ao servidor, esta requisição
pode ser uma consulta para um endereço FQDN onde será retornado o IP ou uma requisição
contendo um endereço IP onde será retornado o nome do host atrelado a este IP chamado
reverso. Isso evita que alguém utilize um domínio que não lhe pertence para enviar spam,
por exemplo.
Há outros tipos de consultas disponíveis como na Figura 3.1.
Figura 3.1 – Principais tipos de registros de recursos do DNS para IPV4Fonte: (TANENBAUM, 2003)
24
3.1.1 BIND
O Berkeley Internet Name Domain6 (BIND) é mantido pela Internet Software Consor-
tium (ISC) e é a implementação mais utilizada como servidor de nomes. O BIND é livre para
uso e compatível com a maioria dos distribuições linux empregada em servidor como a distri-
buição Debian Wheezy7 utilizada neste trabalho.
Não é necessário no presente trabalho a configuração completa do serviço de nomes
BIND, é necessário o acesso a configuração do mesmo de modo a inserir registro do tipo TXT
além da correta configuração do nome e MX para o servidor de e-mail a ser implementado.
3.2 POSTFIX
A função básica de um MTA é capacidade receber e entregar mensagem de e-mail via
SMTP ou para a caixa postal do usuário no caso do Mail Delivery Agent (MDA), e existem
inúmeros programas que objetivam este fim como Postfix8, Qmail9, Sendmail10 Exim11, Micro-
soft Exchange12 e inúmeros outros que normalmente utilizam algum destes citados como base
e adicionam algumas alterações e/ou integram os mais variados serviços(OLIVEIRA, 2011).
O Postfix foi desenvolvido a partir do Sendmail com objetivos de ser rápido e robusto,
fácil de configurar e seguro enquanto compatível com este. Para isto o Postfix utiliza diversos
programas, cada qual executando uma única tarefa e utilizando múltiplas camadas de segurança
para proteger o sistema. Há um daemon13 que é responsável por gerenciamento dos outros
programas que são executados somente quando há necessidade.
Durante a instalação é possível a escolha de modelos básicos de configuração para o
postfix:
• Internet Site: Acesso completo a internet para envio e recebimento de e-mail.
• Smarthost: Servidor recebe mensagens, mas o envio fica a cargo de outra máquina.
• Satellite system: servidor envia através de outra máquina e não recebe mensagens.
6 http://www.isc.org/downloads/bind/7 https://www.debian.org/8 http://www.postfix.org/9 http://www.qmail.org/
10 http://www.sendmail.com11 http://www.exim.org/12 http://www.emailexchange.com.br/13 processo que roda de forma independente em plano de fundo
25
Para configuração adequada de um servidor de e-mail de produção será necessário a con-
figuração dos arquivos /etc/postfix/main.cf para parâmetros de configuração e /etc/postfix/master.cf
para gerência de processos e serviços.
O arquivo /var/log/mail.log contem um registro das operações executadas pelo postfix,
com registro de conexões, entregas, conexões pop, imap e operações como spf e dkim.
3.3 Courier
O Courier14 é um programa que possibilita a recuperação das mensagens de e-mail da
caixa postal do usuário de forma remota através dos protocolos POP3 ou IMAP seja através de
TLS ou não. Os formatos de caixas postal ou recipientes de e-mail pode ser:
• mailbox: Um único arquivo com todas mensagens concatenadas separadas pela string
"From"seguida pelo remetente e data da mensagem.
• Maildir: Cada mensagem forma um arquivo único. É formado pelo diretório raiz cha-
mado "Maildir" que deve conter no mínimo os subdiretórios: "tmp" para mensagens
recém-chegadas, "new" para novas mensagens e "cur" para mensagens marcadas como
lidas. Há ainda a possibilidade de criação de outros subdiretórios assim como possibili-
dade de marcação das mensagens a partir de sinalizações ou "flags".
Há inúmeros programas que se propõe a este fim como: dovecot15, cyrrus16, popa3d17 e
outros. Foi optado neste trabalho o uso do Courier pela grande disseminação assim como farta
documentação e casos de uso.
3.4 SASL
Define pela RFC 2222, é um pacote que permite o uso de mecanismos adicionais de
autenticação a protocolos orientados à conexão . Ele permite a negociação do mecanismo de
autenticação entre um cliente e um servidor antes iniciar a sessão(MYERS, 1997). Alguns
exemplos de mecanismos são digest-md5, cram-md5 e outras. Com a configuração do SASL
fica facilitada a configuração caso o administrador do sistema opte por um autenticação unifi-
14 http://www.courier-mta.org/15 http://dovecot.org/16 http://www.cyrusimap.org/17 http://www.openwall.com/popa3d/
26
cada como por exemplo a configuração do SASL fica facilitada a configuração caso o adminis-
trador do sistema opte por um autenticação unificada como por exemplo o LDAP.
3.5 SPAMASSASSIN
Há inumeros programas de combate a mensagens solicitadas e um dos mais documenta-
dos é spamassassin18. O spamassassin utiliza as mais diversas técnicas para controle de e-mail
recebidos como procura por strings, analise de bayes19, lista de bloqueio chamadas RBL (Real
Time Blacklist) , listas brancas (White Lists), SPF e DKIM , razor que é um catálogo de spam
baseado em assinaturas de e-mail. Todos estes itens para montar uma pontuação ou "score".
Quanto maior esta pontuação menor a chance da mensagem ser um spam.O Dspam20, uma
ferramente similar ao spamassassin permite uma base personalizada por usuário.
Uma abordagem de uma ferramenta como dspam ou spamassassin deve ser feita com
muito cuidado pelo administrador de rede. Todos os fatores que determinam o "Spam" devem
ser estudados e configurados corretamente sob pena do sistema realizar um efeito contrário
ao que se propõe como excluir mensagem legítimas e deixar passar mensagens que o usuário
considerará como "Spam".
Neste Capítulo foi visto uma visão geral de alguns programas que iram exercer funções
principais em um sistema de e-mail. Embora o BIND não seja de fato configurado em função
deste sistema, ele é fundamental para o funcionamento deste serviço. O Postfix é a programa
responsável pela estrutura principal e nele deve ser configurado praticamente todos os parâme-
tros necessários. O Courier tem a função da implementação dos protocolos de recuperação dos
e-mails e há uma visão geral sobre o funcionamento do Spamassassin.
18 http://spamassassin.apache.org/19 Processo de usar métodos estatísticos para classificar documentos por categorias20 http://dspam.nuclearelephant.com/
27
4 ESTUDO DE CASO
Neste capitulo é mostrado um estudo de caso de uma instalação e configuração de um
sistema de e-mail desde da etapa inicial seguindo um roteiro de adição de recursos e verificando
os estudos realizados.
4.1 AMBIENTE DE TESTES
Para realização dos testes, utilizamos a última versão estável do Debian Wheezy que
tem como MTA padrão o programa Exim. Deve ser retirado e instalado o PostFix como MTA.
4.1.1 Teste configuração DNS
O primeiro passo é a correta configuração do serviço de nomes onde deve-se previa-
mente haver um registro no DNS para suporte deste HOST.
Figura 4.1 – Teste Básico de configuração de DNSFonte: Do Autor
4.1.2 Instalação do PostFix
Após a 1a etapa pode se fazer um teste simples para ver o funcionamento do servidor
enviando um texto de um host a outro através do comando:
echo "Um e-mail de teste de B"|mail -s "Assunto Teste"[email protected]
Obtemos o seguinte conteúdo no arquivo /var/log/mail.log
Figura 4.2 – Parte do arquivo de Log referente ao envio de um e-mail.Fonte: Do Autor
O log na Figura 4.2 mostra resumidamente que o e-mail foi enviado com sucesso, mesmo
sendo para o próprio usuário e host.
28
O mesmo teste pode ser realizado para outro host em que o estado de configuração esteja
similar de modo que pode-se fazer o mesmo processo visando um usuário noutro servidor com
um comando similar ao utilizado alterando-se destinatário e servidor.
Pode-se capturar o tráfego da rede como visto na Figura 4.3. As informações contidas no e-mail
são envidas de modo de texto plano e é mostrado a captura do tráfego de rede de um envio de
uma mensagem através do software Wireshark21, como a mensagem é em texto plano pode-se
visualizar todo conteúdo da mensagem.
Figura 4.3 – Captura de trafégo de rede com Wireshark.
21 https://www.wireshark.org/
29
4.2 SASL
Para permitir que o servidor possa ser acessado externamente deve-se ativar um meca-
nismo para limitar o acesso somente a usuários autorizados. Neste caso pode-se usar o Simple
Authentication and Security Layer (SASL) Neste caso a senha será codificada na base64 para
ser realizado o login
Para teste será usado os comandos para codificar o usuário e senha como esta apresen-
tado na Figura 4.4.
Figura 4.4 – Transformação de string para base64.Fonte: Do Autor
Apesar do usuário e senha não serem transmitidos em texto plano pelo protocolo SMTP,
utilizando uma captura de rede com wireshark como abaixo. Como resultado de uma captura
pelo tem-se:
Figura 4.5 – Captura de tráfego com Wireshark.Fonte: Do Autor
30
Uma decodificação básica apartir dos campos capturados na análise tem-se os valores:
echo "YWx1bm8x"|base64 –decode && echo -n ":"&& echo "MTIzbXVkYXI="|base64
–decode
Onde o resultado pelo comando é a sequência "aluno1:123mudar"contedo o usuário e
senha.
4.3 Proteção TLS
Para proteção deve ser instalado criptografia TLS no protocolo SMTP utilizando-se a
parte 3 do Anexo A. Vai ser perguntado informações como chave secreta e outras informações.
Apos a configuração foi realizado um teste com o comando
openssl s_client -starttls smtp -crlf -connect dominioa.intranet.local:25
Foi realizada a mesma transmissão que o modo anterior e feita uma analise com wi-
reshark.
Figura 4.6 – Captura de tráfego com Wireshark com STARTTLS.Fonte: Do Autor
Na captura de tráfego da Figura 4.6 tanto usuário, senha e conteúdo do e-mail não são
mais acessíveis para escuta em rede.
31
4.4 Protocolos POP3 e IMAP
Para utilização dos protocolos de autenticação POP3 e IMAP é seguido a configuaração
da parte 5 do Anexo A que é a instalação do software Courier.
Figura 4.7 – Sessão típica de acesso e recuperação por POP.Fonte: Do Autor
Na Figura 4.7 pode ser visto uma sessão de acesso POP típica. Da linha 1 a linha 5
tem-se o estado de autorização do usuário com os comandos de usuário e senha transmitidos
em texto plano. Mesmo que esta comunicação esteja protegida pela camada inferior de TLS, o
próprio POP tem recursos de encriptação através do comando APOP (MYERS, 1996). Da linha
6 a linha 103 tem-se o estado de transação onde foi pedido para listar as mensagens na linha 6
e recuperar a mensagem 1 na linha 36. Na 104 tem o comando QUIT que finaliza a interação
com o cliente e inicia a fase de atualização.
4.5 Configurando o DKIM
A configuração do DKIM é fácil e simples, o arquivo /etc/opendkim.conf deve conter
algumas configurações de funcionamento. É necessária uma configuração para criação do par de
chaves sendo que uma deve ser utilizada pelo Postfix e outra será disponibilizada pelo servidor
DNS devendo o administrador de rede providenciar a inserção do registro para o servidor de
nomes. De acordo com a Figura 4.8 é visualizada a assinatura em funcionamento nas linhas 17
a 23.
32
Figura 4.8 – Assinatura DKIM no cabeçalho de um e-mail.Fonte: Do Autor
4.6 Configurando o SPF
Diferetemente do que foi realizado na configuração do DKIM onde foi necessário colo-
car a assinatura gerada no e-mail que saia pelo MTA. A configuração do SPF além da realizada
no servidor de domínio para envio de e-mails, deve haver uma integração entre o MTA e uma
ferramenta para análise do e-mails que chegam se o domínio que envio esta de acordo com as
normas SPF.
Na Figura 4.9 tem-se na linhas 4 e 5 a validação do e-mail enviado do dominioa.intranet.local
para dominiob.intranet.local sendo aprovado com o valor "PASS".
Figura 4.9 – SPF validando o email recebido.Fonte: Do Autor
Neste Capítulo foi visto o funcionamento do sistema de e-mail desde a instalação a partir
de um sistema sem nenhuma configuração inicial passando pela instalação e configuração do
Postfix em modo SMTP após com TLS, Courier com acesso POP3 e IMAP ambos utilizando a
proteção da camada TLS, a configuração do DKIM e do SPF no Postfix e o registro necessário
para ser inserido no servidor DNS.
33
5 CONCLUSÃO
O uso de um sistema de e-mail é indispensável para qualquer organização, seja ela
comercial, educacional, público ou privada, pequena ou grande e o não funcionamento deste
sistema ira acarretar em sérios prejuízos não só financeiros como também na imagem desta
organização.
Neste trabalho foi realizado uma proposta de um sistema completo e didático de admi-
nistração de e-mail utilizando-se ferramentas de código aberto que pode ser hospedado dentro
da própria organização, se houver equipamento disponível, acarretando uma economia na dis-
pensa de contratação de serviços externos como também na segurança que os dados dos usuários
não estão em poder de um entidade externa.
Para realização deste trabalho foi necessário um estudo sobre os protocolos que regem o
manuseio de cada mensagem de e-mail desde do envio, transporte entre servidores, entrega na
caixa postal ou recipiente do usuário e recuperação por este usuário onde todas estas atividades
são registradas em arquivos de registro ou logs permitindo auditorias caso forem necessárias,
algo que normalmente não é disponibilizado por entidades que disponibilizam o uso de e-mail
para organizações.
Há também uma abordagem dos principais softwares utilizados assim como um passo a
passo que permite um administrador de rede criar e configurar seu sistema de e-mail utilizando
as ferramentas apresentadas desde o sistema básico até um sistema em condições de aplicação
mais práticas.
Devido a natureza do tráfego de e-mail na atualidade caracterizado pela grande número
de mensagens não solicitadas denominadas como "spam" foi apresentado algumas técnicas vi-
sando a eliminação deste tráfego como o SPF, DKIM e DMARC que são aplicadas a nível do
serviço do domínio de origem onde o administrador deve procurar zelar pela boa conduta dos
usuário deste serviço criando uma nível de confiança entre os domínios que aplicam estas téc-
nicas. A ferramenta DMARC ainda não esta como RFC assim como não há pacotes para as
distribuições tradicionais como por exemplo o Debian que é utilizado neste exemplo.
34
REFERÊNCIAS
ALLMAN, E. [RFC - 4870] DomainKeys Identified Mail (DKIM) Signatures. Network
Working Group, Disponível em <http://www.ietf.org/rfc/rfc4870.txt>. Acessado em Novem-
bro/2014.
ANTISPAM.BR. SPF- Sender Policy Framework. Acessado em Novembro/2014,
http://www.antispam.br/admin/spf/.
BORESTEIN, N. [RFC - 1341] MIME (Multipurpose Internet Mail Extensions). Network
Working Group, Disponível em <https://tools.ietf.org/html/rfc1341>. Acessado em Novem-
bro/2014.
BRASIL. PORTARIA INTERMINISTERIAL Número 141. Diário Oficinal da República Fe-
derativa do Brasil, Brasilia, DF, Brasil, p.82–83, 2014.
BRASIL. e-PING Padrões de Interoperabilidadede Governo Eletrônico Documento de Re-
ferência. Acessado em Novembro/2014, http://eping.governoeletronico.gov.br/.
CRISPIN, M. [RFC - 1730] Internet Message Access Protocol - Version 4. Network Working
Group, Disponível em <https://tools.ietf.org/html/rfc1730>. Acessado em Novembro/2014.
DMARC.ORG. DMARC.org. Acessado em Novembro/2014, http://www.dmarc.org/.
FENTON, J. Leiba e. DomainKeys Identified Mail (DKIM): using digital signatures for domain
verification. Fourth Conference on Email and Anti-Spam, California, CA, USA, 2007.
KUCHERAWY, M. Domain-based Message Authentication, Reporting and Conformance
(DMARC). draft-kucherawy-dmarc-base-05, Disponível em <https://tools.ietf.org/html/draft-
kucherawy-dmarc-base-05>. Acessado em Novembro/2014.
KUROSE, J. F. Redes de Computadores e a Internet. 5th.ed. São Paulo, SP, Brasil: Addison
Wesley, Inc., 2010.
MYERS, J. [RFC - 1939] Post Office Protocol - Version 3. Network Working Group, Dispo-
nível em <https://www.ietf.org/rfc/rfc1939.txt>. Acessado em Novembro/2014.
35
MYERS, J. [RFC - 2222] Simple Authentication and Security Layer (SASL). Network
Working Group, Disponível em <https://www.ietf.org/rfc/rfc2222.txt>. Acessado em Novem-
bro/2014.
OLIVEIRA, W. d. M. Postfix - Servidor de E-mail- Guia Prático. 1th.ed. Rio de Janeiro, RJ,
Brasil: Editora Ciência Moderna Ltda., 2011.
SUPPORT.GOOGLE.COM. Criar um registro DMARC. Acessado em Novembro/2014,
https://support.google.com/a/answer/2466563?hl=pt-BR.
TANENBAUM, A. S. Redes de Computadores. 4th.ed. xBoston, MA, USA: xAddison-Wesley
Longman Publishing Co., Inc., 2003.
WONG, M. [RFC - 4408] Sender Policy Framework (SPF) for Authorizing Use
of Domains in E-Mail - Version 1. Network Working Group, Disponível em
<http://www.ietf.org/rfc/rfc4408.txt>. Acessado em Novembro/2014.
WWW.ZYTRAX.COM. HOWTO - Define a DMARC Record. Acessado em Novem-
bro/2014, http://www.zytrax.com/books/dns/ch9/dmarc.html.
ZIMMERMANN. How PGP works. Acessado em Novembro/2014,
http://www.pgpi.org/doc/pgpintro/.
37
APÊNDICE A – Instalação do PostFix
A.1 Parte 1
Na versão 7 do sistema operacional Debian, deve-se retirar o exim e instalar o postfix
sendo necessário esta logado como usuário administrativo "root".
apt-get update
apt-get upgrade
apt-get remove exim4
apt-get install postfix
No quadro de opções que será apresentado deve ser selecionada a opção "internet site".
O arquivo de configuração inicial do postfix main.cf ficará da seguinte forma:
mydomain = intranet.local
myhostname = dominiob.$mydomain
myorigin = $mydomain
mydestination = $myhostname, $mydomain
mynetworks = 127.0.0.0/8 192.168.0.0/24
home_mailbox = Maildir
A.2 Parte 2
Instalacação do Simple Authentication and Security Layer
apt-get install sasl2-bin
Adição ao arquivo /etc/postfix/main.cf
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
smtpd_helo_required = yes
38
smtpd_recipient_restrictions =
permit_myneworks,
permit_sasl_authenticated,
reject_unauth_destination
Ativação do SASL no arquivo /etc/default/saslauthd.
START=yes
OPTIONS=-c -m /var/spool/postfix/var/run/saslauthd -r"
E a criação do arquivo /etc/postfix/sasl/smtpd.conf com conteúdo:
pwcheck_method: saslauthd
mech_list: plain login
A.3 Parte 3
Para criação dos certificados auto-assinados deve ser executados os comandos abaixo:
openssl genrsa -des3 -rand /etc/hosts -out smtpd.key 1024
chmod 0600 smtpd.key
openssl req -new -key smtpd.key -out smtpd.csr
openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out
smtpd.crt
openssl rsa -in smtpd.key -out smtpd.key.unencrypted
mv smtpd.key.unencrypted smtpd.key
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem
-days 3650
Adiciona ao arquivo /etc/postfix/main.cf
smtpd_tls_auth_only = yes
smtp_use_tls = yes
39
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
A.4 Parte 4
Instalação do Courier apt-get install courier-pop-ssl courier-imap-ssl
Mudança no arquivo /etc/courier/pop3d-ssl:
POP3_TLS_REQUIRED=1
Mudança no arquivo /etc/courier/imapd-ssl:
IMAP_TLS_REQUIRED=1
A.5 Parte 5
Instalação do OpenDKIM
apt-get install opendkim opendkim-tools
Editar o arquivo /etc/opendkim.conf da forma abaixo:
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
Syslog yes
SyslogSuccess Yes
LogWhy Yes
Canonicalization relaxed/simple
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
40
Mode sv
PidFile /var/run/opendkim/opendkim.pid
SignatureAlgorithm rsa-sha256
UserID opendkim:opendkim
Socket inet:12301@localhost
Adicionar ao arquivo /etc/posftix/main.cf
milter_protocol = 2
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301
Além da configuração dos arquivos: /etc/opendkim/TrustedHosts
127.0.0.1
localhost
192.168.0.1/24
*.intranet.local
A geração do par de chaves públicas e privadas:
opendkim-genkey -s mail -d intranet.local
E com a chave gerada o registro a ser colocado no dominio DNS
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=<chave gerada>"
A.6 Parte 6
Na instalação do SPF, há duas opções: uma baseada em python e outra baseada em perl.
41
Nesta instalação foi optado por usar a baseada em python utilizando-se o comando:
apt-get install postfix-policyd-spf-python
Após deve ser adicionado ao arquivo etc/postfix/master.cf:
policy-spf unix - n n - - spawn
user=nobody argv=/usr/bin/policyd-spf
E no arquivo /etc/postfix/main.cf adiconar a cláusula:
smtpd_recipient_restrictions =
a restrição:
check_policy_service unix:private/policy-spf
E adicionar ao final do arquivo a linha:
policy-spf_time_limit = 3600s