New install, outgoig mail fine but incoming and internal mail fail

[dspillett]

I have a new install of Zimbra (the OS edition) in a virtual machine for testing, and I'm having trouble with incoming and internal mail. Everything gets deferred with the status message of "connect to sub.domain.tld[public-ip-address]: connection refused".

Outgoing mail seems to work fine but even mail sent from one Zimbra user to another gets deferred with that error status.

The VM Zimbra is running on has the one interface with the address 192.168.220.2, gets external connections from one of the host machine's public addresses via iptables NAT rules, and sees the outside world via NAT (masquerade) also.

The ip address listed is the public IP, not the one the Zimba MTA is listening on, which I though may be the problem, but I can telnet from the Zimbra VM to that address on port 25 and I get the welcome message from postfix as expected (port 25, amongst others, is being forwarded to the VM's local address via iptables (NAT) rules).

Should it not be trying to connect to the local address (192.168.220.2), as that is what the server name is associated with in /etc/hosts? Though as I can connect via telnet to the external address on port 25, is there some other problem? Is it trying to transfer mail on a different port that I need to arrange a forward for? Should it be trying to connect to anything for internal mail transfers? I woudl have thought mail form user1@localdomain.tld to user1@localdomain.tld would be shuffled around the mail store without the need for a TCP connection.

Any pointers you can give for finding out what is wrong with my setup would be greatly appreciated.

[phoenix]

Originally Posted by dspillett

The ip address listed is the public IP, not the one the Zimba MTA is listening on, which I though may be the problem, but I can telnet from the Zimbra VM to that address on port 25 and I get the welcome message from postfix as expected (port 25, amongst others, is being forwarded to the VM's local address via iptables (NAT) rules).

You don't say which operating system Zimbra is running on, make sure that any firewall and/or SElinux are disabled.

You do have a local DNS server with A & MX records pointing to your Zimbra server don't you? If not then you'll need to set-up a split DNS for Zimbra to work correctly.

[dspillett]

Originally Posted by phoenix

You don't say which operating system Zimbra is running on, make sure that any firewall and/or SElinux are disabled.

You do have a local DNS server with A & MX records pointing to your Zimbra server don't you? If not then you'll need to set-up a split DNS for Zimbra to work correctly.

I've installed Zimbra on a very basic Ubuntu Dapper (LTS) install, though the kernel it is currently running is the current UML kernel from Debian/Etch (kernel version 2.6.18).

That sounds like it could be the problem. I had assumed that having a reference to the local address for the FQDN in /etc/hosts would override the value stored in public DNS records. Though I can connect using telnet, from inside the Zimbra host to the external address (even if I specify the external address directly - telnet does read the local address from /etc/hosts) to postfix - so it doesn't look to be the firewall on the host machine getting in the way. I'll have a play shortly.

One other detail I've discovered: the messages about the mail deferment are appearing in files under /opt/amavis whic I understand to be where the AV/AS filter lives. Could it be that this is somehow misconfigured rather than postfix/DNS?

[phoenix]

It will be lack of an internal DNS server that's causing the problems, postfix and other components use DNS lookups to find the server. The split DNS should fix these problems.

[dspillett]

Originally Posted by phoenix

It will be lack of an internal DNS server that's causing the problems, postfix and other components use DNS lookups to find the server. The split DNS should fix these problems.

It has done, thanks for the pointers.

One other (little) thing I ran into during the install, that might want adding to the wiki for people installing on very bare Linux installs: killall is required by the installer at one point (though its absence didn't stop anything working, there was an error message during the configuration process) and file is needed by the AV scanner or it will refuse to allow anything through. aptitude install psmisc file gets them both on Debian or Ubuntu.

[phoenix]

Originally Posted by dspillett

It has done, thanks for the pointers.

One other (little) thing I ran into during the install, that might want adding to the wiki for people installing on very bare Linux installs: killall is required by the installer at one point (though its absence didn't stop anything working, there was an error message during the configuration process) and file is needed by the AV scanner or it will refuse to allow anything through. aptitude install psmisc file gets them both on Debian or Ubuntu.

Which operating system is this? Could you file an entry in bugzilla for me, that would be the best place for it.