# 郵件列表 郵件列表有如項目交流的面包和黃油。如果用戶在除了網頁之外的地方瀏覽，最有可能是項目的某一個郵件列表。不過在體驗郵件列表本身之前，他們將接觸郵件列表的界面—也就是加入列表（“訂閱到”）的機制。由此帶來了郵件列表的#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)