Life with qmail -- 中文版

5.2.2. Qpopper

如果你需要一个在mbox格式邮箱下工作的的POP后台服务程序, 你可以选用 Qualcomm的 Qpoper. 可以在这里找到 http://www.eudora.com/products/unsupported/qpopper/.

5.2.3. Binc IMAP

Andreas Hanssen 编写了 Binc IMAP服务器, Binc IMAP被设计为和qmail-pop3d使用相同的认证机制(checkpassword), 所以它很适合于qmail 邮件服务器. 和qmail-pop3d一样, 它只支持maildir格式的邮箱. 参见http://www.bincimap.org/.

5.2.4. Dovecot

Timo Sirainen 编写了Dovecot, 这是一个mbox 和 maildir 格式邮箱都予以支持的 IMAP 和 POP 服务器. 以安全为设计目标. 可以在这里访问到它 http://dovecot.procontrol.fi/.

5.2.5. imap-maildir

David R. Harris 整理了有关 University of Washington IMAP 服务器的关于 maildir 格式支持的补丁, 并且存档了安装过程. 参见http://www.davideous.com/imap-maildir/ .

5.2.6. Courier-IMAP

Sam Varshavchik 编写了一个只支持maildir邮箱的IMAP 服务器. 可以在这里 http://www.courier-mta.org/imap/ 访问.

5.2.7. Cyrus

Carnegi Mellon 大学的Cyrus 项目包含了一个IMAP 服务器, 可以在这里找到它 http://asg.web.cmu.edu/cyrus/imapd/. Rick Updegrove 写了一个qmail到cyrus的脚本用来将邮件传送给Cyrus 存储, 这个http://msgs.securepoint.com/cgi-bin/get/qmail0308/41/1/1.html.

5.3. POP 和 IMAP 客户端

5.3.1. fetchmail

fetchmail 是一个从POP或者IMAP服务器接收邮件并且再次本地注入的程序. fetchmail从qmail服务器接收邮件是没有问题的, 不过作为qmail的客户端, 要让它良好的工作, 有两个技巧.

这里是一个在qmail系统上为某个用户配置的.fetchmailrc例子:

poll mail.example.net proto pop3 nodns    user dsill with password flubgart is dave here    fetchall forcecr

这个文件指示fetchmail 通过POP3协议连接mail.example.net服务器, 使用账户dsill , 密码flubgart, 登录并接收所有邮件, 然后传送这些邮件到 dave@localhost. forcecr 标志使fetchmail将每个邮件通过SMTP方式注入本地系统前对邮件的每行以回车符结束. qmail要求如此.

5.3.2. getmail

getmail 从POP服务器接收邮件然后传送到maildir格式的邮箱. 实际上它是个Python 脚本, 所以你在使用getmail之前需要安装Python解释器.

getmail 由 Charles Cazabon 编写, 他在这个位置 http://pyropus.ca/software/getmail/ 为getmail维护了一个网页.

5.4. Multi-RCPT 与 Single RCPT 传送方式的比较

假如你是一个MTA, 你的一个用户发送一封邮件给 hostx.example.com上的三个人. 那么你有以下几种方式可以达成目标.

1. 你可以建立一个连接到hostx主机, 发送邮件的一个拷贝给第一个用户, 发送一个拷贝给第二个用户, 发送一个拷贝给第三个用户, 然后关闭连接.
2. 你可以开始三个进程, 每一个都建立一个和hostx的SMTP连接, 给每个用户发送一份邮件的副本, 然后关闭连接.
3. 你可以建立一个SMTP连接, 然后发送一个标志着传送给所有三个用户的副本, 然后关闭连接.

第一个方法明显劣于第三个. 甚至邮件很小的情况下, 整个邮件传送也需要最长的时间. 如果邮件很大, 那么将会使用很长时间并且浪费大量网络带宽.

所以, 划掉第一个.

第二个和第三个方法有点意思.

第三个方法仅仅建立一个连接到hostx, 而且只发送一个邮件的副本, 这个方式取得了最有效的带宽利用率.

第二种方式建立多个连接, 并且传送了邮件的多个副本, 这是非常浪费带宽的, 不过由于SMTP协议的现状, 这个方式可以得到更少的来回往返延迟, 从而比第三中方式更快. 而且比第三种方式更简单, 进而MTA可以被编写使用一个更直接了当的方式来传送邮件. 最后, 由于每个接收者接收到属于他自己的哪一份邮件副本, 这样才有可能让MTA实现VERPs(参见下一节)

qmail 总是使用第二种方式(single RCPT). 而且没有补丁让qmail实现第三种方式(multiple RCPT)的传送-- 因为那将是一个非常大的修补工作.

虽然有些病态的案例表明第二种方式比第三种方式更慢, 整体上, 系统的简单性和VERP取得的优势比这个更为重要.

Single RCPT 传送方式比multiple RCPT方式的确使用了更多的带宽, 不过差别常常是被夸大了的. 绝大多数邮件至多只有两个接收者, 而他们通常是本别两个主机上的用户, 对于这样的情形, multi-RCPT没有任何优势. 甚至情况特殊些, 在一个邮件列表服务器上, 相对来说, multi-RCPT看起来会有很大帮助可是潜在的增益是非常微小的, 因为SMTP利用的往往只是带宽的很细碎的份额, 在绝大多数连接上, HTTP通常占用了最大的部分.

举一个例子, 如果你的上行带宽的10%用于SMTP, 假设你的SMTP带宽由于使用multiple RCPT被降低了25%, 那么实际上应用multiple RCPT仅仅让你的SMTP需求的总带宽需求降低到了7.5%.

5.5. 关于 VERP

一旦一个邮件未能被传送, MTA的反应应该是按照信封上的返回路径(envelope return path, ERP)发送一个反弹邮件. 反弹邮件应该包括接收者的地址, 未能发送的原因, 以及故障是暂时的还是永久的信息. 尽管某些MTA做的不是正确的事情, 他们发送反弹邮件给邮件头的From区域标志的地址, 或者反弹邮件干脆不能识别接收者.

对于大多数用户到用户的邮件, 这种问题没什么大不了. 人们可以按照反弹定时和邮件内容来处理. 可是对于邮件列表, 糟糕的反弹将会严重的多. 订阅者移动, 转发邮件到他们的新地址, 如果新地址发生传送问题, 并且反弹邮件只包含了新地址, 那就无法知道到底是哪个订户的邮件被反弹了.

 如果您对本文有任何疑问或者建议，请到讨论区发表您的意见: >> 论坛入口 <<