As of right now…
DNS resolution is flaky… Some times i get an answer, sometimes I see a SERVERFAIL reply
i can not receive e-mail. (they bounce back…)
I am however to use the page, and send e-mail to an external server
I have a VPS, running CentOS 5.4
I left the default hostname that was given to it from the provider
I was given 3 ip addresses when i bought the VPS
I picked one of my domains… and set the glue records and created a host for each of the addresses
I then took those 3 fqdn and used them for all of my other domains at the registrar
For some of my domains i take the mx record within virtualmin and change it to point to the GMail servers. Others i leave alone and let my server host the e-mail
For the longest time i thought that the problem was simply with my dns server not responding(slow?) to queries on the mx record, Now i believe there is a configuration error on my part.
I have recently tried to send (web)mail on the server itself to another account on a different domain, Both to an account where the mx record points to google and where the e-mail is on the same server… I can send e-mail to another domain completely, but i can not send e-mail to any domain that is on that server, regardless of where the mx record points.
Gmail will bounce an e-mail back with the following reply
Connection was dropped by remote host (SENT_RCPT)
I cant get the DNS resolution to fail right now… but sometimes i simply see a SERVERFAIL message…
…
Not sure if this is the same problem, or just one really screwed up installation, with many issues… I simply don’t know where to go right now.
I ran a dns check on the domains in question through introDNS
no failure… couple warnings as follows
SOA MNAME entry WARNING: SOA MNAME (*The original host-name as generated by my host*) is not listed as a primary nameserver at your parent nameserver!
Im not sure about this.. why would it matter...
SOA Serial Your SOA serial number is: 1280284406. This can be ok if you know what you are doing.
this is confusing to me.. is it because its high.. or is there another problem?
One place you might start is to browse to intodns.com, and input one of your domains there. It would run a DNS report, and tell you if it sees anything awry.
Effects where name resolution sometimes works and sometimes not are often caused by “flaky” domain entries at the NIC… Like one NS entry pointing to the correct (your) host and a secondary one is not (as in pointing to a completely incorrect server, or a server that does not really host your zone).
To evaluate this further, I’d need to know the concrete domain names in question, and what they are supposed to point to, so that I can do some checks.
all assigned to different ip addresses on the server at the registrar for spydercomputing.com
idoshows.ca is the dns in question that has the mx records pointing to Google. but e-mail bounces back sometimes randomly… so even if my postfix config is screwed… e-mail should work if my dns is working(Right??)… or could postfix still get in the way of that e-mail too?
I changed the SOA from the vendor assigned hostname to dns1.spydercomputing.com … intoDNS seems to like it better. It tells me everything else is okay.
I realize i really should get a second dns server to replicate, instead of having everything point to the same box. I just want to get this working first.
DNS resolution looks good, all the responsible nameservers point to 173.201.26.143 as MX for “spydercomputing.com”.
I then did a “manual” email delivery test via telnet to port 25. It happenes like the reports say: After the RCPT TO command, your Postfix simply drops the connection.
You should check /var/log/mail.log for errors. The reason is quite surely noted there.
I also did not get what you were trying to say with this “idoshows.ca” and it “pointing to Google”? How does that relate to the “spydercomputing” issue?
Dec 4 17:50:26 ip-173-201-26-143 postfix/smtpd[18292]: connect from blu0-omc3-s27.blu0.hotmail.com[65.55.116.102]
Dec 4 17:50:26 ip-173-201-26-143 postfix/smtpd[18292]: fatal: 127.0.0.1:: missing service information
Dec 4 17:50:27 ip-173-201-26-143 postfix/master[10031]: warning: process /usr/libexec/postfix/smtpd pid 18292 exit status 1
Dec 4 17:50:27 ip-173-201-26-143 postfix/master[10031]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling
I point the mx records for idoshows to gmail… but the e-mails still bounce back… unlikely that gmail is down … i assume its my dns…
spydercomputing e-mail is hosted on this same virtualmin server… so i have 2 diferent domains, both with similar issues, but with 2 different e-mail solutions… led me to believe its a DNS issue…
How exactly do mails to idoshows bounce back? What’s the error message? Its MX records look good and point to Google, your Postfix issue should not be the reason there.
Dec 4 17:50:26 ip-173-201-26-143 postfix/smtpd[18292]: fatal: 127.0.0.1:: missing service information
This looks like the culprit there. My first guess it that it might have to do with Greylisting, which is implemented as a policy daemon - getting called through Postfix’ smtpd_recipient_restrictions by connecting to it on 127.0.0.1. Maybe the port number is missing there.
Do you have Greylisting active? Does it work when you turn it off? Before you do that, does your /etc/postfix/main.cf contain a line like this?
i don’t have an example of a bounced e-mail send to Gmail. it always works for me because my Gmail accounts are linked and just go to the correct box without leaving google… I have not been “lucky” enough to bounce one when i try on my own… i just know it happens from talking to people in person… I’ll try to dig up a copy from somebody else.
Maybe its just my server not responding when they query the mx record… shrugs
[root@ip-173-201-26-143 log]# grep smtpd_recipient_restrictions /etc/postfix/main.cf
# through Postfix. See the smtpd_recipient_restrictions parameter
# relay mail to. See the smtpd_recipient_restrictions description in
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:127.0.0.1:
… from the web interface
Greylist is a technique to reduce spam by initially rejecting email the first time another mail server tries to contact your server. Real mail servers will re-try after a short delay, but those operated by spammers typically will not. Thus legitimate email still gets delivered, but spam does not.
Greylisting is not currently fully enabled on your system. Click this button to have Virtualmin configure
Yes, obviously the port number in your smtpd_recipient_restriction directive is missing. You can add it, according to the line I sent you, or turn greylisting off and on again. That should re-create the correct line too.
(And I must note here that I’m somewhat proud of myself that I had the right idea there right away. )
And yes, if your nameserver does not respond when someone tries to send a mail to that Google-based domain, that would sure be a reason for failure, even if Google itself is up.