Andy,
I hear you, though I wouldn't necessarily dismiss DNS as an appropriate
solution. The beauty of DNS is that it is designed to handle simple
queries in very high volume, it caches lookups, it is simple to
distribute, and you can construct and maintain zones in easy to format
text files. LDAP is so much more than what this requires, and I fear
that it might involve more load, though that depends on the conditions
(number of addresses and volume to be checked). So maybe DNS is a
hammer to the nail, and LDAP is more of a sledgehammer in this
instance. Even if things were equal otherwise, the ease of use and my
familiarity with DNS would definitely make me favor this as the
solution of choice. Note that placing blacklist data in DNS isn't an
intended use, it just makes sense to do it that way. I see no
difference in storing Mail From's in DNS than from storing IP4R or
RHSBL data. Heck, I even have a full Mail From blacklist already in use
using Declude's %MAILFROMBL% variable.
If you already have everything in LDAP, it might be an entirely
different story. Exchange servers certainly benefit from the AD
integration in ORF, but as IMail admins that operate gateway services,
there is no single store of data, and I must collect it from all over
the place into a SQL database and then export it somewhere. Making a
zone out of this is cake. Exporting ORF configs out of this and
restarting services, etc. is pressing it, but the only option currently
available. If you only have IMail users, maybe the LDAP thing is more
appropriate for you, but you might need some help if there is an issue
with aliases, and I expect that there is in fact an issue.
Matt
Andy Schmidt wrote:
Message
Hi Matt:
I absolutely would like ORF to be able test for
valid Imail users and Aliases.
However, I'm not in favor of replacing the
"interface of choice" (LDAP) with one that was NOT intended for email
lookups (DNS) - just because we happen to be familiar with that one.
Having said that - I have NOT been able to set aside the time to
investigate how exactly to get LDAP working with Imail in multi-domain
environment and whether Imail's LDAP support DOES include aliases
(which would make it worthless).
So - I'm in the same boat as you (as far as LDAP
know-how). But, if I were to invest time/money, I would prefer
investing it into getting up to speed with LDAP rather than interfacing
it to DNS.
Best Regards
Andy Schmidt
Phone: +1 201 934-3414 x20
(Business)
Fax: +1 201 934-9206
Sandy,
Nick and I are in the same boat. Although we have found ways around
it, we much prefer to use a 'Mail >From BL' (LHS/RHS) type format
and maintain everything in DNS. You are good at LDAP stuff, I'm not
and I don't believe that Nick is either. I'm sure that it would work,
but it doesn't seem like a big time saver since both of us already have
experience with RBL generation, and would be maintaining these things
regardless, so it's better to combine. I would think that DNS would be
more efficient anyway, and with a 1 million address/day dictionary
attack on a single domain, a small number could make a huge
difference. This attack is more than 50 times worse than the standard
type that only does 10,000 to 20,000 a day on many of my domains. If
this spreads to other domains, it might be too much. The patterns look
much easier to block though as the IP's are consistently being reused.
Anyway, another piece of complexity that makes the ORF recipient
blacklist somewhat impractical is the growth in the number of addresses
listed. The interface is dog slow with 10,000 addresses in it due to
what I suspect is renumeration when you use it to save the config and
restart, though the service doesn't lag with simple restarts nearly so
much. I wonder about how efficient this might be compared to DNS
checks on 127.0.0.1.
It sounds like you haven't yet figured out how to integrate this type
of hook just yet. Please correct me if I am wrong. If that is the
case however, I am probably going to lobby VAMSoft for this as their
reception to my asking about this many months ago was fairly warm, but
they weren't working on new features at that time having just rolled
out a new version. Sounds like Nick might want to join me. They're
generally pretty receptive over there, but they are missing the big
picture when it comes to spam blocking having never escaped the plain
vanilla white/black scoring method.
Side note to Andy Schmidt and other ORF users...do you have any need
for this sort of thing?
Matt
Sanford Whiteman wrote:
I have orf doing that now but I have to enter the names into orf
Using ORF's "everything-but" recipient blacklist is really the long
way around, IMO (though I have suggested this feature, knowing people
wouldn't want to go further). The best-fit protocol for directory
lookups is, of course, LDAP. ORF's Active Directory lookup feature,
despite the vendor-specific name, can be run against OpenLDAP or any
other extensible directory. If extending the LDAP schema in OpenLDAP
doesn't scare you, that gives you a robust address-checking solution
that can talk directly to IMail mailbox servers. And, yes, it does use
a local cache of the LDAP data, so the mailbox server doesn't need to
be up for the MX to accept mail. (You could even use slurpd to
replicate data among multiple OpenLDAP servers, including one on the
MX itself, but that's a discussion for a later day.)
As far as a LHS.RHS kind of blacklist, I don't think ORF is there yet.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/
Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases!
http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/
http://www.mailmage.com/products/software/freeutils/ldap2aliases/download/release/
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
|
