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 188.8.131.52 is the IP address of the godaddy MTA, and 184.108.40.206 is the IP address of the netsol MTA.
20210812 09:29:10.177 core sid="id1" id="id1id2" ip="220.127.116.11" action="PERMERR" dstmta="18.104.22.168" age="61" code="553" reason="553 5.3.0 22.214.171.124 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="126.96.36.199" 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 188.8.131.52/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).