Ключевые слова:mail, sendmail, ldap, howto, (найти похожие документы)
Date: Tue, 29 Oct 2002 10:52:21 +0500
From: Alexandr Goncharov <[email protected]>
Newsgroups: ftn.ru.unix.bsd
Subject: Настройка sendmail в связке с LDAP
VN>>>>>> При check_rcpt сделать lookup на наличие юзера. Можно через тот же
VN>>>>>> ldap map (вставить в local_check_rcpt), можно внешним скриптом
VN>>>>>> (тогда подставлять в одну из access_db).
AD>>> Hе, что сказать ldadsearch'у я представляю.
AD>>> Я любопытствовал, как примерно может выглядеть правило, в котором
AD>>> делается лукап через внешний скрипт.
VN>> Это не правило. Это скрипт, который формирует табличку и подсовывает ее
VN>> как часть access_db.
AD> Что-то я никак не пойму.
AD> Это в смысле запустить скрипт руками и обновить access_db? Это не очень интересно.
AD> Или же это какой-то динамический процесс?
VN>> Можно сделать и через map типа program, но зачем?
AD> Exchange сначала заглатывает всю почту, а уже потом решает что
AD> с ней делать. Да еще в случае несуществующего ящика генерит идиотский
AD> NDR, норовя пришпилить к нему исходное сообщение.
AD> Вот и хочется, чтобы сендмейл, на этапе сheck_rcpt лез по LDAP в AD и
AD> говорил "550 тра-ля-ля" в случае, если реципиент не найден.
AD> Проблему можно решить, собрав sendmail с поддержкой LDAPMAP, я как раз
AD> пытаюсь врубиться в это дело. А тут увидел предложение со внешним скриптом
AD> и решил поинтересоваться подробностями.
У нас работает именно так, как хочется. За исключением того, что Exchange отсутствует.
sendmail-8.12.3, собран с поддержкой ldap следующим образом:
при сборке в site.config.m4 добавлено:
dnl LDAP
APPENDDEF(`conf_sendmail_ENVDEF',-DLDAPMAP')
APPENDDEF(`conf_libsm_ENVDEF',-DLDAPMAP')
dnl APPENDDEF(`conf_sendmail_ENVDEF',-D_FFR_LDAP_RECURSION')
dnl APPENDDEF(`conf_sendmail_ENVDEF',-D_SM_CONF_LDAP_MEMFREE=1')
APPENDDEF(`confINCDIRS',-I/usr/local/include')
APPENDDEF(`confLIBDIRS',-L/usr/local/lib')
APPENDDEF(`conf_sendmail_LIBS',-lldap -llber')
dnl #APPENDDEF(`conf_sendmail_LIBS',-llber')
В relay.mc :
divert(-1)
#
#
divert(0)dnl
OSTYPE(freebsd4)dnl
DOMAIN(ourdomain)dnl
define(`confDOMAIN_NAME',`xxxxxx')dnl
define(`confDONT_EXPAND_CNAMES',`true')dnl
define(`confLDAP_CLUSTER',`relays')dnl
В domain/ourdomain.m4:
.....
define(`confDONT_BLAME_SENDMAIL',`groupreadablesasldbfile')dnl
FEATURE(`ldap_routing',`ldap -1 -v mailHost -k
(&(objectClass=inetLocalMailReceipient)(mailLocalAddress=%0))',`bounce',`precerve')dnl
FEATURE(mailertable,`LDAP')dnl
FEATURE(access_db, `LDAP')dnl
RELAY_DOMAIN_FILE(`@LDAP')dnl
LDAPROUTE_DOMAIN_FILE(`QLDAP')dnl
define(`confLDAP_DEFAULT_SPEC',-h"xxx.xxx" -d"cn=xxx,dc=xxxx,dc=xx" -P"xxxx"
-b"dc=xxxxxx,dc=xx"')dnl
define(`confLDAP_CLUSTER',`relays')dnl
А в ldap подгружена схема, которая находится в cf/sendmail.schema, рядом
с небезызвестным cf/README (в котором стоит почитать про работу с ldap)
Есть еще некоторые нюансы, не все сходу вспомнится, да и нет задачи детально
описывать.
Работает это так (у нас):
в ldap для юзера есть записи для релеев (LDAP_CLUSTER relays)
и для машины с майлбоксами. Содержание разное.
При приеме письма релей делает запрос о ldap_routing. Или получает в ответ
информацию о том, куда и как доставлять почту и принимает письмо. Или
получает ответ о несуществующем адресе и отказывается принять письмо.
Машина с майлбоксами при приеме письма тоже делает запрос, но в другой
кластер и получает информацию о том, куда именно доставить письмо.
В результате все сводится к внесению всей необходимой информации в LDAP.
В случае Exchange (повторюсь - не используем и как там что - не знаю) я бы
смотрел на одно из двух:
1) Возможность видоизменения схемы и соответствующих правил сендмайла, чтобы
сендмайл и Exchange в одно место смотрели.
2) Если 1) чересчур сложно - подумал бы о синхронизации данных в ldap его
средствами или внешними программами. Чтобы добавление юзера в Exchange
автоматически отображалось в объекты sendmail.schema
p.s. все вышеизложенное - не более чем поверхностное описание работающей
схемы. Может рассматриваться не как how-to, а лишь как направление поиска.
