Remote Server rejecting mail

[Shane3673]

I have this problem when sending to one domain only. We get a bounce back:

[email protected]
SMTP error from remote mail server after RCPT
TO:<[email protected]>:
host mx2c1.maildomain.com [69.49.xxx.xxx]:
550 5.7.1 <[email protected]>... Relaying denied:
You must check for new mail before sending mail.

I understand what this would mean it I was using a mail client and my server rejected the message because I do force authentication for outgoing mail, but this is mail leaving my server and going to a different server. Then the remote server rejects it. I have seen other people write this on the forum, but have seen no replies. Does anyone know why it is doing this or if there is a way to fix it?

Also when I did an email trace it goes to 173.15.xx.xxx first which resolves to mail.domain.com and then goes to the other address, is it being redirected for some reason?

 

[vanessa]

The issue happens for me too when I try to send to that address. It would appear to be a problem with that person's mail server, not yours. Let them know about it.

The email is also not being redirected, as you can see, the hostname you referenced points to the same IP:

root@ocelot [~]# host mail.domain.com
mail.domain.com has address 173.15.xx.xxx


This is because you cannot point an MX (mail record) to an IP, only a hostname. So the MX goes to mail.domain.com, then mail.domain.com points to an IP.

 

[Shane3673]

Thank you for the reply. That is what I was thinking and usually I'm like the bounce back was from their server so it their issue, but my client is not in the position to ask someone about anything technical so I will have to call their domain. I will let you know how that goes because I'm guessing if it works fro me it will also work for you. I use Mikrotik routers for my firewalls instead of the Linux iptables as I am more familiar with that working for a WISP. I read something I didn't think would work, but tried it anyway talking about 587. I did a destination nat of 25 traffic going to these IPs to switch to 587 traffic. He hasn't got back to me since, but I'm pretty sure he gets of work about 30 mins after I put the rule in.

Just curious, you have a client in VA that communicates to a insurance company in IL?

BTW You look pretty good for a girl that I would expect to answer my back on this forum....Just saying

 

[Shane3673]

To the replier:
The domain that I just switched to my server that is having the issue used to be hosted by Frontier. I have seen this before when the other host has left over records. Is your account the same? I have contacted my client and asked him to let me know who their email provider is so I can give them a call.

 

[vanessa]

lmk if you need me to test again - I was getting the same error you were. This is probably not related to a firewall on either end - if I had to guess, it would be that the mail server accepting the email is responsible for relaying the email back to the user's actual mail server (similar to how spam filtering services work), but that something is missing in between. Their authentication from the relay server may be incorrect, or their local mail server isn't configured to allowed relayed mail. Without having access to their server, your guess is as good as mine.

Just curious, you have a client in VA that communicates to a insurance company in IL

It's possible, but not that I recall off the top of my head. I have a lot of clients

 

[Shane3673]

That is exactly what I was thinking, but I have taught myself all of this in the past year so it good to make sure once in a while. The reason why I tried the firewall rule is because I heard some bullsh** ( not sure is I can swear on this forum) that said that port 25 is consider unauthenticated mail and 587 is considered authenticated. Goes against everything I know about networking which is my strong point, figured I'd give it a shot.

Also, I hear you on that. I have about 15+ clients which is not that much, but I recently dropped InMotion because of network related issues that would not fix. Being a WISP we have our own IPs, our own network, so why not our own email and web servers. Don't worry about checking it now, but I might hold you to that after I talk to whoever it is that hosts these servers. It might benefit us both.

I do have a question about your client is you can figure it out is:
If they were hosted by any party related to Frontier Internet because I have seen error like it when I transferred a domain from a ISP that is close to us. They still had the domain on their server so it was thinking that the server was client and wanted it to authenticate like a mail client.

 

[vanessa]

I think you might be confusing this - when you send mail from your own server, you would typically use port 25, 587, or 465. Other ports are configurable but these are the most common, and all are authenticated unless configured as an open relay (meaning, you don't need a username and password to send mail from them). Port 587 is usually a TLS port, and port 465 is usually SSL. This is only relevant to you, as the sender, in how you configure mail to be sent from your own server. Regardless of how you send email out, your mail server is always going to communicate with the remote mail server (aka, the person you are currently having trouble emailing) on port 25 unless you specifically configured it to do something else. The problem is that the mail server on the remote side (mail.belvideremutualinsurance.com) has some sort of mail setup that is causing mail to be rejected, seemingly due to a bad relay provider. Nothing you do on your end will resolve this problem.

While I don't make it a point to talk about IMH on these forums, I will add that last October we went through major network upgrades to resolve a number of issues. Put simply, we all go through growing pains, and networks as large as ours take a lot of time and patience to plan and execute changes against. I'm not sure what issues you're referring to specifically, but I'll be happy to discuss this off the public forums if you need more information.

The clients I was referring to were for TCA though, not IMH.

 

[Shane3673]

You are confirming my first thoughts on all of this. Like I said I'm learning the email server and linux thing as a go, but network traffic I am very good at. I just thought I would give it a try. If you remember my first thought on this was bulls*** ( someone please let me know if I can saw bull**** on this forum). In other talk I would not mind getting a few tips from you "off the public forums". I have a lot of unorthodox things that I do with my servers and have mostly figured out things for myself from this point, but as someone who googles linux commands could always use a little help. PM me if that is apart of this site and I'll give you my personal email. The only people that have replied to my threads are CPanel workers and they have been helpful, but only with supported issues. I actually do alot of no supported things. I have 2 servers, in which use the same IP addresses. They are completely mirrored and use rsync to sync email. This way if one goes down I can use OSPF routing protocol (my specialty is networks) to switch instead of DNS. Its a 1 minute switch vs 24-48 DNS switch.

My thought is if the traffic was redirecting it would never show the first IP because that is how routing works. If you do a dst-nat it tricks the packet into thinking it is supposed to go to the other IP so it would never make it to the first one. Hence, the first one wouldn't even shoe up on the email trace.

Anyway, like you said nothing I do on my end will fix it, I will let you know if I can solve it by calling their provider. Hopefully I can fix both our clients problems by bit**ing (really I hope I can swear, it takes all the Ephesus away) at our problem's host. The weird thing is in my mind is, I believe when my client was hosted by his last provider he had no problems so they must have authenticated some way.

I also wanted to add I just noticed you worked for InMotion. I just wanted to say I didn't drop them cuz they were a bad host. It is just better to be in control of everything you work with: network, server, IPs, except for the fact that you have to deal with all the problems of course. I realize now how you have clients in IL, you have clients in every state.

 

[cPanelMichael]

Feel free to update this thread with the outcome once you receive a response from the remote mail server administrator.

Thank you.

 

[Shane3673]

I will. I having trouble getting a hold of them at the moment.

 

[Shane3673]

They got back to me and said the company is hosting an exchange server at their location and the email gets forwarded by a server hosted by their domain registrar, which is the server that is rejecting the email. He contacted them and they told him that they found a DNS issue and it would would fixed within 24 hours. Well see if they actually get it fixed or not. My guess is that this should also fix vanessa's client if it fixes mine.

 

[cPanelPeter]

Hello,

That's most likely the problem. Please update this post/thread with the outcome.

 

[Shane3673]

They made a change. Now it seems like they have no MX record at all so the error changed. Had to contact the guy again. Will update when new info.

 

[Shane3673]

Is it possible to create a MX record for a remote domain on my server. My server does not seem to be able to find a MX record for this domain anymore. Neither can a server hosted by InMotion that we still have an account on. I checked MX toolbox for email health and that seems to find one. Can I, on my server, tell it to send mail to this IP when it needs to go to this domain without having that domain on my server? The only options for creating DNS entries I can find are for accounts that are on my server. My other option, I was thinking about trying is putting the account on my server, it will not be in use of course because I don't own the domain name, but I could put in a MX record to trick my server into thinking it is a local domain, but pushes the email to a different location.

 

[Shane3673]

The second option didn't change anything, same error. They are now denying an issue on their end even though whatever they changed last week when trying to fix the first problem is obviously causing the new one.

 

[vanessa]

MX records direct inbound mail only. You can set up custom outbound routers in Exim, but that's unnecessarily complicated. Do this from your server:

dig +short $remotedomainname MX


Does anything come up?

- - - Updated - - -

For the record:

nessa@nessa-desktop:~$ dig +short belvideremutualinsurance.com MX
10 173.15.76.233.

If your server returns something different, the problem could be with your resolver. In which case, try this:

nessa@nessa-desktop:~$ dig @8.8.8.8 +short belvideremutualinsurance.com MX
10 173.15.76.233.

8.8.8.8 is a public nameserver.

 

[Shane3673]

allow_mx_ip_ip = yes this fixed the new issue they have so when they "fixed" the DNS issue they had before, they pointed the mx record directly to an IP address which is not the correct way. I have told them what they need to do to fix it for other people so hopefully they will listen.