Do czasu, gdy te słowa zostaną opublikowane, problem spamu w Internecie zapewne urośnie dwukrotnie—lub przynajmniej można będzie odnieść takie wrażenie. Jeszcze nie tak dawno temu można było prowadzić listę dyskusyjną bez żadnych filtrów antyspamowych. Od czasu do czasu zagubiona wiadomość pojawiła się na liście, ale działo się to na tyle rzadko, że nie sprawiało większego kłopotu. Te czasy już minęły. Dziś lista dyskusyjna, która nie stosuje zabezpieczeń antyspamowych, zostanie szybko zalana śmieciowymi mailami tak, że stanie się nieużywalna. Ochrona antyspamowa jest koniecznością.

Ochronę antyspamową można podzielić na dwa rodzaje: zapobieganie pojawianiu się spamu na liście i uniemożliwianie spamerom uzyskiwania nowych adresów email z listy. Pierwsza z nich jest bardziej istotna, więc zajmiemy się nią najpierw.

Uczestnicy listy na ogół chcą przechowywać wiadomości z listy w osobnym folderze, oddzielnie od reszty poczty. Ich programy pocztowe mogą automatycznie filtrować wiadomości opierając się na nagłówkach. Nagłówki to pola na samym początku wiadomości określające nadawcę, odbiorcę, temat, datę i różne inne informacje opisujące wiadomość. Niektóre nagłówki są dobrze znane i praktycznie obowiązkowe:

From: ...
To: ...
Subject: ...
Date: ...

Inne są opcjonalne, choć wciąż dość powszechne. Na przykład maile nie muszą koniecznie zawierać nagłówka

Reply-to: nadawca@tutaj.adres.email

, ale większość zawiera, ponieważ ułatwia to kontakt z autorem (jest to szczególnie przydatne gdy autor wysyła wiadomość z innego adresu niż ten, na który oczekuje odpowiedzi).

Niektóre programy pocztowe oferują łatwy w obsłudze interfejs do filtrowania wiadomości w oparciu o wzorzec w nagłówku Subject (temat). Z tego powodu wielu użytkowników proponuje, aby lista automatycznie dodawała odpowiedni przedrostek do każdego tematu, dzięki czemu będą mogli filtrować wiadomości do folderów na podstawie tego przedrostka. Chodzi o to, że gdy autor napisze:

Subject: Przygotowanie wydania 2.5.

na liście dyskusyjnej pojawi się wiadomość o następującym temacie:

Subject: [discuss@lists.example.org] Przygotowanie wydania 2.5.

Wprawdzie większość oprogramowania do zarządzania listami oferuje taką opcję, nie zalecam jednak jej stosowania. Problem, w którym ta metoda pomaga może zostać rozwiązany innymi, znacznie lepszymi sposobami, a przestrzeń w temacie jest zbyt cenna, aby ją marnować. Doświadczeni użytkownicy list dyskusyjnych na ogół przeglądają tematy nowych wiadomości na liście, aby zdecydować które z nich przeczytać lub i na które odpisać. Dołączanie nazwy listy w temacie może spowodować, że prawdziwy temat nie zmieści się na ekranie. Wtedy informacja na której ludzie polegają, aby zdecydować którą wiadomość otworzyć, staje się trudno dostępna, a użyteczność listy spada.

Zamiast modyfikować nagłówek Subject, naucz użytkowników korzystania z innych standardowych nagłówków, zaczynając od nagłówka To, który powinien zawierać adres listy dyskusyjnej:

To: <discuss@lists.example.org>

Każdy program pocztowy potrafiący filtrować po temacie powinien też równie łatwo filtrować pocztę po nagłówku To.

Istnieje też kilka innych opcjonalnych, ale często spotykanych nagłówków, których można się spodziewać po listach dyskusyjnych. Filtrowanie po nich jest nawet pewniejsze, niż opieranie się na nagłówkach To i Cc. Te nagłowki są często dodawane do każdej wiadomości przez oprogramowanie zarządzające listą, więc niektórzy użytkownicy będą się ich spodziewać:

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

Większość z nich jest dość oczywista. Patrz http://www.nisto.com/listspec/list-manager-intro.html aby dowiedzieć się więcej. Bardziej szczegółową, formalną specyfikację można znaleźć tutaj http://www.faqs.org/rfcs/rfc2369.html.

Powyższe nagłówki mówią, że jeśli istnieje lista dyskusyjna o nazwie "list", dostępne są także adresy administracyjne "list-help" i "list-unsubscribe". Oprócz nich powszechne są także adresy "list-subscribe" do zapisania się na listę, "list-owner" do kontaktu z administratorem listy. W zależności od zastosowanego oprogramowania do zarządzania listami dyskusyjnymi adresy administracyjne mogą się różnić, więcej informacji można znaleźć w informacji. Na ogół infromacje o takich specjalnych adresach są wysyłane do każdego nowego uczestnika listy w automatycznym mailu powitalnym. Administrator na ogół otrzymuje kopię takiego maila. Jeśli tak się nie dzieje, poproś o nią jednego z użytkowników—aby wiedzieć, jakie informacje otrzymują nowi subskrybenci. Zachowaj taką kopię, aby móc odpowiadać na pytania o możliwości listy, albo lepiej umieść odpowiednie informacje na stronie WWW. Wtedy gdy ktoś zapyta "jak się wypisać z tej listy?" wystarczy podać URL.

Niektóre listy dyskusyjne dają możliwość dołączania informacji o tym, jak się wypisać, na końcu każdej wiadomości. Jeśli taka opcja jest dostępna, włącz ją. Zwiększa ona rozmiar każdej wiadomości jedynie o kilka linii dodanych w mało rzucającym się w oczy miejscu, a pozwoli oszczędzić wiele czasu, znacznie zmniejszając liczbę osób piszących do ciebie—lub co gorsza na listę—z pytaniem o to, jak się wypisać.

Wcześniej, w „Avoid Private Discussions”, podkreślałem wagę tego, aby dyskusje pozostawały na forum publicznym, i omówiłem sposoby na to, aby unikać przenoszenia dyskusji do prywatnych wątków. Ten rozdział poświęcony jest konfiguracji oprogramowania mającego zaoszczędzić nam pracy. Tak więc jeśli oprogramowanie zarządzające listą dyskusyjną ma opcję ułatwiającą utrzymanie rozmowy na liście, mogłoby się wydawać, że wlączenie jest będzie oczywystą deyzją.

Jednak nie do końca. Istnieje taka opcja, ma ona jednak dość istotne wady. Pytanie czy z niej korzystać, czy nie, to jedna z najgorętszych debat w temacie zarządzania listami dyskusyjnymi—może nie ma tyle, aby można było o tym usłyszeć w wieczornych wiadomościach, ale jest to problem, który pojawia się od czasu do czasu w projektach wolnego oprogramowania. Dalej opiszę, w czym rzecz, podam argumenty obu stron i postaram się pomóc w podjęciu decyzji.

Opcja, o której mowa, jest bardzo prosta: oprogramowanie listy dyskusyjnej może, jeśli chcesz, automatycznie ustawiać nagłówek Reply-to każdej wiadomości tak, aby wskazywał na listę dyskusyjną. Innymi słowy, nie ważne jaką wartość autor wstawi w nagłówek Reply-to (może nawet nie podawać żadnej), w momencie gdy wiadomość dotrze do subskrybentów, wspomniany nagłówek będzie zawierał adres listy:

Reply-to: discuss@lists.example.org

Z pozoru wygląda to na dobre rozwiązanie. W zasadzie każdy program pocztowy rozpoznaje nagłówek Reply-to, więc każdy, kto odpisze na wiadomość z listy, automatycznie zaadresuje ją do całej listy, a nie tylko nadawcy danej wiadomości. Oczywiście wciąż można ręcznie zmienić adresata, jednak najważniejsze, że domyślnie odpowiedzi są kierowane na listę. To doskonały przykład zastosowania technologii aby zachęcić do współpracy.

Niestety istnieje kilka wad tego rozwiązania. Pierwsza z nich nazywana bywa problemem "nie mogę znaleźć drogi do domu": czasem nadawca podaje swój "prawdziwy" adres email w polu Reply-to, gdyż z jakiegoś powodu wysyła wiadomości z innego adresu email niż ten, na który chciałby otrzymać odpowiedź. Osoby, które zawsze wysyłają i odbierają pocztę z tego samego adresu nie mają tego problemu, i bywają zaskoczeni, gdy o tym słyszą. Jednak dla tych, którzy posiadają niestandardową konfigurację poczty, lub nie mają wpływu na to, jaką wartość ma nagłówek From wysyłanych przez nich wiadomości (na przykład dlatego, że wysyłają pocztę z pracy, i nie mają dobrych układów z administratorami), korzystanie z pola Reply-to może być jedynym sposobem na podanie poprawnego adresu zwrotnego. Gdy taka osoba wysyła wiadomość na listę, na którą nie jest zapisana, wartość pola Reply-to staje się ważną informacją. Jeśli oprogramowanie listy nadpisze to pole, odpowiedzi mogą do niej w ogóle nie dotrzeć.

Drugi problem dotyczy oczekiwań, i moim zdaniem to najpoważniejszy argument przeciwko modyfikowaniu pola Reply-to. Większość doświadczonych użytkowników poczty elektronicznej jest przyzwyczajona do dwóch podstawowych rodzajów odpowiedzi: "odpowiedz wszystkim" i "odpowiedz autorowi". Współczesne oprogramowanie pocztowe posiada osobne polecenia dla każdej z tych akcji. Użytkownicy spodziewają się, że aby odpowiedzieć wszystkim (a więc także na listę), powinni wybrać opcję "odpowiedz wszystkim", a żeby odpowiedzieć prywatnie autorowi, powinni wybrać "odpowiedz autorowi". Wprawdzie chcemy zachęcać ludzi do odpowiadania na listę, zdarzają się jednak sytuacje, w których prywatna odpowiedź jest konieczna—na przykład, gdy chcemy wysłać autorowi wiadomości jakieś niepubliczne informacje, które nie powinny pojawić się na liście.

Zastanówmy się teraz, co się stanie, gdy lista nadpisze pole Reply-to. Użytkownik wybiera polecenie "odpowiedz autorowi", chcąc odpowiedzieć prywatnie autorowi wiadomości. Spodziewa się takiego efektu, więc być może nie spojrzy uważnie na pole odbiorcy nowej wiadomości. Następnie wprowadzi prywatną i poufną treść, na przykład jakąś obraźliwą opinię na temat jednej z osób na liście, i wyśle wiadomość. Niespodziewanie chwilę później jego wiadomość pojawia się na liście dyskusyjnej! Faktycznie, w teorii powinien spojrzeć na pole odbiorcy i nie zakładać nic na temat zawartości pola Reply-to. Jednak pole Reply-to prawie zawsze ustawiane jest (najczęściej automatycznie przez sam program pocztowy) na adres prywatny nadawcy, i wielu użytkowników poczty jest do tego przyzwyczajonych. Gdy ktoś celowo ustawia pole Reply-to na jakiś inny adres, jak lista dyskusyjna, na ogół wspomina o tym w treści wiadomości, aby nikt nie był tym zaskoczony.

Ze względu na możliwość takich nieprzewidzianych komplikacji, na ogół konfiguruję oprogramowanie zarządzające listą tak, aby nie ruszało nagłówka Reply-to. To przykład sytuacji, w której użycie technologii w celu ułatwienia komunikacji ma, a przynajmniej tak mi się zdaje, potencjanie niebezpieczne efekty uboczne. Jednak druga strona debaty na także silne argumenty. Którekolwiek rozwiązanie wybierzesz, na pewno od czasu do czasu ludzie będą wysyłali wiadomości na listę z pytaniem, dlaczego nie podjęłeś innej decyzji. To nie jest temat, który powinien być głównym wątkiem na liście, więc warto przygotować sobie gotową odpowiedź, najlepiej taką, która zakończy dyskusję, zamiast ją zaognić. Przede wszystkim nie upieraj się, że twoja decyzja, jakakolwiek by nie była, jest jedyną logiczną i właściwą (nawet jeśli sądzisz, że tak rzeczywiście jest). Zamiast tego zwróć uwagę, że to stara dyskusja, każda ze stron ma dobre argumenty, a ty dokonałeś najlepszej możliwej decyzji. Uprzejmie poproś o to, żeby nie wracać więcej do tego tematu, chyba że ktoś rzeczywiście ma coś nowego do powiedzenia, a następnie nie angażuj się więcej w wątek i poczekaj, aż umrze śmiercią naturalną.

Ktoś może zaproponować głosowanie, aby wybrać jedną z alternatyw. Jeśli chcesz, możesz się na to zgodzić, choć ja osobiście nie uważam, żeby w tym przypadku liczenie głosów było dobrym rozwiązaniem. Konsekwencje dla kogoś, kto nie zdaje sobie sprawy z działania listy są poważne (przypadkowe wysłanie prywatnej wiadomości na publiczną listę), a kłopot dla pozostałych niewielki (konieczność przypomnienia komuś od czasu do czasu, żeby odpisał na listę a nie na prywatny adres), że nie jestem przekonany, czy większość powinna mieć możliwość wystawienia mniejszości na takie ryzyko.

Nie przedstawiłem tutaj wszystkich aspektów problemu, a jedynie te, które wydawały się najważniejsze. Aby dowiedzieć się więcej, warto przeczytać następujące dwa klasyczne artykuły, cytowane na ogół w trakcie takich dyskusji:

Mimo sugestii, które podałem powyżej, nie uważam, że istnieje jedyne właściwe rozwiązanie tego problemu, i sam uczestniczę w wielu listach, które nadpisują pole Reply-to. Najważniejsze, żeby jak najszybciej zdecydować się na którąś z alternatyw, a następnie starać się nie wplątywać w dyskusje na ten temat.

Techniczne szczegóły archiwizacji listy dyskusyjnej są mocno zależne od oprogramowania, zarządzającego listą, tym samym wykraczają poza zakres tej książki. Wybierając lub konfigurując rozwiązanie archiwizacyjne, weź pod uwagę następujące czynniki:

To jedynie lista technicznych kwestii ważnych w trakcie wyboru i konfiguracji archiwum. Do tego. jak skłonić ludzi do korzystania z archiwum, aby poprawić komunikację w projekcie, wrócimy w dalszych rozdziałach, w szczególności w „Conspicuous Use of Archives”.

Poniżej znajduje się lista wolnego oprogramowania do zarządzania listą i archiwizacji. Jeśli serwer, na którym ulokowany jest twój projekt, ma już działające oprogramowanie do obsługi list dyskusyjnych, być może nawet nie będziesz musiał podejmować decyzji. Jeśli jednak musisz zainstalować je sam, masz sporo możliwości. Ja sam korzystałem z Mailman, Ezmlm, MHonArc i Hypermail, ale nie znaczy to, że inne nie są dobre (oczywiście są jeszcze inne narzędzia, na które nie trafiłem, więc nie uznawaj tej listy za kompletną).

Oprogramowanie do zarządzania listami dyskusyjnymi:

Oprogramowanie do archiwizacji list: