Re: OpenLDAP client binaries and sendmail RESULTS!!!

[Rich Graves <rcgraves@brandeis.edu>]

I was waiting for an actual expert to chime in with all the answers, but
it's been a while, so here goes.

We've been doing pretty much what Stanford does with maildrop, except I
renamed the maildrop attribute to mailforwardingaddress in a misguided
attempt to follow parts of Netscape's schema.

A source RPM and a tarball including our sendmail.cf and patches for
nonLinuxers are in http://www.brandeis.edu/~rcgraves/sendmail-ldap/

SPECS/imap.spec should be mostly human-readable as an INSTALL roadmap.

Notes and gotchas:

-DSUNET_ID is cool. Use it. joeschmo, joe.schmo, joe-schmo, and joe_schmo
are made equivalent. This eliminates the most common errors caused by such
supposedly "user-friendly" aliases. Just make sure you avoid collisions. We
had both a CCOHEN and a C_COHEN on the old VAX; the latter needed to be put
into a static alias file.

My M4 file does most of what needs to be done to sendmail.cf, but I still
need to hack two things by hand.

I have OpenLDAP installed in /usr/lib and /usr/include, you'll need to add
your paths if you have it elsewhere.

Booker doesn't mention, because it should be obvious, that you need
feature(`LUSER_RELAY') in order for the ruleset 5 changes to have any
context. It took me a month to figure that out. The ruleset will still work
if the L macro is undefined. In that case sendmail's last resort after both
alias and ldap map lookups fail is "user unknown" rather than forwarding to
a relay. This happens to be what we want.

I applied the patch for using LDAP as a "real" alias map rather than a
ruleset 5 hack, but found the resulting behavior very unfortunate. You get a
lot of lookups like alias+*. You don't want to be doing several wildcarded
lookups per email message. You could probably stop that by breaking the
plussed users feature, but I didn't see an obvious way to do that so I went
back to ruleset 5.

Your maildrop (or mailacceptinggeneralid) value *must* be a single fully
qualified email address. There are suggestions to the effect that
multivalued answers or comma-separated lists should work as in a normal
aliases map, but this doesn't work for me. Instead sendmail tries to deliver
to e.g.

rcgraves@drop.brandeis.edu,foo@drop.brandeis.edu... deliverable: mailer
esmtp, host drop.brandeis.edu, user rcgraves@drop.brandeis.edu,foo

which of course fails. If someone could fix this for me I'd be much obliged.

Booker seems to state that if the LDAP servers are down, mail is accepted
but queued. This doesn't work for me. Instead messages get rejected at
RCPT TO with a 421 temporary error. Our solution is to make sure the LDAP
servers never go down. :-/ A better answer would be a lower priority MX that
doesn't do LDAP. Still this would only solve the problem if what's talking
to you is a real mail server that knows about MX. Desktop clients will just
fail. If anyone can fix this for me I'd be much obliged.
-- 
Rich Graves <rcgraves@brandeis.edu>
UNet Systems Administrator