I'm trying to setup postfix in a VPC on AWS where an external server communicates with a postfix mail server in the same subnet.
I'm getting an error from postfix every time I try to connect to postfix from an external client. The error says:
warning: hostname example.com does not resolve to address 54.x.xxx.xxx
connect from unknown[54.x.xxx.xxx]
lost connection after CONNECT from unknown[54.x.xxx.xxx]
I'm suspecting this is related to the IP address that is being pointed to the hostname. When I run:
dig example.com
The 'answer' section outputs this:
;; ANSWER SECTION:
example.com. 60 IN A 10.0.1.132
I've looked at this link: http://www.postfix.org/LINUX_README.html
and I've tried editing /etc/host.conf and the /etc/postfix/main.cf file from that link and a bunch of other things from googling but nothing is working and I still get the same error mentioned above.
Is there a way to configure the VPC or the EC2 instance to point to my public IP address, or can I fix this problem trying to add some more configuration settings for postfix?
Related
I have a Wildfly 16 instance running on a test server. This instance can be reached successfully via the host name and the IP address of the server. In addition, there is a DNS entry for the server similar to test.mydomain.internal. The server does not respond to the DNS name (example url: http://test_instance.mydomain.internal:8080/test/). The connection is refused.
What do I have to set in the standalone.xml so that I can also get a connection via the DNS name?
-update-
The sample url has been adjusted to clarify the problem in the question .
I found the problem. It had nothing to do with the settings in the Wildfly. The DNS entry had underlines in the name. SOAPUI and two other programs had a problem with that.
We are currently encountering the following error when trying to connect to a Cloud SQL instance: Lost connection to MySQL server at 'reading initial communication packet', system error: 0.
This is a familiar error, and as detailed here usually means the IP address needs to be whitelisted. However, we believe we have done so.
Is there a way to see connection attempts and their IP addresses that have been made (and refused) to the Cloud SQL instance?
Currently we don't expose that information but it is something we would like fix. :-)
According to #Razvan, as of September 2014, this information isn't exposed.
We ended up using CIDR blocks to search the space and find the actual IP address. This is unsatisfying, obviously, but it's a way to pin down the problem.
If other people want to sanity check that the problem is their IP is being refused, you can add 0.0.0.0/0 in order to accept all ranges and try to connect. If it works, you know what is the problem.
Be absolutely sure to remove this as an accepted range, after you are done, however!
Figured I might help someone who stumbles here.
Had exactly the same issue essentially trying to connect to a GCP SQL instance from a hosting provider.
Whitelist the IP address that is shown in my cpanel and it will not connect. (It used to, but the provider made some changes with their infrastructure lately and it stopped working)
put 0.0.0.0/0 in my Cloud Platform whitelist and it connects no problem.
So now I know that my cpanel IP is not the IP trying to connect to GCP.
After some hair pulling (figured that the bare metal server had a different IP than my cpanel IP, it did, but this also didn't work.)
finally tried the IP address for the name servers that point to my domain and bam. All is good.
If you are facing this issue, try your name server (usually something like NS1.hostingprovider.com etc..). I put both the NS1 and NS2 ip's in the whitelist and we are working fine.
I have no trouble sending out email with my EC2 server, but how can I check the email that is sent to me? I have an elastic IP setup and modified reverse DNS records. Do I need to install Postfix to receive email?
Ensure that port 25 is active and open on your server. Install an SMTP service on your instance ...postfix is mighty fine.
Ensure you have also set up some MX records if you want to receive email from the world...
I suppose the first thing to do is testing if you can open a telnet connection to port 25 on your server. Then you know if anything is listening for incoming mail.
If not, then you should probably install postfix as well as test your firewall settings (I seem to recall the EC2 having some sort of firewall setting for which ports to allow in the web interface)
edit: correct port number
Check this error and please help me.
2009-07-24 15:58:34.209 LBS[2636] Host 'staging.common.virtualearth.net' not found using 'gethostbyname()' - perhaps the hostname is wrong or networking is not set up on your machine
2009-07-24 15:58:34.209 LBS[2636] Attempt to lookup host entry for bad IP address (staging.common.virtualearth.net)
NOTE: you should run 'diskperf -y' to enable the disk statistics
I am running the objC codes for hitting a webservice on GNU for Windows.
Why is this error?
The first line says it can't find the IP address off the DNS servers.
The second is some kind of fallback with an incredibly cryptic error. Looks like it's trying reverse DNS using hostname as the IP address (hence bad IP address) or ARP resolution using hostname as IP address.
Basically fix the DNS to that host and both will be solved.
I'm using exim on both the sending and relay hosts, the sending host seems to offer:
HELO foo_bar.example.com
Response:
501 Syntactically invalid HELO argument(s)
Possibly a problem with underscores in the hostname?
http://www.exim.org/lurker/message/20041124.113314.c44c83b2.en.html
Underscores aren't actually valid in internet host names, despite some people using them anyway. A sane DNS server should not allow you to have records for them.
Change your system's host name so it's valid, hopefully this will fix it.
After spending so many hours trying to fix this problem, which in my case just come up from nothing, I ended up with a solution. In my case, only the systems deployed to Suse OSs suddenly stopped sending emails but not those ( the same ) running on Ubuntu. After exhausting and eliminating all the suggested possibilities of this problem and even considering to change de OS of those machines, I found out that somehow the send email service is sensible to the hostname of the host machine. In the Ubuntu machines the file /etc/hosts have only the following line:
127.0.0.1 localhost
and so were the Suse machines, which stopped sending the emails. After editing the /etc/hosts from Suse machines to
127.0.0.1 localhost proplad
where proplad is the hostname of the machine, the errors were vanished. It seems that some security policy ( maybe from the smtp service ) uses the hostname information carried through the API, which was being ignored in the case of the Ubuntu machines, but not in the case of Suse machines. Hope this helps others, avoiding massive hours of research over the internet.
Diago's answer helped me solve the problem I have been trying to figure out.
Our Suse OS also stopped working out of nowhere. Tried every suggestion that I found here and on google. Nothing worked. Tried adding our domain to etc/hosts but that did not help.
Got the hostname of server with the hostname command. Added that hostname to the etc/hosts file just like Digao suggested.
127.0.0.1 localhost susetest
I saved the changes, then ran postfix stop, postfix start. And works like a charm now.
The argument to HELO should be a hostname or an IP address. foo_bar.example.com is neither an IP address nor a hostname (underscores are illegal in hostnames), so the error message is correct and there is nothing to fix.
Using qmail I came across this problem. I realised this was because of a previously unfinished installation.
1) When sending email qmail announces itself to other SMTP servers with "HELO ..." and then it adds what is in the file at: /var/qmail/control/me
(sometimes the file is located at /var/qmail/control/helohost)
2) This file should have a hostname with a valid DNS entry in.
Mine did not it had (none) which is why mails were failing to be sent.
I found that my local dev server suddenly stopped sending emails (using external SMTP) and on the server logs I found:
rejected EHLO from cpc96762-*******.net [..**.68]: syntactically invalid argument(s): 127.0.0.1:8888/app_dev.php
127.0.0.1:8888/app_dev.php is my local URL, I am using Docker, Symfony and Swift Mailer.
The only solution that helped in my case was adding the parameter:
local_domain = "localhost"
to my Swift Mailer configuration. That solved all the problems.
See the docs for the Swift Mailer local_domain option: https://symfony.com/doc/current/reference/configuration/swiftmailer.html#local-domain