Without using the control panel, how can prevent email from being delivered to a local domain?

I

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,114
Without using the control panel, how can prevent email from being delivered to a local domain? This is an old FreeBSD server that DirectAdmin doesn't work on anymore. One domain is no longer hosted on this server, but one other one is. If the one that still is sends and email, it is not delivered to the new host. E.G. it resolves locally no matter what I do.
 
A bit unclear.
IT_Architect said:
If the one that still is sends and email, it is not delivered to the new host. E.G. it resolves locally no matter what I do.
Click to expand...
If it's sending mail to itself, that seems logically. So I presume you mean it should be sending to the domain which is no longer hosted on the server? And then it resolves locally because probably there is something from that old domain still on the server, is that correct?
Otherwise you might need to be more specific, or work with examples.

I don't use FreeBSD, but seems to me if you remove the moved domain from the named directory (on Centos that would be /var/named) and from the named.conf and from the /etc/virtual/domains file, it should not resolve locally anymore.
Restart the name service too.

However, just to be sure... there are some FreeBSD users still on. Maybe @bdacus01 can point to the correct files/directory's.
 
Hello,

In order to disable local delivery of emails you should remove a domain from /etc/virtual/domains
This way you will disable the option "Use this server to handle my e-mails" for a domain on a Directadmin server.
 
Richard G said:
... seems to me if you remove the moved domain from the named directory (on Centos that would be /var/named) and from the named.conf and from the /etc/virtual/domains file, it should not resolve locally anymore. Restart the name service too.
Click to expand...
zEitEr said:
In order to disable local delivery of emails you should remove a domain from /etc/virtual/domains
This way you will disable the option "Use this server to handle my e-mails" for a domain on a Directadmin server.
Click to expand...
I will give these a try and let you know.

Thanks!
 
You don't need to remove the domain from DNS if you want to disable local email delivery only.
 
@zEitEr Correct. But he also said:
One domain is no longer hosted on this server,
Click to expand...
So why not remove it if it's not there anyway anymore and maybe prevent other future resolving issues for it too. But it's not required for mail indeed.
I also mentioned the /etc/virtual/domains file with it. So he should be fine in fact.
 
Richard G said:
...remove the moved domain from the named directory ... Restart the name service too.
Click to expand...
zEitEr said:
Who knows whether DNS is hosted there? Not me.
Click to expand...
This doesn't work for some reason. (This is between two busy businesses which is why I can't test things instantly.)

Instead of the sending customer on the old server not getting an error message, and assuming the other customer got it OK because it was delivered to his mailbox on the old server they used to both be on, the company on the old server now gets the error message: "Unroutable Address" when trying to send to the company that used to be on the same old server. If I go to the old server and do a: dig MX domain.com, it returns the correct MX name, mail.domain.com. If I do an NSLookup on the old server for mail.domain.com, it correctly returns the IP address for the MX record on the new server he moved to.

So in summary, even though the old server finds the new DNS and MX address for the recipient's domain that used to also be on the old server, it now throws the error: "Unroutable Address", even though nobody else has a problem sending him emails, only the company still on the old server that they used to be on together.
 
Richard G said:
Try this:
dig -t MX domain.com
Does that also return the correct value? If yes, then I don't know how it still can deliver to the old ip if it does not resolve there anymore.
Click to expand...
- Yes, it does return the correct MX name,
- and no, it no longer delivers to the old ip,
- but now throws an error to the sender on the old server, "Unroutable Address".
- When testing from a terminal window on the old server:
a. Using dig MX I get the correct MX record name for the new host (which is the same as it was on the old server.)
b. When I do a ping using the MX record name, it returns the correct address for the mail server on the new host.

Summary of testing from the old server: Making the changes modified the behavior from sending to the old mailbox, to returning an "Unroutable Address" error, even though when querying the DNS for that domain returns the correct current name for the new mail server, and pinging that name returns the correct IP for the new mail server. Yes, I did restart named, but apparently we are still missing a piece.
 
IT_Architect said:
"Unroutable Address" error
Click to expand...
That means that Exim does not understand what is happening. Seems it still is finding something about the old domain somewhere in DA
I presume you also restarted Exim already?

If nothing of the old domain needs to be run on the old server, maybe it's a good idea to remove it from other local files like maybe in the /usr/local/directadmin/data/users/accountname/domains.list and in the /domains directory in the same directory.

Or maybe @zEitEr has some idea as to what could create this odd behaviour.
 
Richard G said:
That means that Exim does not understand what is happening. Seems it still is finding something about the old domain somewhere in DA
I presume you also restarted Exim already?

If nothing of the old domain needs to be run on the old server, maybe it's a good idea to remove it from other local files like maybe in the /usr/local/directadmin/data/users/accountname/domains.list and in the /domains directory in the same directory.

Or maybe @zEitEr has some idea as to what could create this odd behaviour.
Click to expand...
I did restart Exim and Dovecot after it didn't work and before replying last time, but the customers have not retried it since.
 
Richard G said:
That means that Exim does not understand what is happening. Seems it still is finding something about the old domain somewhere in DA
I presume you also restarted Exim already?

If nothing of the old domain needs to be run on the old server, maybe it's a good idea to remove it from other local files like maybe in the /usr/local/directadmin/data/users/accountname/domains.list and in the /domains directory in the same directory.

Or maybe @zEitEr has some idea as to what could create this odd behaviour.
Click to expand...
After I learned that it didn't work, and before I posted the last time, I did think of that and restarted Exim, but the customers have not tried it since.

>If nothing of the old domain needs to be run on the old server, maybe it's a good idea...<
Nothing of the old domain needs to remain, so I could also do that too before they retry it.

Thanks!
 
I forgot one. Check your /etc/named.conf file (or whatever freebsd uses), probably it's still in there too.
Better then remove it (again, if no dns hosted for the domain on that server) from there too and restart named.
 
Richard G said:
I forgot one. Check your /etc/named.conf file (or whatever freebsd uses), probably it's still in there too.
Better then remove it (again, if no dns hosted for the domain on that server) from there too and restart named.
Click to expand...
It was in /var/named/etc/namedb/named.conf file, so I backed it up, made the change, and restarted named.
 
None of these ideas work. I'm not going to try anymore. For the one customer, they are going to have to Gmail the customer on the new server until they get off the old one.
 
Richard G said:
@zEitEr any conclusive idea's about this strange issue?
Click to expand...

It is not clear on how much old FreeBSD is that server having, and whether or not Exim setup is customized. Anyway I'd rather see all the related to the failed delivery lines from exim logs. It might give some clues.
 
You must log in or register to reply here.
Back
Top