邮件列表

# 邮件列表 邮件列表有如项目交流的面包和黄油。如果用户在除了网页之外的地方浏览，最有可能是项目的某一个邮件列表。不过在体验邮件列表本身之前，他们将接触邮件列表的界面—也就是加入列表（“订阅到”）的机制。由此带来了邮件列表的#1法则： > *不要试图手工管理邮件列表—让软件来做。* 放弃这一点充满诱惑，开始时就设置软件来管理邮件列表看起来有些小题大做了。手动管理小型低流量的邮件列表似乎是理所当然的：你只需设置一个指向自己的订阅地址，然后当有人向其发送邮件，你把他们的邮件地址加入（或是删除）一个保存了所有地址的文本文件中。还能比这更简单的吗？ 问题在于，人们所期望的好的列表管理并非是如此简单。它不仅只是按用户的需求订阅或是退订而已。还包括防止垃圾邮件，提供发送邮件列表摘要而不是每条信息都发送的的形式，通过自动应答机提供标准列表和项目信息，以及许多其他事情。一个由人监控的订阅地址只能支持最小数量的简陋功能，而且在可靠性和反应速度上也不如软件。 现代化的列表管理软件至少提供了以下这些特性： 同时通过邮件和网页订阅 当用户订阅一个列表时，她应当能立即收到一条表示欢迎的回复，告知她订阅了什么，下一步该如何使用邮件列表软件，并且（也是最重要的）告知如何退订。当然，这个回复还应该能被定制地加入诸如项目的站点，常见问题和回答等项目的特定信息。 可选择摘要或是每个信息单独发送的订阅模式 选择摘要模式，订阅者每天会收到一封包含当天所有列表活动的邮件。对那些并不紧跟列表，不会参与讨论的用户，摘要模式更合适他们，因为这允许他们在任何时刻一次检索所有的主题，避免了随机时间到来邮件的分神。 审核特性 在邮件发送到整个列表之前的“审核”是检查邮件以确保：a) 不是垃圾邮件，以及b) 符合主题。审核必须有人参与，但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。 管理界面 不管一些其他的作用，这个特性至少能让管理员轻松地进入列表并删除一个废弃的地址。当一个订阅者的地址开始自动地对每一封列表邮件发出“我已不在这个地址”的回复时，情况就变得非常紧急了。 （有些邮件列表管理软件甚至能依靠自身捕获这种情况，并自动完成退订。） 邮件头处理 许多人在自己的电邮客户端中设置了精密的过滤和回复规则。为了利用这些优势，邮件列表管理软件能为这些人添加和处理某一种标准的邮件头（更多详细内容参阅下面）。 归档 发往被管理列表的所有邮件都会被保存，并且能够通过网页访问；有些邮件列表软件以可插入的形式提供外部归档工具如MHonArc（[http://www.mhonarc.org/](http://www.mhonarc.org/)）的接口。就像[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “归档的显著使用”](# "归档的显著使用")所讨论的，归档很重要。 所有这些的要点是为了强调邮件列表管理是一个复杂的问题，已经耗费了许多思考，而且大多数已经被解决。你确实无须成为一个专家。但你应该知道，虽然其中大部分已被解决，但总还有进步的空间，在运作一个自由软件项目的过程中列表的管理将一次次地占据你的注意力。下面我们将回答几个有关邮件列表配置的最常见问题。 ### 垃圾邮件防护 这些话从动笔到出版的这段时间里，因特网上的垃圾邮件问题很可能又严重了一倍—或至少给人的感觉是如此。有那么一段时间，就在不久之前，当时可以完全无须任何的垃圾邮件防护措就能运转一个邮件列表。偶尔会有那么几封，只能构成小小的烦恼。好日子已经一去不复返了。现在如果邮件列表没有垃圾防护措施，很快就会被乱七八糟的邮件淹没，以至于不可用。必须实施垃圾防护。 垃圾防护分为两种类型：防止垃圾邮件出现在你的邮件列表中，防止你的邮件列表成为垃圾制造者地址收割机获取新邮件地址的一个源。前者更重要，所以我们首先研究。 ### 过滤邮件 垃圾邮件防护有三种最基本的技术，大部分的邮件列表软件都会提供，最好能串联使用： 1. **只自动允许来自列表订阅者的邮件。** 只要使用就有效，因为通常只需要在邮件列表软件的配置中做一点小小的改动，所以只需要很少的管理投入。但注意，那些不能自动认可的邮件不能简单地销毁了事。相反，必须传递给审核程序，有两个原因。首先你希望允许非订阅者的邮件。仅仅想问一个问题或是提供建议的人，不应该只为了发一封邮件而需要订阅整个列表。其次，有时甚至订阅者都有可能从非订阅时用的地址发出一封邮件。邮件地址不是鉴别人的可靠方法，它不该被如此对待。 1. **通过垃圾过滤软件过滤邮件。** 如果邮件列表软件允许（大部分是），你能用垃圾过滤软件来获得过滤后的邮件。由于在垃圾制造者和过滤器编写者之间进行着一场永不停息的军备竞赛，自动垃圾过滤从来不是也永远不会是完美的。然而，它可以大大减少进入审核队列的邮件数量，因为更长的列表需要更长的人工处理时间，一定程度的自动过滤总是有益的。 这里没有空间来详细地介绍垃圾过滤的设置。你应该查阅你的邮件列表软件的文档（见本章后面的[the section called “软件”](# "软件")）寻求答案。列表软件通常会有一些内置的垃圾防护功能，但也许你想要添加一些第三方的过滤器。推荐两个我有良好体验的软件：SpamAssassin ([http://spamassassin.apache.org/](http://spamassassin.apache.org/)) 和SpamProbe ([http://spamprobe.sourceforge.net/](http://spamprobe.sourceforge.net/))。这并非是对众多的其他开源垃圾过滤器的不敬，其中的一些显然也是非常好的。只是这两个是我曾经亲身使用过的，并且它们让我很满意。 1. **审核。** 由于不是列表订阅者的原因而未能自动许可的邮件，就会根据设置进入垃圾过滤软件，最后一个阶段将是*审核*：邮件将被发送到一个特殊的地址，那里会有人来检查和决定是许可还是拒绝。 许可一个邮件有两种形式：你可以只是这一次接受它，或你可以告诉列表软件为这一封邮件同一发送者以后的所有邮件开绿灯。为了减少以后的审核负担，你很可能会选择后者。具体如何许可在不同的系统之间有很大的差异，但是通常的形式是向一个特殊的地址发送一条带有命令“accept”（代表这一次许可）或是“allow”（允许这次以及以后的邮件）的回复。 拒绝通常只需简单的忽略所审核的邮件即可。如果列表软件没有收到确认有效的邮件，它不会让邮件通过并出现在列表上，所以简单地扔掉审核邮件就能达到目的。有时你还有其他选择，返回“reject”或是“deny”命令来杜绝以后来自同一个发送者的邮件进入审核程序。但这么做通常没什么意义，因为大部分需要审核处理的都是垃圾邮件，而垃圾邮件制造者不太会从同一个地址两次发出垃圾邮件。 确保审核*只*被用在过滤垃圾邮件和明显是和主题无关的消息上，比如有时会有人意外地在一个错误的邮件列表中发送了邮件。审核系统通常给你一个直接同发送者联系的途径，但是不要用这种方式来回答属于邮件列表本身的问题，即使那些答案就在你的头脑之中。如果这么做了，将会剥夺项目社区了解人们正在问那些类型问题的具体形式，剥夺它们自己回答问题或者获得答案的机会。邮件列表审核除了严格确保列表中没有垃圾和同主题无关的邮件，没有其他了。 ### 归档中的地址隐藏 为了防止你的邮件列表成为垃圾邮件发送者的地址源，一个常见的技术是混淆用户的邮件地址，例如通过替换 > `jrandom@somedomain.com` 为 > `jrandom_AT_somedomain.com` 或 > `jrandomNOSPAM@somedomain.com` 或一些类似的明显的（对人类来说）加密。因为垃圾邮件地址收割器通常会遍寻网络—包括你的邮件列表的网络归档—它们会查找包含“@”的字符串，对地址加密是为了让人们的邮件地址对垃圾邮件发送者来说不可见或不可用。这对防止垃圾邮件发送者将邮件直接发送到邮件列表本身无用，但它可以防止直接发送到用户个人地址的垃圾邮件的增加。 地址隐藏可能存在争议。许多人很喜欢，如果你的归档不能自动支持，他们会很惊讶。还有些人认为这样太不方便了（因为人们需要在使用之前转化地址）。有时候用户断定这样做不能产生预期的效果，因为收割器理论上可以弥补任何不变的加密模式。然而，有一个实验证据可以证明地址隐藏*是*有效的，见[http://www.cdt.org/speech/spam/030319spamreport.shtml](http://www.cdt.org/speech/spam/030319spamreport.shtml)。 理想情况下，邮件列表软件为每个订阅者提供选择的机会，通过特别的yes/no头，或者通过订阅者列表帐户的参数选择设置。然而，我不知道有哪个软件提供了每订阅者或每邮件的选项，因此现在列表管理员必须为所有人作出决定（假定归档程序已经提供了这些特性，就不存在这个问题了）。我倾向于适度使用地址隐藏。一些人对于将自己的邮件发布到网页上或其他收割器可能会搜索的地方会非常小心，他们会因为邮件列表归档暴露它们关心的内容而感到失望，归档用户中的地址隐藏带来的不便是轻微的，因为如果你希望联系某个人，将混淆的邮件地址恢复非常容易。但是最后还是要牢记，这是一场军备竞赛：在你阅读到本文的事以后，收割器可能已经得到了进化，能够识别大多数常见的隐藏形式，我们可以想一些其他形式。 ### 身份和头管理 列表订阅者经常希望将来自列表的邮件存放到特定的目录，能够和其他邮件区分开。他们的邮件阅读软件可以自动检查邮件的*头*。这个头是在邮件的顶部，用来指明发送者、接收者、主题、日期和其他邮件相关的东西。某些头是众所周知的，而且是必须有的： ~~~ From: ... To: ... Subject: ... Date: ... ~~~ 还有一些是可选的，尽管也是标准的头。例如，邮件不必有 ~~~ Reply-to: sender@email.address.here ~~~ 头，但大多数情况下都有，因为这可以保证接收者（当作者必须从一个不能接收邮件的地址发送邮件的时候这特别有用）能够联系到原作者。 一些邮件阅读软件提供了基于主题头模式的易用界面，可以用来过滤邮件。这导致人们会要求邮件列表为所有的主题提供自动前缀，所以他们可以设置的阅读器查找前缀并自动将文件归入正确的文件夹。如果原来的作者是这样写： ~~~ Subject: Making the 2.5 release. ~~~ 但是列表中显示的邮件会是： ~~~ Subject: [discuss@lists.example.org] Making the 2.5 release. ~~~ 尽管大多数列表管理软件提供这个选项，但我强烈反对开启这个功能。因为这个问题可以通过更自然的方式轻松解决，而且主题字段消耗的空间也太多了。有经验的邮件列表用户通常会扫视每天的列表邮件的主题，然后决定阅读和/或回复哪些邮件。主题中前置的列表名称会使得主题的正式内容脱离屏幕，无法看到。这混淆了人们赖以决定是否打开邮件的信息，从而减弱了邮件列表的整体功能。 我们不会处理主题头，而是让你的用户利用其他标准的头，以To头说起，可以用来说明邮件列表名称： ~~~ To: <discuss@lists.example.org> ~~~ 任何可以过滤主题的邮件阅读器一定也能轻易的处理To。 还有一些其它的邮件列表期望的可选但标准的头。根据这些头过滤比利用“To”或“Cc”头更加可靠；因为这些头是邮件列表软件本身为每个邮件添加的，一些用户会依赖他们的出现： ~~~ list-help: <mailto:discuss-help@lists.example.org> list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org> list-post: <mailto:discuss@lists.example.org> Delivered-To: mailing list discuss@lists.example.org Mailing-List: contact discuss-help@lists.example.org; run by ezmlm ~~~ 绝大部分是自解释的，更多解释可以看[http://www.nisto.com/listspec/list-manager-intro.html](http://www.nisto.com/listspec/list-manager-intro.html)，或者如果你觉得不够详细，正式的规范可以看[http://www.faqs.org/rfcs/rfc2369.html](http://www.faqs.org/rfcs/rfc2369.html)。 如果你有一个名为“list”的邮件列表，请注意这些头是如何暗示的，然后你也有了管理地址“list-help”和“list-unsubscribe”。除此之外，用来加入的“list-subscribe”和接触列表管理员的“list-owner”也非常常见。取决于你所使用的管理软件，也可能会设置一些其它的管理地址；文档应该会有详细介绍。通常情况下，每个新用户在订阅时都会收到自动的“欢迎邮件”，其中会完整解释所有的特别地址。你可能有这个欢迎邮件的一份拷贝。如果你没有，可以问其他人获取一份拷贝，这样你就知道当你的用户到来时，他们会看到什么。手中有一份拷贝，你就可以回答邮件列表功能的问题，更好一点，可以放置到网页上。这样当有人丢失了自己的指导并询问“我如何从列表退订时？”，你就可以将URL发送个他。 一些邮件列表软件会在每个邮件的底部追加退订信息。如果有这个选项，请打开它。这样只会导致每个邮件有一段额外的行，在一个无害的位置，可以帮助你节省很多时间，减少了给你，或者更坏的情况，给邮件列表发邮件询问如何退订的人数！ ### 伟大的Reply-to辩论 在前面的[the section called “避免私下讨论”](# "避免私下讨论")，我强调了保持在公共论坛讨论的重要性，谈论了如何防止私下邮件讨论的一些主动措施，除此之外，本章将会讨论如何设置项目交流软件来更好的做这件事。因为如果邮件列表管理软件提供了一个方法来自动导致讨论保持在列表中，你会认为开启这个功能是显而易见的选择。 好的，有时候也不是如此认为。尽管有这个特性，但是它却有严重的Bug。问题是无论你是否在邮件列表管理中使用这个功能都会成为最热的辩论—诚然，这不大可能成为你城市里的晚间新闻那样的论战，但它会在自由软件项目中一次次的爆发。下面，我将描述这个特性，提供两方面的主要论点，提出我能作出的建议。 这个特性本身非常简单：如果你愿意，邮件列表软件可以在每个邮件中自动设置转向到邮件列表的Reply-to头。也就是无论原来的发送者设置了什么Reply-to头（或者他们没有设置），当邮件列表的订阅者看到邮件时，它的头将会包含列表地址： ~~~ Reply-to: discuss@lists.example.org ~~~ 从表面上看非常好。因为实际上所有的邮件阅读软件会注意到Reply-to头，这样当任何人回复邮件时，他们的回复都会自动来到整个列表，而不仅仅是邮件的发送者。虽然回复者仍然可以手工修改回复的地址，但重要的是*缺省的*回复会指向列表。这是通过技术鼓励协作的完美实例。 不幸的是，也有一些缺点。首先是*找不到回家的路*问题：有时候原来的发送者会把“真正的”邮件地址存放到Reply-to字段，通常是某种原因他们不能通过发送邮件的地址接收邮件。一直从同一个地址读取和发送的人们不会有这种问题，甚至会惊讶有这种情况。但是对于有特别的邮件设置，或者不能设置他们所看邮件的From地址（或许因为他们在工作时发送，而且不能通过IT部门修改配置）时，使用Reply-to可能是保证回复能够收到的唯一方法 。当此类人在未订阅的邮件列表中发送邮件时，她的Reply-to设置就成为了关键信息。如果列表软件覆盖了它，她可能就看不到回复了。 第二个可以预期的缺点，从我的观点看是Reply-to处理最有力的反对论点。大多数有经验的邮件用户会习惯于两个回复的基本方法：*reply-to-all*和*reply-to-author*。所有现代的邮件阅读软件对于两个动作都有单独的按键。用户知道如果是回复到所有人（也包括列表），他们会选择reply-to-all，如果是私下回复到作者，他们应该选择reply-to-author。尽管你希望鼓励人们尽可能回复到列表，但确实有情况回复者需要有权利私下回复—例如，他们希望和邮件的原作者说一些机密的事情，可能不适合出现在公共列表中。 现在考虑一下如果列表覆盖了发送者的Reply-to时会发生什么。回复者点reply-to-author，希望向原发送者私下发送一个邮件。因为那是他所预期的行为，所以就可能不会小心查看新邮件的接收地址。他编写了他的私人的、机密信息，可能会说一些对列表中的人来说很尴尬的内容，并点击发送键。出乎意料的是，几分钟之后他的信息出现*邮件列表中！*诚然，他应该仔细查看接收字段，对于Reply-to头不要有任何设想值。但是作者几乎会肯定将Reply-to设置为他们的个人地址（更确切地说，他们的软件做了设置），许多资深的邮件用户都会期望这样。实际上，如果一个人直接将Reply-to设置为其他地址，他通常会邮件的正文提及这一点，这样人们就不会为回复所发生的事情感到惊讶了。 因为可能出现的严重后果，我的观点是保证列表管理软件决不要碰Reply-to头。这是一个使用技术来鼓励协作的实例，但是对我来说有潜在的危险副作用。然而，在论战的另一面也有强有力的论据。无论你选择何种方式，你都会在列表中看到有人问你为什么不选择另一种方式。因为你肯定不希望这成为邮件列表中的主要讨论，所以最好准备好回应，诸如此类结束讨论而不是鼓励讨论。请确认你*不是*坚持认定你的决定，也就是无论是哪个，它都应该明显是唯一正确和明智的选择（即使你认为那是一个事实）。相反，指出这是一个老争论了，两方面都有好的论点，没有能够满足所有用户的选择，因而你只是做出了你能做出的最佳决定。有礼貌的告知不要再炒冷饭了，除非有一些独特的新内容，然后不必再参与讨论并希望它能够自然死亡。 有些人会建议开展一个投票。如果你愿意你可以这样做，但是这个情况下我不认为这是一个满意的解决方案。对于某个人因为出人意料的行为模式的惩罚是巨大的（不小心的将私有邮件发送到公共列表），而对于所有其他人的不便是相对轻微的（偶尔需要提醒某人回复到整个列表而不仅仅是你），多数票是什么并不清楚，即使能得到多数票，少数者应该承担这样的危险吗？ 这里我没有涉及问题的所有方面，仅仅包含了看起来最重要的。完整的讨论，请看这两篇权威的文档，当人们遇到争论时经常会引用它们： - **勿动eply-to**, *by Chip Rosenthal* [http://www.unicom.com/pw/reply-to-harmful.html](http://www.unicom.com/pw/reply-to-harmful.html) - **把Reply-to设置为列表地址**, *by Simon Hill* [http://www.metasystema.net/essays/reply-to.mhtml](http://www.metasystema.net/essays/reply-to.mhtml) 无论你偏爱上面的哪一条，我不认为此问题有所谓的“正确”答案，也会很乐意参与到*设置*Reply-to的许多列表。最重要的事情是你尽早确立一种方式，之后再也不要陷入到争论之中。 ### 两个幻想 将来有一天，有些聪明人会在邮件阅读器实现一个*reply-to-list*键。它可以使用前面提到的一些自定义的列表头来指出邮件列表的地址，然后会将回复仅指向到邮件列表，同时消除所有的其他接收地址，因此，无论如何大多数都是订阅列表的地址。最终，其他邮件阅读器也会采用这个特性，整个争论也就可以偃旗息鼓了。（实际上，[Mutt](http://www.mutt.org/)邮件阅读器已经提供了这个特性。[[13](#)]） 一个更好的解决方案是让每个订阅者自己选择是否进行Reply-to处理。如果希望经过Reply-to处理（自己与他人的邮件），可以要求，而如果不希望，则可以设置为Reply-to不变。然而，我不知道有任何列表管理软件提供这个每订户基础的设置。我们还是只能使用全局设置。[[14](#)] ### 归档 运转列表的软件都有自己特定的设置邮件列表归档的技术细节，超出了本书的范围。当选择归档时，请考虑这些特性： 立刻更新 人们经常会引用在上个小时所做的发布归档。如果可能，归档器必须能够立刻归档每个发布，这样发布出现在邮件列表时，它也就出现在了归档中。如果没有这个特性，至少应该将其设置为每小时更新一次。 （默认情况下，一些归档器会每夜更新，对于一个活跃的邮件列表这有点太滞后了。） 引用稳定性 一旦一个信息已经归档到特定URL，它应该在相同的可访问URL，并尽可能的永远保持。即使归档重建，从备份中恢复，或者其他修正，任何已经公开的URL应该保持相同。稳定引用可以让Internet上的搜索引擎能够索引归档，可以方便用户查找答案。稳定引用重要的另一个原因是因为邮件列表经常会在Bug跟踪（参考本章后面的[the section called “Bug跟踪”](# "Bug跟踪")）或其他项目的文档中被引用。 理想情况下，邮件列表应该能够包含一个信息归档的地址，或者至少在分发到接收者的信息头上有URL的信息特定的部分。这样人们就有了信息的拷贝，已经知道了归档的位置，而无须实际访问归档，这样做很有用，因为任何操作都需要花费网络浏览器的时间。我不知道是否有邮件列表软件实际支持这个特性；不幸的是，我用过的都不行。然而，这是我要寻找的（或者，如果你正在写邮件列表软件，这应该是一个可以考虑实现的特性）。 备份 如何备份归档必须相当清楚，而恢复方法也不能太难。换一句话说，不要把归档器当作黑盒子。你（或者你项目中的某个人）应当知道信息存放在什么地方，以及如何在必要时从信息存放处重新生成归档页。这些归档是珍贵的数据—失去了它们，就像失去了项目集体记忆中美好的一部分。 线索支持 应该能够从任意单独的信息进入原来信息所归属的*线索*（一组关联的信息），每个线索必须拥有自己的URL，与线索中的其他信息区分开来。 可搜索性 一个不支持搜索的归档器—针对信息内容、以及作者和主题—接近于无用。注意某些归档器只是将此工作交给了诸如[Google](http://www.google.com/)的第三方搜索引擎。这是可以接受的，但是直接的搜索支持通常会更加易于调整，例如我们可以指定搜索匹配的是主题行还是正文。 上面是一个技术检查列表，可以帮助你评估和设置归档器，本章后面将讨论如何让人们*利用*归档器来使项目获益，特别是在[the section called “归档的显著使用”](# "归档的显著使用")。 ### 软件 这里是一些可以进行列表管理和归档的开源工具。如果你的项目主机已经有默认的设置，你可能无法决定一个工具。但是如果你必须自己安装一个，这些是可以选择的。我实际使用过的包括ailman、Ezmlm、MHonArc和Hypermail，这并不是意味着其他工具不好（当然可能有其他一些工具只是我碰巧没有找到，所以不要把这当作完全的列表）。 邮件列表管理软件： - **Mailman** — [http://www.list.org/](http://www.list.org/) （有内置的归档器，以及外挂其他归档器的钩子。） - **SmartList** — [http://www.procmail.org/](http://www.procmail.org/) （专门用于Procmail邮件处理系统。） - **Ecartis** — [http://www.ecartis.org/](http://www.ecartis.org/) - **ListProc** — [http://listproc.sourceforge.net/](http://listproc.sourceforge.net/) - **Ezmlm** — [http://cr.yp.to/ezmlm.html](http://cr.yp.to/ezmlm.html) （设计与[Qmail](http://cr.yp.to/qmail.html)邮件投递系统协同工作。） - **Dada** — [http://mojo.skazat.com/](http://mojo.skazat.com/) （不管网站因为什么奇怪的想法希望掩盖这个事实，这确实是一个自由软件，使用GNU许可证发布，也有内置的归档器。） 邮件列表归档软件： - **MHonArc** — [http://www.mhonarc.org/](http://www.mhonarc.org/) - **Hypermail** — [http://www.hypermail.org/](http://www.hypermail.org/) - **Lurker** — [http://sourceforge.net/projects/lurker/](http://sourceforge.net/projects/lurker/) - **Procmail** — [http://www.procmail.org/](http://www.procmail.org/) （SmartList的伴侣软件，也可以是通用的邮件处理系统，很显然，被配置为归档器。） [[13](#)] 在本书出现后不久，[Michael Bernstein](http://www.michaelbernstein.com/)告诉我：“也有一些Mutt之外的其他客户端实现了reply-to-list功能。例如，Evolution的一个快捷键有这个功能，但不是一个按钮（Ctrl+L）。” [[14](#)] 写到这里，我已经发现至少有一个列表管理系统提供了这个特性：[Siesta](http://siesta.unixbeard.net/)。请看这篇相关的文章：[http://www.perl.com/pub/a/2004/02/05/siesta.html](http://www.perl.com/pub/a/2004/02/05/siesta.html)