mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
8d6fffc9ba
to put it in line with current practices. Most likely I got them wrong, so maight not even compile right now.
189 lines
7.8 KiB
Plaintext
189 lines
7.8 KiB
Plaintext
This is the README file for mail500, a mailer that does X.500 lookups
|
|
via LDAP.
|
|
|
|
If you are planning to run mail500 at your site, there are several
|
|
things you will have to tailor in main.c:
|
|
|
|
LDAPHOST - The host running an LDAP server
|
|
|
|
base[] - The array telling mail500 where/how to search for
|
|
things. See the explanation below.
|
|
|
|
*** WHAT mail500 DOES: ***
|
|
|
|
mail500 is designed to be invoked as a mailer (e.g., from sendmail),
|
|
similar to the way /bin/mail works. It takes a few required arguments
|
|
and then a list of addresses to deliver to. It expects to find the
|
|
message to deliver on its standard input. It looks up the addresses in
|
|
X.500 to figure out where to route the mail, and then execs sendmail to
|
|
do the actual delivery. It supports simple aliases, groups, and
|
|
mailing lists, the details of which are given below.
|
|
|
|
*** HOW IT WORKS (from the sendmail side): ***
|
|
|
|
The idea is that you might have a rule like this in your sendmail.cf
|
|
file somewhere in rule set 0:
|
|
|
|
R$*<@umich.edu>$* $#mail500$@umich.edu$:<$1>
|
|
|
|
This rule says that any address that ends in @umich.edu will cause
|
|
the mail500 mailer to be called to deliver the mail. You probably
|
|
also want to do something to prevent addresses like terminator!tim@umich.edu
|
|
or tim%terminator.rs.itd.umich.edu@umich.edu from being passed to mail500.
|
|
At U-M, we do this by adding rules like this to rule set 9 where we
|
|
strip off our local names:
|
|
|
|
R<@umich.edu>$*:$* $>10<@>$1:$2
|
|
R$+%$+<@umich.edu> $>10$1%$2<@>
|
|
R$+!$+<@umich.edu> $>10$1!$2<@>
|
|
|
|
See the sample sendmail.cf in this directory for more details.
|
|
For sendmail 8.9 (and later) users can use MAILER(mail500) if
|
|
mail500.m4 is placed within sendmail's cf/mailer directory.
|
|
|
|
The mail500 mailer should be defined similar to this in the
|
|
sendmail.cf file:
|
|
|
|
Mmail500, P=/usr/local/etc/mail500, F=DFMSmnXuh, A=mail500 -f $f -h $h -m $n@$w $u
|
|
|
|
This defines how mail500 will be treated by sendmail and what
|
|
arguments it will have when it's called. The various flags specified
|
|
by the F=... parameter are explained in your local sendmail book (with
|
|
any luck). The arguments to mail500 are as follows:
|
|
|
|
-f Who the mail is from. This will be used as the address
|
|
to which any errors should be sent (unless the address
|
|
specifies a mailing list - see below). Normally, sendmail
|
|
defines the $f macro to be the sender.
|
|
|
|
-h The domain for which the mail is destined. This is passed
|
|
in to mail500 via the $h macro, which is set by the
|
|
$@ metasymbol in the rule added to rule set 0 above.
|
|
It's normally used when searching for groups.
|
|
|
|
-m The mailer-daemon address. If errors have to be sent,
|
|
this is the address they will come from. $n is normally
|
|
set to mailer-daemon and $w is normally the local host
|
|
name.
|
|
|
|
The final argument $u is used to stand for the addresses to which to
|
|
deliver the mail.
|
|
|
|
*** HOW IT WORKS (from the mail500 side): ***
|
|
|
|
When mail500 gets invoked with one or more names to which to
|
|
deliver mail, it searches for each name in X.500. Where it searches,
|
|
and what kind(s) of search(es) it does are compile-time configurable
|
|
by changing the base array in main.c. For example, the configuration
|
|
we use at U-M is like this:
|
|
|
|
Base base[] =
|
|
{ "ou=People, dc=OpenLDAP, dc=org", 0
|
|
"uid=%s", "cn=%s", NULL,
|
|
"ou=System Groups, ou=Groups, dc=OpenLDAP, dc=org", 1
|
|
"(&(cn=%s)(associatedDomain=%h))", NULL, NULL,
|
|
"ou=User Groups, ou=Groups, dc=OpenLDAP, dc=org", 1
|
|
"(&(cn=%s)(associatedDomain=%h))", NULL, NULL,
|
|
NULL
|
|
};
|
|
|
|
which means that in delivering mail to "name" mail500 would do the
|
|
the following searches, stopping if it found anything at any step:
|
|
|
|
Search (18) [2]: dc=org@dc=OpenLDAP@ou=People
|
|
Search subtree (uid=name)
|
|
Search (18) [3]: dc=org@dc=OpenLDAP@ou=People
|
|
Search subtree (cn=name)
|
|
|
|
Search (18) [4]: dc=org@dc=OpenLDAP@ou=Groups@ou=System Groups
|
|
Search subtree & ((cn=name)(associatedDomain=OpenLDAP.org))
|
|
|
|
Search (18) [5]: dc=org@dc=OpenLDAP@ou=Groups@ou=User Groups
|
|
Search subtree & ((cn=name)(associatedDomain=OpenLDAP.org))
|
|
|
|
Notice that when specifying a filter %s is replaced by the name,
|
|
or user portion of the address while %h is replaced by whatever is
|
|
passed in to mail500 via the -h option (typically the host portion
|
|
of the address).
|
|
|
|
You can also specify whether you want search results that matched
|
|
because the entry's RDN matched the search to be given preference
|
|
or not. At U-M, we only give such preference in the mail group
|
|
portion of the searches. Beware with this option: the algorithm
|
|
used to decide whether an entry's RDN matched the search is very
|
|
simple-minded, and may not always be correct.
|
|
|
|
There is currently no limit on the number of areas searched (the base
|
|
array can be as large as you want), and an arbitrary limit of 2 filters
|
|
for each base. If you want more than that, simply changing the 3 in
|
|
the typedef for Base should do the trick.
|
|
|
|
*** HOW IT WORKS (from the X.500 side): ***
|
|
|
|
In X.500, there are several new attribute types and one new object
|
|
class defined that mail500 makes use of. At its most basic, for normal
|
|
entries mail500 will deliver to the value(s) listed in the
|
|
rfc822Mailbox attribute of the entry. For example, at U-M my entry has
|
|
the attribute
|
|
|
|
mail= tim@terminator.rs.itd.umich.edu
|
|
|
|
So mail sent to tim@umich.edu will be delivered via mail500 to that
|
|
address. If there were multiple values for the mail attribute, multiple
|
|
copies of the mail would be sent.
|
|
|
|
A new object class, rfc822MailGroup, and several new attributes have
|
|
been defined to handle email groups/mailing lists. To use this, you
|
|
will need to add this to your local oidtable.oc:
|
|
|
|
# object class for representing rfc 822 mailgroups
|
|
rfc822MailGroup: umichObjectClass.2 : \
|
|
top : \
|
|
cn : \
|
|
rfc822Mailbox, member, memberOfGroup, owner, \
|
|
errorsTo, rfc822ErrorsTo, requestsTo, rfc822RequestsTo,
|
|
joinable, associatedDomain, \
|
|
description, multiLineDescription, \
|
|
userPassword, krbName, \
|
|
telecommunicationAttributeSet, postalAttributeSet
|
|
|
|
And you will need to add these to your local oidtable.at:
|
|
|
|
# attrs for rfc822mailgroups
|
|
multiLineDescription: umichAttributeType.2 : CaseIgnoreList
|
|
rfc822ErrorsTo: umichAttributeType.26 : CaseIgnoreIA5String
|
|
rfc822RequestsTo: umichAttributeType.27 : CaseIgnoreIA5String
|
|
joinable: umichAttributeType.28 : Boolean
|
|
memberOfGroup: umichAttributeType.29 : DN
|
|
errorsTo: umichAttributeType.30 : DN
|
|
requestsTo: umichAttributeType.31 : DN
|
|
|
|
The idea was to define a kind of hybrid mail group that could handle
|
|
people who were in X.500 or not. So, for example, members of a group
|
|
can be specified via the member attribute (for X.500 members) or the
|
|
rfc822MailBox attribute (for non-X.500 members). Similarly for the
|
|
errorsTo and rfc822ErrorsTo, and the requestsTo and rfc822RequestsTo
|
|
attributes.
|
|
|
|
To create a real mailing list, with a list maintainer, all you have to
|
|
do is create an rfc822MailGroup and fill in the errorsTo or
|
|
rfc822ErrorsTo attributes (or both). That will cause any errors
|
|
encountered when delivering mail to the group to go to the addresses
|
|
listed (or X.500 entry via it's mail attribute).
|
|
|
|
If you fill in the requestsTo or rfc822RequestsTo (or both) attributes,
|
|
mail sent to groupname-request will be sent to the addresses listed
|
|
there. mail500 does this automatically, so you don't have to explicitly
|
|
add the groupname-request alias to your group.
|
|
|
|
To allow users to join a group, there is the joinable flag. If TRUE,
|
|
mail500 will search for entries that have a memberOfGroup attribute
|
|
equal to the DN of the group, using the same algorithm it used to find
|
|
the group in the first place (i.e. the DNs and filters listed in the
|
|
base array). This allows people to join (or subscribe to) a group
|
|
without having to modify the group entry directly. If joinable is
|
|
FALSE, the search is not done.
|
|
|
|
Finally, keep in mind that this is somewhat experimental at the moment.
|
|
We are using it in production at U-M, but your mileage may vary...
|