Feb 8

Zimbra alias domains vs. individual aliases

Category: Zimbra

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.

Spam Activity Graph

1 Comment so far

  1. Juls July 7th, 2008 12:39 pm

    Sounds useful - could you post your “simple script” ?

Leave a comment

You must be logged in to post a comment.