11

I've got a problem with Gmail.

It started after one of our trojan infected PCs sent spam for one day from our IP address.

We've fixed the problem, but we got into 3 black lists. We've fixed that, too. But still every time we send an email to Gmail the message is rejected:

So I've checked Google Bulk Sender's guide once again and found an error in our SPF record and fixed it. Google says everything should become fine after some time, but this doesn't happen. 3 weeks already passed but we still can't send emails to Gmail.

Our MX setup is a bit complex, but not too much: We have a domain name delo-company.com, it has it's own mail @delo-company.com (this one is fine, but the problems are with sub-domain name corp.delo-company.com).

Delo-company.com domain has several DNS records for the subdomain:

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" 

(I set ~all for testing purposes only, it was -all before that)

These records are for our corporate Exchange 2003 server at 82.209.198.147. Its LAN name is s2.corp.delo-company.com so its HELO/EHLO greetings are also s2.corp.delo-company.com.

To pass EHLO check we've also created some records in delo-company.com's DNS:

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

As I understand SPF verifications should be passed in this way: Out server s2 connects to MX of the recepient (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX says Ok, and makes SPF check of HELO/EHLO. It does NSlookup for s2.corp.delo-company.com and gets the above DNS-records. TXT records says that s2.corp.delo-company.com should be only from IP 82.209.198.147. So it should be passed.

Then our s2 server says RCPT FROM: Rcp.MX` server checks it, too. The values are the same so they should also be positive.

Maybe there is also a rDNS check, but I'm not sure what is checked HELO or RCPT FROM.

Our PTR record for 82.209.198.147 is:

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

To me everything looks fine, but anyway all emails are rejected by Gmail.

So, I've checked MXtoolbox.com - it says everything is fine, I passed http://www.kitterman.com/spf/validate.html Python check, I did 25port.com email test. It's fine, too:

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>

I also checked with spf-test@openspf.net, but it FAILs all the time, no matter which SPF records I make:

<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">

I've filled Gmail form twice, but nothing happens.

We do not send spam, only emails for our clients. 2 or 3 times we did mass emails (like New Year Greetings and sales promos) from corp.delo-company.com addresses, but they where all complying to Gmail Bulk Sender's Guide (I mean SPF, Open Relays, Precedence: Bulk and Unsubscribe tags). So, this should be not a problem.

Please, help me. What am I doing wrong?

UPD: I also tried Unlocktheinbox.com test and the server also fails this test. Here is the result; here is one more.

I also tried to send email from that server manually via telnet and everything is fine. Here is what I type:

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

And this is what I get:

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
Glorfindel
  • 1,213
  • 3
  • 15
  • 22
pablomedok
  • 133
  • 1
  • 11
  • Have you tried changing the TXT record from `ip4:82.209.198.147` to `mx`? Like you, I can't see an error, but that may be worth trying. – James O'Gorman Mar 02 '12 at 21:14
  • Tried mx for corp: : Recipient address rejected: SPF Tests: Mail-From Result="permerror": Mail From="supruniuk-p@corp.delo-company.com" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147"> – pablomedok Mar 02 '12 at 23:03
  • And mx for s2.corp. : 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"> Both are Softfail. – pablomedok Mar 02 '12 at 23:15
  • Do you have a DSN (Delivery Status Notification) for a bounced message ? Can you post it ? You don't say whether you know for sure that SPF is why Gmail is rejecting your email. – kls Mar 02 '12 at 23:18
  • I can give it to you, but it's in Russian: Сообщение не было получено одним или несколькими получателями. Тема: test 22 Отправлено: 03.03.2012 0:07 Сообщение не получили следующие получатели:   pablomedok@gmail.com на 03.03.2012 0:08   Ошибка связи с сервером электронной почты получателя по протоколу SMTP. Обратитесь к системному администратору.    The message breaks after the first line. I saw the logs, after it there is QUIT – pablomedok Mar 02 '12 at 23:46
  • here is the log http://f.cl.ly/items/1n181D231C01120B1L3A/log.txt – pablomedok Mar 02 '12 at 23:53
  • fs-mail-relay# host -t txt corp.delo-company.com corp.delo-company.com descriptive text "v=spf1 mx ~all" doesn’t match what you are showing us, so something is wrong there. Did you change it today ? – kls Mar 03 '12 at 01:39
  • yes, @kls, I changed it for the sake of testing, as James O'Gorman suggested above. I reverted it already – pablomedok Mar 03 '12 at 11:43
  • I tried to check the records with unlocktheinbox.com and here what is says: http://bit.ly/wYr39h – pablomedok Mar 03 '12 at 12:48
  • Your mail to Gmail is not being rejected. Your SPF is working. You need to start checking other things. Check the logs on Exchange. Make sure your messages aren't being tagged as spam by Gmail thus making them not show up in your "inbox". Send a regular message again and see if it gets through now. Maybe Gmail just got around to removing you from their RBL. – kls Mar 05 '12 at 19:58
  • Dear @kls, thanks for reply, I also think that SPF is ok. But the emails are rejected. I showed the log above - f.cl.ly/items/1n181D231C01120B1L3A/log.txt – connection breaks right after DATA command. Maybe it's because of incorrect headers of the email? When I sent emails manually from that server via telnet - I had the same response from gmail when i made some typos in commands and headers. – pablomedok Mar 12 '12 at 12:19
  • In your telnet test you used HELO, in the log from the rejected email you(the system) used EHLO. Try your telnet test again using EHLO and see what happens. – kls Mar 12 '12 at 18:59
  • Have you checked the "My Domain can't send to Gmail Form" buried in the Gmail help documentation. The russian rejection notice you posted in your comment looks exactly like the beginning of Gmails "You're on our blacklist" notice. https://support.google.com/mail/bin/answer.py?hl=en&answer=80369#BulkSenders – Albion Mar 15 '12 at 14:32
  • @kls, I did an EHLO test and everything is fine. Test Email delivered fine to gmail account. Tomorrow I would ask our ISP to change PTR to corp.delo-company.com and I would also change HELO name of the server. So the situation would get a bit simplier. – pablomedok Mar 15 '12 at 18:56
  • @Albion, I checked it before - looks like in every situation Gmail points to its Bulk Sender's Guide. I also wrote about my situation to 2 Google contact forms: http://support.google.com/mail/bin/request.py?contact_type=msgdelivery and https://support.google.com/mail/bin/request.py?hl=en&nomods=1&contact_type=bulk_send Two weeks past and it didn't help. Google is deaf – pablomedok Mar 15 '12 at 19:00

3 Answers3

2

Microsoft has a nice wizzard. Maybe it can suggest some changes?

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

DerekC
  • 106
  • 5
2

After 50 days of trying and googling for a solution, Gmail started to accept our emails. They pass to inbox in normal way (they are not tagged as spam).

I didn't make any changes or any other tries during last 15 days. I don't know is it bureaucracy or some algorithms that take so long, but to my mind it took 10 time longer than it should. 5 day penalty for our weak security is enough.

By the way, unlocktheinbox.com now passes the test, openspf.org test is still reporting a failure. Looks like my situation is too complex for the test. I would fix my PTR and HELO names to match domain name.

However it took already a week after we asked our ISP to change PTR and it's still remains unchanged... One more bureaucracy issue.

Thanks for everyone's help.

pablomedok
  • 133
  • 1
  • 11
1

could it be because you're using only TXT records, without an SPF type record?

to quote RFC 4408:

It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose.

An SPF-compliant domain name SHOULD have SPF records of both RR
types. A compliant domain name MUST have a record of at least one
type. If a domain has records of both types, they MUST have
identical content.

Waleed Hamra
  • 731
  • 6
  • 16
  • Our hosting control panel does not support SPF record type (only a, aaaa, cname, ns, mx, srv, txt). But that was not a problem before. I just can't understand, why some services pass and some other fail. And why manual message sending via Telnet was successful from the same server? Looks like there is something wrong with Exchange settings. – pablomedok Mar 04 '12 at 00:19
  • 1
    For anyone reading this now, be aware that use of the `SPF` RR type was deprecated in 2014. use `TXT`. See [RFC 7208](https://tools.ietf.org/html/rfc7208) for details. – mc0e Apr 29 '19 at 04:49