[These comments come from the initial 1998 implementation of the INN
and Sendmail LDAP enhancements.]


                 Sendmail Response To Unavailable LDAP


When the LDAP server is down, not accepting connections, not running, or
whatever, Sendmail will try to be "nice" about the situation. The following
are some examples of what Sendmail does when the LDAP server is unable to
service it.

When the LDAP server is not running/functioning (etc.), there will be a
mail log entry for MAIL500 directed mail similar to the following:

...................................................................
Jul 26 17:04:30 freebsd1 sendmail[479]: RAA00479:
from=<jimd@amiga2.jim.dutton>, size=567, class=0, pri=30567, nrcpts=1,
msgid=<Pine.NEB.3.96.980726170323.917A-100000@amiga2.jim.dutton>,
proto=ESMTP, relay=amiga2.jim.dutton [10.0.0.3]

Jul 26 17:04:30 freebsd1 mail500[482]: ldap_open failed

Jul 26 17:04:30 freebsd1 sendmail[481]: RAA00479:
to=<netnews.administrator@freebsd1.jim.dutton>, delay=00:00:00,
xdelay=00:00:00, mailer=mail500, relay=freebsd1.jim.dutton, stat=Deferred
...................................................................

If an LDAP entry cannot be found that corresponds to the userid in the
E-mail address handed off to MAIL500, a "return code" error message will
be logged in the mail log, and the piece of mail will be requeued.

...................................................................
Jul 26 17:12:50 freebsd1 mail500[499]: return 0x20 from X.500

Jul 26 17:12:50 freebsd1 sendmail[498]: QAA00392:
to=<netnews.admin@freebsd1.jim.dutton>, delay=00:51:56, xdelay=00:00:01,
mailer=mail500, relay=freebsd1.jim.dutton, stat=Deferred
...................................................................


                     Conclusions On Sendmail LDAP Use


Since there are two methods, internal and external, that Sendmail can use
to make use of an E-mail address in an LDAP entry, several choices are
available to the Sendmail Administrator:

1) Both methods require an installed LDAP server - an additional external
process to Sendmail itself, which may have security or resource load
implications.

2) Either method could be used in the place of the other; this sample
scenario used both, but the Sendmail rules could have been modified such
that both sample uses of LDAP could have been handled by the same method.

3) Using the "internal" method requires a Sendmail compiled with some
installed, compatible, version of the LDAP libraries; the "external" method
does not have the same requirement for Sendmail, but it does requires the
UMich/OpenLDAP distribution to be fully installed to make use of the
MAIL500 program.

4) The Sendmail rules used in the samples that selected the mail to be
handled via LDAP could possibly be moved to other Sendmail rules, but this
would affect when the moved rules would be utilized.

5) If LDAP is THE authority for ALL E-mail addresses,
then perhaps /etc/aliases entries won't be used for general users, and the
Sendmail process may wish to "move up" the LDAP subprocess to a "first
resolution" position rather than being used as a "last possible
resolution" placement given to the two samples.

6) While the external method may be simpler to implement, the internal
method may provide for more flexibility; once MAIL500 has done its LDAP
lookup, its major function is complete; the internal method could make use
of further Sendmail rule processing for whatever reason after
the LDAP lookup has been completed internally, perhaps even leading to
additional LDAP lookups, or address manipulation.

7) If the internal method is used as in the example where LDAP is used
to answer for a userid that does not exist on the Sendmail host, then
any format of a userid could be used so long as there is a
corresponding Common Name attribute in the LDAP database.

8) As delivered, the MAIL500 program strips periods and underscores from
the userid to form a normal DN. If, however, it is desired to use modified,
secondary, DN entries for special purposes (such as triggering MAIL500
delivery), then using the pattern in this particular scenario
("firstname.lastname") would normally be translated into a DN of "firstname
lastname". This is certainly OK and only requires one DN entry for a person.
However, if a DN entry that also used periods or underscores is desirable for
auditing, special function triggering, etc., then the MAIL500 program needs a
simple alteration: comment out or remove the lines 237-240 in MAIN.C which
check "argv[i][j]" for "." or "_". This will then allow userids with periods
or underscores to be passed to LDAP, intact. In this manner, the period
"trigger" could be used for one function or specific LDAP attribute, and the
underscore could be used for a different function or use a different LDAP
attribute, or not.


                       Caveats and Comments


This is a list of caveats encountered during the setup and testing of the
applications used.

1) Two compilation configuration options that were used for INN to
ensure some amount of host access identity security were:

  a) NNRP_GETHOSTBYADDR DO
  b) NNRP_AUTH_SENDER DO

The first forces DNS resolutions (lookups) for incoming host connections
(hence the infamous "connection refused" error due to invalid 'reverse
address lookups'). The second removes any included "Sender:" header records
if NNRPD knows that the "user" associated with the posting host
transmitting the news article, has not authenticated with the news server.

2) DNS+LDAP enabled (compiled) Sendmail requires its DNS to be up and
operational before it starts or it will not be able to use the "LDAP map"
(the LDAP hostname will be unresolvable).

3) Sendmail internal LDAP use does not provide for a Distinguished Name to
be supplied during the LDAP server connection, so the resulting LDAP
connection recorded in the LDAP server log may be difficult to identify by
itself (ie; "unknown" connection and a NULL bind). Note that "dogbreath"
has no LDAP entry - hence "nentries=0". For example, notice the "null"
BIND Distinguished Name from the following server log entry:

...................................................................
... connection from unknown (10.0.0.2) 
... BIND dn="" method=128 
... RESULT err=0 tag=97 nentries=0 
... SRCH base="o=LocalNet10,c=US" scope=2 filter="(cn=DOGBREATH)" 
... RESULT err=0 tag=101 nentries=0 
...................................................................

To help identify LDAP usage, it is recommended that each application
which uses LDAP provide some kind of non-null DN where they can.

4) Each queued item of mail which requires LDAP for addressing will
incur an LDAP lookup during each Sendmail queue processing cycle

5) If the Sendmail relay macro L is not defined, then the sample LDAP code
for Sendmail rule S5 will not work since it is dependent upon L being
defined; if the "user" database is not to be used at all, then the S5 rules
which refer to the "user" database will either not exist or be commented
out, which is not a problem, and the "K" and "DL" definitions will be
commented out; in this case of using the  sample LDAP code in the S5 place
suggested, the simplest thing to do to take care of the relay macro L is to
insert or uncomment it, and define it for LDAP (ie; "DLldap"), and leave
the "user" database definitions and rules alone; if the LDAP rules are moved
out of S5 or otherwise changed, then they will/may need a different
'trigger' other than the relay L macro.

6) Any mail which requires an LDAP resolution for which either there is
no Common Name entry found or the LDAP server is not running/functioning,
will be enqueued until the appropriate LDAP entry can be found or the
Sendmail queue time limit is reached

7) When using an IP address ACL, be careful about just what/which
applications from that IP host will be able to access the LDAP server since
the ACL rule will match on the host and not on the specific
application; a good example of a potential problem is to run a News server,
the web500gw server, and the LDAP server all on the same host, with an ACL
which specifies the IP address of the "News server" (which also matches
the "web500gw server"); an ACL to benefit the "News server" in this
situation will open the door, incidently, to ALL accesses via
the same-host "web500gw server", as far as the matching ACL rule is
concerned.

8) For UMich-3.3 SLAPD, and possibly other LDAP servers, selecting Berkeley
DB for use in compiling LDAP and forgetting to define the DB library
(ie; leaving "#LDBMLIB=-ldb" commented out) can create a SLAPD that doesn't
run well; in one instance, the SLAPD daemon used up all available CPU, was
a constantly RUNning task, and had 10 threads open, doing basically nothing;
when LDAP was recompiled with the DB library definition uncommented, a
"normal" SLAPD was produced that used very little CPU and normally was not
in a RUN state.


      Some general comments about LDAP, Sendmail, INN, and anything else:


["SLAPD" is the name of the UMich/OpenLDAP LDAP server program.]

1) It is highly recommended that all of the ancillary LDAP servers
(MAIL500, RCPT500, etc.) which are put into service be identified by a
Distinguished Name entry in the LDAP database AND in the
INCLUDE/LDAPCONFIG.H(.edit) file (if available) for each server.

This allows for easy identification of each server in the SLAPD log file.
It becomes even more important if there are multiple MAIL500 (etc.) servers
on multiple hosts (how do you know \underline{what} is accessing the LDAP
server if all there is in the log file is a "connection from unknown
(<IP address>)" message for multiple services coming from the same host?.

Most of all - if the WEB500GW server runs on the same host as the
LDAP server, the SLAPD log file will show "connection from unknown
(<IP address>)" where the IP address IS the host of the WEB500GW/LDAP
servers!

With each ancillary LDAP server identified by a DN, it is now possible to
identify when a user uses one of THOSE servers to connect to the LDAP server
and perform some LDAP function. For example, note the rcpt500 DN in the
following log entry,

...................................................................
connection from unknown (10.0.0.2)
BIND dn="cn=rcpt500,ou=Services,cn=FreeBSD1, ....
RESULT err=0 tag=97 nentries=0
SRCH base="o=LocalNet10,c=US" scope=2 filter= ...
RESULT err=0 tag=101 nentries=1
SRCH base="cn=Sloppy Focus,ou=People,cn=FreeBSD1, ...
RESULT err=0 tag=101 nentries=1
...................................................................

2) The UMich and OpenLDAP "suites" include some additional Unix "client"
servers which provide access to an LDAP server via these Unix "client"
(command line) commands or "aliases" definitions. Each has its own builtin
format for the data displayed (in a,b,c).

  a) rcpt500 - LDAP inquiries via mail (Sendmail /ETC/ALIASES entry)
  b) finger  - LDAP inquiries via finger command
  c) whois++ - LDAP inquiries via whois command
  d) fax500
  e) gopher

The rcpt500 program can be very useful for users who don't have any
LDAP-capable applications, or who use their E-mail client quite a bit and
would find it natural to submit a query via electronic mail. It can also
provide a general LDAP access where users, internal or external, have no
knowledge of other available LDAP services.

3) Two possible LDAP E-mail attributes were chosen to validate an article
poster's E-mail address: "mail" and "otherMailbox". The main reason for
using two different attributes is that the "mail" attribute is normally
treated as the default mail delivery address whereas the "otherMailbox" is
usually treated as just extra information and isn't used (automatically) for
mail delivery, but may contain other E-mail addresses.

Additionally, both attributes may be repeated so as to provide for multiple
values. To prevent unwanted multiple copies of mail, only one mail address
is defined by the "mail" attribute. Any other mail addresses are relegated
to the "otherMailbox" attribute.

4) Once the Perl "exit" is working satisfactorily, the amount of log
output should be reduced to a minimum as extensive logging will use more
resources than necessary (CPU to write and disk to store
(twice: NEWS.NOTICE and NEWS.DAILY report))

5) Using Netscape DS V3 in place of UMich LDAP-3.3 server is possible, but
it should be noted that Netscape V3 has dropped the "umichPerson" and
"service" objectclasses; much of what was in "umichPerson" has been
redistributed to one or more objectclasses such as Netscape's
"inetOrgPerson"; missing attributes can be easily added under a "local"
objectclass (it is recommended to NOT extend Netscape's base objectclass
definitions); Netscape DS V1 is not recommended mostly because of advances
in V3; MAIL500 and other "LDAP addons" are not available with Netscape's DS
product (yet).

[Additional comments can be found in the HTML/FOILS files.]
