OpenSolaris

Printable Version Enter a New Search
Bug ID 6337505
Synopsis Sendmail is unable to use LDAP mail aliases > 256 bytes
State 10-Fix Delivered (Fix available in build)
Category:Subcategory utility:sendmail
Keywords 256 | MAXNAME | aliases | buffer | dynamically | getldapaliasbyname | ldap | libsldap.so.1 | sendmail | space
Responsible Engineer John Beck
Reported Against solaris_2.8
Duplicate Of
Introduced In solaris_8
Commit to Fix snv_78
Fixed In snv_78
Release Fixed solaris_nevada(snv_78)
Related Bugs
Submit Date 17-October-2005
Last Update Date 21-November-2007
Description
Scenario:
Migrating from NIS to LDAP on Solaris 9 with SUN Directory server 5.2
Using ldapaddent I've inserted mail aliases in the the aliases ou in the LDAP directory. On systems where the directory service is now LDAP instead 
of NIS, large mail aliases cannot be expanded using sendmail. The message returned is "User unknown".

Using debugging on sendmail shows that a call: getldapaliasbyname is failing due to insufficient buffer space (errno=79). On looking at the SUN 
sendmail patch, it seems that LDAP alias expansion is done using the call __getldapaliasbyname provided by libsldap.so.1 This call requires its 
output buffer to be preallocated and passed in as a parameter.

However, the buffer passed to this call is only MAXNAME+1 bytes which equates to 257 bytes which explains the size limit on aliases stored in LDAP.

The NIS version has the buffer allocated by the yp_match library call itself which will accomodate whatever size aliases you need (up to the dbm record 
limit of 1024 characters).

>From looking at the source to the changes made to sendmail by SUN, it seems like a very hurried hack, the consequences of which have not been 
documented or thought about.

It must be the case that most people using sendmail and LDAP on SUN expand aliases in a different way. Could someone enlighten me?

##############################################
See John Beck comment in the "Comments" field.
##############################################
Work Around
N/A
Comments
N/A