Fresh Install - Cant Send Mail?

[BigBirdy]

Did a fresh install of ZMC on a CentOS 5.x x64 machine. The FQDM is (fake) server.domain.com but I get mail to users@domain.com so on the install I set the domain name to domain.com. I left all other settings primarily at default to ensure everything worked before dealing with my gateway. However, I cant seem to send email from the web interface logged in as the admin user? But if I go to a shell, tail /var/log/maillog and run "mail -s 'test' admin@domain.com", or even "mail -s 'test' user@anotherdomain.com" it works fine? Just not from the web interface. It just times out, gives an error, nothing in /var/log/zimbra.log etc? Now I also have a gateway server and another internal SMTP server which does not require authentication but even if I put in any of these into the "Relay MTA for external delivery" field with a port, or leave it empty, or even use localhost and port, sending mail times out with no message other than "The server is slow to respond....". Any suggestions?

[phoenix]

I remember having mentioned to you in an earlier thread about setting up a Split DNS if you're behind a NAT router, are you and did you? If you did then search the forums for details of what's needed to check the DNS (plus hosts & rsolv.conf files) are correct, post the results in this thread.

[BigBirdy]

Thanks kindly (again) and yes I did then go ahead and create a new Bind zone for the server with MX records that point back to it and this solved the mail problem (sending from the admin account) but now I have a new one! I just posted it as a new issue but I cant login to any of the new accounts I create? This never happened on any of the previous installs and so its strange that it is happening now. No matter what I use as a password when creating the account, or going back in and changing the password, I cant login to the user gui? No errors or anything in /var/log/zimbra.log either. I can login to the user gui with the admin account just fine.

I did just notice these errors in zimbra.log though?

Sep 17 13:41:17 vmserver postfix/postfix-script[12587]: warning: not owned by root: /opt/zimbra/data/postfix/spool
Sep 17 13:41:17 vmserver postfix/postfix-script[12596]: warning: not owned by root: /opt/zimbra/postfix-2.6.2.2z/conf/main.cf
Sep 17 13:41:17 vmserver postfix/postfix-script[12597]: warning: not owned by root: /opt/zimbra/postfix-2.6.2.2z/conf/master.cf
Sep 17 13:41:17 vmserver postfix/postfix-script[12598]: warning: not owned by root: /opt/zimbra/postfix-2.6.2.2z/conf/master.cf.in
Sep 17 13:41:17 vmserver postfix/postfix-script[12601]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/unix.smtp-amavis
Sep 17 13:41:17 vmserver postfix/postfix-script[12602]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/unix.lmtp
Sep 17 13:41:17 vmserver postfix/postfix-script[12603]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/inet.127.0.0.1:10025
Sep 17 13:41:17 vmserver postfix/postfix-script[12604]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/unix.showq
Sep 17 13:41:17 vmserver postfix/postfix-script[12605]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/unix.smtp
Sep 17 13:41:17 vmserver postfix/postfix-script[12606]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/master.pid
Sep 17 13:41:17 vmserver postfix/postfix-script[12608]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/inet.smtp
Sep 17 13:41:17 vmserver postfix/postfix-script[12609]: warning: not owned by postfix: /opt/zimbra/data/postfix/./spool/pid/unix.cleanup

[phoenix]

Let's start with the basic information. How much RAM is on this server? If it's a VM how much RAM is allocated to the VM? Post the output of the following (run on the zimbra server):

cat /etc/hosts
cat /etc/resolv.conf
dig yourdomain.com mx
dig yourdomain.com any
host `hostname`  <-- use that exact command with backticks not single quotes

[BigBirdy]

Might have been related to cached content as I have been experimenting with some proxies. After a reboot, for some reason, I could then login and all seems fine now. Clearly the main point I have learned here is the importance of ensuring mx records point back to the server, and properly functioning dns.