One of the things I love about Zimbra as an administrator is the fact that it includes some decent graphing functionality in the administration interface. I can quickly see the health of my Zimbra servers and the affects of any configuration updates I’ve made.

Many companies and other organizations these days have multiple domains, and they want to be able to receive mail for the same addresses (local parts) at each domain. The standard way to handle this in Zimbra is to create an “Alias Domain”, or a domain with the zimbraDomainType set to “alias” and the zimbraMailCatchAllAddress and zimbraMailCatchAllForwardingAddress attributes set appropriately. Since Zimbra uses Postfix as its underlying MTA, this translates to setting:

@aliasdomain    @realdomain

in your virtual alias table. Herein lies the problem with doing that: using this sort of aliasing bypasses Postfix’s ability to properly check for valid addresses.

When Postfix, and hence Zimbra, begins receiving a message, in a normal configuration, it will check its final delivery tables (local, virtual, etc) to see if the recipient in question exists. If the recipient does exist, the message will be accepted. If the recipient doesn’t exist, Postfix will reject the message before queuing it. This is exactly what you want to happen when (not if) your server gets hit with a dictionary-style spam run. In this case, the sender is trying lots of addresses that don’t exist, so you want your mail server to reject them without processing them, since processing them likely includes sending them through your CPU-intensive spam and virus filtering systems. Postfix, however, only performs a one-level check to see if the recipient exists. By one level, I mean that Postfix only looks to see if any mailboxes or aliases exist without seeing what those aliases might result in. Because of this, Postfix will see that a catchall alias exists for a certain domain and decide that a match exists without seeing whether or not the target of that alias is valid, and, therefore, accepts the message for processing. This is actually correct behavior since its impossible to tell if an alias actually translates to a valid recipient in many cases, but it can have dire consequences for your mail server. It can even mean that your mail server can be blacklisted for sending out tons of non-deliverable reports for users who don’t exist, since many spam bots use invalid sender addresses as well.

To combat this problem on my Zimbra servers, I recently wrote a simple script that creates actual one-to-one aliases. One-to-one aliases, as opposed to catchall aliases, allow the Postfix server to reject messages for non-existant recipients since an alias won’t exist for that recipient. The script periodically runs through the Zimbra LDAP store and finds all addresses in the designated primary/real domain. It then checks for existing aliases in any domain that is “attached” (as opposed to aliased) to the primary domain. Any aliases that don’t exist get created, and any aliases that exist for addresses in the primary domain that no longer exist get deleted. Pretty simple in the end, but the results have been excellent. Below is a graph of the messages processed by the Zimbra Amavis (spam catching) process. Green represents the total number of messages processed, and blue represents the number of spam messages. As you can see, since the script was put in place four days ago, the amount of noise that is now being outright rejected and no longer processed due to this one seemingly simple change is pretty amazing.

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.