Troubleshooting email bounces

[HCHTech]

I have a customer that has a home-based consulting business. Their domain is hosted on GoDaddy, and they have a Comcast residential internet connection at their home. They have Outlook 2016, and they are popping email from their domain. The Servers in Outlook are pop.secureserver.net and smtpout.secureserver.net.

Just recently, the customer has started getting email bounced when they try to send to their biggest client - who happens to be Johnson & Johnson, believe it or not. The domain part of the recipient addresses is its.jnj.com. No other email is bouncing (so far, at least).

The bounce message says:

"Reason: There was an error while attempting to deliver your message with [Subject: "Redacted"] to redacted@its.jnj.com. MTA p3plsmtpa07-10.prod.phx3.secureserver.net received this response from the destination host IP - 68.232.149.99 - 554 , 554-esa18.jnj.iphmx.com

554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error please contact the intended recipient via alternate means."

Attached to the bounce message is this details.txt file:

"Reporting-MTA: dns; p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.229]
Received-From-MTA: dns; DESKTOPKK9DBAO [73.154.209.XXX]
Arrival-Date: Mon, 17 Jul 2017 08:46:45 -0700

Final-recipient: rfc822; redacted@its.jnj.com
Diagnostic-Code: smtp; 554-esa18.jnj.iphmx.com

Last-attempt-Date: Mon, 17 Jul 2017 08:47:16 -0700"

Ok, so I'm having trouble interpreting this enough to point the finger of blame appropriately. WHO'S MTA has a poor reputation, here? The "Received From" line in the details.txt file lists my customer's computer name, and an IP address that belongs to Comcast (73.154.209.XXX). If you lookup this IP on MX Toolbox's blacklist check, you'll see it on two blacklists. Ok, is that the end of the story? Her computer is clean, but maybe another household member's computer is sending spam? A quick trip to whatismyip.com on their computer returns only an IPv6 address, so that isn't exactly a slam-dunk.

Just for fun, I also looked up the IPv4 address from the details.txt file on Spamhaus's PBL list - I get:

"Ref: PBL1625004

73.154.0.0/16 is listed on the Policy Block List (PBL)
Outbound Email Policy of Comcast for this IP range:

Email sent by Comcast subscribers using a mail program such as Outlook Express are required to send the email through Comcast. To insure your mail program is properly configured, please visit http://www.comcast.net/help/faq/index.jsp?faq=Email117481. If you are a Comcast Commercial Services customer and need support, please contact support_biz@cable.comcast.com"

Which is basically saying (I think): This is a dynamic Comcast address. You are sending email over this connection but you are NOT using Comcast's email servers - so you are being a bad boy and you are on the list. Is that the real problem? Should I change Outlook to send mail out through Comcast servers? That feels a little kludgy.

Isn't the more important thing the sending mail server? Outgoing mail is being sent through smtpout.secureserver.net (GoDaddy), right?

So a couple of other facts. There are two MX records for the domain. The 0 record is smtp.secureserver.net, who's IP address is not on any blacklists. The 10 record is mailstore1.secureserver.net, who's IP address is listed on the spamcannibal blacklist. I don't think this is related to the bounce problem (MX is incoming mail), but I would think GoDaddy should be responsible for removing that secondary server from a blacklist.

Because it's never a bad thing, I have the customer running virus & malware scans on the other household computers, but I'm struggling to make a better plan of action.

 

[nlinecomputers]

It is complaining because the email is coming via Comcast. If they are running a business then they need real email, not a stupid web host mail. Get them on Office 365 from Microsoft or Sherweb and not GoDaddy. You can change it to the Comcast server but I doubt that will help the rep very much. Comming from a Comcast IP is what got the email flagged.

 

[Slaters Kustum Machines]

If they are running a business then they need real email, not a stupid web host mail. Get them on Office 365 from Microsoft or Sherweb and not GoDaddy.

This.

 

[Markverhyden]

Something is not right here. If they are popping their email from Godaddy then the SMTP will be secureserver.net but they will also report the originating IP address of the client. It's possible it may somehow be tagging that. An MTA is an email server not the client. And the filtering service, iphmx.com, is a Cisco mail filtering service. So they are the ones blocking this. Do they have a website? Has it been checked?

Whatismyip only picks up IPv6 in areas where Comcast has IPv6 enabled even if it's not being used. Try something like ipchicken, that should give you the IPv4. You can also see that in the router. But the email header has the client IP anyways. What I have seen of the header is correct for Godaddy hosted email. Have you checked their records? Do they have SPF, etc records?

When you looked up the Comcast address

Just for fun, I also looked up the IPv4 address from the details.txt file on Spamhaus's PBL list - I get:

"Ref: PBL1625004

73.154.0.0/16 is listed on the Policy Block List (PBL)
Outbound Email Policy of Comcast for this IP range:

That is normal behavior. By outbound they are referring to the SMTP address, not the client address. Dynamic IP scopes are pretty much blocked everywhere because the blackhats used to drop in a small SMTP server on consumer machine to spam, hence coming from a dynamic block. I used to run my SMTP directly, have a dynamic IP, but stopped about 10 years ago because of this. So I just relay through my Earthlink account.

 

[nlinecomputers]

Something is not right here. If they are popping their email from Godaddy then the SMTP will be secureserver.net but they will also report the originating IP address of the client. It's possible it may somehow be tagging that.

Yes, they are definitely tagging on that.

"Ref: PBL1625004

73.154.0.0/16 is listed on the Policy Block List (PBL)
Outbound Email Policy of Comcast for this IP range:

Email sent by Comcast subscribers using a mail program such as Outlook Express are required to send the email through Comcast.

Maybe Comcast term of use for residential is to require you to use only the Comcast SMTP servers.

Which is the other half of this equation: If she had a business internet connection instead of a residential then she wouldn't get lumped in with all the spambots on a residential range of IP addresses. Your client is in a bad neighborhood and is being unfairly slammed because she lives next door to the crack dealer.

 

[Markverhyden]

Maybe Comcast term of use for residential is to require you to use only the Comcast SMTP servers.

I don't think so, at least for email clients. That would be a huge mess. Now maybe they do that for if someone is running an SMTP server but pretty much all of the BL services block dynamic IP scopes anyways.

I checked the IP for mailstore1.secureserver.net on spamhaus and it is clean, never heard of spamcannibal. Since the problem is intermittent I'm thinking it may be a problem with iphmx.com. At any rate the key to trouble free email is making sure all the correct records are published, PTR, SPF, and DKIM. @HCHTech should verify if those are published through Godaddy assuming they are the DNS provider for the domain. These additional records have evolved to help reduce these false positives.

Of course having a business class service with the ISP is also very important.

https://www.rackaid.com/blog/email-dns-records/

 

[Tech Savvy]

I like to start simple, have you verified that the correct email account is sending the email? By this I mean if the user has two email accounts setup in outlook, one for the business and the other his personal Comcast acct, maybe outlook is trying to send from his personal account.

Also, try checking the reverse DNS entries, you'll want the record to match the domain of his business. This is often used by filters to blacklist an email because the sender is not verified to be the real sender. Enter the users email in a service like: https://mxtoolbox.com/domain/ and see if there are any mail errors and if reverse DNS is one of them this can be an issue.

 

[HCHTech]

Thanks guys - I think the best solution is to just move them to hosted exchange and avoid this whole issue. $5/mo is way cheaper than fighting to raise their reputation, an uphill battle with Comcast, I'm sure. So I clearly misunderstood that their service vendor (comcast) had much bearing on their reputation if they were using domain email on a webhost.

BTW, if you do an nslookup on mailstore1.secureserver.net, 3 IPs return.

72.167.238.32
68.178.213.243
68.178.213.244

Both the 2nd and 3rd IP listed come up as on the SpamCannibal blacklist when checked on MxToolbox. I don't think this is relevant to the current problem, but surely it's still a problem, yes?

They do NOT have an SPF record, so I think I'll add one if we can't migrate right away to hosted exchange.

Can someone discuss the relative merits of using something like:

"v=spf1 a mx include:secureserver.net ~all" ....which names the godaddy server explicitly and prohibits all others

as opposed to

"v=spf1 mx -all" ....which says (I think) all servers named in this domain's MX records are ok

It appears that both are functionally equivalent, but I'm no expert on the minutiae of SPF.

 

[nlinecomputers]

The ~ in the longer one is a softer requirement. -all is a firm no one else is allowed. ~all is maybe. Other than that they are the same as you mention.

 

[HCHTech]

The ~ in the longer one is a softer requirement. -all is a firm no one else is allowed. ~all is maybe.

Ok, I see - softfail vs. hardfail. This appears to be the definitive list of options, although lots of questions remain. For softfail, they list:

"The SPF record has designated the host as NOT being allowed to send but is in transition" as the explanation, and then in a column titled "Intended action" they have: "accept but mark"

In practice, will filters that score based on SPF records treat a softfail with more suspicion than a hardfail (I imagine yes)? I guess the "intended action" is not guaranteed to be the "actual action" taken by filters...

 

[nlinecomputers]

Not exactly. ~all on the end your record is a cleanup item. If you don't exactly match the previous part you end up at the end. SO if you have listed your MX record as valid and email is sent from an unlisted mail server then the all function decides how you declare it. ~all means that other email servers MIGHT be mine so you should mark as spam but allow in. -all means that you reject anything that didn't pass before.

v=spf1 mx -all says that my MX record listed is valid but every other server is considered a spam source

v=spf1 mx ~all says my MX record is valid but every other server MIGHT be considered a spam source or might not. If you mark as spam you might miss something from me.

 

[HCHTech]

Thanks, @nlinecomputers , that helps.