I had occasion today to need to do some “creative” email routing for one of my Zimbra servers. Charter Communications appears to have either blackhole-routed or simply firewalled traffic coming from a block of IP addresses that I recently acquired. I guess that the last person/company to use these addresses may have upset them in some way. As far as the public RBLs are concerned, the block is clean, but Charter doesn’t like it, and they haven’t been very responsive to my requests to have the block re-evaluated. So, in the meantime, I decided to route email from that server headed to charter.net through another MTA of mine on a different address block that was not having problems.

Figuring out how to set up a regular transport in Zimbra was interesting. Searching in Google didn’t turn up any dead ringers for my issue. Of course, I could have just gone into the Postfix configs directly and set up the transport maps, but what I really wanted was to be able to do it from inside of Zimbra itself. After poking around at Zimbra’s Postfix configs, along with contextual clues from some of the articles I looked at on Zimbra’s wiki and forums, I came up with the answer.

Zimbra stores just about all of its transient configurations in the Zimbra LDAP server, and if you look at Zimbra Postfix’s transport configuration, it indeed does look up all transport configuration, by default, in LDAP, so I wanted it stored there. You can specify the zimbraMailTransport attribute for any domain or account, and the value is the value that would appear in a Postfix transport map (ie smtp:mx.domain.com, etc). So I knew I wanted a domain that has the appropriate zimbraMailTransport attribute, but, by default, a Zimbra domain also means that Zimbra’s Postfix will try to deliver mail for the configured domain locally. A quick look at the Zimbra Postfix virtual_alias_domains and virtual_mailbox_domains configuration provides us with the answer. The LDAP filters for each of these table lookups looks for the zimbraDomainType attribute to be either local, for a virtual mailbox domain, or alias, for a virtual alias domain. Nowhere else in the Postfix configuration is the zimbraDomainType attribute referenced. So, the answer in that case was to set the value to something other than local or alias. I used simply “transport“.

So in the end, it turns out that setting up a transport in Zimbra for charter.net was actually a very simple process from the command line:

zmprov cd charter.net zimbraMailTransport smtp:other.MTA.server zimbraDomainType transport

Indeed, once I did that and requeued mail headed for charter.net, Zimbra dutifully passed off the mail to my other MTA, who I had set up to accept relayed mail from the Zimbra server, and that MTA passed the mail on successfully to Charter. Just another day in the life of a postmaster.