[GTER] sobre spam: bloquear reverso inconsistente funciona mesmo?

[Raphael Bittencourt S. Costa]

Henrique,

Realmente você tem razão sobre a RFC não contemplar a rejeição, porém o helo
precisa ser FDQN e pode ser utilizado para verificar se corresponde ao ip de
origem. 

RFC: http://www.freesoft.org/CIE/RFC/1123/90.htm

5.2.5 HELO Command: RFC-821 Section 3.5

The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is
a valid principal host domain name for the client host. As a result, the
receiver-SMTP will not have to perform MX resolution on this name in order
to validate the HELO parameter.

The HELO receiver MAY verify that the HELO parameter really corresponds to
the IP address of the sender. However, the receiver MUST NOT refuse to
accept a message, even if the sender's HELO command fails verification.

DISCUSSION:
Verifying the HELO parameter requires a domain name lookup and may therefore
take considerable time. An alternative tool for tracking bogus mail sources
is suggested below (see "DATA Command").

Note also that the HELO argument is still required to have valid <domain>
syntax, since it will appear in a Received: line; otherwise, a 501 error is
to be sent.

IMPLEMENTATION:
When HELO parameter validation fails, a suggested procedure is to insert a
note about the unknown authenticity of the sender into the message header
(e.g., in the "Received:" line).


[]s,

Raphael Costa

-----Original Message-----
From: gter [mailto:gter-bounces at eng.registro.br] On Behalf Of Henrique de
Moraes Holschuh
Sent: quarta-feira, 22 de agosto de 2012 12:06
To: gter at eng.registro.br
Subject: Re: [GTER] sobre spam: bloquear reverso inconsistente funciona
mesmo?

On 22-08-2012 00:19, Raphael Bittencourt S. Costa wrote:
> Acredito que esta questão seja melhor para a MASOCH...

Mais ou menos.  Enquanto o nível da discussão estiver bem elevado, não é tão
ruim ficar na GTER, parte é on-topic (DNS, etc).

> Helo - Ser fqdn. - Possuir o mesmo fqdn que o reverso.

Atrelar o FQDN do HELO/EHLO com o reverso não é coberto por nenhum RFC, e na
minha experiência não funciona muito bem na prática (muito falso positivo).
A função real do EHLO é impedir loop (e na rede interna acaba sendo útil
também para ajudar em rastreio).  Na prática, o que funciona bem é exigir
que o EHLO seja sintaticamente válido conforme RFC, e bloquear pipelining
ilegal.

Já a exigência do reverso bem configurado para o IP do MTA, realmente ajuda.
Por RFC, você não exigiria a existência do reverso (na prática, pela minha
experiência exigir reverso funcional só recusa email de gambiarra (tipo
tentar hospedar servidor de email em ADSL residencial e spambot).

Por RFC, você exige apenas que, se o reverso existe, ele deve estar correto.
Cuidado para não exigir que exista apenas um PTR.  Os dois RFCs relacionados
ao reverso de IPv4 deixam bem claro que podem existir vários PTR [e todos
precisam estar corretos].

Quando testei isso um ano atrás, bloquear reverso inconsistente eliminava
parte do espaço dial-up/banda larga residencial, mas acaba sendo mais
eficiente checar via blocklist composta (que vai permitir rejeitar por
outros motivos).  Aqui fazemos os dois, mas testamos as blocklists primeiro.
É um problema geral de operadora ser incompetente/negligente no tratamento
do DNS...

Para ter números palpáveis, basta inverter a ordem e testar o reverso do
cliente IP antes das blocklists.  Não posso fazer isso aqui devido à
degradação de performance, mas quem tem menos bot batendo na porta talvez
possa...

--
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.
--
gter list    https://eng.registro.br/mailman/listinfo/gter