Thursday, January 04, 2007

SNTT - Integrating a Barracuda Spam Firewall with Domino LDAP

Spam is a never ending battle. A few years ago I purchased a Barracuda Networks Spam Firewall 300 to help reduce my headaches and the load on my Domino servers. It is hands down the best $1900 I have spent and I have been nothing but thrilled with it. On the average day we reject over 85% of all inbound SMTP traffic with virtually no false positives.

As you can see, the number of "bad recipients" is significant. Here's what happens during the delivery process:
  • Barracuda checks its own rules and filters to see if the message is spam
  • If it's not spam, it tries to deliver to Domino and waits for an OK response.
  • Domino checks the recipient to make sure it's valid (I have this setting enabled). If it is, the Barracuda takes the response and updates the log to show the message was delivered.
  • If the recipient isn't valid, the Barracuda shows the document as not delivered and flags it as a bad recipient. Meanwhile, Domino generates its own delivery failure report, which it delivers to the sender. The Barracuda doesn't cache these bad recipients, it just passes them through.
On an average day this isn't a problem. However in mid-December we started getting about 500 e-mails an hour for randomly generated e-mail addresses. Domino handled the load fine, but it was generating about 400MB of log entries a day and causing our mail.boxes to backlog with delivery failure reports.

I had to stop this. Luckily the Barracuda has the option to do LDAP lookups to verify recipients exist before it even tries to deliver the messages. Getting the Barracuda to resolve all the possible incoming e-mail addresses my users have proved to be more challenging than I expected.

Step One: Enabling LDAP in Domino
Let me start by saying I am a mediocre Domino administrator. I find Domino Administrator overwhelming and difficult to use, and I honestly don't understand what a lot of it means. I usually leave it alone until something breaks, then I hit the Internet and methodically try solutions until something fixes my problem. Also, my knowledge of LDAP begins and ends with defining the acronym. I have a vague idea of what it does and why it's important, but it's never been anything I thought I would have a use for. Even with that crippling deficiency, enabling LDAP really isn't so bad.

The biggest trouble I had was finding the right Configuration document. The Domino Administrator help says to go to your default configuration document, but doesn't tell you which one that is. Since I only have LDAP running on my mail server I thought that's where I would go to enable it. Wrong-o. Here's the first thing that went wonky on me. When I open the Configurations view, this is what I get.

Notice the scrollbar on the right side of the view. If I scroll up ....

*Poof* I have more Configuration documents! Okay, maybe it's not magic (I can suspend my disbelief for a moment) and maybe some of you already knew about this. I don't understand why it's behaving like this, and I only discovered this when I accidentally hit the scroll wheel on my mouse and the other documents appeared, so color me clueless. The "default" Configuration document is the one listed as "* - [All Servers]". Once you find the Configuration document, click the Edit button and go to the LDAP tab.

What this does is maps fields on the Person document to the standard LDAP schema. I honestly have no clue what 99% of this stuff means or why it's relevant. I also don't know when/where/how/why all that stuff got put in there, but I just left it. I do know from extensive trial and error that at a minimum you need the cn, FullName, mail and shortname LDAP attributes. The only one I had to add was the FullName. The rest of the LDAP configuration is as follows.

We already had anonymous LDAP enabled for some network scanners to be able to e-mail files to users. While setting that up I learned that if you don't limit the number of LDAP entries that can be returned it takes a while for LDAP to run through the entire directory. I only have 200 users and I was getting timeout errors. I set the maximum entries to 15 and the errors went away. I didn't do any analysis, I just tried it and it worked. Your mileage may vary. Once you have these settings to your liking, click Save and Close.

If you didn't have LDAP already loaded, load it from the server console (load ldap). If it was already running, issue the command tell ldap reloadschema.

Step Two: Configuring the Barracuda
LDAP configuration is done from the Domains tab.

The important bits:
  • LDAP Server - your server's IP address
  • LDAP Port - 389 is the default
  • Exchange Accelerator/LDAP Verification - Set to Yes
  • Unify Email Aliases - Set to Yes, unless you have a reason not to. Everything I read on the Barracuda support forums said this should always be Yes, so I enabled it. Pittsburgh is still intact and mail is flowing, so I guess it didn't hurt anything.
  • Bind DN - Only required if you don't allow anonymous LDAP. If that's the case I'll assume you know what to put here.
  • Bind Password - Password for the above account.
  • LDAP Filter - This is the most important part and requires more discussion. See below.
  • Everything else - leave it at the default
The LDAP filter tells your Barracuda what LDAP fields to search and what constitutes a match. For example, if you used nothing but (|(mail=${recipient_email})), it would only look for an exact match on the incoming e-mail address. That is to say, if the InternetAddress field on the Person document does not contain the recipient e-mail address, this would not be a match and would be a "bad recipient".

And that's a bad, bad thing because... we have lots of people with e-mail aliases in the FullName field (which is labeled User name on the Person record). Mostly this is when someone gets married, wants their primary e-mail address to be their married name, but still needs to get e-mail with their previous address. The easy way to accommodate this is to change the primary internet address and copy the old one to the FullName field as an alias.

A "mail=" search won't match these aliases. Okay, so you might think you could match the incoming name against the ShortName field since you rename people using the standard AdminP process. Unfortunately the automatic rename process does not update the ShortName field. It could be part of your process to update it manually, but I haven't been doing that and didn't want to try to figure out which ones needed updating.

As you consider all the implications you might think you need to do a search against the FullName attribute. However, aliases entered in the FullName field are listed under the cn attribute. I don't understand why, but that's the way it works.

Taking all this into consideration, the LDAP filter on my production Barracuda is:


This searches for the internet address, any e-mail aliases, and the shortname as a final last-ditch attempt to get the message delivered. LDAP queries are always OR'ed, so if anything matches it will return a True, the message will be delivered, and life is good. But if none of those match, the Barracuda will take care of sending the delivery failure report. The Barracuda does not cache invalid LDAP recipients, but at least Domino isn't having to do the double duty of doing both the lookup and generating a NDR.

That's all there is to it. As simple as the filter is, it took me many hours of tinkering before I finally found the right combination that worked for me. I strongly recommend you do some tests using the Test LDAP feature in the Barracuda to make sure you are getting everything you expect.



  1. If the Barracuda is configured to send mail directly to a Domino server, email address verification can also be done by enabling the following option within Domino.

    "Verify that local domain recipients exist in the Domino Directory".

    This will check user names and other aliases in the Domino Directory.

    This option can be found in the Domino configuration: Router/SMTP > Restrictions and Controls > SMTP Inbound Control > Inbound Intended Recipients Controls

  2. Right, I have that turned on, and I was getting 400MB of errors logged every day and legitimate outbound mail was backlogged because I was getting spammed to death. I explained that in my post.

  3. Thanks for the info Charles. I have been meaning to set this up on my Cuda after the New Year. I worked with our firewall admin this morning and got it working. The only thing I had different from you was the LDAP filter, so I just copied yours. It seems to work like a champ!

  4. FYI, we were seeing the following messages on our console:

    [12170:00005-00000094] 01/08/2007 16:10:16 LDAP Server: You should full text index Domino directory names.nsf on HQMAIL01/COMPORIUM to improve search performance for filters like '( (mail=x)(cn=x)(shortname=x))'

    So, we enabled FTI and the LDAP lookup wasn't functioning well. Instead of seeing about 150 "Bad Recipients" logged each hour, we were seeing close to 1,000. After I deleted the FTI we are now back to preventing them from showing in our log.

    A few weeks ago I spoke with Cuda about our web UI performance and they told me they could see a 75MB attachment trying to be scanned that was causing some perf. issues and that we should enable LDAP since we have so many hits on "Bad Recipient". They said this should help our performance.

    So after enabling it last week, we have seen a little better performance on the Web interface.

  5. Charles - this is a kick a** post! Thanks for sharing.

  6. Very helpful, exactly what I needed to get ours working.

  7. BTW, regarding "LDAP Search Base", the Domino LDAP server does not serve up defaultNamingContext - it's an Active Directory root DSE attribute! When querying Domino's root DSE you will however get the namingContext attribute back with an empty string, indicating the root of the naming tree (since we tend to use flatnames for groups). If Barracuda is only looking for Person object and they live underneath O=YourCompany, use it for your "LDAP Search Base".

  8. To make sure I'm clear, are you saying I should be using namingContext as my LDAP Search Base? It works like this, so I'm a little confused as to why I need to change it.

  9. First, let me say this is a great post for help installing a Barracuda for filtering Lotus Domino mail - I've found links to this page from more than one source now in my search for help. Thanks Charles! Now to biz - regarding the "LDAP" search base, I believe what 'google' said was to populate the LDAP Search Base with o=YourCompanyNameHere. I couldn't get it to recognize any names until I used that format for my search base.

    I hope I can use this useful post to get some useful feedback with a problem I'm having getting Barracuda to recognize any of our group names. Currently, I am using the above forementioned search base with your (Charles) LDAP filter which works great for everything but our groups. I get this error returned when I click the 'test ldap' button:

    LDAP still fails on a group with the following error:
    could not set open file limit to 8192: Operation not permitted
    lookup order: fb
    listening on localhost/44918
    LDAP search filter for (|(
    LDAP requested attributes for objectClass, uid, mail
    expanded LDAP search base DN for o=mydomain

    Any feedback is much appreciated, and you can email me directly at

    Gracias ahead of time from Sunny San Diego!

  10. Kaginken, I'll respond to your hotmail account to make sure you get this, but I'll also respond here in the interest of keeping the thread complete.

    I'm not sure what you mean by "populate the LDAP Search Base with o=YourCompanyNameHere". As I said, my knowledge of LDAP begins and ends with defining the acronym. All I did was the exact steps I outlined here.

    I also cannot get groups with Internet names to resolve. I'm going to dig into that and see if I can determine why.

  11. I cannot get the Barracuda and Domino to see hierarchical names that appear in the user name area in a person document, i.e. John_Doe/ It will see

    What LDAP field corresponds to the User Name field in the person document? Any ideas how to fix this...I've tried and tried and can't get this resolved.

  12. You want to make sure your LDAP Search Base is set to ($defaultnamingcontext} and you have mapped the FullName field in the Domino LDAP attributes.

  13. Charles,

    I clicked on your name and see you're in Charleston. I'm located in Mt. Pleasant.

    Everything sure looks right. I verified the LDAP search base and I'm looking at the Barracuda and LDAP on Domino. On the latter I see the LDAP Attribute Type FullName mapped to the Domino Field Fullname.

  14. Richard,

    I'm surprised you're so close. I only know of two Domino shops in the metro area other than the one I just left. Shoot me an e-mail and we'll do lunch sometime. :-)

    I don't use hierarchical names, so I'm not sure what else might be needed. I do know that aliases in the FullName field are reported through the cn LDAP attribute. Have you verified that attribute is mapped, too? Other than that I'm out of ideas.

  15. Thanks Charles, this the BEST posting, and it actually WORKS thanks again charles

  16. You're welcome, Ralph. I'm glad you found it useful. :-)