O Gmail rejeita e-mails. Openspf.net falha nos testes

11

Estou com um problema no Gmail.

Tudo começou depois que um de nossos PCs infectados por cavalos de Troia enviou spam por um dia a partir do nosso endereço IP.

Corrigimos o problema, mas entramos em 3 listas negras. Nós consertamos isso também. Mas ainda assim, sempre que enviamos um email para o Gmail, a mensagem é rejeitada:

Portanto, verifiquei o guia do remetente em massa do Google mais uma vez e encontrei um erro em nosso registro SPF e o corrigi. O Google diz que tudo deve ficar bem depois de algum tempo, mas isso não acontece. Já passaram três semanas, mas ainda não podemos enviar e-mails para o Gmail.

Nossa configuração de MX é um pouco complexa, mas não muito: temos um nome de domínio delo-company.com, ele próprio [email protected] (este é bom, mas os problemas estão com o nome de subdomínio corp.delo-company.com).

O domínio Delo-company.com possui vários registros DNS para o subdomínio:

corp                     A     82.209.198.147
corp                     MX    20 corp.delo-company.com
corp.delo-company.com    TXT   "v=spf1 ip4:82.209.198.147 ~all" 

(Eu configurei ~ all apenas para fins de teste, era -tudo antes disso)

Esses registros são para o servidor corporativo do Exchange 2003 em 82.209.198.147. Seu nome de LAN é s2.corp.delo-company.com, portanto, os cumprimentos HELO / EHLO também são s2.corp.delo-company.com.

Para passar na verificação do EHLO, também criamos alguns registros no DNS do delo-company.com:

s2.corp                  A     82.209.198.147
s2.corp.delo-company.com TXT   "v=spf1 ip4:82.209.198.147 ~all" 

Pelo que entendi, as verificações do SPF devem ser passadas desta maneira: O servidor s2 se conecta ao MX do destinatário (Rcp.MX): EHLO s2.corp.delo-company.com O Rcp.MX diz Ok e faz a verificação SPF do HELO / EHLO. Ele faz o NSlookup para s2.corp.delo-company.com e obtém os registros DNS acima. Os registros TXT afirmam que s2.corp.delo-company.com deve ser apenas do IP 82.209.198.147. Portanto, deve ser aprovado.

Então nosso servidor s2 diz que o servidor RCPT FROM: Rcp.MX` também verifica. Os valores são os mesmos e, portanto, também devem ser positivos.

Talvez haja também uma verificação de rDNS, mas não tenho certeza do que está marcado HELO ou RCPT FROM.

Nosso registro PTR para 82.209.198.147 é:

147.198.209.82.in-addr.arpa. 86400 IN PTR s2.corp.delo-company.com.

Para mim, tudo parece bem, mas mesmo assim todos os emails são rejeitados pelo Gmail.

Então, verifiquei o MXtoolbox.com - ele diz que está tudo bem, passei no http://www.kitterman.com/spf/validate.html verificação de Python, fiz o teste de email do 25port.com. Tudo bem também:

Return-Path: <[email protected]>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <[email protected]>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <[email protected]>)
Authentication-Results: verifier.port25.com; spf=pass [email protected]
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) [email protected]
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass [email protected]
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----_=_NextPart_001_01CCF89E.BE02A069"
Subject: test
Date: Fri, 2 Mar 2012 21:03:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <[email protected]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <[email protected]>
To: <[email protected]>

Também verifiquei com [email protected], mas FALHA o tempo todo, independentemente dos registros SPF que eu fizer:

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <[email protected]>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="[email protected]" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

Preenchi o formulário do Gmail duas vezes, mas nada acontece.

Não enviamos spam, apenas emails para nossos clientes. Duas ou três vezes, fizemos e-mails em massa (como saudações de ano novo e promoções de vendas) dos endereços corp.delo-company.com, mas todos eles estavam em conformidade com o Guia do remetente em massa do Gmail (refiro-me ao SPF, retransmissões abertas, precedência: em massa e cancelar inscrição) Tag). Portanto, isso não deve ser um problema.

Por favor me ajude. O que estou fazendo de errado?

UPD: Eu também tentei o teste Unlocktheinbox.com e o servidor também falhou nesse teste. Aqui está o resultado; aqui está mais um.

Também tentei enviar e-mails desse servidor manualmente via telnet e está tudo bem. Aqui está o que eu digito:

220 mx.google.com ESMTP g15si4811326anb.170
HELO s2.corp.delo-company.com
250 mx.google.com at your service
MAIL FROM: <[email protected]>
250 2.1.0 OK g15si4811326anb.170
RCPT TO: <[email protected]>
250 2.1.5 OK g15si4811326anb.170
DATA
354  Go ahead g15si4811326anb.170
From: [email protected]
To: Pavel <[email protected]>
Subject: Test 28

This is telnet test
.
250 2.0.0 OK 1330795021 g15si4811326anb.170
QUIT
221 2.0.0 closing connection g15si4811326anb.170

E é isso que eu recebo:

Delivered-To: [email protected]
Received: by 10.227.132.73 with SMTP id a9csp96864wbt;
        Sat, 3 Mar 2012 09:17:02 -0800 (PST)
Received: by 10.101.128.12 with SMTP id f12mr4837125ann.49.1330795021572;
        Sat, 03 Mar 2012 09:17:01 -0800 (PST)
Return-Path: <[email protected]>
Received: from s2.corp.delo-company.com (s2.corp.delo-company.com. [82.209.198.147])
        by mx.google.com with SMTP id g15si4811326anb.170.2012.03.03.09.15.59;
        Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 82.209.198.147 as permitted sender) client-ip=82.209.198.147;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates 82.209.198.147 as permitted sender) [email protected]
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <[email protected]>
From: [email protected]
To: Pavel <[email protected]>
Subject: Test 28

This is telnet test
pablomedok
fonte
Você já tentou alterar o registro TXT de ip4:82.209.198.147para mx? Como você, não vejo erro, mas vale a pena tentar.
James O'Gorman
Tentei mx para corp: <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <[email protected]>: Endereço do destinatário rejeitado: SPF Tests: SPF Tests: Mail-From Result = "permerror" : Correio de = "[email protected]" Nome HELO = "s2.corp.delo-company.com" Resultado HELO = "softfail" IP remoto = "82.209.198.147">
pablomedok
E mx para s2.corp. <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <[email protected]>: Endereço do destinatário rejeitado: Testes SPF: Resultado do resultado da correspondência = "softfail": Correio da = " [email protected] "HELO name =" s2.corp.delo-company.com "HELO Result =" softfail "IP remoto =" 82.209.198.147 "> Ambos são Softfail.
Pablomedok
Você tem um DSN (notificação de status de entrega) para uma mensagem devolvida? Você pode postar? Você não diz se sabe ao certo que é por causa do SPF que o Gmail está rejeitando seu e-mail.
KLS
Eu posso dar a você, mas está em russo: Сообщение не было получено одним или несколькими получателями. Тема: teste 22 Отправлено: 03.03.2012 00:07 Сообщение не получили следующие получатели: [email protected] на 03.03.2012 00:08 Ошибка связи с сервером электронной почты получателя по протоколу SMTP. Обратитесь к системному администратору. <s2.corp.delo-company.com # 5.5.0 smtp; 550-5.7.1 [82.209.198.147 3] Nosso sistema detectou uma taxa incomum de> A mensagem quebra após a primeira linha. Eu vi os logs, depois que há
desistir

Respostas:

2

Após 50 dias de pesquisa e busca no Google por uma solução, o Gmail começou a aceitar nossos e-mails. Eles passam para a caixa de entrada da maneira normal (não são marcados como spam).

Não fiz alterações nem tentei nos últimos 15 dias. Não sei se é burocracia ou alguns algoritmos que demoram tanto, mas, na minha opinião, demorou 10 vezes mais do que deveria. Uma penalidade de 5 dias para nossa fraca segurança é suficiente.

A propósito, unlocktheinbox.com agora passa no teste, o teste openspf.org ainda está relatando uma falha. Parece que minha situação é muito complexa para o teste. Eu consertaria meus nomes PTR e HELO para corresponder ao nome de domínio.

No entanto, já levou uma semana depois que pedimos ao nosso ISP para alterar o PTR e ainda permanece inalterado ... Mais um problema de burocracia.

Obrigado pela ajuda de todos.

pablomedok
fonte
1

poderia ser porque você está usando apenas registros TXT, sem um registro de tipo SPF?

para citar a RFC 4408:

Reconhece-se que a prática atual (usando um registro TXT)
não é ideal, mas é necessária porque existem várias
implementações de servidor DNS e resolvedor em uso comum que não podem lidar com
o novo tipo de RR. O esquema de dois registros fornece um caminho
para a melhor solução do uso de um tipo RR reservado para essa finalidade.

Um nome de domínio compatível com SPF DEVE ter registros SPF de ambos os
tipos RR . Um nome de domínio compatível DEVE ter um registro de pelo menos um
tipo. Se um domínio tem registros de ambos os tipos, eles devem ter
conteúdo idêntico.

Waleed Hamra
fonte
Nosso painel de controle de hospedagem não suporta o tipo de registro SPF (apenas a, aaaa, cname, ns, mx, srv, txt). Mas isso não era um problema antes. Eu simplesmente não consigo entender por que alguns serviços passam e outros falham. E por que o envio manual de mensagens via Telnet foi bem-sucedido no mesmo servidor? Parece que há algo errado nas configurações do Exchange.
precisa saber é o seguinte
1
Para qualquer pessoa que esteja lendo isso agora, saiba que o uso do SPFtipo RR foi descontinuado em 2014. use TXT. Veja RFC 7208 para detalhes.
Mc0e 29/04/19