Sumário

• 1. Introdução
• 2. Relays abertos
• 3. SMTP autenticado
• 4. Porta de submissão (587/TCP)
• 5. Servidores secundários
• 6. Endereços especiais

1. Introdução

Esta seção tratará das formas de evitar que o spam seja enviado a partir de seu serviço de correio eletrônico e o que fazer quando isto acontecer.

A configuração usual do serviço de correio eletrônico em redes corporativas e mesmo em provedores de serviços é um servidor concentrador que pode atender toda a corporação, um departamento ou um pequeno grupo, e um número de estações clientes. Não importa aqui o número de usuários do serviço e sim a arquitetura e as medidas tomadas. Temos dois objetivos:

• fazer com que as mensagens enviadas passem pelo servidor; e
• evitar que mensagens saiam clandestinamente, sem passar por ele.

Além do lado preventivo, tratamos da correção de situações que normalmente são percebidas por terceiros, ao receberem mensagens originadas em nossa rede. Para implementar políticas corretivas temos que estar com os "ouvidos" abertos, o que significa ter endereços de correio prontos para receber reclamações e reagir a essas reclamações.

2. Relays abertos

Relays abertos são MTAs que transmitem mensagens de qualquer domínio, ou mesmo só de domínios determinados, para qualquer outro, sem pedir autenticação, sem restringir (ou restringindo muito pouco) a faixa de endereços IP de origem.

Os relays abertos são utilizados por spammers pelo fato de proverem anonimato. Para o responsável pelo MTA com relay aberto sendo abusado, as conseqüências são o consumo de recursos e a possível inclusão do MTA em listas de bloqueio. Além disso, ele pode passar a receber mensagens de erro e reclamações sobre os spams enviados via seu MTA.

Os softwares atuais para servidores MTA costumam vir em sua maioria configurados por padrão para não aceitar a transmissão indiscriminada de mensagens. Normalmente estes softwares permitem a manutenção de uma lista de domímios pelos quais um determinado MTA responde e uma lista de endereços autorizados a usar seu relay.

É importante, ao configurar um MTA, restringir ao máximo os endereços IP que tem permissão para usá-lo como relay, se possível limitando ao localhost. Na seção sobre servidores Web são discutidas implicações na liberação do localhost para uso do relay.

Há também casos em que dois MTAs, aparentemente bem configurados, agem como se fossem um relay aberto. A mensagem chega no primeiro MTA, é retransmitida para o segundo, que por sua vez a retransmite para qualquer outro servidor. Essa situação ocorre quando o primeiro MTA tem o segundo como seu "mail hub" e o segundo tem o primeiro na lista de IPs autorizados a usá-lo como relay. É uma situação bem difícil de diagnosticar e fácil de ser explorada. Mais detalhes na seção sobre servidores secundários.

Antes de tornar um serviço de correio eletrônico público é fundamental verificar se ele está se comportando como relay aberto. Uma maneira fácil de fazer isso é através de um telnet pela porta adequada, digitando os comandos SMTP diretamente. A ferramenta openssl, com o comando s_client, pode ser usada no caso de sessões cifradas.

Exemplo:

myhost:~$ telnet mailserver.example.com 25
Trying 192.0.2.82...
Connected to mailserver.example.com.
Escape character is '^]'.
220 babbo.example.com ESMTP Sendmail 8.13.4/8.13.4; Tue, 20 Sep 2005 16:31:04 -0300
helo myhost.example.net
250 babbo.example.org Hello IDENT:1008@myhost.example.net [192.0.2.44], pleased to meet you
mail from: <john.doe@example.net>
250 2.1.0 <john.doe@example.net>... Sender ok
rcpt to: <fulano@example.edu>
550 5.7.1 <fulano@example.edu>... Relaying denied. Proper authentication required.
quit
221 2.0.0 babbo.example.com closing connection
Connection closed by foreign host.

3. SMTP autenticado

Normalmente o protocolo SMTP trabalha sem utilizar autenticação e não diferencia se a conexão está sendo feita por um cliente ou por outro MTA. A falta de autenticação por parte de um cliente ao utilizar o MTA para o envio de mensagens pode facilitar o envio de spam ou o abuso por parte de spammers.

Para evitar esse tipo de abuso uma das medidas é exigir que qualquer cliente, independentemente do endereço IP de origem, apresente credenciais de acordo com a RFC 4954, a não ser que o destino da mensagem seja local.

Praticamente todos os MTAs possuem recursos de autenticação, sejam nativos ou por meio de patches. Há diferenças entre os mecanismos suportados pelos vários MTAs e MUAs, mas no mínimo devem ser suportados PLAIN, LOGIN e CRAM-MD5. Os dois primeiros são considerados inseguros, pois as credenciais passam pela rede em texto claro, o que pode ser resolvido usando SMTP em canal seguro, pela porta 465/TCP.

4. Porta de submissão (587/TCP)

Uma configuração que é bastante efetiva contra abusos consiste em reservar a porta 25/TCP somente para troca de mensagens entre MTAs e usar a porta 587/TCP para mensagens enviadas por um cliente para o seu MTA. Costuma-se usar o termo MSA (Mail Submission Agent) para o MTA configurado para responder pela porta 587/TCP.

Para a utilização da porta de submissão, onde a autenticação é obrigatória, é necessário que todos os MUAs dos clientes reconfigurados para a utilização da nova porta e fornecimento de credenciais.

Mais informações sobre a adoção do padrão de Message Submission e a diferenciação entre os serviços de submissão e de troca de mensagens podem ser encontradas na seção Gerência de Porta 25.

5. Servidores secundários

É bastante comum uma rede possuir dois (ou mais) servidores de correio eletrônico destinados à recepção de mensagens: um principal, responsável por entregar as mensagens para as caixas postais dos destinatários e outros secundários que não fazem entrega de mensagens diretamente aos destinatários. Caso o servidor principal fique impossibilitado de receber mensagens, os secundários as recebem e as enfileiram, para retransmití-las ao principal quando este estiver restabelecido.

Para evitar que servidores secundários sejam abusados por spammers, alguns cuidados devem ser tomados ao configurá-los:

• todas as medidas anti-spam adotadas no servidor principal, como SPF, greylisting, etc, devem, na medida do possível, ser implementadas no servidor secundário também, de modo que o spam seja barrado igualmente em qualquer um deles;
  
  
• o servidor secundário deve saber para quais domínios ele pode fazer relay. Este servidor não deve ser configurado como 'null relay client', para evitar que sua combinação com o servidor principal forme um relay aberto de segundo nível;
  
  
• o servidor principal deve assumir que o servidor secundário é confiável, e não fazer testes de SPF nem colocar em greylisting mensagens que venham dele. Pois, se ele foi corretamente configurado, essas verificações já foram feitas. Caso seja utilizado SPF pode-se implementar SRS no servidor secundário.

6. Endereços especiais

A RFC 2142 (Mailbox Names for Common Services, Roles and Functions) prevê um conjunto de endereços especiais, que devem ser configurados como aliases para os e-mails do pessoal responsável pelas áreas específicas.

Estes endereços devem estar corretamente configurados, de acordo com o descrito na seção sobre e-mails especiais e dados de WHOIS.