Rather than viewing ldap as the world's ldap we have an obligation or lust to sync with, imagine that ldap is another storage container like sql and bdb and flat files. All of those are another pen to hold in our hand, then we need to start from where we are, take our equity with us, what ain't broke don't fix it, it's worth something if it works.
For example, where we come from is rcpthosts, a flat file. We could then take up the ldap pen and write "rcpthosts" flat file as ldap groupOfNames--translating our practical equity into the new frontier like carrying gold coins--
dn:o=q objectClass:top
dn:cn=rcpthosts,o=q cn:rcpthosts member:vdomain1.tld member:vdomain2.tld member:vdomain3.tld member:vdomain4.tld objectClass:groupOfNames objectClass:top
We could also continue to translate our equity by continuing the tradition of adding a "." to indicate that sub-domains are OK. That would be just the same--note the prefix "."--
member:.vdomain5.tld
Then to check rcpthosts for [EMAIL PROTECTED], our query would be
"cn=rcpthosts,o=q" "(member=\.vdomain5\.tld)" member
...one ldap call and we can base a decision, ldap already did the iteration loop internally.
We probably don't want a dn:rcptusers,o=q because a dn:dc=domain,dc=tld,cn=rcptusers,o=q would be a smaller list, faster search for ldap and rcpt's levenshtein edit-distance algorithm(decide to informatively deny or queue content to honeypot).
We don't want passwords in dc=domain,dc=tld,cn=rcptusers,o=q because we want accounts to give us passwords AND de-alias a [EMAIL PROTECTED] to uid/mailbox name.
dn: uid=u_dom_tld,o=q mail:[EMAIL PROTECTED] mail:[EMAIL PROTECTED] userPassword:secret objectClass:inetOrgPerson objectClass:posixAccount objectClass:top
my auth_ldap plugin-- "o=q" "([EMAIL PROTECTED])" userPassword "o=q" "([EMAIL PROTECTED])" userPassword saslauthd-- "o=q" "(uid=u_dom_tld)" userPassword
What to make the uid depends on what it takes to get dspamd to hand off to cyrus lmtpd. Changing the format of uid will not break my auth_ldap plugin. I need to work out uid format to do the queue to dspam to lmtpd.
-Bob
Elliot F wrote:
One problem is that if a configuration value has a space (or spaces) in it, it
breaks. This could be a problem for many people's LDAP configs, as many DNs
have spaces, and if/when I add the configurable filter (which could very likely
have spaces,) that would be a problem as well.
If we take the spaces out, as in "cn=word,dc=dom,dc=tld", or in ldif file,"attr:word", ldap handles that fine. It returns ldif dumps and search results with spaces, but does not need them to understand us either in ldif file or search query.
Some search methods require () around filters. I noticed that Net::LDAP handles a filter without (), possibly adding them internally. That is standard regex, saying "=~ s/base(this)/$1/", and () differentiates (filter) from base when base is not specified--base isn't required--() specifies it's the filter and not the base(which normally appears first).
dn in searches can be a dynamically configured filter. That's why you can't state the one and only base dn in a config file.
Actually, we could agree on our very own ldap syntax. Such as--
-Bob Dodds
