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 mail@delo-company.com (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: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <check-auth@verifier.port25.com>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <supruniuk-p@corp.delo-company.com>)
Authentication-Results: verifier.port25.com; spf=pass smtp.mailfrom=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) header.From=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass header.From=supruniuk-p@corp.delo-company.com
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: <4C9EB1DB67831A428B2E14052F4A418707E1FF@s2.corp.delo-company.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <supruniuk-p@corp.delo-company.com>
To: <check-auth@verifier.port25.com>

Também verifiquei com spf-test@openspf.net, 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 <spf-test@openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="supruniuk-p@corp.delo-company.com" 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: <supruniuk-p@corp.delo-company.com>
250 2.1.0 OK g15si4811326anb.170
RCPT TO: <pablomedok@gmail.com>
250 2.1.5 OK g15si4811326anb.170
DATA
354  Go ahead g15si4811326anb.170
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
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: pablomedok@gmail.com
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: <supruniuk-p@corp.delo-company.com>
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 supruniuk-p@corp.delo-company.com 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 supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) smtp.mail=supruniuk-p@corp.delo-company.com
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <4f52520c.0f53640a.77bf.5626SMTPIN_ADDED@mx.google.com>
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test

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 <spf-test@openspf.net>: Endereço do destinatário rejeitado: SPF Tests: SPF Tests: Mail-From Result = "permerror" : Correio de = "supruniuk-p@corp.delo-company.com" 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 <spf-test@openspf.net>: Endereço do destinatário rejeitado: Testes SPF: Resultado do resultado da correspondência = "softfail": Correio da = " supruniuk-p@corp.delo-company.com "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 Сообщение не получили следующие получатели: pablomedok@gmail.com на 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.


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.


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
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.