4.0.8

[Corey_ironport]

Anyone using this in production yet? Thoughts?
Specifically, is anyone using the conversational LDAP yet? Thoughts?

[tminchin_ironport]

We have 4.0.8 - we are in the process of setting up to use the conversational LDAP stuff (which we really need as we're a two hop relay to get mail to Exchange and a quarter of our outgoing email is NDRs...)

[Erich_ironport]

We've started the 4.0.8 deployment on our secondary MX records w/ conversational LDAP accept and everything is going well (no issues). The plan is to complete the secondary MX tomorrow and update the IronPorts for out primary MX next week.

Erich

[jbaxter_ironport]

4.0.8 has been on our boxes for over a week with no issues. Conversational LDAP is turned on, and it is awesome - no more NDRs! Cuts down a lot of the traffic to the back-end server.

At one point during testing, we had it turned on for one of our MX but not the other, and it was funny to see the different error messages at Yahoo Mail for example - one time you'd get our NDR, the next time it would be their internal NDR... so much nicer to see when the mail is coming from *them* instead of *us*.

[tminchin_ironport]

Is it causing much load for your LDAP server? Our AD people were a little nervous about it - despite us not handling much email (say 8 million messages/month).

[jbaxter_ironport]

Nope, but then again, we have a real Directory server (Sun) not a Microsoft piece of...

Ahem. No, actually, just do some testing and make sure that your queries are nice and simple and that you have the right attributes indexed in your directory (I assume AD has something like indexes). The cache'ing on the IronPort is great, so the queries are really low-key. No impact that we've noticed..

[Erich_ironport]

No, significant load added to the AD global catalog server we are querying against, based on ~10 million messages per day. And yes AD does have indexes and the user attribute which includes smtp addresses is indexed by default.

[Corey_ironport]

I wondered about increase load at first, but then I got to thinking that wouldn't it stay the same? Before conversational LDAP, the IronPorts would attempt to hand the messages off to our Exchange bridgeheads, where an AD lookup occurrs. We're just moving the AD lookup further up the chain.

[tminchin_ironport]

well, if 60% of your email is being dropped by Brightmail, that's 60% of email which would not make it to the Exchange Bridgeheads for a lookup in AD.

Once you start doing LDAP on the border (before Brightmail kicks in) then the number of LDAP queries would increase by 60%. However, caching of the queries on the Ironport will reduce the impact - except for dictionary attacks.

Anyway, we're looking forward to reducing our NDR output (which should please people like Yahoo and Hotmail).

[Corey_ironport]

Excellent point. I hadn't though of that. I won't be telling my AD guys though. :wink:

[shannon.hagan]

If you already had your ironports doing ldap accept, ldap accept is done in the workqueue prior to hitting brightmail so whether it does it during the conversation level or in the work queue the same number of queries would be done.

If you weren't doing ldap acceptance already then yes you would see more queries to your ad. But depending on how busy your ad admins are, will they notice if you don't tell them?

[tminchin_ironport]

We never did LDAPACCEPT before (in the workqueue) as it didn't really give us the NDR reduction.

An aside - is anyone seeing any false positives on mailing lists which send out emails with a large number of recipients (in a single message) which invariably contain defunct addresses?

From reading into it, if a single message containing say 50 recipients and contains 10 dead recipients, then the message is error 4xx'ed. I guess it will encourage our correspondents to keep their mailing lists current...

[Erich_ironport]

I guess it will encourage our correspondents to keep their mailing lists current...

Or go to single recipient emails in place of emails with tons of recipients.

[tminchin_ironport]

the LDAP logging is rather minimal - in fact non-existent.

It would be nice if you actually logged when you rejected a message that failed an LDAP lookup (with the rest of the mail log).

Currently all you can do is do an LDAP debug - but then you have no easy way to match up a failure (or success) with an ICID or MID.

[shannon.hagan]

There is already a defect ID for it not logging the ldap rejects if ldap acceptance is done at the conversational level.