LDAPACCEPT question

[atucker_ironport]

Ok, here is the situation.
Ironport C30
Exchange 2000 on Windows 2000
My user has several email addresses defined in his AD account. For some reason the ironport will only accept mail to the primary email address. If somone sends email to one of the other email address defined in his account the ldap lookup does not find that address.

Any ideas?

-Adam

[Erich_ironport]

How odd, it works for us just fine with multiple smtp addresses.
Here is the query we use.

Query: (proxyaddresses=smtp:{a})

[mdial_ironport]

LDAPAccept works for us also with

Query: (proxyaddresses=smtp:{a})

Note that we are using Windows Exchange/AD 2003. I have no experience with 2000 as we recently converted from HP OpenMail.

Good luck, mdial

[atucker_ironport]

our statement is (|(mail={a})(proxyAddresses={a})).

Maybe that is the problem. I could have sworn this is what the manual said to use.

Thanks,
-Adam

[goldfish_ironport]

You should use this:

(|(mail={a})(proxyAddresses=smtp:{a}))

Note the "smtp" before the colon. I run SBS 2003 with Exchange2003, this query works just find.

Cheers,
Luk

[MikeK_ironport]

Is there a way to create a query for specific domains?

For example, I route email to some domains that I don't have LDAP info for. I would like to enable the LDAP accept on some domains, but allow the rest to pass through.

Ideas?

[goldfish_ironport]

For the moment, you'd be forced to use different listeners. So 1 public listener where the mail comes in for the domains that you have on LDAP and thus enable LDAP accept for. The other listener for the other domains. I believe we're looking at this in a future release, so we can support it on 1 listener. Hope this helps.

[MikeK_ironport]

That's what I was afraid of...

This makes this awesome new feature unavailable to us. I will be looking forward to this ability in future releases...

Thanks!

[ian_ironport]

I've set up a 2nd listener using same LAN port (2 different IP addresses on the same LAN port, both using TCP port 25). Have a public listener on each - one with LDAP accept , one without. Set the HAT/RAT to control which domains each listener accepts mail for. Set DNS MX records to match. No need for 2nd cable etc, just need 2nd IP address.

It would be useful to have a common HAT but not a big deal to export the HAT and then import it as the HAT for the new listener (actually its really easy!) but future changes may mean they get out of sync.

Seems to work OK. Asyncos 4.5.5-033, LDAP using MS Active Directory.

I've had a few sleepless nights as the new Overview page shows we block a lot of mail just on Senderbase and LDAP. But the users are not complaining that real mail is not getting through, which is good. Maybe Ironport can publish some anonymous data to show ranges of % mail blocked by Senderbase, LDAP, Brightmail etc - then I'd know if we were typical or above/below what we could expect...

[Erich_ironport]

We are still on 4.5.0 so I don't have much insight into the exact LDAP accept numbers, but we are using conversational LDAP accept.

Looking forward to the 4.5.5 details, but it will be Feb. time frame for us though (we have some big end of year & end of financial year moratoriums for production changes).

From everything I can put together SenderBase blocks about 70%+ percent for us (including the DNS verification).

Hope this helps. I'll post updates when I get the data from 4.5.5

[shannon.hagan]

One thing to keep in mind - in the 4.5.5 overview the number of messages stopped by reputation filtering is an estimate based on a hard coded multiplier. Depending on how your "spam" traffic looks the multiplier may or may not be appropriate in your environment.

From the Ironport Manual:
"Notes on Counting Messages in Mail Flow Monitor
The method Mail Flow Monitor uses to count incoming mail depends on the number of recipients per message. For example, an incoming message from example.com sent to three recipients would count as three messages coming from that sender.

Because messages blocked by reputation filtering do not actually enter the work queue, the
appliance does not have access to the list of recipients for an incoming message. In this case, a multiplier is used to estimate the number of recipients. This hard-coded multiplier was determined by IronPort Systems, Inc. and based upon research of a large sampling of existing
customer data.

[goldfish_ironport]

Yes, that's correct because you can't know how many messages are on a single connection, or how many recipients that message had since you never received the message... We've done exentive tests with ISP's to get the averages and as far as I've seen it's quit accurate.

One thing's for sure, atleast with 4.5.5 you're comparing the same things (messages), before you were comparing messages with connections and recipients, which is like comparing apples with oranges and pears.

Cheers
Luk