Ulisses Thadeu Vieira Guedes
2012
Conteúdo 1. ATRIBUTO MX ... 3 1.1. IPv4 ... 3 1.1.1. Exemplo-1: ... 3 1.1.2. Exemplo-2: ... 4 1.1.3. Exemplo-3: ... 4 1.1.3.1. Caso 1: ... 4 1.1.3.2. Caso 2: ... 4 1.2. IPv6 ... 5 2. ATRIBUTO SPF ... 6 2.1. PARÂMETROS DO SPF ... 7 2.2. QUALIFICADORES DO SPF ... 7 2.3. MODIFICADORES ... 8 2.4. Exemplo: ... 8 2.5. APLICAÇÃO DO SPF ... 9
3. INTEGRAÇÃO COM DKIM ... 9
1. ATRIBUTO MX
O atributo MX designa o nó que executa o serviço SMTP associado a um FQDN (Full Qualified Domain Name/Nome de Domínio Completamente Qualificado) ou a um FQHN ( Full Qualified Host Name/Nome de um Nó Completamente Qualificado).
Repare que é de um serviço SMTP e não, exatamente, da localização da caixa Postal (caixa de E-mail) de um usuário.
A sintaxe do atributo MX é:
FQDN | FQHN IN MX pref FQHN-MX
onde:
FQDN
É o nome de uma ZONA.
FQHN
É o nome de um NÓ.
MX
É o atributo da designação Mail EXchanger.
pref
É um valor numérico que define a prioridade da designação. Quanto menor for este valor maior é a preferência na utilização do FQHN-MX designado.
FQHN-MX
É o FQHN do sistema MX, que tem um IP associado através do atributo A ou
AAAA.
1.1. IPv4
1.1.1. Exemplo-1:
Considere a ZONA empresa.com.br. Nesta ZONA tem-se o sistema com nome mensagem.empresa.com.br executando o serviço de correio via protocolos SMTP e/ou
SMTPS configurado para receber mensagens no formato usuario@empresa.com.br.
Neste caso, designa-se
empresa.com.br. IN MX 10 mensagem.empresa.com.br. mensagem.empresa.com.br. IN A IPv4
1.1.2. Exemplo-2:
Considere a ZONA empresa.com.br que troca uma grande quantidade de mensagens com
seus clientes ao ponto de exigir mais de um sistema com serviço de correio eletrônico (SMTP) em alguns períodos do mês ou da semana. Agora, dois nós foram configurados com serviço de correio: mensagem.empresa.com.br e msgbck.empresa.com.br . Estes 2 nós
receberão mensagens no formato usuario@empresa.com.br. Por algum motivo (sistema msgbck.empresa.com.br é mais lento, por exemplo) os sistemas externos devem tentar o
envio através do nó mensagem.empresa.com.br e caso ele esteja muito ocupado então os
sistemas externos devem tentar a conexão com msgbck.empresa.com.br.
No caso, as designações seriam:
empresa.com.br. IN MX 10 mensagem.empresa.com.br. empresa.com.br. IN MX 20 msgbck.empresa.com.br. mensagem.empresa.com.br. IN A IPv4-de-mensagem msgbck.empresa.com.br. IN A IPv4-de-msgbck
Ao receber a resposta de uma requisição sobre o atributo MX, o sistema que pretende enviar a mensagem ordenará os registros em ordem crescente de preferencia e utilizará a primeira opção ordenada. Caso ocorra uma falha na comunicação então aquele sistema tentará a segunda preferencia.
1.1.3. Exemplo-3:
Considere a ZONA empresa.com.br que troca uma grande quantidade de mensagens com
seus clientes ao ponto de exigir mais de um sistema com serviço de correio eletrônico (SMTP) constantemente. Esse é o perfile de ocupação de grandes provedores de correio eletrônico tais como o Gmail, Hotmail, Yahoo, etc.
O objetivo do administrador é distribuir as conexões pelos vários NÓS com SMTP.
Há duas formas de se alcançar esse objetivo, que podem ser acumulativas. Uma delas é designar um FQHN-MX com vários endereços IPs (Caso 1). A segunda forma é criar vários registros MX com vários FQHN-MXs, tendo cada registro MX o mesmo valor de preferencia (Caso 2). 1.1.3.1. Caso 1: empresa.com.br. IN MX 10 mensagem.empresa.com.br. mensagem.empresa.com.br. IN A 10.1.0.2 mensagem.empresa.com.br. IN A 10.1.0.3 mensagem.empresa.com.br. IN A 10.1.0.4 mensagem.empresa.com.br. IN A 10.1.0.5 ...
empresa.com.br. IN MX 10 mensagem2.empresa.com.br. empresa.com.br. IN MX 10 mensagem3.empresa.com.br. empresa.com.br. IN MX 10 mensagem4.empresa.com.br. mensagem1.empresa.com.br. IN A 10.1.0.2 mensagem2.empresa.com.br. IN A 10.1.0.3 mensagem3.empresa.com.br. IN A 10.1.0.4 mensagem4.empresa.com.br. IN A 10.1.0.5 ...
Nos dois casos qualquer mensagem destinada a usuario@empresa.com.br chegará a qualquer um daqueles IPs.
Porém, no caso 2, se a mensagem for enviada para usurio@mensagem2.empresa.com.br então somente aquele sistema será eleito como receptor daquela mensagem.
1.2. IPv6
Não há qualquer diferença quanto ao atributo MX para o IPv6 em relação ao IPv4.
Contudo, enquanto há transição entre IPv4 e IPv6 é recomendável que o atributo MX seja específico para questionamentos conforme o protocolo de rede. Ou seja, se uma requisição vier de uma rede IPv6 então o DNS deve responder com um MX apontando para um FQHN-MX com atributo AAAA, mesmo que o FQHN-MX execute os dois protocolos (IPv4 e IPv6).
Conforme a RFC5322 ainda não há uma padronização ou recomendação de prática, mas um estudo de caso pode ser considerado quanto a tomada de tal decisão.
Considere um sistema FQHN-MX com pilhas IPv4 e IPv6, numa rede lógica interna onde os dois protocolos coexistem, mas sem enlace IPv6 para a Internet. Neste caso o requisitante questionará através do IPv4 pois não há como ele estabelecer uma conexão com a pilha IPv6 externamente e a requisição virá sob o IPv4, resultando numa resposta de MX de um FQHN-MX com A IPv4.
Por outro lado ele poderá utilizar um conversor intermediário IPv4/IPv6, mas neste caso o conversor agirá como um proxy, tomando para si a identidade da conexão, o que representa uma requisição sob IPv6, resultando uma resposta de MX de um FQHN-MX apontando para AAAA IPv6.
Se aquele mesmo sistema encapsular IPv6 sobre o IPv4, a requisição será IPv6, pois será a última pilha de rede a ser extraída.
Se os protocolos são diferentes então não há conectividade estabelecida.
Logo, apesar de ainda não existir uma padronização tem-se comportamentos definidos.
2. ATRIBUTO SPF
O atributo SPF (Sender Policy Framework) foi introduzido para auxiliar as aplicações MTA identificarem se um MTA externo tem autorização para o envio de mensagens com remetente pertencente a uma ZONA. Ou seja, um NÓ duvidoso.empresa.sem.br pode enviar mensagem com remetente usuario@empresa.com.br? A zona
utilizando um remetente FQDN. 2.1. PARÂMETROS DO SPF
O SPF é um conjunto de parâmetros (ou mecanismos) assim definidos: A
Se o A ou AAAA do FQHN-MX é o mesmo que enviou a mensagem. IP4
Informa a faixa de endereços IPv4 que estão autorizados a utilizar a ZONA do MAIL-FROM.
IP6
Informa a faixa de endereços IPv6 que estão autorizados a utilizar a ZONA do MAIL-FROM.
MX
Se a ZONA tem um registro/atributo MX coerente com o MAIL-FROM: PTR
Se o atributo PTR do FQHN tem tem o mesmo IP da conexãodesignado a aquele nome.
ALL
Comparar sempre.
2.2. QUALIFICADORES DO SPF
Qualificadores são sinais que precedem os parâmetros. Qualquer parâmetro aceita os qualificadores:
'~'
significa uma condição de debug, a comparação é aceita e um aviso em log é emitido.
'-'
Não houve coincidência. Nega a condição. Quando -ALL então sinaliza a evidência de falsificação.
'?'
Resultado NEUTRO. Indica que não uma política definida para o caso. '+'
Sinaliza que o resultado da regra implica em aprovação. JAMAIS insira este qualificador em ALL.
2.3. MODIFICADORES
As RFCs 4408 e 6652 preveem, ainda, 5 modificadores. exp, redirect, ra, rp e rr. Tais modificadores são adicionados aos parâmetros.
2.4. Exemplo: Considere o cenário:
Os MTAs (Mail Trasfer Agent), em execução nos nós IPs 192.168.1.15 e 192.168.1.100, com nomes mta1.empresa.com.br e mta2.empresa.com.br, podem enviar mensagens com MAIL-FROM: <usuario@empresa.com.br>.
Um nó, nome malicioso.qualquerzona.br, com endereço IP 192.168.100.20, não pertencente à zona empresa.com.br, envia uma mensagem para o destinatário, que será recebido pelo MTA-DESTINATÁRIO.
O DNS da zona empresa.com.br retorna:
• quando questionada pelo atributo SPF (ou TXT):
empresa.com.br. SPF “v=spf1 ip4:192.168.1.15 ip4:192.168.1.100 a:mta1.empresa.com.br a:mta2.empresa.com.br -all”
• quando questionada pelo atributo IN A de mta1 ou mta2.empresa.com.br:
mta1.empresa.com.br. IN A 192.168.1.15 mta2.empresa.com.br. IN A 192.168.1.100
100.1.168.192.in-addr.arpa. IN PTR mta2.empresa.com.br.
Tão logo o envelope fornecer o MAIL-FROM (usuario@empresa.com.br), o MTA questionará o atributo SPF para o DNS da zona empresa.com.br, que retornará o registro acima.
Em seguida o MTA-DESTINATÁRIO questionará os outros atributos. Mesmo que malicioso.qualquerzona.br se anuncie como pertencente à zona empresa.com.br não haverá condição satisfeita, o MTA-DESTINATÁRIO segue a decisão -all do SPF, ou seja,
rejeitará a mensagem.
2.5. APLICAÇÃO DO SPF
Ou seja, o atributo SPF é satisfatório para ZONAS onde seus usuários utilizam o sistema de correio eletrônico apenas internamente, mas não satisfaz uma condição onde os usuários internos utilizam sistemas externos para o envio de mensagens usando aquela zona.
3. INTEGRAÇÃO COM DKIM
Não há um atributo específico DKIM (DomainKey Ideintified Mail) na tabela de tradução de NS, mas a integração DKIM, usada nos MTAs (Mail Transfer Agent) , MUAs (Mail User Agent) e MSAs (Mail Submission Agent) é feita através de uma entrada de registro específica com atributo TXT na tabela de tradução direta de um NS.
Considera-se que o DKIM siga as recomendações da RFC6376 . O leitor deve considerar a atualização desta RFC e verificar se as informações aqui prestadas são relevantes. O DKIM utiliza o NS (especificamente um DNS) para obter o valor da chave pública DKIM de um domínio “_domainkey” de uma ZONA e para uma tag específica.
Um MTA, MUA, MSA questionará o atributo TXT referente a requisição formada pela tag, seguinda do domínio _domainkey e completada pela ZONA.
Ou seja, se a tag=”Empresa-SA” e a ZONA é empresa.com.br, deve existir um único atributo TXT com a entrada:
Empresa-SA._domainkey.empresa.com.br. IN TXT “v=DKIM; p=chave-publica; s=email
onde:
v
é a versão do DKIM. E DEVE iniciar com DKIM.
p
é o indicador de uma chave pública que pode ser revogada a qualquer tempo. Esta chave NÃO DEVE ser criada por um CA (Certification Authority - Autoridade Certificadora)
s
é um seletor de finalidade. Pode ser um e-mail, uma data, um nome, e pode ter espaços.
O valor da chave pública é obtida a partir da uma chave privada. Via OpenSSL, os comandos são:
• Para gerar a chave privada e armazená-la no arquivo private.key:
openssl genrsa -out private.key 1024
• Para criar a chave pública correspondente e armazená-la no arquivo public.key:
openssl rsa -in private.key -pubout -out public.key
O conteúdo de public.key, removendo os cabeçalhos e rodapé --- BEGIN PUBLIC KEY --- e –--- END PUBLIC KEY ---, deve ser copiado para o valor de chave publica
3.1. APLICAÇÃO
Enquanto o SPF opera com os dados de envelope de uma mensagem, o DKIM opera com os cabeçalhos e conteúdo, o que identifica um remetente externo sendo este autenticado pela chave DKIM e outros parâmetros.
Ou seja, o DKIM permite que funcionários que trabalham fora da empresa e usam sistemas externos à empresa, usem o e-mail da zona da empresa, desde que insira a chave pública, a tag e o seletor correspondentes. Tal recurso atende a um cenário diferente do SPF.
