Zimbra behind firewalls
New year, new environment. I got laid off from my last employer, and they were kind enough to not whack my mailbox on the spot (2 1/2 years as network admin has to count for something, right?), and I've just now finally gotten built a sufficiently ballsy box to run Zimbra to move my mail to.
So I installed 6.0.8CE.
And, of course, because I'm not running DNS on *this* much smaller LAN, I got bitten by the LMTP/7025 problem mentioned here:
Incoming Mail Problems - Zimbra :: Wiki
It seems to me that this problem is one of an entire class of problems which are the result of the Zimbra architectural people not understanding, deep in their bones, that nearly *all* of their installs:
1) will be behind a firewall; normally a NAT firewall
2) will be done at a time when the public MX address won't necessarily yet point to the server, cause you need to *test* the server first, and
3) will be on a machine that only actually responds to the public IP of it's MX because of that NAT.
That is: the machine will next to *always* have a private LAN address, and that name won't resolve to the same thing inside and outside a network.
Because of this, lots of assumptions made by the installer and the system about equivalences between public and DNSable addresses, and the actual physical IPs of the boxen are invalid assumptions in this very common setup.
While the prescribed Split-DNS solutions *will* fix this problem, they're somewhat overcomplicated for really small sites, *and* they make it difficult to figure out what answers you're supposed to provide during install and some of config, as well.
I'm open to opinions that one or more of these assertions are either totally incorrect, or do not apply sufficiently widely for them to take notice of... but I think they do.
On this specific point, there ought to be a much easier and less breakable way to force the LMTP delivery point in the configuration. I haven't checked 'zilla yet; perhaps someone's already hung this bug...
And, as it happens, the IP alias idea doesn't *work*; I get this:
Aug 26 21:52:04 benjamin postfix/smtp: 583C24A02EC: to=<firstname.lastname@example.org>, relay=none, delay=0.04, delays=0.0
1/0/0.03/0, dsn=5.4.6, status=bounced (mail for benjamin.baylink.com loops back to myself)
Yup, that's basically the exact situation I am in. I am migrating to a box with no MX records yet, behind a firewall with a private IP block. I don't know why you'd expose it directly to the internet, it is going to be tricky to get this thing working. That or I'll just make it live and fix it in production (very bad idea)!
Well, it should have an MX & A record pointing to the server - it's a Postfix requirement that it's able to do an MX lookup to deliver the mail to the correct server IP and behind a NAT router (or firewall) that would be the LAN IP. It's a trivial matter to set-up a LAN DNS server on the Zimbra box or another server in your LAN.
Originally Posted by nosebreaker
It shouldn't be.
Originally Posted by nosebreaker
Hey, look. It's Enterprise blindness again!
Originally Posted by phoenix
Technically, maybe it is easy, and maybe it's not. But you're forgetting layers 8 and 9; many people may already *have* DNS running on the LAN, and they do not have administrative access to it.
It is only safe for Zimbra to make any assumptions at all about the network upon which it lives (let alone undocumented ones) *if you are willing to tell people "you may need to put Zimbra on its own subnet, if there are prerequisites you can't fulfill any other way -- and there may well be".
In the mean time, off I go to find a solution to this problem for myself, since I have those constraints, my Zbox being parked on someone else's LAN, on which I can't run a DNS server to suit myself.
And note: setting up DNS can be a day long job.
As it turns out, I was apparently doing the IP alias wrong; I've put it back on, and my "loops back to myself" problem went away, to be replaced with:
lay=none, delay=0.25, delays=0.01/0.24/0/0.01, dsn=4.4.1, status=deferred (delivery
temporarily suspended: connect to benjamin.baylink.com[18.104.22.168]:7025: Connecti
It would appear the LMTP server is listening on $LOCALIP, not on *, so the easy first solution from the wiki page doesn't actually work, unless I've missed something else.
[ UPDATE: apparently LMTP only binds to what it sees on startup; restarting the server after setting up the alias does appear to have worked. ]