[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=, size=567, class=0, pri=30567, nrcpts=1, msgid=, 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=, 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=, 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 ()" 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 ()" 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.]