[MASOCH-L] HELO inválido

[Bruno Vane]

Show Leandro, vou fazer esse teste. Obrigado!

Em 11 de abril de 2017 10:33, Leandro <leandro at spfbl.net> escreveu:

> Opa. Com certeza! Existem inúmeros casos de envios legítimos que caem nesse
> problema que você apontou. Apesar de não ser 100% correto, do ponto de
> vista técnico, usar esse critério que mencionei é uma forma de sermos
> pragmáticos em relação aos efeitos colaterais de sermos duros demais ou de
> sermos complacentes demais. Esse critério fica no meio termo e os falsos
> positivos dele são desprezíveis e contornáveis.
>
> Leandro
> SPFBL.net
>
> Em 11 de abril de 2017 10:20, Bruno Vane <broonu at gmail.com> escreveu:
>
> > Leando,
> >
> > Eu até uso SPFBL nesse servidor, mas está sendo rejeitado direto no
> > postfix.
> > Acha melhor então eu remover essa regra rígida do postfix e deixar o
> SPFBL
> > cuidar disso?
> >
> > Em 11 de abril de 2017 10:10, Leandro <leandro at spfbl.net> escreveu:
> >
> > > 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@
> > > 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
> > > >
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>