上一页    目录    索引    下一页
iPlanet Messaging Server 5.2 管理员指南

附录 B MTA 直接 LDAP 操作


在 iPlanet Messaging Server 5.2 版之前，MTA 使用的有关用户和组的目录信息是通过许多文件和数据库存取的。这些文件和数据库中的数据更新由 dirsync 进程控制，该进程可监控目录的变化并相应地更新文件和数据库数据。在 5.2 版中，这仍然是默认运行状态，然而有一新选项可用来使 MTA 直接与目录交互。这个选项就是直接 LDAP 模式。

当被配置为按直接 LDAP 模式操作时，MTA 便可不使用 dirsync 进程及其数据库。取而代之的是，MTA 将进行相等的 LDAP 调用，首先确定在 MTA 上是否有托管的域，然后再存取所需的发送信息。当把 dirsync 操作模式更改为直接 LDAP 模式时，对地址转换几乎没有实际影响，但直接 LDAP 模式更便于配置、机制更透明。但是，受托域的工作方式还是有一些变化，对系统运行方式也有一些影响。有关详细信息，请参阅“转变到直接 LDAP 模式的意义”。

本章由以下的部分组成：


启用直接 LDAP 模式

启用直接 LDAP 模式时，须对标准 MTA 配置做如下改动：

  1. 在文件 .../imta/config/imta.cnf 中的“重写”部分中添加下一行

    $*      $E$F$U%$H$V$H@localhost

    其中，localhost 是 MTA 的主要主机名。

    例如，如果 MTA 叫做 island.siroe.com，需修改文件
    .../imta/config/imta.cnf 中的“规则”部分，将其改为：

    ! Rules to select   local users
    $*                  $E$F$U%$H$V$H@island.siroe.com
    island.siroe.com    $U%$D@island.siroe.com
    siroe.com           $U%$D@island.siroe.com

  2. 更改 .../imta/config/imta.cnf 文件中 ims-ms 的通道定义以移除其中的 filter ssrd:$A 子句。

    如果 ims-ms 通道定义是

    ! ims-ms
    ims-ms defragment subdirs 20 notices 1 7 14 21 28  \
     backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" \
     maxjobs 1 pool IMS_POOL fileinto $U+$S@$D filter ssrd:$A
    ims-ms-daemon

    则应改为

    ! ims-ms
    ims-ms defragment subdirs 20 notices 1 7 14 21 28 \
     backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" \
     maxjobs 1 pool IMS_POOL fileinto $U+$S@$D
    ims-ms-daemon

  3. 在 .../imta/config/option.dat 文件中添加下列各行：

    ALIAS_MAGIC=8764
    ALIAS_URL0=ldap:///$V?*?sub?$R
    USE_REVERSE_DATABASE=4
    REVERSE_URL=ldap:///$V?mail?sub?$Q
    USE_DOMAIN_DATABASE=0

    如果需要虚拟域支持，还必须设置下列附加的选项：

    DOMAIN_MATCH_URL=ldap:///$B?msgVanityDomain?sub? \
    (msgVanityDomain=$D)
    ALIAS_URL1=ldap:///$B?*?sub?(&(msgVanityDomain=$D)$R)
    ALIAS_URL2=ldap:///$1V?*?sub?(mailAlternateAddress=@$D)

  4. 从 .../imta/config/job_controller.cnf 文件中移除下列各行：

    [PERIODIC_JOB=dirsync_incr]
    command=IMTA_TABLE:../../imsimta dirsync
    time=/00:10
    !
    [PERIODIC_JOB=dirsync_full]
    command=IMTA_TABLE:../../imsimta dirsync -F
    time=02:00/24:00
    !

  5. 从文件 .../imta/config/mappings 末尾的 SEND_ACCESS 映射中移除下列各行

    *|*|inactive|* $X4.2.1|$NMailbox$ temporarily$ disabled
    *|*|deleted|* $X5.1.6|$NRecipient$ no$ longer$ on$ server

  6. 删除，或者至少移动这些 MTA 数据库：

    .../imta/db/aliasesdb.db
    .../imta/db/domaindb.db
    .../imta/db/reversedb.db

  7. 编译已修改的 MTA 配置。这必须在其生效之前进行。


直接 LDAP 模式的工作原理

MTA 在对目标邮件地址的处理方面基本上没有变动。这一过程简述如下：首先，MTA 使用重写规则：1）确定是否有经过验证的域；2）重写相应的地址；3）将邮件路由到相应的通道。如果邮件被路由到 l 通道，则用别名查找进程转换地址（请参阅“直接 LDAP 别名解析”），然后再次用重写规则重写所得地址，以将这些地址路由到与别名相关联的通道上。通常这个通道就是 ims-ms 通道、auto_reply 通道或其它标准的 MTA 通道中的某一个。

直接 LDAP 模式操作改变了地址处理的重写规则阶段和别名阶段。这些改动会在下面的章节中说明。


使用直接 LDAP 模式解析地址（$V）

MTA 解析地址时，首先依照重写规则检查地址中的域部分（@ 右边的部分）。重写规则位于 .../imta/config/imta.cnf 文件的上半部分。如果发现匹配，规则会指定邮件将被路由到哪个通道。例如，邮件可被路由到 tcp_local 的出站因特网通信流，或如果是目录中配置的用户，则可将邮件路由到本地通道 l。

当 MTA 被配置为 dirsync 模式时，规则评价程序将使用域数据库中的信息，该数据库是 dirsync 进程维护的数据库中的一个。当 MTA 被配置为直接 LDAP 模式时，在则使用一个特殊的“try me first”重写规则。这一规则格式如下：

$*     $E$F$U%$H$V$H@localhost

位于规则左侧的 $* 模式，其含义是首先尝试这个规则，而且是在所有的地址上。规则右侧的含义是：


LDAP 域查找功能的工作原理

重写规则进程的新部分是 $V 匹配参数。$V 用来确定一地址是否是本地的，若是，则在目录树中查找其位置。$V 需要一个表示地址主机部分的参数，如此例中的 $H。$V 标记可将几个 LDAP 查找同时投入运行。查找过程包括在 DC 树中查找地址中的域部分，以发现用户树和组树的相应的子树。例如，如果有关地址是：

robinson.crusoe@desert.island.siroe.com

MTA 首先检查域 desert.island.siroe.com，如果失败，再依次检查 island.siroe.com、siroe.com 以及 com。这一 LDAP 查找通常在目录中的 DC 树中进行（有关 iPlanet Messaging Server 名字空间和 DIT 结构的详细说明，请见 iPlanet Messaging Server Provisioning Guide）。此树所在的位置是由 service.dcroot 配置属性指定的，默认值为 o=internet。查找对象为那些有判别名的条目：

dc=desert,dc=island,dc=siroe,dc=com,o=internet
dc=island,dc=siroe,dc=com,o=internet
dc=siroe,dc=com,o=internet
dc=com,o=internet

如果找到的条目是 inetDomain 的对象类和 inetDomainBaseDn 的属性，或是 inetDomainAlias 的对象类和 aliasedObjectName 属性，一次域查找才视为成功。

如果想防止对上一级域的检查，如例子中的 island.siroe.com、siroe.com 和 com，就需清除 DOMAIN_UPLEVEL 选项的最低有效位。DOMAIN_UPLEVEL 是在文件 .../imta/config/option.dat 中指定的。它的默认值是 1，以便防止上一级检查添加下行：

DOMAIN_UPLEVEL=0

to .../imta/config/option.dat.

这里有另一个新标记，$Z，其含义与 $V 完全相反。$V 在目录中找到主机时使一条规则与之匹配，$Z 则在目录中找不到主机时使一条规则与之匹配。


虚拟域查找
如果有为任何用户定义的任何虚拟域（不是受托域），也需要为之启用 LDAP 检查。虚拟域检查在默认设置中是禁用的。要启用虚拟域检查，需要把下列各行添加到文件 .../imta/config/option.dat 中：

DOMAIN_MATCH_URL=ldap:///$B?msgVanityDomain?sub? \
  (msgVanityDomain=$D)

仅当受托域检查失败时，才会进行虚拟域检查。


域查找缓存
检查所有域中的目录是一项开销很大的操作，因为它必须在所有的域中执行，包括任何有邮件向之发送的 internet 域。为了减少开销，查找的结果被 MTA 缓存。按默认方式，多达 100000 个结果（成功与否）可缓存长达 600 秒。缓存方式可以通过设置文件 .../imta/config/option.dat 中的下列选项而加以控制。

DOMAIN_MATCH_CACHE_SIZE=100000
DOMAIN_MATCH_CACHE_TIMEOUT=600


管理地址重写期间的 LDAP 错误

在目录中的查找域时，有四种可能出现的结果。

第一种情况说明没有问题。第二种情况和第三种情况将被当作同一问题进行处理，并导致 $V 规则失败。最后的一种情况是比较困难的。在这种情况下，MTA 有两套可采取的合理操作：

  1. 拒绝带有 400 Temporary lookup failure SMTP 响应。

  2. 将邮件重定向到 reprocess 通道等待稍后处理。

如果邮件来自某些远端 MTA，第一种操作是显然的和正确的。如果邮件来自一用户代理提交的邮件，第二种操作更适合。MTA 需要区分这两种情况并采取相应的行动。启用这一处理机制的是 MTA 选项 DOMAIN_FAILURE。DOMAIN_FAILURE 指定在一个字符串，用来在域查找失败的情况下覆盖一个重写规则中的不用部分。因此，如果 DOMAIN_FAILURE 的默认值为

DOMAIN_FAILURE=reprocess-daemon$Mtcp_local$1M$1~-error$4000000?Temporary lookup failure

并且被处理的重写规则是标准的

$*     $E$F$U%$H$V$H@localhost

以及由 $V$H 语句所实施的域查找失败，则处理继续进行，如同重写规则为：

$*      $E$F$U%$H$V$H@reprocess-daemon$Mtcp_local$1M$1~-error$4000000?Temporary lookup failure

结果规则的处理如下：

因此，如果来源通道是 tcp_local（在所有可能的源于某些远程 MTA 的连接中）则重写规则成功，但没有 reprocess-daemon-error 的通道存在，因而地址被拒绝，并以规则中指定的 400 出错代码而被拒绝。

如果源通道是 tcp_intranet（可能是一个用户代理），规则成功地将邮件路由到 reprocess 通道。

这个 DOMAIN_FAILURE 选项和由之创建的有效的重写规则使用某些新的重写标记。

$1M 与现存的 $Mchannel 标志类似，当源通道是一个 reprocess 通道时会引起一个规则失败。大致上等同于 $Mreprocess$Mprocess$Mdefragment$conversion。

$~ 使通道执行任何由 $M 或 $1M（或 $M 或 $1N）标志所指定的匹配检查，如果结果是失败，立即以一个成功终止处理。

$abbbccc?text 指定在出错事件发生时使用的出错代码和出错信息文本。出错代码实际上是三个十进制数 a、bbb、ccc 并生成扩展的 SMTP 结果代码：a.bbb.ccc。


直接 LDAP 别名解析

别名解析的作用是提取邮件的进入地址（别名），并产生一个用来传递邮件到一个通道的电子邮件的地址。这个地址被称为传递地址，通常有形式 uid@ 通道名称。

重写规则只考虑地址的 @ 标记右边的部分。但是，别名解析潜在地考虑整个地址。使用于地址解析的机制由文件 .../imta/config/option.dat 中的 ALIAS_MAGIC 选项所控制。默认行为是在 aliases 文件和由 dirsync 进程维护的 aliases 数据库中查找一个匹配。（参阅“别名”。）

为了启用直接 LDAP 操作，增加以下各行到文件 .../imta/config/option.dat 中。

ALIAS_MAGIC=8764

这导致使用 aliases 文件尝试进行别名解析（通常仅用于网站的 Postmaster），然后通过 LDAP 目录。LDAP 别名解析在产生一个发送通道前要经过一系列。这些步骤如下：

  1. 在 LDAP 目录中寻找地址的用户/组条目。

  2. 确定条目类型（用户或组）。

  3. 提取条目状态（例如：active, inactive, deleted, hold）。

  4. 提取 uid 属性。

  5. 寻找用户位置。

  6. 核实邮件的长度没有超过指定的限制。

  7. 产生基于 mailDeliveryOption 属性（例如：邮箱、自动回复、程序和转发）的传递地址。

这部分的剩余内容对每一步进行了详细地说明。


在 LDAP 目录中寻找用户/组条目

查找别名地址的用户/组条目的 LDAP 查询是由文件 .../imta/config/option.dat 中的以下选项所指定的 URL 定义的：

ALIAS_URL0
ALIAS_URL1
ALIAS_URL2

除非支持虚拟域，仅使用 ALIAS_URL0。这个选项的推荐设置是

ALIAS_URL0=ldap:///$V?*?sub?$R

处理 $V 标志类似于处理在“LDAP 域查找功能的工作原理”中描述的 $V 标志。如果地址的域名部分查找成功的话，URL 中的 $V 即被找到的条目中的 inetDomainBaseDn 属性或 aliasedObjectName 属性所指向的 DN 所置换。如果查找失败，别名将无法扩展（存在着 $V 标志的一个可用变体 $1V，如果查找失败，返回用户树和组树最顶层的 DN - local.ugldapbasedn 的值。）

$R 被一个适合于在用规划的过滤器置换，该规划是通过 configutil 的参数 local.imta.schematag 定义的。对于匹配的邮件地址，可能的规划值和要搜索的属性如下：

ims50    mail,mailalternateAddress,mailEquivalentAddress
nms41    mail,mailalternateAddress
sims40   mail,rfc822mailalias

local.imta.schematag 可以指定多于一个这样的值，但须用逗号隔开。如果指定了多个规划，相关属性的并被搜索以寻找一个匹配。如果目录规划不能完全匹配这些规划中的任何一个，可以通过指定 configutil 参数 local.imta.mailaliases 来覆盖被搜索的属性列表。例如：

local.imta.mailaliases=mail,mailAlternateAddresses,email

启动一次搜索，以寻找在 mail、mailAlternateAddresses 和 email 等属性上的匹配项。

默认情况下，由 $R 标志生成的过滤器只搜索给定的地址。但是，可能需要使别名表示更高层的域。因此，尽管在 desert.island.siroe.com 域中已经提供了 robinson.crusoe，还可能需要在域树的所有域中匹配其用户名。因此，如果在重写规则的评估中匹配的域是 siroe.com，那么在目录中搜索的地址是

robinson.crusoe@desert.island.siroe.com
robinson.crusoe@island.siroe.com
robinson.crusoe@siroe.com

为了达到这样的效果，必须设置 DOMAIN_UPLEVEL 选项的次最低有效位，例如添加如下行到文件 .../imta/config/option.dat 中：

DOMAIN_UPLEVEL=3


在非标准目录中的域查找
如果你不能使用由用户和组树中分离出来的标准目录结构 DC 树，可用另一种机制来寻找树的基以便在其中搜索别名。与上述在 ALIAS_URL0 中使用的 $V 不同的是，您可以调用一个映射。完成这种操作的语法是，用下面的短语来替换 URL 中的 $V ：

$|/mapping-name/mapping-argument|

| 启动和终止 CALLOUT。紧接在 $| 后的字符是映射名和参数之间的分隔符；所选择的分隔符不得同用于映射名或参数中的字符值发生冲突。mapping name 是域查找映射表的名称。mapping-argument 是域的名字，例如：$D 成为一个域的名字。


虚拟域别名的域查找
为了支持虚拟域别名，下列附加 URL 必须在文件 .../imta/config/option.dat 中定义

ALIAS_URL1=ldap:///$B?*?sub?(&(msgVanityDomain=$D)$R)
ALIAS_URL2=ldap:///$1V?*?sub?(mailAlternateAddress=@$D)


别名解析过程中的 LDAP 失败
在目录中的别名查找的结果可以是 0，1，或几个结果。如果与多于一个条目相匹配，查找被认为失败，就象没有结果返回，该地址将作为非法地址而被拒绝。对于任何原因，如果所设置的目录服务器没有一个能连接，或如果 LDAP 查找导致出错，地址将以临时失败的提示（SMTP 中 4xx 错误）而被拒绝。发送的 MTA 会稍后重试邮件，那时目录问题可能已经解决。


确定条目类型

一旦一条目在目录中被发现，它就能够被处理并且邮件能够被传递到适当的通道。处理条目的第一步是判断它是否代表了一个用户、组或者不可识别的任何类型。如果我们发现条目是一个用户或一个组，处理会正常地继续进行。如果条目既不是用户又不是组，条目以及地址即被忽略。

条目类型是通过观察条目所属的对象类来决定的。用户和组所必需的对象类是目录在用规划所暗示的，就象被 local.imta.schematag 设置所定义了一样。必须为不同的规划中一个用户或组的条目而加以定义的对象类是：

ims50:       users:    inetLocalMailRecipient + inetmailuser
             groups:   inetLocalMailRecipient + inetmailgroup

nms41:       users:    mailRecipient + nsMessagingServerUser
             groups:   mailGroup

sims40:      users:    inetMailRouting + inetmailuser
             groups:   netMailRouting + inetmailgroup

如果目录规划不能与这些规划中的任何一个完全相匹配，则可以定义自己的识别因子，以便于识别不同的用户和组的目录条目。MTA 选项 LDAP_USER_OBJECT_CLASSES 和 LDAP_GROUP_OBJECT_CLASSES 可用来指定对象类，这些对象类必须显式地作为一个条目给出并分为用户或组两类。例如，增加以下各行到 .../imta/config/option.dat 文件中。

LDAP_USER_OBJECT_CLASSES=inetLocalMailRecipient+inetmailUser,mailRecipient+nsMessagingServerUser

LDAP_GROUP_OBJECT_CLASSES=inetLocalMailRecipient+inetmailgroup,mailGroup

与设置 local.imta.schematag=ims50,nms41 下述方面是等价的：如果一个条目有对象类 inetLocalMailRecipient 和 inetmailUser，或者由对象类 mailRecipient 和 nsMessagingServerUser，该条目即被确定为一个用户。


提取用来创建传递地址的属性

一旦地址条目的类型确定了，MTA 需要从域和用户或组条目中提取一系列属性来创建发送地址并且传递邮件。来自域和用户或组条目中的下列属性中的部分或全部（请参阅表 B-1，表 B-2 和表 B-3）会被提取出来。下列表格给出了所用的必需的默认属性名，以及用来选择不同属性名的 MTA 选项。通常这些选项不会设置为同标准规划相符的默认值。但是，你的目录可能针对这些属性中的一个或多个属性使用了不同的属性名，这些属性名可通过在 .../imta/config/option.dat 中设置适当的选项来改变。

表 B-1 默认域属性和 Override 选项


LDAP 属性名称

MTA Override 选项

domainUidSeparator

LDAP_DOMAIN_ATTR_UID_SEPARATOR

mailDomainCatchallAddress

LDAP_DOMAIN_ATTR_CATCHALL_ADDRESS

mailDomainConversionTag

LDAP_DOMAIN_ATTR_CONVERSION_TAG

mailDomainMsgMaxBlocks

LDAP_DOMAIN_ATTR_BLOCKLIMIT

mailDomainReportAddress

LDAP_DOMAIN_ATTR_REPORT_ADDRESS

mailDomainSieveRuleSource

LDAP_DOMAIN_ATTR_FILTER

mailDomainStatus

LDAP_DOMAIN_ATTR_STATUS

mailRoutingHosts

LDAP_DOMAIN_ATTR_ROUTING_HOSTS

mailRoutingSmarthost

LDAP_DOMAIN_ATTR_SMARTHOST


表 B-2 默认用户属性和 Override 选项


LDAP 属性名

MTA override 选项

mailConversionTag

LDAP_CONVERSION_TAG

mailDeliveryFileURL

LDAP_PROGRAM_INFO

mailDeliveryOption

LDAP_DELIVERY_OPTION

mailhost

LDAP_MAILHOST

mailMsgMaxBlocks

LDAP_BLOCKLIMIT

mailMsgQuota

LDAP_MESSAGE_QUOTA

mailProgramDeliveryInfo

LDAP_PROGRAM_INFO

mailQuota

LDAP_DISK_QUOTA

mailRoutingAddress

LDAP_ROUTING_ADDRESS

mailSieveRuleSource

LDAP_FILTER

UID

LDAP_UID

LDAP_SPARE_1*

LDAP_SPARE_2*

* 这两个备用的 LDAP 选项很重要，因为它们可用于替代传递选项模式。具体说明，请见后面的“配置传递选项”。


表 B-3 默认组属性和 Override 选项


LDAP 属性名称

MTA override 选项

mailRejectText

LDAP_REJECT_TEXT

memberURL

LDAP_GROUP_URL2

mgrpAddHeader

LDAP_ADD_HEADER

mgrpAllowedBroadcaster

LDAP_AUTH_URL

mgrpAllowedDomain

LDAP_AUTH_DOMAIN

mgrpAuthPassword

LDAP_AUTH_PASSWORD

mgrpBroadcasterPolicy

LDAP_AUTH_POLICY

mgrpDeliverTo

LDAP_GROUP_URL1

mgrpDisallowBroadcaster

LDAP_CANT_URL

mgrpDisallowDomain

LDAP_CANT_DOMAIN

mgrpErrorsTo

LDAP_ERRORS_TO

mgrpMsgMaxSize

LDAP_ATTR_MAXIMUM_MESSAGE_SIZE

mgrpMsgPrefixText

LDAP_PREFIX_TEXT

msgpMsgSuffixText

LDAP_SUFFIX_TEXT

mgrpModerator

LDAP_MODERATOR_URL

mgrpRemoveHeader

LDAP_REMOVE_HEADER

mgrpRFC822MailMember*

LDAP_GROUP_RFC822

rfc822MailMember*

LDAP_GROUP_RFC822

uniqueMember

LDAP_GROUP_DN

* 注意，按默认方式，即可使用 mgrpRFC822MailMember 又可使用 rfc822MailMember，但不能同时使用。


提取用户/组状态
控制生成的传递地址的关键属性之一就是用户/组和域的状态。如果 mailDomainStatus 所定义的域状态是 inactive 或 deleted，则作为用户状态使用，而用户状态就不再加以检查。如果域状态是 active，则使用用户或组条目的状态。用什么属性来定义条目状态，取决于所使用的规划。如下所示：

ims50:       users:     inetuserstatus or mailuserstatus
             groups:    inetmailgroupstatus
nms41:       NO STATUS ATTRIBUTES
sims40:      users:     inetsubsscriberstatus
             groups:    inetmailgroupstatus

如果有必要，用来定义用户和组状态的属性名可以被覆盖。选项 LDAP_USER_STATUS 可以用来指定用于用户状态的属性，LDAP_GROUP_STATUS 选项可以用来指定用于组状态的属性。一旦用户或组的状态确定了，它将是 active、inactive、deleted 或 hold 中的一种。

active - 如果发现用户或组的状态是 active（活动的），处理将如“用户位置”中描述的那样继续进行。

inactive - 如果发现用户或组的状态是 inactive（非活动的），地址将以一个临时失败的提示（4xx SMTP 出错代码）而被拒绝。

deleted - 如果发现用户或组的状态是 deleted（被删除的），地址将以一个临时失败的提示（5xx SMTP 出错代码）而被拒绝。

hold - 如果发现用户或组的状态是 hold（保留），生成一个别名来使地址被重写到 hold 通道中。生成的别名被 HOLD_TEMPLATE MTA 选项所指定的模式所控制。摸板的默认值是：

$M?$2I@hold-daemon

模式中标志的含义在“使用 DELIVERY_OPTIONS 生成传递地址”中说明。如果给出的地址是

robinson.crusoe@desert.island.siroe.com

并且匹配条目给出一个在 island.siroe.com 的受托域中的 rcrusoe 的 UID，生成别名应为

rcusoe?island.siroe.com@hold-daemon

该地址与文件 .../imta/config/imta.cnf 中的同重写规则相匹配。

hold-daemon $U%$H@hold-daemon

它匹配但不修改地址，因此邮件被传递到 hold 通道。


提取 UID
目录中所有有效用户条目必须有一个 uid 属性，组条目可以有一个 uid。uid 是用来生成传递地址的。如果一个用户条目没有 uid 属性，该条目被忽略。如果一个用户有多个 uid 属性，只使用第一个。

有时, 目录中的 uid 属性可能包含了比需要的还要多的信息。例如，受托域的条目可能具有这样的形式：真实的 uid，一个分隔字符（由 domainUidSeparator 属性定义），然后是一个域（例如：uid=walter@siroe.com）。如果分隔字符出现在 uid 中，则用于构建别名的 uid 仅是分隔字符之前的那部分。

如果有必要使用除 uid 外的一个属性作为传递地址的 uid，则 LDAP_UID 选项可以用来指定该属性名。


用户位置

一旦一个用户或者组被确定为一个活动用户，MTA 必须检查确认该用户是这个 MTA 的本地用户。要认定为本地用户，一条目必须有一个 mailhost 属性，它或者与 local.hostname configutil 属性匹配，或者与 local.imta.hostnamealiases configutil 属性所指定的名称之一匹配。如果用户是本地的，MTA 进行下一步 - 确认邮件没有超越大小限制。

如果 mailhost 不能与这个 MTA 的任何名称相匹配，一个新的地址，其格式为

@mailhost:user@domain

被生成。这是一个源路由 RFC822 地址，它将通过重写规则而被处理。对于源路由地址，重写规则查将之看成是域部分。

如果一用户条目没有 mailhost 属性，那么生成的地址将使用 mailRoutingSmarthost ,但必须关联这个域：

@smarthost:user@domain

如果用户没有 mailhost 属性并且域没有 mailRoutingSmartHost，地址被放弃并生成一个 5xx 出错报告。

如果一个组没有 mailhost 属性，组将再本地处理。这个明显的矛盾是重要的，因为对于一个在入站转发 MTA 上 - 而不是在一个特定的服务器上 - 进行扩展的组来说，有时是有意义的。


提取大小限制

有一个 MTA 必须在传递地址被构建（为用户）或组被扩展之前进行的最终检查。这个最终检查保证邮件消息自身没有超越该用户的 mailMsgMaxBlocks 属性，或者，如果该属性没有设置，没有超越该域的 mailDomainMsgMaxBlocks 属性。如果邮件太大，地址会以一个 5xx size exceeded 错误被拒绝。


使用 DELIVERY_OPTIONS 生成传递地址

如果找到的条目是一个用户条目，它保留下来仅用于生成用户的传递地址，它将通过将规则重写到相应的通道而使邮件向回路由。传递地址生成处理也对组进行，但是对于组有一些额外事由将在以后的章节中说明。

通过一组模式生成传递地址。所用模式取决于为属性 mailDeliveryOption 所定义的值。对于每个合法的 mailDeliveryOption 都将生成传递地址。这个模式是由 MTA 选项 DELIVERY_OPTIONS 定义的，该选项可在文件 .../imta/config/option.dat 中定义。DELIVERY_OPTIONS 默认值是

DELIVERY_OPTIONS=*mailbox=$M%$2I+$2S@ims-ms-daemon,
&members=*,
*native=$M@native-daemon,
*unix=$M@native-daemon,
&file=+$F@native-daemon,
hold=$M?$2I@hold-daemon,
&$members_offline=*,
program=$M%$P@pipe-daemon,
forward=**,
*autoreply=$M@autoreply-daemon

DELIVERY_OPTIONS 的值是用逗号分隔的一组规则。每个规则的左边是传递方法的名称（例如：mailbox、unix、forward ），右边是构建传递地址的模式。每个规则的前面都可以有一个或两个特殊标志字符，以影响如何和何时应用规则。这些标记字符是

* 这个规则仅应用于用户

& 这个规则仅应用于组

$ 这个标志使邮件在 reprocess 通道入队这样扩展即可在脱机进行。

因此，传递方法 mailbox、native、unix 以及 autoreply 只能为用户所使用。传递方法 members 和 members_offline 只能为组所使用，传递方法 program 和 forward 可被用户和组二者使用。

右边由简单替代文本和一些标志组成，这些标志插入各种 LDAP 属性的值。请参阅“置换标志（不区别大小写）”。


生成传递地址 - 例子
设想，作为一个例子，一邮件发送到地址

robinson.crusoe+goats@desert.island.siroe.com

假定目录条目中包含属性

UID: rcrusoe@desert.island.siroe.com
mail: robinson.crusoe@desert.island.siroe.com
mailDeliveryOption: mailbox
mailDeliveryOption: native
mailDeliveryOption: program
mailDeliveryOption: forward
mailDeliveryOption: autoreply
mailProgramDeliveryInfo: capriform.msg
mailForwardingAddress: friday@desert.island.siroe.com
mailForwardingAddress: hulahula@londonbank.siroe.com

那么原始地址将生成六个别名，一个别名对应一种传递方法，即 mailbox、native、program 和 autoreply，另两个别名对应传递方法 forward。

mailbox 的模式 $M%$2I+$2S@ims-ms-daemon，是相当复杂的一个。


表 B-4 传递选项 mailbox 的模式扩展


模式组合

操作

结果

$M

生成 rcrusoe

rcrusoe

%

生成 %

rcrusoe%

$2I

生成 desert.island.siroe.com

rcrusoe%desert.island.siroe.com

+

生成 +

rcrusoe%desert.island.siroe.com+

$2S

生成 goats

rcrusoe%desert.island.siroe.com+goats

@ims-ms-daemon

生成 @ims-ms-daemon

rcrusoe%desert.island.siroe.com+goats@ims-ms-daemon

此结果地址有一个域部分，它严格匹配 ims-ms 通道的通道标志，所以被路由到该通道而无须进一步重写。

这个 native 的模式 $M@native-daemon 简单一些。

传递选项 native 的模式扩展。

表 B-5 传递选项 native 的模式扩展


模式组合

操作

结果

$M

生成 rcrusoe

rcrusoe

@native-daemon

生成 @native-daemon

rcrusoe@native-daemon

此结果地址有一个域部分，它严格匹配 native 通道的通道标志，因此被传递到该通道而无须进一步重写。

autoreply 模式 $M@autoreply-daemon 非常简单。


表 B-6 传递选项 autoreply 的模式扩展


模式组合

操作

结果

$M

生成 rcrusoe

rcrusoe

@autoreply-daemon

生成 @autoreply-daemon

rcrusoe@autoreply-daemon

此结果地址有一个域部分，它严格匹配 autoreply 通道的通道标志，因此被传递到该通道而无须进一步重写。

program 模式 $M%$P@pipe-daemon 几乎等同于：


表 B-7 传递选项 program 的模式扩展


模式组合

操作

结果

$M

生成 rcrusoe

rcrusoe

%

生成 %

rcrusoe%

$P

生成 prog

rcrusoe%prog

@pipe-daemon

生成 @pipe-daemon

rcrusoe%prog@pipe-daemon

此结果地址有一个域部分，它严格匹配 pipe 通道的通道标志，因此被传递到该通道而无须进一步重写。

forward **. 的模式只是生成属性 mailForwardingAddress 所使用的值而已,从而产生下列地址:

friday@desert.island.siroe.com
hulahula@londonbank.siroe.com

因此，发送到 robinson.crusoe 的邮件可生成下列传递地址并且被发送到下列通道：

rcrusoe%desert.island.siroe.com+goats@ims-ms-daemon      ims-ms
rcrusoe@native-daemon                                    native
rcrusoe@autoreply-daemon                                 autoreply
rcrusoe%prog@pipe-daemon                                 pipe
friday@desert.island.siroe.com
hulahula@londonbank.siroe.com


SIEVE 规则

最终从用户条目中获得的 LDAP 属性是 mailSieveRuleSource。此属性包含用户的 SIEVE 过滤器规则。在邮件到达要入队到传递通道这一点以前这些规则不被应用。尽管在 MTA 扩展别名时获得 SIEVE 过滤器，不被使用直到要到结果传递地址被扩展并被发送到 ims-ms、native、autoreply 或者 pipe 通道之后，SIEVE 规则才被使用。注意出自 non-dirsync 操作模式的行为改变：在该模式下，只有传递到 ims-ms 通道的邮件才通过 SIEVE 规则进行处理。


处理组条目

对于组这有四个可用的程序传递选项。它们是 program、forward、members 和 members_offline。

program 和 forward 是专为用户设立的。

members 和 members_offline 二者的模式是 *，它调用组扩展处理的全部功能，并将在下一部分中说明。

members_offline 规则的前面缀以 $，意味着组扩展发生在 reprocess 通道。如果入队的通道不是 reprocess 通道 - 最初入队的通道几乎肯定是 tcp_ 通道中的一个 - 则地址处理停止，原始地址被接受，邮件入队到 reprocess 通道。当 reprocess 通道运行时，采用与处理地址相同的逻辑，所不同的是，入队的通道是 reprocess 通道，因此对 members_offline 及其 $ 处理与对 members 的处理完全相同。

原则上，处理组是直接的：有一对属性可将组成员列出，或者作为电子邮件地址，或者作为判别名。无论哪种情况，那些地址都被作为部分组扩展的结果使用。

实际上，组处理所涉及的属性比上述情况要多得多，有超过一打的其它的属性能够影响组条目得处理。


处理组条目的详细信息
MTA 通过依次考虑每个不同的组处理选项来处理一组条目。选项的处理顺序是重要的。组属性可大致分为三类：

下面表格列出了组的处理属性。


表 B-8 提供组处理参数的属性


属性

说明

mailRejectText

在任何与组相关联的认证机制引发邮件被拒绝的情况下，提供作为 SMTP 响应的返回文本。这个属性应该是一个以 US-ASCII 表示的单值属性，仅服从 SMTP 协议规则。如果属性是多值的，那么只使用第一个值。如果值的表示不止一行，只采用第一行。

mgrpMsgMaxSize

陈旧的属性。应当取而代之地使用 mailmsgMaxBlocks，因为该条目在开始处理时就已检查完毕。如果邮件超过这个值（以字节计），邮件将以 message too large（邮件太大）错误而被拒绝。

mgrpAuthPassword

如果指定的 mgrpBroadcasterPolicy 需要一个密码，则需指定一个组密码并使用这个密码。

mgrpErrorsTo

信封原创者（MAIL FROM）地址会被设置成这个属性的一个值，如果指定了该属性的话。如果不指定，邮件的原创者地址保持不变。

mgrpAddHeader

（目前尚不支持）

mgrpRemoveHeader

（目前尚不支持）

mgrpMsgPrefixText

（目前尚不支持）

mgrpMsgSuffixText

（目前尚不支持）


表 B-9 邮件组访问控制属性


属性

说明

mgrpBroadcasterPolicy

指定发送一邮件到组所需要的认证级别。可能的级别是：

SMTP_AUTH_REQUIRED 或 AUTH_REQ 二者都意味着必须在用 SMTP AUTH 命令鉴别了发件人之后，才能邮递到组。

PASSWORD_REQUIRED、PASSWD_REQUIRED 或 PASSWD_REQ，无论哪个都意味着针对 mgrpAuthPassword 属性指定的列表的密码必须出现在一个邮件的 Approved:标题字段中。

NO_REQUIREMENTS 与未提供属性的效果相同，因此没有特殊要求。

mgrpAllowedDomain

多值。列出用户能提交邮件到组的域。若没有，任何域的用户都能够邮寄邮件到组。

mgrpDisallowedDomain

多值。列出用户不能够邮寄邮件到组的域。

mgrpAllowedBroadcaster

URL 在扩展时生成一个允许发送到通道列表的地址表。如果 URL 扩充的结果地址是一个组，那么这个组将扩展以生成一个详细列表，但是只限于 MTA 扩展 URL。针对每个作为这种扩展结果的地址来检查邮件的信封收件人地址，只有匹配成功的那个邮件才是被允许的邮件。

mgrpDisallowedBroadcaster

URL 在扩展时生成一个不允许发送到通道列表的地址表。如果 URL 扩充的结果地址是一个组，那么这个组将扩展以生成一个详细列表，但是只限于 MTA 扩展 URL。针对每个作为这种扩展结果的地址来检查邮件的信封收件人地址，只有匹配成功的那个邮件才是被允许的邮件。

mgrpModerator

URL 在扩展时生成一个允许发送到通道列表的地址表。如果 URL 扩充的结果地址是一个组，那么这个组将扩展以生成一个详细列表，但是只限于 MTA 扩展 URL。针对每个作为这种扩展结果的地址来检查邮件的信封收件人地址。

如果信封收件人地址与这些地址中的一个匹配，则邮件来自中介人,而且允许邮寄到组。

如果信封收件人地址不与这些地址中的任何一个相匹配，那么邮件将被发送到刚扩展的中介人地址的列表,并不以其他任何方法发送到组。也就是说, 在下面组成员表中的所有属性将被忽略，并且任何 program 或 forward 传递选项也将被忽略。


表 B-10 邮件组扩展属性


属性

说明

mgrpDeliverTo

URL在扩展时生成一个地址表。如果 URL 扩充的结果地址是一个组，那么这个组被扩展以生成一个详细列表，以此类推。重复的地址将被消除，但又可能创建相互参照的组，从而产生无限递归。MTA 为解决这个问题，只允许列表扩展嵌套到 10 层。

memberURL

另一个 URL 列表以 mgrpDeliverTo 相同的方式被扩展。

uniqueMember

组成员的判别名。每 DN 能够参照用户条目、组条目或者目录中一个子目录，在后一种情况下目录中的所有条目都将被扩展。

mgrpRFC822MailMember, rfc822MailMember

这些属性的值是组的成员邮件住址。在对于任何给定的条目，只有这些属性中的一个中被允许。对 rfc822MailMember 的支持只是为了提供对 Netscape Messaging Server 的向后兼容性。


别名缓存

所有的这种 LDAP 活动可严重影响 MTA 的性能。为了减轻这种影响，MTA 进程将缓存 LDAP 查找的结果。这样的缓存操作是受到下列各选项控制的，显示内容包含默认值：

ALIAS_ENTRY_CACHE_SIZE=1000
ALIAS_ENTRY_CACHE_TIMEOUT=600
ALIAS_ENTRY_CACHE_NAGATIVE=0

这意谓缓存条目的最大数是 1000 条，而且条目保存的最长度时间是十分钟（600 秒）。这里的缓存条目比域缓存条目要大，但是如果系统上有足够的内存，增加缓存大小可能是值得的。ALIAS_ENTRY_CACHE_NEGATIVE 控制匹配失败的别名是否缓存。默认为不缓存。不缓存失败别名会加速新用户活动，而且使这样的情况不太可能：重复的失败尝试将使得以一种影响系统的性能的频率传递同一用户。


反转地址转换

反转地址，如From:标题，通常在流经 MTA 时被规范化。（规范化意味着在标题地址中，个人名称被移到前面，而注释则被移到后面。此外，对于 From: 地址，查地址被查找，如果发现是一个 mailalternateaddress 地址，就转而使用邮件地址。）通常所应用的原则是，用户目录条目中列出第一个邮件地址就是应使用的地址。处理包括在 DC 树中查找地址的域部份，以发现要在其中查找地址的用户树和组树的子树，然後查找这样一个条目：它包含任何匹配给出的地址条目的电子邮件地址，并返回该条目的第一邮件地址。这是一个和别名处理非常相似的处理。

直接 LDAP 地址转换依赖于在文件 .../imta/config/option.dat 中设置的两个选项。

USE_REVERSE_DATABASE=4
REVERSE_URL=ldap:///$V?mail?sub?$Q

USE_REVERSE_DATABASE=4 通知 MTA 不要使用旧的反转数据库，而是改为使用直接 LDAP 机制。这个 REVERSE_URL 与 ALIAS_URL0 URL 非常相似，这在“在 LDAP 目录中寻找用户/组条目”中已有讨论。$V 标志被扩展的方式在该节中有说明。$Q 标志类似于用于标准的 ALIAS_URL0 中的 $R 标志，不同的是生成一个过滤器搜索含有地址的属性，该地址可能与 MTA 正试图匹配的反转地址匹配。被 $R 生成的过滤器依靠设置的 local.imta.schematag configutil 选项：

ims50         mail,mailalternateAddress
nms41         mail,mailalternateAddress
sims40        mail,rfc822mailalias

通过在 MTA 选项 LDAP_MAIL_REVERSES 中加以指定，可以覆盖搜索要使用的属性。

实际生成的搜索非常类似于用于别名查找 $R 标志所生成的搜索：不但搜索最初给出的地址, 而且还搜索这样的地址：它含有在 DC 树置换中实际找到的域。这在“在 LDAP 目录中寻找用户/组条目”中有说明。

如果反转地址查找失败，反转地址保持不变。

如同其它 LDAP 查找，反转地址查找的结果被缓存。缓存的大小和超时由选项控制，如下所示（包括默认值）：

REVERSE_ADDRESS_CACHE_SIZE=10000
REVERSE_ADDRESS_CACHE_TIMEOUT=600


转变到直接 LDAP 模式的意义


对于 MTA 地址转换，从 dirsync 操作模式改为 LDAP 模式几乎没有明显的影响，但处理更方便配置并且其机制更透明然而，这一转换改变了受托域的工作方式。在 dirsync 模式中，受托域的所有子域隐含地归自己拥有，这相当于在直接 LDAP 模式中设定 DOMAIN_UPLEVEL=3。然而，只有实际配置的域属于 principle domain，这相当于在直接 LDAP 模式中设定 DOMAIN_UPLEVEL=0。操作模式的这种分歧在直接 LDAP 模式不存在：你必须拿定主意，选择一种你所需要的域所有权机制。这种不同大概没有差别, 但是应该清除。

显然对系统运行的整体状况有一些影响。所影响之处是：


改变了 LDAP 负荷

dirsync 处理产生少量的但带来大量潜在的基于 LDAP 目录的检索。在直接 LDAP 模式中，MTA 在目录上生成许多小的检索。实际效果是，吞吐量的明显减少不是因为所使用的缓存。然而，施加于目录上的负荷变得更加常规，因此系统具有了更好的可扩展性。同时对于 dirsync 来说，很难将一个 MTA 扩展到超过大约 6 百万用户，而在直接 LDAP 模式中应当能够提供一千万个用户。


减少对数据库的依赖

在 dirsync 模式中，MTA 的操作依赖于许多的数据库，特别是别名数据库和域数据库。如果一个系统突然失败，这些数据库具有复杂的磁盘结构，在突遇系统故障时容易遭到损坏。对于高效系统这被证明是一个问题领域。在直接 LDAP 模式中，MTA 对数据库几乎没有依赖。


改变了整体邮件吞吐量

增加目录使用和减少数据库使用对吞吐量有一定的影响。从目录中提取信息并将之处理为要求的格式比起简单地在数据库中查找结果又更多的开销。然而，如果条目在缓存中发现，整体代价就小于在数据库中查找。这意谓如果大多数邮件的处理是针对少数用户的，而这些用户的条目又在缓存中，则吞吐量上升。如果邮件分布在一个大的用户社区，吞吐量将下降。


针对直接 LDAP 模式下邮件吞吐量的性能调整

系统性能对于别名缓存的大小很敏感，缓存的大小通过 ALIAS_ENTRY_CACHE_SIZE 设置。这个默认值是 1000，对任何重要的系统可能都太小：这些缓存条目可以比较大，大约 2K 字节，而默认值是选来避免一个小型系统超负荷的。对于一个大系统，合理取值可能高达 10,000 甚至 50,000。为使这种改变有用，增加 dispatcher.cnf 中的 MAX_LIFE_CONNS 的值是很重要的。MAX_LIFE_CONNS 应该至少两倍，或许四倍于 ALIAS_ENTRY_CACHE_SIZE，以发挥缓存的优势。从 dirsync 操作模式转变到直接 LDAP 模式，地址转换几乎没有变化, 但配置和机制更透明了。


上一页    目录    索引    下一页
(c) 2002 年 Sun Microsystems, Inc. 版权所有。

更新日期：2002 年 2 月 27 日