1

I've been having a terrible problem sending emails from a godadddy shared-hosting (CPANEL) email account to any email account hosted by Network Solutions. I have spent hours on the phone with technical support from both godaddy and Network Solutions. I have two open tickets with Network Solutions for two different email addresses, and will open a third one for a third email address. As far as I can tell, email sent from that godaddy account reaches all other addresses just fine. There is a correct spf record for the godaddy account (gmail likes it). And some of the emails (the most important ones) even have DKIM signatures. Gmail doesn't quite like the DKIM signatures, but accepts the mail. And the ones I've entered tickets for with netsol do not have DKIM signatures. But mail sent to the netsol addresses do not get delivered. They do not get delivered to Spam and they don't bounce. They simply go to /dev/null.

I won't rant about how incompetent the netsol response has been, but the first of the tickets was opened on August 3, and it's still open, and the problem persists. The only visible action on their part that I have seen is that they sent an email to my netsol account with a spoofed sender address of the godaddy account. But I could see in the headers that it originated from a netsol server, so that's why it got through.

On the other hand, godaddy technical support has been extremely helpful, and I eventually managed to sweet talk the support agents out of the relevant entries from their outgoing server logs. The agent I spoke with about the third netsol address was not willing to send the actual server log entries, but he confirmed to me that they were equivalent to what I had been given for the first two, which were essentially the same.

So here is (a highly-sanitized version of) the server interaction, where 1.2.3.4 is the IP address of the godaddy MTA, and 5.6.7.8 is the IP address of the netsol MTA.

20210812 09:29:10.177 core sid="id1" id="id1id2"
    ip="1.2.3.4" action="PERMERR" dstmta="5.6.7.8" age="61" code="553"
    reason="553 5.3.0 198.71.225.36 Your message was rejected for possible spam/virus
    content.Please ask your email provider to visit http://emailadmin.registeredsite.com
    for resolution.\r\n" account="[email protected]""
    fwd="0" bounce="false" mailfrom="[email protected]" fromdomain="godaddy-example.com"
    recipient_list="[email protected]" todomain="netsol-example.com"
    subject="Sad news" subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""

20210812 09:28:09.658 core sid="id1" id="id1id2"
    ip="1.2.3.4" action="ACCEPT" reason="CLEAN" account="[email protected]"
    fwd="0" mailfrom="[email protected]" fromdomain="godaddy-example.com"
    recipient_list="[email protected]" todomain="netsol-example.com" subject="Sad news"
    subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""

Can anybody explain why this would have resulted in the mail being thrown on the floor? Or how it can be that netsol would be unable to fix the problem within 10 days? I didn't have these logs back on Aug 3, but I did give them the timestamp, Message-ID, and sending and receiving email addresses. Obviously the Subject line isn't suspicious, and the message body was a single sentence saying that my grandfather passed away the previous day at 5 PM. Not likely to be recognized as spam. So my only conclusion was that it must be based on the IP address of of the godaddy server. I checked the IP address at mxtoolbox.com, and it was listed on a couple of blacklists, but no really bad ones (SORBS SPAM, which charges a fee for delisting, is ignored by godaddy, but they are proactive at staying off of Spamhaus). And I tried re-sending again after it was shown not to be on any blacklists, but it still went undelivered. I also checked it at http://emailadmin.registeredsite.com a few times, and it never showed as blocked. And of course they say that being blocked results in a bounce message.

Isn't it kind of a requirement of SMTP that messages either get delivered or bounced? Does anybody know the specific meaning of the bounce="false" parameter in the 553 rejection entry? Is that saying that the netsol server will not issue a bounce, or is it telling the godaddy server not to bounce it? Should the godaddy server be issuing a bounce in response to the 553 from netsol anyway? Either way, it's still a netsol problem for discarding the messages, but it would help me if godaddy sent a bounce in this situation.

EDIT 1: Additional information with its own question:

I took the IP address of the particular "netsol" server that issued the 553 response and fed it to ARIN's WHOIS-RWS tool. It said that the address belonged to Cloudflare (i.e. within the CIDR block 172.64.0.0/13, which ARIN has directly allocated to Cloudflare, Inc). Does this mean anything? Netsol has lots of IP addresses that it owns, does the fact that this MTA has an address owned by Cloudflare imply anything about netsol's possibly outsourcing the MTA service to Cloudflare? And perhaps netsol does not directly control the server, and that's part of the reason for the delay in getting it fixed?? Or does Cloudflare more likely just "sub-lease" the IP address to netsol who actually owns and runs the server? Netsol has been providing email service for longer than Cloudflare has been in existence, but over the years seems to have become much less technical and more marketing and business-deal oriented (IMO). And after this fiasco, I'm getting much less likely to stay with netsol after more than 20 years with them.

EDIT 2: More of a rant about about netsol technical support

I said initially that I didn't want to do this, but I'm so frustrated by the lack of any action in response to my ticket from 11 days ago, as well as the new ticket for a different account reporting the same problem 2 days ago, which has also received no response. So this is what I posted as a comment on the first ticket:

So around 9:45, the agent said her supervisor would call me within the next 2-4 hours, and then very considerately noted that that would put it after midnight my time. I said that was no problem, I'm an adult and can stay up after midnight if I want. So I stayed up until 4 AM waiting for a call that never arrived, and still hasn't. Guess I can while away the hours helping my friend enter a ticket for the same problem with her netsol email account, and update this post I made to superuser.com: How to interpret specific SMTP responses which started out promising not to rant about the poor technical support from netsol, but is being updated to document this abject failure by netsol to provide support to a customer of more than 20 years. So now I have to add the rude treatment by a supposed supervisor. Funny thing was that I had asked the agent if it was possible to escalate this case to a higher technical team, and she apparently interpreted that to mean her supervisor.

Edit 3: Continuing the rant/saga

More phone calls, and finally got an agent to say they were escalating it to Tier 2 support, and gave me a new ticket number (beginning with "I" instead of "S") and that the supervisor in charge of it would call me back with a status update. In the meantime, I got an email from a support person saying that upon checking the details of the 2nd ticket, they found that the domain involved belonged to godaddy rather than netsol. The email cited a non-existent domain (in TLD .com rather than .org as the original report and my comments on it specified). And that mistaken domain was an error in the domain name from the 1st ticket. And then I found that the 2nd ticket had been closed! I replied to the email asking "Luisa C." to reopen the ticket, but 2 days later it was still marked closed, so I couldn't comment on it. So I called back again to ask to get it re-opened, and that did work. Yay! But still no status update. So I called again today, gave the agent the new "I' number for the Tier 2 escalation, and was told that the supervisor and "back office team" were working on it, and that the supervisor would call me back later (I didn't manage to get a deadline for the callback before the call ended).

5
  • I'll toss this out there on the off chance that it'll help: my wife suddenly found that her emails were not going through; I don't recall whether it was to just some recipients or all. After a lot of flailing around, we found that it was down to too many links in her signature. Too many according to some nannyware or other, at any rate. Removed 'em all, problem solved. Added them back one at a time until the problem recurred, backed off by one and problem's remained solved. Aug 14, 2021 at 16:37
  • Thanks for the suggestion @Steve, but that's not not the case here. The subject line was "Sad news" and the complete body of the message was plain text reading "Hi Rich, Sorry to tell you your grandfather passed yesterday at 5 PM. "
    – sootsnoot
    Aug 14, 2021 at 17:00
  • 1
    Oh well; sorry to hear it. Both that the suggestion didn't help and the message it didn't help with. Aug 15, 2021 at 15:56
  • Actually, the message was a test message attempt to ensure that the message itself could not possibly be interpreted as spam. The first awesome godaddy agent suggested that a test message not mention testing receipt as that could cause the netsol folks to claim that's why it was rejected. So this is what I came up with. However, a tragic death was involved, in that what brought the problem to light was my sending 80 email invitations to a memorial service for my best friend who died at the age of 67 of CLL leukemia. She was the most wonderful person I have ever known.
    – sootsnoot
    Aug 15, 2021 at 16:33
  • 1
    Too young! I'm sorry to hear it. Aug 15, 2021 at 16:38

1 Answer 1

0

Well, the 4th netsol supervisor I talked to actually had some understanding of the problem, and cleared up the biggest mystery: He pointed out to me today that their 553 response itself contains a 3rd IP address: 198.71.225.36. And that that address is the one being complained about, and it is in fact blacklisted if you check at the url contained in the message. All this time I hadn't noticed that address as relevant (or even an address, could have been section numbers like 5.3.0 or something). The 1.2.3.4 was the IP address for the server identified by the MX entry in the zone file for the sending domain, so I assumed it was the one that must have been blacklisted! I haven't yet gotten an explanation for the 'bounce="false"' parameter, or which server generated it.

So I called godaddy support, and they confirmed the netsol blacklisting of their IP address, and submitted a delisting request.

What remains a little unclear is exactly where the 'bounce="false"' parameter came from (which server), and what it means. The netsol supervisor reluctantly admitted that they should have sent a bounce to the sender address, and was "sure" that they would have done that, so perhaps godaddy is blocking the bounce. When I pointed out that I get bounces from other servers just fine, only have the problem with netsol, he was a little less sure.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .