I have a customer who hosts their email on Google. But if they send email through their web interface, the system wants to do local delivery because of the presence of their domain in /etc/postfix/local-host-names Is there a way in ISPconfig to prevent that domain from going into that file so that the emails get relayed over to Google?
How do you do that? I'm sure setting the domain and co-domain to an external mail server is very simple but can anyone explain how to do it? I have the same problem with sendmail not delivering mail to my Google Apps address and am new to configuring sendmail. Thanks!
For the web site's main domain (www.example.com) you can do that on the Options tab. For the Co-Domain (example.com without www) you must go to the Co-Domains tab, select the Co-Domain, and then go to the Options tab of the Co-Domain.
I have exactly this same problem but on newest ISP 3. Under Options tab I have: Added date, Added by, Linux user, Linux group, Logfiles retention time, Apache AllowOverride, Apache Directives. Nothing more. How configure this? The client has mail service on G Suite, MX records points to google MX's.
This problem does not exist in ISPConfig 3 as ISPConfig 3 has separate web and mail domains. If you have similar symptoms on an ISPConfig 3 server, then you must have accidently added that external domain under the email module as local mail domain, so all you have to do is to go to the email module and delete that domain there.
I explain what happens, because maybe I understood wrongly earlier posts. I have server with newest ISP panel. There is domain colonel.com.pl and dns zone for it. I set A record point to server but each MX points to google servers. I asked on Postfix group: They advise to me to disable accepting incoming e-mails for this domain. After some time of googling I reached this thread. Moreover I suppose that "disable accepting incoming e-mails for this domain" means just "disable local delivery for this domain". I tried to confirm this and then I have found thread on stackoverflow, where one guy said that server name should be removed from the line: Code: mydestination = server_name_fqdn, localhost, localhost.localdomain
Your server does not accept incoming emails for that domain if you did not add that domain as email domain, so there is nothing to be disabled unless you actively added the domain as email domain.
I think this same but I tried execute on virtual machine deployed on my personal computer in my job: Code: user@haha:~$ nc colonel.com.pl 25 220 s1.poliman.net ESMTP Postfix (Ubuntu) ^C Google says that here should be "refused to connect".
Your test is wrong. So the result is ok and does not indicate that the server accepts emails for that domain.
I used this link to do tests: https://toolbox.googleapps.com/apps/checkmx/ You can check it for colonel.com.pl. I am really confused, because logic says something another than powerful Google.
The test you made is a test for the DNS A-Record and not the MX record. The test from google is not correct as its oversimplified which leads to a wrong result. The test assumes wrongly that when it can reach an email server on the A-Record of a domain (the A-record is not responsible for email, it is used for e.g. the web server), then that this smtp server instance accepts emails for that domain. But your server does not accept emails for that domain and google did not test that. Beside that, google nowhere says that the result from its test mean that email is not working correctly, it just informs you that it found a program listening on port 25 on the web server of that domain. So instead of using test tools, simply start using the email for that domain at google, then you will see that it works.
Thank God that this test is wrong. What newbie would suppose? Yes, I normally use mails configured on G Suite in domain colonel.com.pl. What about this: Code: user@haha:~$ nc colonel.com.pl 25 220 s1.poliman.net ESMTP Postfix (Ubuntu) ^C and I will be 100% sure. In other words, how this result should be interpreted?
I explained that already above: The test you made is a test for the DNS A-Record and not the MX record. The test from google is not correct as its oversimplified which leads to a wrong result. The test assumes wrongly that when it can reach an email server on the A-Record of a domain (the A-record is not responsible for email, it is used for e.g. the web server), then that this smtp server instance accepts emails for that domain. But your server does not accept emails for that domain and google did not test that. Beside that, google nowhere says that the result from its test mean that email is not working correctly, it just informs you that it found a program listening on port 25 on the web server of that domain.
I think I understood what you said in your earlier post. I am curious that trying nc or telnet specific domain on port 25 is good. I suppose that yes, because MTA use 25 port to delivers mails. But I am from newbies group, so I can be wrong. That's all. PS Message from Postfix mailing list as answer on pasting result of executing command "nc colonel.com.pl 25": Funny. You are pro admin and pro developer, they also. I am beginner and I get two different answers. But I think you have right.
Both answers are correct, the guy at postfix mailing list just assumes a different setup that what I assume here. They assume that you don't want to be able to use any mail function for other domains on that server and that you don't run a full hosting system while I assume that you probably want to have a fully working ISPConfig server as you posted in the ISPConfig forum and just want to host that specific email at google while being able to use that server for other email domains locally. Beside that, it does not matter if you run an SMTP server on the a-record of that domain for hosting the email at google which I explained already twice.
