Mailing List Archive

ldap fields
Hi all, and esp Aaron,

I'm trying to test/debug the authldap layer, but I'm not exactly clear
as to how all the fields are supposed to operate.

Could you Aaron please document the fields as allowed in the dbmail.conf
file.

I'm all clear on these:

"BIND_DN"
"BIND_PW"
"BASE_DN"
"PORT"
"HOSTNAME"
"OBJECTCLASS"
"FIELD_UID"
"FIELD_CID"
"FIELD_QUOTA"
"FIELD_PASSWD"

but how exactly are the following fields supposed to work/interact or
map to authsql:

"FIELD_MAIL"
"FIELD_MAILALT"
"FIELD_NID"
"MAILALTPREFIX"
"FIELD_FORWARD"
"FIELD_FWDSAVE"
"FIELD_FWDTARGET"
"FWDTARGETPREFIX"
"FIELD_MEMBERS"

I would much appreciate some enlightenment regarding this issue.

thanks,


--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
Re: ldap fields [ In reply to ]
Hey,

Long story short, I no longer maintain an Active Directory user base, and I
don't have my configs around to double check my memory. So I'll do my best...
and if we get descriptive enough, let's make this thread part of the
documentation project, LDAP could really use a help text!

I'm pretty sure that there are Exchange2k-ism's that need to be worked out --
in particular, I'd like to be a near drop-in replacement for qmail-ldap and to
function with inetOrgPerson and posixPerson accounts. Let me know if you have
any trouble getting things to work!

More inline...

Paul J Stevens <paul@nfg.nl> said:

>
> Hi all, and esp Aaron,
>
> I'm trying to test/debug the authldap layer, but I'm not exactly clear
> as to how all the fields are supposed to operate.
>
> Could you Aaron please document the fields as allowed in the dbmail.conf
> file.
>
> I'm all clear on these:
Ok, I'll try giving a brief explanation anyways, for future posterity and
those who might be new to LDAP and not recognize as many key words yet.
>
> "BIND_DN"
This is the Distinguished Name of the user who has read access to the LDAP
server. It is not recommended to use an Administrator or Manager account, as a
precaution in case the mail server is compromised.

> "BIND_PW"
The plain text password of the account above. Again, preferably not an
Administrator or Manager account.

> "BASE_DN"
The root or starting point from which searches will be conducted. All searches
use the LDAP_SCOPE_SUBTREE option to search everything in this base and below.

> "PORT"
The port number that the LDAP server is listerning on. By default, 389 for
insecure and 636 for secure, however secure LDAP is currently unsupported.

> "HOSTNAME"
The hostname of the LDAP server. May be an IP address.

> "OBJECTCLASS"
The object class to use as a search filter, typically 'user', 'inetOrgPerson'
or possibly something else in more complex LDAP environments.

> "FIELD_UID"
The field which contains the user login name of the user. Required.

> "FIELD_CID"
The field which contains the group id number of the user. Not required.

> "FIELD_QUOTA"
The field which contains the quota, in bytes, of the user. Not required.

> "FIELD_PASSWD"
The field which contains the password of the user. Not implemented.

>
> but how exactly are the following fields supposed to work/interact or
> map to authsql:
>
> "FIELD_MAIL"
The field which contains the primary email address of the user. Required.

> "FIELD_MAILALT"
The field which contains an alternate email address of the user. Not required.

> "FIELD_NID"
The field which contains the user id number of the user. Required.

> "MAILALTPREFIX"
A prefix which may appear on the MAILALT entry and should be ignored. MS
Exchange 2000 uses the prefix 'smtp:'. Not required.

> "FIELD_FORWARD"
The boolean field which indicates if email should be forwarded or not.

> "FIELD_FWDSAVE"
The boolean field which indicates if email should also be delivered locally if
it is forwarded.

> "FIELD_FWDTARGET"
The field which contains a destination email address for forwarding mail.

> "FWDTARGETPREFIX"
A prefix which may appear on the FWDTARGET entry.

> "FIELD_MEMBERS"
The field containing a list of DN's to users in the email distribution group.

>
> I would much appreciate some enlightenment regarding this issue.
>
> thanks,
>
>
> --
> ________________________________________________________________
> Paul Stevens paul@nfg.nl
> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
> The Netherlands_______________________________________www.nfg.nl
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--
Re: ldap fields [ In reply to ]
Thanks a lot Aaron. From your description and the authldap.c code I
think I can work out a test-bed installation and a dbmail.schema file.


Aaron Stone wrote:
> Hey,
>
> Long story short, I no longer maintain an Active Directory user base, and I
> don't have my configs around to double check my memory. So I'll do my best...
> and if we get descriptive enough, let's make this thread part of the
> documentation project, LDAP could really use a help text!
>
> I'm pretty sure that there are Exchange2k-ism's that need to be worked out --
> in particular, I'd like to be a near drop-in replacement for qmail-ldap and to
> function with inetOrgPerson and posixPerson accounts. Let me know if you have
> any trouble getting things to work!
>
> More inline...
>
> Paul J Stevens <paul@nfg.nl> said:
>
>
>>Hi all, and esp Aaron,
>>
>>I'm trying to test/debug the authldap layer, but I'm not exactly clear
>>as to how all the fields are supposed to operate.
>>
>>Could you Aaron please document the fields as allowed in the dbmail.conf
>>file.
>>
>>I'm all clear on these:
>
> Ok, I'll try giving a brief explanation anyways, for future posterity and
> those who might be new to LDAP and not recognize as many key words yet.
>
>>"BIND_DN"
>
> This is the Distinguished Name of the user who has read access to the LDAP
> server. It is not recommended to use an Administrator or Manager account, as a
> precaution in case the mail server is compromised.
>
>
>>"BIND_PW"
>
> The plain text password of the account above. Again, preferably not an
> Administrator or Manager account.
>
>
>>"BASE_DN"
>
> The root or starting point from which searches will be conducted. All searches
> use the LDAP_SCOPE_SUBTREE option to search everything in this base and below.
>
>
>>"PORT"
>
> The port number that the LDAP server is listerning on. By default, 389 for
> insecure and 636 for secure, however secure LDAP is currently unsupported.
>
>
>>"HOSTNAME"
>
> The hostname of the LDAP server. May be an IP address.
>
>
>>"OBJECTCLASS"
>
> The object class to use as a search filter, typically 'user', 'inetOrgPerson'
> or possibly something else in more complex LDAP environments.
>
>
>>"FIELD_UID"
>
> The field which contains the user login name of the user. Required.
>
>
>>"FIELD_CID"
>
> The field which contains the group id number of the user. Not required.
>
>
>>"FIELD_QUOTA"
>
> The field which contains the quota, in bytes, of the user. Not required.
>
>
>>"FIELD_PASSWD"
>
> The field which contains the password of the user. Not implemented.
>
>
>>but how exactly are the following fields supposed to work/interact or
>>map to authsql:
>>
>>"FIELD_MAIL"
>
> The field which contains the primary email address of the user. Required.
>
>
>>"FIELD_MAILALT"
>
> The field which contains an alternate email address of the user. Not required.
>
>
>>"FIELD_NID"
>
> The field which contains the user id number of the user. Required.
>
>
>>"MAILALTPREFIX"
>
> A prefix which may appear on the MAILALT entry and should be ignored. MS
> Exchange 2000 uses the prefix 'smtp:'. Not required.
>
>
>>"FIELD_FORWARD"
>
> The boolean field which indicates if email should be forwarded or not.
>
>
>>"FIELD_FWDSAVE"
>
> The boolean field which indicates if email should also be delivered locally if
> it is forwarded.
>
>
>>"FIELD_FWDTARGET"
>
> The field which contains a destination email address for forwarding mail.
>
>
>>"FWDTARGETPREFIX"
>
> A prefix which may appear on the FWDTARGET entry.
>
>
>>"FIELD_MEMBERS"
>
> The field containing a list of DN's to users in the email distribution group.
>
>
>>I would much appreciate some enlightenment regarding this issue.
>>
>>thanks,
>>
>>
>>--
>> ________________________________________________________________
>> Paul Stevens paul@nfg.nl
>> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
>> The Netherlands_______________________________________www.nfg.nl
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>
>
>
>

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl
Re: ldap fields [ In reply to ]
Would dbmail.schema be a help document, or a schema that can be loaded into
OpenLDAP. I'm all for a help text, but I am leery of having our own schema.
I really want to be based on existing standard object classes. The only thing
I can think of that we might need a custom schema for is group quotas...

Aaron


Paul J Stevens <paul@nfg.nl> said:

> Thanks a lot Aaron. From your description and the authldap.c code I
> think I can work out a test-bed installation and a dbmail.schema file.
>
>
> Aaron Stone wrote:
> > Hey,
> >
> > Long story short, I no longer maintain an Active Directory user base, and I
> > don't have my configs around to double check my memory. So I'll do my best...
> > and if we get descriptive enough, let's make this thread part of the
> > documentation project, LDAP could really use a help text!
> >
> > I'm pretty sure that there are Exchange2k-ism's that need to be worked out --
> > in particular, I'd like to be a near drop-in replacement for qmail-ldap and to
> > function with inetOrgPerson and posixPerson accounts. Let me know if you have
> > any trouble getting things to work!
> >
> > More inline...
> >
> > Paul J Stevens <paul@nfg.nl> said:
> >
> >
> >>Hi all, and esp Aaron,
> >>
> >>I'm trying to test/debug the authldap layer, but I'm not exactly clear
> >>as to how all the fields are supposed to operate.
> >>
> >>Could you Aaron please document the fields as allowed in the dbmail.conf
> >>file.
> >>
> >>I'm all clear on these:
> >
> > Ok, I'll try giving a brief explanation anyways, for future posterity and
> > those who might be new to LDAP and not recognize as many key words yet.
> >
> >>"BIND_DN"
> >
> > This is the Distinguished Name of the user who has read access to the LDAP
> > server. It is not recommended to use an Administrator or Manager account, as a
> > precaution in case the mail server is compromised.
> >
> >
> >>"BIND_PW"
> >
> > The plain text password of the account above. Again, preferably not an
> > Administrator or Manager account.
> >
> >
> >>"BASE_DN"
> >
> > The root or starting point from which searches will be conducted. All searches
> > use the LDAP_SCOPE_SUBTREE option to search everything in this base and below.
> >
> >
> >>"PORT"
> >
> > The port number that the LDAP server is listerning on. By default, 389 for
> > insecure and 636 for secure, however secure LDAP is currently unsupported.
> >
> >
> >>"HOSTNAME"
> >
> > The hostname of the LDAP server. May be an IP address.
> >
> >
> >>"OBJECTCLASS"
> >
> > The object class to use as a search filter, typically 'user', 'inetOrgPerson'
> > or possibly something else in more complex LDAP environments.
> >
> >
> >>"FIELD_UID"
> >
> > The field which contains the user login name of the user. Required.
> >
> >
> >>"FIELD_CID"
> >
> > The field which contains the group id number of the user. Not required.
> >
> >
> >>"FIELD_QUOTA"
> >
> > The field which contains the quota, in bytes, of the user. Not required.
> >
> >
> >>"FIELD_PASSWD"
> >
> > The field which contains the password of the user. Not implemented.
> >
> >
> >>but how exactly are the following fields supposed to work/interact or
> >>map to authsql:
> >>
> >>"FIELD_MAIL"
> >
> > The field which contains the primary email address of the user. Required.
> >
> >
> >>"FIELD_MAILALT"
> >
> > The field which contains an alternate email address of the user. Not required.
> >
> >
> >>"FIELD_NID"
> >
> > The field which contains the user id number of the user. Required.
> >
> >
> >>"MAILALTPREFIX"
> >
> > A prefix which may appear on the MAILALT entry and should be ignored. MS
> > Exchange 2000 uses the prefix 'smtp:'. Not required.
> >
> >
> >>"FIELD_FORWARD"
> >
> > The boolean field which indicates if email should be forwarded or not.
> >
> >
> >>"FIELD_FWDSAVE"
> >
> > The boolean field which indicates if email should also be delivered locally if
> > it is forwarded.
> >
> >
> >>"FIELD_FWDTARGET"
> >
> > The field which contains a destination email address for forwarding mail.
> >
> >
> >>"FWDTARGETPREFIX"
> >
> > A prefix which may appear on the FWDTARGET entry.
> >
> >
> >>"FIELD_MEMBERS"
> >
> > The field containing a list of DN's to users in the email distribution group.
> >
> >
> >>I would much appreciate some enlightenment regarding this issue.
> >>
> >>thanks,
> >>
> >>
> >>--
> >> ________________________________________________________________
> >> Paul Stevens paul@nfg.nl
> >> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
> >> The Netherlands_______________________________________www.nfg.nl
> >>
> >>_______________________________________________
> >>Dbmail-dev mailing list
> >>Dbmail-dev@dbmail.org
> >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>
> >
> >
> >
> >
>
> --
> ________________________________________________________________
> Paul Stevens mailto:paul@nfg.nl
> NET FACILITIES GROUP PGP: finger paul@nfg.nl
> The Netherlands________________________________http://www.nfg.nl
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--
Re: ldap fields [ In reply to ]
Aaron Stone wrote:
> Would dbmail.schema be a help document, or a schema that can be loaded into
> OpenLDAP. I'm all for a help text, but I am leery of having our own schema.
> I really want to be based on existing standard object classes. The only thing
> I can think of that we might need a custom schema for is group quotas...

For testing purposes I've adapted a custom schema file based off of the
qmail schema file. I don't see any real objection to having our own OID
space and designing a custom ldap-schema. I want to be able to tell
users of the debian packages: 'use this schema file, use this config
setup, and you're ready to rock-n-roll'.

Of course, example setups using other, existing schemas will also be
useful and necesary, but if dbmail has it's own OID space all that would
be required to integrate with existing ldap implementations would be to
change some settings in dbmail.conf. Correct me if I'm wrong though.

I'd be happy to know of any existing schema that will serve dbmail's
purposes. Apparently you have one :-).


>
> Aaron
>
>
> Paul J Stevens <paul@nfg.nl> said:
>
>
>>Thanks a lot Aaron. From your description and the authldap.c code I
>>think I can work out a test-bed installation and a dbmail.schema file.
>>
>>
>>Aaron Stone wrote:
>>
>>>Hey,
>>>
>>>Long story short, I no longer maintain an Active Directory user base, and I
>>>don't have my configs around to double check my memory. So I'll do my best...
>>>and if we get descriptive enough, let's make this thread part of the
>>>documentation project, LDAP could really use a help text!
>>>
>>>I'm pretty sure that there are Exchange2k-ism's that need to be worked out --
>>>in particular, I'd like to be a near drop-in replacement for qmail-ldap and to
>>>function with inetOrgPerson and posixPerson accounts. Let me know if you have
>>>any trouble getting things to work!
>>>
>>>More inline...
>>>
>>>Paul J Stevens <paul@nfg.nl> said:
>>>
>>>
>>>
>>>>Hi all, and esp Aaron,
>>>>
>>>>I'm trying to test/debug the authldap layer, but I'm not exactly clear
>>>>as to how all the fields are supposed to operate.
>>>>
>>>>Could you Aaron please document the fields as allowed in the dbmail.conf
>>>>file.
>>>>
>>>>I'm all clear on these:
>>>
>>>Ok, I'll try giving a brief explanation anyways, for future posterity and
>>>those who might be new to LDAP and not recognize as many key words yet.
>>>
>>>
>>>>"BIND_DN"
>>>
>>>This is the Distinguished Name of the user who has read access to the LDAP
>>>server. It is not recommended to use an Administrator or Manager account, as a
>>>precaution in case the mail server is compromised.
>>>
>>>
>>>
>>>>"BIND_PW"
>>>
>>>The plain text password of the account above. Again, preferably not an
>>>Administrator or Manager account.
>>>
>>>
>>>
>>>>"BASE_DN"
>>>
>>>The root or starting point from which searches will be conducted. All searches
>>>use the LDAP_SCOPE_SUBTREE option to search everything in this base and below.
>>>
>>>
>>>
>>>>"PORT"
>>>
>>>The port number that the LDAP server is listerning on. By default, 389 for
>>>insecure and 636 for secure, however secure LDAP is currently unsupported.
>>>
>>>
>>>
>>>>"HOSTNAME"
>>>
>>>The hostname of the LDAP server. May be an IP address.
>>>
>>>
>>>
>>>>"OBJECTCLASS"
>>>
>>>The object class to use as a search filter, typically 'user', 'inetOrgPerson'
>>>or possibly something else in more complex LDAP environments.
>>>
>>>
>>>
>>>>"FIELD_UID"
>>>
>>>The field which contains the user login name of the user. Required.
>>>
>>>
>>>
>>>>"FIELD_CID"
>>>
>>>The field which contains the group id number of the user. Not required.
>>>
>>>
>>>
>>>>"FIELD_QUOTA"
>>>
>>>The field which contains the quota, in bytes, of the user. Not required.
>>>
>>>
>>>
>>>>"FIELD_PASSWD"
>>>
>>>The field which contains the password of the user. Not implemented.
>>>
>>>
>>>
>>>>but how exactly are the following fields supposed to work/interact or
>>>>map to authsql:
>>>>
>>>>"FIELD_MAIL"
>>>
>>>The field which contains the primary email address of the user. Required.
>>>
>>>
>>>
>>>>"FIELD_MAILALT"
>>>
>>>The field which contains an alternate email address of the user. Not required.
>>>
>>>
>>>
>>>>"FIELD_NID"
>>>
>>>The field which contains the user id number of the user. Required.
>>>
>>>
>>>
>>>>"MAILALTPREFIX"
>>>
>>>A prefix which may appear on the MAILALT entry and should be ignored. MS
>>>Exchange 2000 uses the prefix 'smtp:'. Not required.
>>>
>>>
>>>
>>>>"FIELD_FORWARD"
>>>
>>>The boolean field which indicates if email should be forwarded or not.
>>>
>>>
>>>
>>>>"FIELD_FWDSAVE"
>>>
>>>The boolean field which indicates if email should also be delivered locally if
>>>it is forwarded.
>>>
>>>
>>>
>>>>"FIELD_FWDTARGET"
>>>
>>>The field which contains a destination email address for forwarding mail.
>>>
>>>
>>>
>>>>"FWDTARGETPREFIX"
>>>
>>>A prefix which may appear on the FWDTARGET entry.
>>>
>>>
>>>
>>>>"FIELD_MEMBERS"
>>>
>>>The field containing a list of DN's to users in the email distribution group.
>>>
>>>
>>>
>>>>I would much appreciate some enlightenment regarding this issue.
>>>>
>>>>thanks,
>>>>
>>>>
>>>>--
>>>> ________________________________________________________________
>>>> Paul Stevens paul@nfg.nl
>>>> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
>>>> The Netherlands_______________________________________www.nfg.nl
>>>>
>>>>_______________________________________________
>>>>Dbmail-dev mailing list
>>>>Dbmail-dev@dbmail.org
>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>
>>>
>>>
>>>
>>>
>>--
>> ________________________________________________________________
>> Paul Stevens mailto:paul@nfg.nl
>> NET FACILITIES GROUP PGP: finger paul@nfg.nl
>> The Netherlands________________________________http://www.nfg.nl
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>
>
>
>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
Re: ldap fields [ In reply to ]
You know, thinking about it more, I think you're right. I've registered two
OID's before, so I know the process. But if you know the ropes and want to
take care of doing it, please do!

I can see that the dbmail-ldap-howto is going to be very segmented, basically
explaining how to use three or four different schemas, get them set up
correctly, and how to manage them.

The schema that I've used was from Windows 2000 with Exchange 2000, with user
id support provided by AD4UNIX. Day to day user management was done with an
LDAP user manager module I wrote for TWIG.

There are certainly other valid schemas out there, and while I'm still tempted
to say that we should prefer something that's already an open standard (such
as inetOrgPerson or some derivative of it), writing our own will certainly
make it easier for users who just want to slap a schema into the ldap and go.

Aaron

TWIG (spiffy new website!):
http://informationgateway.org

AD4UNIX (apparently moved to sourceforge):
http://sourceforge.net/project/showfiles.php?group_id=84224


Paul J Stevens <paul@nfg.nl> said:

>
>
> Aaron Stone wrote:
> > Would dbmail.schema be a help document, or a schema that can be loaded
> > into OpenLDAP. I'm all for a help text, but I am leery of having our own
> > schema.
> > I really want to be based on existing standard object classes. The only
> > thing I can think of that we might need a custom schema for is group
> > quotas...
>
> For testing purposes I've adapted a custom schema file based off of the
> qmail schema file. I don't see any real objection to having our own OID
> space and designing a custom ldap-schema. I want to be able to tell
> users of the debian packages: 'use this schema file, use this config
> setup, and you're ready to rock-n-roll'.
>
> Of course, example setups using other, existing schemas will also be
> useful and necesary, but if dbmail has it's own OID space all that would
> be required to integrate with existing ldap implementations would be to
> change some settings in dbmail.conf. Correct me if I'm wrong though.
>
> I'd be happy to know of any existing schema that will serve dbmail's
> purposes. Apparently you have one :-).
>
>
> >
> > Aaron
> >
> >
> > Paul J Stevens <paul@nfg.nl> said:
> >
> >
> >>Thanks a lot Aaron. From your description and the authldap.c code I
> >>think I can work out a test-bed installation and a dbmail.schema file.
> >>
> >>
> >>Aaron Stone wrote:
> >>
> >>>Hey,
> >>>
> >>>Long story short, I no longer maintain an Active Directory user base, and I
> >>>don't have my configs around to double check my memory. So I'll do my best...
> >>>and if we get descriptive enough, let's make this thread part of the
> >>>documentation project, LDAP could really use a help text!
> >>>
> >>>I'm pretty sure that there are Exchange2k-ism's that need to be worked out --
> >>>in particular, I'd like to be a near drop-in replacement for qmail-ldap
and to
> >>>function with inetOrgPerson and posixPerson accounts. Let me know if you have
> >>>any trouble getting things to work!
> >>>
> >>>More inline...
> >>>
> >>>Paul J Stevens <paul@nfg.nl> said:
> >>>
> >>>
> >>>
> >>>>Hi all, and esp Aaron,
> >>>>
> >>>>I'm trying to test/debug the authldap layer, but I'm not exactly clear
> >>>>as to how all the fields are supposed to operate.
> >>>>
> >>>>Could you Aaron please document the fields as allowed in the dbmail.conf
> >>>>file.
> >>>>
> >>>>I'm all clear on these:
> >>>
> >>>Ok, I'll try giving a brief explanation anyways, for future posterity and
> >>>those who might be new to LDAP and not recognize as many key words yet.
> >>>
> >>>
> >>>>"BIND_DN"
> >>>
> >>>This is the Distinguished Name of the user who has read access to the LDAP
> >>>server. It is not recommended to use an Administrator or Manager account,
as a
> >>>precaution in case the mail server is compromised.
> >>>
> >>>
> >>>
> >>>>"BIND_PW"
> >>>
> >>>The plain text password of the account above. Again, preferably not an
> >>>Administrator or Manager account.
> >>>
> >>>
> >>>
> >>>>"BASE_DN"
> >>>
> >>>The root or starting point from which searches will be conducted. All
searches
> >>>use the LDAP_SCOPE_SUBTREE option to search everything in this base and
below.
> >>>
> >>>
> >>>
> >>>>"PORT"
> >>>
> >>>The port number that the LDAP server is listerning on. By default, 389 for
> >>>insecure and 636 for secure, however secure LDAP is currently unsupported.
> >>>
> >>>
> >>>
> >>>>"HOSTNAME"
> >>>
> >>>The hostname of the LDAP server. May be an IP address.
> >>>
> >>>
> >>>
> >>>>"OBJECTCLASS"
> >>>
> >>>The object class to use as a search filter, typically 'user', 'inetOrgPerson'
> >>>or possibly something else in more complex LDAP environments.
> >>>
> >>>
> >>>
> >>>>"FIELD_UID"
> >>>
> >>>The field which contains the user login name of the user. Required.
> >>>
> >>>
> >>>
> >>>>"FIELD_CID"
> >>>
> >>>The field which contains the group id number of the user. Not required.
> >>>
> >>>
> >>>
> >>>>"FIELD_QUOTA"
> >>>
> >>>The field which contains the quota, in bytes, of the user. Not required.
> >>>
> >>>
> >>>
> >>>>"FIELD_PASSWD"
> >>>
> >>>The field which contains the password of the user. Not implemented.
> >>>
> >>>
> >>>
> >>>>but how exactly are the following fields supposed to work/interact or
> >>>>map to authsql:
> >>>>
> >>>>"FIELD_MAIL"
> >>>
> >>>The field which contains the primary email address of the user. Required.
> >>>
> >>>
> >>>
> >>>>"FIELD_MAILALT"
> >>>
> >>>The field which contains an alternate email address of the user. Not
required.
> >>>
> >>>
> >>>
> >>>>"FIELD_NID"
> >>>
> >>>The field which contains the user id number of the user. Required.
> >>>
> >>>
> >>>
> >>>>"MAILALTPREFIX"
> >>>
> >>>A prefix which may appear on the MAILALT entry and should be ignored. MS
> >>>Exchange 2000 uses the prefix 'smtp:'. Not required.
> >>>
> >>>
> >>>
> >>>>"FIELD_FORWARD"
> >>>
> >>>The boolean field which indicates if email should be forwarded or not.
> >>>
> >>>
> >>>
> >>>>"FIELD_FWDSAVE"
> >>>
> >>>The boolean field which indicates if email should also be delivered
locally if
> >>>it is forwarded.
> >>>
> >>>
> >>>
> >>>>"FIELD_FWDTARGET"
> >>>
> >>>The field which contains a destination email address for forwarding mail.
> >>>
> >>>
> >>>
> >>>>"FWDTARGETPREFIX"
> >>>
> >>>A prefix which may appear on the FWDTARGET entry.
> >>>
> >>>
> >>>
> >>>>"FIELD_MEMBERS"
> >>>
> >>>The field containing a list of DN's to users in the email distribution group.
> >>>
> >>>
> >>>
> >>>>I would much appreciate some enlightenment regarding this issue.
> >>>>
> >>>>thanks,
> >>>>
> >>>>
> >>>>--
> >>>> ________________________________________________________________
> >>>> Paul Stevens paul@nfg.nl
> >>>> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
> >>>> The Netherlands_______________________________________www.nfg.nl
> >>>>
> >>>>_______________________________________________
> >>>>Dbmail-dev mailing list
> >>>>Dbmail-dev@dbmail.org
> >>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >> ________________________________________________________________
> >> Paul Stevens mailto:paul@nfg.nl
> >> NET FACILITIES GROUP PGP: finger paul@nfg.nl
> >> The Netherlands________________________________http://www.nfg.nl
> >>
> >>_______________________________________________
> >>Dbmail-dev mailing list
> >>Dbmail-dev@dbmail.org
> >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >>
> >
> >
> >
> >
>
> --
> ________________________________________________________________
> Paul Stevens paul@nfg.nl
> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
> The Netherlands_______________________________________www.nfg.nl
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--