由于 Majordomo 负责管理电子邮件列表，因此 Majordomo 非常依赖 MTA（邮件传输代理），例如 Sendmail。 还有其他 MTA，例如 Smail 和 Qmail； 但是，Sendmail 是最古老和最常见的。 本节向读者介绍 Sendmail 中在使用 Majordomo 时有用或需要配置的区域。
Sendmail 别名文件（通常是/etc/aliases）用于为电子邮件地址创建别名。 例如，安装 Majordomo 后，aliases 文件中的条目通常如下所示：
此条目表示发送到
majordomo-owner@host.com的所有邮件实际上将发送到
jarchie@host.com。 请注意，没有必要附加
@host.com到
jarchie，因为两个用户都在同一主机上。 如果希望将消息重定向到不同主机上的不同用户，则必须添加
@host.com部分。
别名文件中的另一种类型的条目允许将电子邮件重定向到文件中列出的多个地址
testlist: :include:/usr/local/majordomo-1.94.5/lists/testlist |
此条目声明发送到
testlist@host.com的任何消息都将被重定向到文件
/usr/local/majordomo-1.94.5/lists/testlist中列出的所有地址。
testlist文件可能如下所示：
johnarchie@emeraldis.com
srobirds@yahoo.com
acreswell@geocities.com |
Majordomo 能够通过利用此功能来添加或删除列表中的地址。 当一个
subscribe请求被处理时，用户的电子邮件地址将附加到
testlist文件中； 当一个
unsubscribe请求被处理时，用户的电子邮件地址将从
testlist文件中删除。 还可以通过使用文本编辑器（如
vi）编辑文件来手动添加或删除地址。
由于 Majordomo 需要能够处理通过电子邮件发送给它的命令，因此 Sendmail 必须能够执行 Majordomo 程序并将消息传递给它。 这是通过将另一种类型的条目添加到aliases文件中来完成的
majordomo: "|/usr/local/majordomo-1.94.5/wrapper majordomo" |
程序
/usr/local/majordomo-1.94.5/wrapper是一个包装器（SUID
majordomo和 SGID
majordomo或
daemon，具体取决于配置），它运行 Majordomo 程序。 别名条目的第二部分周围的引号用于告诉 Sendmail 该条目的这一部分是一个语句； 如果
wrapper和
majordomo中列出的所有地址。
|之间没有空格，则引号是不必要的。
| 被称为“管道”；它用于告诉 Sendmail 通过标准输入将电子邮件发送到 wrapper。（由于 wrapper 在这里所做的只是调用
majordomo，因此实际上是将电子邮件发送到 Majordomo。）wrapper 接受一个参数——它应该执行的程序的参数。（第一个之后的任何参数都将传递给 wrapper 正在执行的程序。）出于安全原因，wrapper 仅执行位于 Majordomo 目录中的程序，
/usr/local/majordomo-1.94.5/。 此限制防止程序员使用 wrapper 运行不应具有 Majordomo 权限的程序。（例如，
wrapper /bin/vi 将允许任何用户编辑任何 Majordomo 配置文件。）当消息发送到
majordomo@host.com时，Sendmail 启动 wrapper，而 wrapper 又启动
majordomo，并且 Sendmail 通过标准输入将消息发送到
majordomo 脚本。 然后，Majordomo 从消息中提取命令并适当地响应。
由于其神秘的语法，sendmail.cf可能是所有配置文件中最令人恐惧的文件。 在安装majordomo时，没有绝对必要编辑sendmail.cf；但是，一些功能非常有用。 除非必须对sendmail.cf进行重大更改（值得庆幸的是，Majordomo 不需要），否则编辑文件并不那么困难。 需要做的就是向文件中添加额外的行。
为 Majordomo 别名创建一个单独的文件，例如/usr/local/majordomo-1.94.5/majordomo.aliases，通常是个好主意。 这可以通过在sendmail.cf文件中来完成的
OA/usr/local/majordomo-1.94.5/majordomo.aliases |
的末尾添加一行来轻松完成。
/usr/local/majordomo-1.94.5/majordomo.aliases要拥有一个
/usr/local/majordomo-1.94.5/majordomo.aliases.db）。 完成此操作的最简单方法是继续为 Sendmail 创建一个空数据库以进行覆盖。
[root@kes majordomo-1.94.5]# touch majordomo.aliases.db
[root@kes majordomo-1.94.5]# chmod 644 majordomo.aliases.db |
解决此问题的另一种方法是简单地在
majordomo.aliases文件中创建
/etc/目录中，而不是 Majordomo 主目录中。
对于某些设置，Sendmail 使用的一些安全措施可能会阻止 Majordomo 正常工作。 显然，必须关闭这些安全功能。
Sendmail 经过编程，使人们难以伪造“完美”的电子邮件。 例如，当用户通过 SMTP 发送消息时，通常会记录源 IP 地址，并且当用户通过直接将消息提供给 Sendmail 并使用 sendmail -f 指定发件人时，Sendmail 会在标头中放置警告消息，指定真正发送消息的用户。 但是，某些程序需要能够伪装成其他用户发送消息，并且在标头中附加此额外的安全行令人讨厌。 Sendmail 通过拥有受信任的用户来处理此问题。 为了使 Majordomo 的 resend 脚本正常工作，majordomo必须是 Sendmail 受信任的用户，因为该程序需要从其他用户重新发送邮件。
使 Majordomo 成为受信任用户的一种方法是添加行
到
sendmail.cf文件中。
如果 Sendmail 正在使用 smrsh，那么唯一可以执行的程序是那些在/etc/smrsh/目录下的程序。 从aliases文件中运行 wrapper 的最佳解决方案可能是创建一个从/etc/smrsh/wrapper到/usr/local/majordomo-1.94.5/wrapper.
[root@kes smrsh]# ln -s /usr/local/majordomo-1.94.5/wrapper wrapper |
开始的符号链接。
/etc/smrsh/目录中。
[root@kes smrsh]# mv /usr/local/majordomo-1.94.5/wrapper ./ |
如果安全不是主要问题，则可以禁用安全 shell。 一种相当粗略的方法是简单地删除
/usr/sbin/smrsh并复制或链接
/bin/sh到其位置。
[root@kes sbin]# rm -f smrsh
[root@kes sbin]# ln -s /bin/sh smrsh |
一种更好（但更困难）的方法是编辑
sendmail.cf。 将引用从
/usr/sbin/smrsh
Mprog, P=/usr/sbin/smrsh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/,
T=X-Unix,
A=sh -c $u |
到
/bin/sh
Mprog, P=/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/,
T=X-Unix,
A=sh -c $u |
如果您计划让非 root 用户添加和管理邮件列表，则需要使majordomo.aliases文件组可写。 但是，出于安全原因，Sendmail 不允许此配置（请参阅第 2.4 节）。 要禁用此安全功能，请添加行
O DontBlameSendmail=GroupWritableAliasFile |
到
sendmail.cf文件。 此外，列表目录必须是组可写的才能添加列表，但出于类似的安全原因，Sendmail 不允许此设置。 要禁用此安全功能，需要添加行
O DontBlameSendmail=IncludeFileInGroupWritableDirPath |
到
sendmail.cf配置文件。
安全性与便利性成反比； 唯一安全的机器是任何人都无法访问的机器。 当 Sendmail 的某些安全功能被禁用时，机器将不可避免地变得不太安全。 但是，重要的是要了解基本的安全风险，以便确定便利性是否超过了可能的安全漏洞。
如果用户具有访问别名文件的写入权限，则 她应该是受信任的用户。 通过将条目放入别名文件中（例如用于执行 wrapper 的条目），用户可以使用 Sendmail 的权限执行任何程序（daemon或者，在旧版本中，root）。 这种失误将允许人们删除或更改属于daemon的文件的权限（在别名文件中使用 rm 或 chmod 命令）。 在某种程度上，可以通过使用 smrsh 来避免这种可能性； 但是，仍然必须小心/etc/smrsh/目录中。
中有什么文件。 另一个重要的安全问题是，可以访问别名文件的用户可以通过文件重定向（使用daemon而不是>>或>）附加或写入属于|的文件。 即使如此，也可以通过在sendmail.cf文件中添加一行来解决此漏洞，该行限制可以通过别名文件写入哪些文件。 添加行
O SaveFileEnvironment=/path/to/safe/files |
到
sendmail.cf文件或添加
define(`confSAFE_FILE_ENV',`/path/to/safe/files') |
到
sendmail.mc文件。 但是，这种策略只在用户和
daemon之间留下了一层薄薄的安全层。 一个更好的主意是让别名文件只能由 root 用户写入，并创建一个 SUID root 程序来添加和删除 Majordomo 相关的别名。
对于包含或 .forward 文件，命令或重定向以拥有该文件的用户身份运行。 因此，如果文件是组可写的，则该组的成员可以以拥有该文件的用户身份执行命令。 换句话说，majordomo组中的任何用户都可以以 Majordomo 的身份执行命令。 但是，由于在没有 shell 的情况下创建了majordomo用户，因此将不会处理majordomo.
如果用户具有对目录的组写入权限，例如/etc/，则用户可以简单地移动任何文件并在其位置创建一个新文件。 攻击可能如下所示：
[mallory@kes etc]$ mv aliases ...
[mallory@kes etc]$ vi aliases |
然后，用户可以创建自己的别名！ 但是，可以通过 Sendmail 的安全检查来防止这种攻击，该检查用于检查不安全的组可写路径。 这种攻击也适用于具有不安全路径的包含和 .forward 文件。
对于 Majordomo，majordomo组中的用户已经可以访问包含文件，因此这实际上不会损害安全性。 但是，管理员应小心防止将来出现这些不受欢迎的不安全组可写目录路径，因为 Sendmail 不会 检查它们。
不幸的是，复杂的垃圾邮件发送者可以使用 EXPN SMTP 命令扩展邮件列表。 因此，管理员在服务邮件列表时应禁用此功能。 添加行
到
sendmail.cf文件或
define(`confPRIVACY_FLAGS',`noexpn') |
到
sendmail.mc文件中。