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: luciano@cpd.ufsm.br

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 ANEXOS

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"aluno2@dominiob.intranet.local

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/.

36

APÊNDICES

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