[MASOCH-L] HELO inválido

[Leandro]

Oi Bruno.

Aqui a gente usa a seguinte lógica para rejeitar neste cenário: remetente
sem validação SPF e ao mesmo tempo HELO não aponta para o IP de origem. Se
qualquer um dos dois critérios for falso, aceitamos a mensagem. Alias, isso
já está implementado no SPFBL.

Essa lógica se baseia na ideia de dicotomia de responsabilidades. Para
simplificar, tomemos como base um cenário que o responsável pelo MTA de
disparo é diferente do responsável pelo domínio do remetente. Se o
responsável pelo domínio de remetente faz a parte dele, configurando
corretamente o SPF, então seria injusto barrar as mensagens dele caso o
responsável pelo MTA de disparo não fez a parte dele. Considere o oposto
também. O que sobra é apenas os casos onde ambos não fizeram a suas partes,
que é o critério acima.

A vantagem de trabalhar desta forma é que qualquer um dos dois responsáveis
podem resolver o problema configurando sua parte, sem precisar da
intervenção do outro. As vezes um lado tem cabeça dura demais e fica
difícil deixar tudo 100% perfeito, como é esse caso que você mostrou.

Como seu caso dá PASS no SPF, recomendo aceitar as mensagens deles. Mas se
em algum momento parar de dar PASS, ai pode rejeitar sem dó pois há
desleixo em demasia.

Abraços,

Leandro
SPFBL.net

Em 11 de abril de 2017 09:53, Bruno Vane <broonu at gmail.com> escreveu:

> Pessoal, como vocês agem em caso de SMTP fazendo HELO com host inválido?
>
> Apr 11 09:40:56 mail2 postfix/smtpd[3420]: NOQUEUE: reject: RCPT from
> mail.tjrj.jus.br[200.222.1.30]: 450 4.7.1 <srv-relay.tjrj.jus.br>: Helo
> command rejected: Host not found; from=<nao.responda.12156553 at tjrj.jus.br>
> to=<XXXXXX at XXXXXX.com.br> proto=ESMTP helo=<srv-relay.tjrj.jus.br>
>
> Tenho enviado e-mails para eles tanto para o e-mail do whois quanto usando
> o formulário do site, sempre devidamente ignorado, como se espera de órgãos
> públicos.
>
> Não quero ficar liberando quem faz tudo errado, sendo que trabalhamos duro
> pra manter tudo certo, mas como não prejudicar também os clientes que
> precisam receber as mensagens?
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>