One major difference between Sendmail's LDAP client capability and the mail500 LDAP client program is that Sendmail only accepts one returned e-mail address whereas mail500 accepts all returned e-mail addresses. This is not a weakness in Sendmail's LDAP client, but rather a difference in philosophy which can be put to good use. If a note to a mailing list could generate many e-mail addresses, then allowing an external program such as mail500 to do all of the work in assembling those addresses from an LDAP database relieves Sendmail of work that it doesn't really need to do, freeing it to do the work it is more expected to do - deliver mail. On the other hand, a single user LDAP lookup fits in quite well with Sendmail since it can, and sometimes does, the same kind of process in other user databases created for Sendmail specifically. It should be noted that the specific uses of LDAP in this report are not the only way that the desired affects could have been achieved.
In general, data stored in an LDAP server that is meant to be user consumable is in clear text - not encrypted. Internal server information may or may not be encrypted, but the user does not see and usually cannot access such data. Also, most general LDAP connections today are insecure, not only for connection or update authentication, but also for data transmission. Additionally, there may be possibilities of IP hostname or address spoofing. These can be serious concerns for some sites or individuals.
In the case of the file relay facility, some possible methods to increase security are:
However, in the end, the file relay service is dependent on trust and accountability no matter what security mechanisms are used since its job submission client must deal with a remote host userid and password, or equivalent, to perform its function.
The facilities in this report were not implemented with the intent of providing secure applications. They are meant to show the feasibility of certain LDAP-enhanced applications, and to provide a test bed for exploring such LDAP add-ons.
Version 3 of the LDAP protocol specifies a secure BIND capbility through
the use of Simple Authentication and Security Layer (SASL), RFC 2222.
Several INTERNET-DRAFT documents propose the use of Transport Layer Security,
RFC 2246, as a means of protecting data transmitted between an LDAP client
and server. It may be possible to create ``secure tunnels'' or ``wrappers'' using
OpenSSH, OpenSSL, SSLeay,
and/or stunnel[22]
for LDAP clients or servers without security capabilities.
Perhaps in the future, LDAP clients and servers will have the requisite hooks built-in or coding added to provide security at all levels of interaction. In the meantime, network, password, and data security is left up to the implementor and/or administrator. Different layers of security and some security mechanisms are discussed in[17, Chapter 11]. Actual implementation, however, is still up to the site.