[MASOCH-L] reverso PTR

[Henrique de Moraes Holschuh]

On 25-07-2012 23:48, Eduardo Schoedler wrote:
> Em 25/07/2012, às 23:22, "Marcelo Szeer"<marcelo at vianet.com.br>
> escreveu:
>> Existe alguma RFC a respeito de configurar um servidor de e-mail
>> para rejeitar e-mails quando o reverso PTR não bate com o IP da
>> sessão de inbound do SMTP ?

Sim.  Mas cuidado para não confundir as coisas.  Quando o reverso não
bate com o IP, é violação dos RFCs do DNS, e não dos RFCs relacionados a
email, SMTP, ESMTP e afins.  Não tem nenhum RFC atrelando o recebimento
de email com a existência ou não existência de PTR no reverso.

O uso correto de registros PTR nunca foi trivial.  O que você precisa
garantir é que:

Seja "IP(A)" um IPv4 ou IPv6 que está sendo utilizado para contactar um
servidor que faz a verificação de reverso (no caso, um MTA).

O IP(A) pode ou não ter um RRset PTR associado através da zona de DNS
reverso.  Note que é um RRset, então um IP PODE ter mais que um registro
PTR associado via DNS reverso (não que fazer isso seja uma boa ideia.
Não é, pois causa problemas porque muita gente e muito software não sabe
que múltiplos PTR para o mesmo IP é configuração legal).

De qualquer forma, não importando quantos RR existem no RRset PTR
retornado após uma consulta normal (que resolve CNAMEs, etc), estes
RRs *obrigatoriamente* precisam ser nomes canônicos que resolvem para
RRsets do tipo A (IPv4) ou AAAA (IPv6) que CONTÉM o IP(A).  Ou seja,
NENHUM PTR pode apontar para um CNAME (RFC 1035 e RFC 2181).

Nenhum RFC relacionado à e-mail exige este registro PTR.  Entretanto, é
regra de melhor prática que o PTR exista e esteja correto para qualquer
MTA operando como MX de saída.  Quem não coloca PTR correto é
considerado suspeito de uso não autorizado, e o serviço é negado por uma
fração muito significativa dos MX de entrada.

Note que o NOME utilizado pelo servidor de email para se identificar via
EHLO/HELO NÃO precisa ser um dos nomes retornados nos registros PTR.  A
exigência baseada em RFC é que, o registro PTR existindo, um dos nomes
retornado via PTR precisa resolver diretamente (sem CNAMEs) para RR tipo
A ou AAAA que retorna o IP utilizado pelo servidor de email.

As RFC que definem o PTR são: RFC 1035 e RFC 2181.

Em particular, a RFC2181 diz:
    Confusion about canonical names has lead to a belief that a PTR
    record should have exactly one RR in its RRSet.  This is incorrect,
    the relevant section of RFC1034 (section 3.6.2) indicates that the
    value of a PTR record should be a canonical name.  That is, it should
    not be an alias.  There is no implication in that section that only
    one PTR record is permitted for a name.  No such restriction should
    be inferred.

    Note that while the value of a PTR record must not be an alias, there
    is no requirement that the process of resolving a PTR record not
    encounter any aliases.  The label that is being looked up for a PTR
    value might have a CNAME record.  That is, it might be an alias.  The
    value of that CNAME RR, if not another alias, which it should not be,
    will give the location where the PTR record is found.  That record
    gives the result of the PTR type lookup.  This final result, the
    value of the PTR RR, is the label which must not be an alias.

Incorrer no erro de que PTR precisa ser único é extremamente comum (eu
mesmo já cometi esse erro :-p).  Ir contra essa concepção errada causa
problemas operacionais.

>> pergunto isso pelo fato de que a gigantesca maioria dos e-mails
>> enviados por esses sistemas de mailing lists são recebidos de forma
>> legítima com o remetente de um domínio ao qual neles não está
>> hospedado... se habilitar o servidor de e-mail para devolver um 501
>> e fechar a conexão estaremos infringindo alguma RFC ?

Depende.

Exigir que exista PTR, e que o mesmo esteja correto, é considerado
melhor prática, e não vai causar problemas para MX de saída bem
configurado (e nem com mailing lists que utilizem MX de saída bem
configurado).

O que não se exige é que o EHLO coincida com o PTR. Se você exigir
isso, vai recusar MUITA email legítima de sites que estão perfeitamente
bem configurados.  Da mesma forma, não há relação entre o que está no
envelope ou nos cabeçalhos e o PTR.

A função do nome informado no EHLO (ou HELO) é INTERROMPER LOOP, para
evitar que um MTA por qualquer motivo esdrúxulo, fale com ele mesmo.
O nome informado no EHLO precisa necessariamente ser um nome que
identifique unicamente o MTA MESMO no caso de existirem vários MTAs
operando no mesmo IP (vários MTA rodando no mesmo host, ou devido a
NAT).  Exigir que EHLO seja idêntico ao PTR torna impossível diversos
usos perfeitamente normais, não tem base em nenhum RFC ou melhor
prática, e está *errado*.

Relações entre IP de envio e conteúdo de envelopes e cabeçalhos é
assunto para SPF e DKIM.  Que eu saiba, nenhum deles exige nada em
relação ao DNS reverso, mas se exigir, está descrito na especificação do
DKIM e SPF.

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.