[Mimedefang] Maybe OT: using sendmail and Active Directory to reject invalid recipients

[David F. Skoll]

On Wed, 10 Dec 2003 brian at bluecoat93.org wrote:

> Apologies if this is off-topic, but hopefully someone here will find it
> useful.

I find it quite useful!  Thanks.

[...]

> INITIAL THOUGHTS:  use either LDAP or MIMEdefang's
> check_against_smtp_server() function to validate each recipient in
> real-time against Active Directory or Exchange.  The problem we ran
> into with this in testing is that it GREATLY increased the load on our
> Exchange and AD servers.  MIMEdefang opens up a brand new SMTP session
> for *each recipient* when validating against an SMTP server.  Thus, for
> a spam message with 100 recipients, Exchange now had to handle 101
> SMTP sessions instead of only 1.

But not all at the same time -- they are serialized.

> This wasn't ideal for us.  Likewise
> with querying Active Directory:an extra 100 queries per message.  We
> decided that real-time validation wasn't going to scale for our
> environment.

Is AD that slow?  I thought the whole point of LDAP was the "L" part:
"Lightweight".  Can't AD keep up with 5-10 queries/second?

I ran a quick test on my machine (P-II 400Mhz):

time for i in `seq 1 100` ; do ldapsearch -x -D 'cn=Manager,dc=roaringpenguin,dc=com' -w foo '(mail=dfs at roaringpenguin.com)' > /dev/null; done

This is using OpenLDAP, and it did 100 queries in 4 seconds.  The test
is grossly inefficient, because we're also timing the invocation of
ldapsearch, the opening of a new LDAP connection, the query, and the
closing of the connection; a proper implementation would be much
faster.  AD must be awful indeed if it won't scale to this level.

Our CanIt product does several (sometimes tens) of SQL queries against
a PostgreSQL database per email; that is surely heavier than an LDAP
lookup, and reasonable hardware can handle upwards of 5-10 emails/second.

> http://www.packetslave.com/code/adexport.txt
> http://www.packetslave.com/code/genaccessdb.txt

Very nice; thanks!

Regards,

David.