Mailman - The GNU Mailing List Management System Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA Megjegyzés: A Mailman GYIK (angolul a FAQ) már on-line is elérhető a "FAQ Wizard" rendszer segítségével, a http://www.python.org/cgi-bin/faqw-mm.py címen. GYAKRAN ISMÉTLŐDŐ KÉRDÉSEK K. Hogyan kell helyesen leírni a program nevét? V. A "Mailman" első "M" betűjét nagybetűvel kell írni, míg a második "m" kicsivel írandó. A "MailMan" írásforma helytelen (mg. felejtsük el itt a szótagok kezdőbetűjének nagybetűs írásformáját). K. A kimenő leveleket iszonyúan lassan továbbítja a program. Úgy tűnik, hogy amikor az MTA valamely címzettnél DNS kérést végez, akkor a qrunner nagyon lassan dolgozza fel a várakozási sort. Ötlet? V. Valóban az MTA DNS kérést végez a címzetteknél, amikor a leveleket helyben továbbadja (pl. a Mailman az SMTPDirect.py-vel az MTA-nak). Ez bizony hiba. Ki kell kapcsolnunk a gép folyamatos DNS kérését. Exim esetén, ez a receiver_verify_hosts megfelelő beállításával történhet. Bővebb információt a README.EXIM.hu-ban találhatunk. Más MTA-k esetében (természetesen) más beállítást kell végrehajtani. Először olvassuk el az MTA-hoz tartozó megfelelő README állományt, majd végső esetben az MTA dokumentációját. K. A lista tagok a Mailman List-* fejléceiről kérdezgetnek. Mik ezek valójában? V. Ezeket a fejlécek a Mailman minden egyes kimenő levélhez hozzáadja, a felhasználók kényelmében. A Mailman az RFC 2369-ben foglaltaknak megfelelően hozza létre ezeket a fejléceket. Az RFC 2369 ezeket a fejléceket definiálja. Ha még mindig kíváncsiak a felhasználók, akkor olvassuk el jó tanácsokért a README.USERAGENT.hu állományt. Végső esetben a lista adminisztrációs oldalán az Általános beállítások részben le lehet tiltani ezen fejlécek hozzáadását a kimenő levelekhez. K. Hogyan tudom a felhasználó címét megjeleníteni a minden levél alján megtalálható láblécben? V. A Mailman 2.1-es verziótól támogatja a személyre szabott levél- küldést, azonban alapesetben nincs engedélyezve, mivel túlzott terhelést okozhat a rendszeren. Ha szeretnénk támogatni az egyedi levelek küldését, akkor a ~mailman/Mailman/mm_cfg.py állományban adjuk meg a következő beállításokat: VERP_PASSWORD_REMINDERS = 1 VERP_PERSONALIZED_DELIVERIES = 1 VERP_DELIVERY_INTERVAL = 1 VERP_CONFIRMATIONS = 1 A VERP (variable envelope return path = változtatható válaszcímű levél) engedélyezése után a lista adminisztrációs oldalán a Nem-Digest küldési beállítások részben ismertetett változók segítségével a felhasználó feliratkozási címét, nevét, beállítási oldalát és jelszavát is el lehet helyezni. K. A felhasználóim kerülni szeretnék a HTML formátumú leveleket és én biztonsági okok miatt szeretném a MIME csatolt állományokat is a levelekből eltávolítani. Hogyan tehetem ezt meg? V. A Mailman 2.1-ben lehetőség van a tartalomszűrésre, amellyel korlátozni, vagy tiltani lehet hogy milyen típusú mellékletek, levelek jelenhetnek meg a listán. Ehhez szükséges beállításokat a lista adminisztrációs oldalán keresztül a Tartalom szűrés részben lehet módosítani. A 2.1 előtti Mailman verziókhoz külső programokat, minnt pl. a demime vagy stripmime kell használni. Ezekről bővebb információt a következő oldalakon lehet találni: (Stripmime) http://www.phred.org/~alex/stripmime.html (Demime) http://scifi.squawk.com/demime.html K. Mi van akkor, ha "document contains no data" (üres dokumentum) üzenetet kapok a webkiszolgálótól, vagy a levelek nem kerülnek fel- dolgozásra, vagy "Premature end of script" (hibás szkript befejezés) vagy "Mailman CGI error!!!" (Mailman CGI Hiba) üzenetet kapok. V. A leggyakoribb hibát az okozza, hogy a C wrapper program nem a web- kiszolgáló által várt GID jogokkal lett lefordítva. Ugyanilyen hibát okoz az is, ha a levelezőrendszer más GID-del hívná meg a lefordított C levél wrappert. A hiba elhárításához újra kell fordítani a Mailman-t a --with-cgi-gid és --with-mail-gid kapcsolókkal. Az INSTALL állományban erről bővebben lehet olvasni. Ezek a hibaüzenetek nem a Mailman naplóállományaiban, hanem a rendszerszintű naplóállományokban jelennek meg. A CGI wrappernél felmerülő hibák közvetlenül a web böngészőben jelennek meg, a szükséges GID-del együtt. Ez nagymértékben tud segíteni a probléma elhárításánál. A syslog-ot be lehet állítani, hogy pl. a mail.error hibákat egy megadott állományba naplózza; például Solaris rendszeren a mail.debug /var/log/syslog sor azt jelenti, hogy az üzenetek a /var/log/syslog állományba kerülnek. (A rendszerhez tartozó syslog.conf állomány mondja meg (ha van), hogy az üzenetek hova kerüljenek. A syslog man-jában erről bővebb információ található.) Ha a rendszerünk így van beállítva és a mailman/listinfo lap meg- tekintésénél UID vagy GID hibával találkozunk, akkor a /var/log/syslog állományban találhatjuk meg a kívánt és a működéshez szükséges UID/GID értékeket. K. Miért 'fagynak' le a weboldalak? V. Az ok, hogy a CERN típusú webszerverek a Python folyamatokat futási állapotban hagyhatják, ezzel lefagyaszthatják a CGI-ket. A probléma kiküszöbölhető Apache használatával. Előfordulhat, hogy lejárt zárolások vannak jelen. A Mailman az adat- bázisának biztonsága érdekében szigorúan veszi a zárolást, de néha rendszerhibák következtében lejárt zárolások maradhatnak. A $prefix/locks könyvtárban találhatóak a zároló állományok. (Könnyen megállapítható. hogy lejárt-e valamelyik zárolás, ha a ps paranccsal megnézzük, hogy az állományban található folyamatazonosítóhoz (PID) tartozik-e futó folyamat. Amennyibben nem tartozik, akkor az az állomány nyugodtan törölhető.) K. Mit kell időnként megnéznem? V. A szkriptek többsége a ~mailman/logs/error állományba jegyzi be hibaüzeneteit, így alkalmanként ebben kell keresnünk hibára utaló üzenetet. Az állományban *nem* találhatóak meg a szintaktikai hibára vonatkozó üzenetek, mivel ezek az installálás során, a .py állományok fordításánál azonnal megjelennek. Szintaktikai hibák előfordulhatnak a forrás nem megfelelő módosításakor, vagy 'nem modul' típusú szkriptek használatakor. A `compile' vagy `compileall' Python modulokkal bármikor le lehet bájtonként fordítani egy állományt, vagy egyszerűen a Python értelmező segítségével azt betölteni és tesztelni. K. Miért nem működik az archívum? V. A listára érkezett már levél? Ez egy ismert hiba; az archívum addig nem működik amíg legalább egy levél nem érkezett a listára. K. Rendben, az archívum működne, de mégsem tudom a nyilvános archívumot elérni. Miért? V. Apache esetén győződjünk meg, hogy a FollowSymlinks a nyilvános archívum útvonalára is meg van-e adva. Fontos tudni, hogy az archívum mindig a privát könyvtárban található; nyilvános archívumnál mindössze egy hivatkozás mutat a privát archívumra. Bővebb információ olvasható a következő címen: http://mail.python.org/pipermail/mailman-users/1998-November/000150.html K. Még mindig nem megy? QMail-t használ? V. Győződjünk meg róla, hogy a "mailman" wrapper program meghívásánál a "preline" meg van adva: |preline /home/mailman/mail/mailman post listname A "preline" használatával egy Unix-típusú "From " fejléc jön létre a levelekben, amelyek az archiváláshoz szükségesek. Az archívum mbox állományában lévő minden üzenetbe a következő sort beszúrva From somebody Mon Oct 9 12:27:34 MDT 2000 megoldódik a probléma. Futtassuk újra a "bin/arch listaneve" parancsot. Az archívumnak most már létre kell jönnie. További információt a README.QMAIL állományban lehet olvasni. K. Még mindig nem megy? GNU/Linux-ot használ? V. Olvassuk el a README.LINUX állományt. K. Az archívumból szeretnék pár levelet törölni. Hogyan tehetem ezt meg? V. David Rocher megoldása: * töröljük a $prefix/archives/private/ könyvtárat * szerkesztővel módosítsuk a következő állományt: $prefix/archives/private/.mbox/.mbox * futtassuk a $prefix/bin/arch parancsot K. Igenre állítottam a "member_posting_only" (csak_tagok_küldhetnek) beállítást, hogy csak a listatagok küldhessenek levelet a listára, azonban úgy néz ki, hogy a listatagoktól érkező összes levél engedélyezésre vár a megjelenéshez. Miért? V. Egyes rendszereken a levél feladója (pl. a Unix "From " sor) hibás lehet. Ekkor a Mailman a feladót nem tudja listatagként azonosítani. 1.0b12-es verzióig a Mailman alapesetben előbb a levél feladóját és nem a From: mezőben található feladót keresi meg, mivel az előbbit az SMTP program tölti ki, míg utóbbinak a felhasználó bármit megadhat. [ A levél feladójának megváltoztatásából adódó hibák gyakran elő- fordulnak, de a sendmail "owner-alias" szolgáltatásról illik itt pár szót ejteni: Ha egy levél érkezik a "foo" listára, és az "owner-foo" alias is meg van adva, akkor a levél feladója egyszerűen "owner-foo"- ként lesz azonosítva. A Mailman 1.0rc2 verziójától fogva már megfelelően kezeli ezt a (nem változtatható) sendmail-es problémát. Régebbi verziók esetében megoldást jelenthet az, ha az ajánlott "owner-LISTNAME" sort kihagyjuk minden egyes Mailman listánál az alias állományból. Azonban ilyen probléma esetén biztosabb megoldást jelent, ha a From: fejlécet használjuk a levél feladójaként beállított helyett. Ehhez az mm_cfg.py állományba kell a következő sort elhelyezni: USE_ENVELOPE_SENDER=0 Ha még (vitathatóbb) biztonságra akarunk törekedni akkor az mm_cfg.py állományba a következőt írjuk be: USE_ENVELOPE_SENDER=1 Azonban olvassuk el a Defaults.py-ben található leírást a változóról. Alapesetben a 2.0-s Mailman a From: fejlécet használja fel címazonosításhoz. K. Mennyire biztonságos a Mailman web azonosítási módszere? V. Ha a Mailmant SSL-re képes web kiszolgálóra telepítettük (pl. a Mailman weblapokat "https://..." címeken érjük el), akkor annyira biztonságos az azonosítás, amennyire az SSL kapcsolat. Azonban a legtöbb Mailman telepítés hagyományos, titkosítás nélküli kiszolgálókra történik. Ezzel legtöbbnyire nincs is gond, azonban egy felkészült cracker azonosítás nélkül is képes *lehet* adatokhoz hozzáférni a következő módokon: * Kapcsolat lehallgatással: A nem nyilvános Mailman lapokon használt azonosításnál a jelszavak sima szöveges formátumban kerülnek elküldésre. Ha ezt el akarjuk kerülni, akkor használjunk SSL-re képes kiszolgálót. * Érvényes süti ellopással: Sikeres bejelentkezés után a Mailman egy sütit küld vissza a felhasználóhoz. A süti a további védett oldalakon segít az azonosításban. A Mailman "kapcsolatig érvényes sütiket" (session cookies) használ, amelyek a böngésző bezárásával, vagy kilépés gombra kattintva lejárnak. A felhasználó sütijének megszerzésével (pl. a felhasználó böngészőjének sütiket tartalmazó adatbázisának olvasásával, vagy a kapcsolat lehallgatásával, vagy akár olyan hibás böngésző használatával, amely a felhasználó összes sütijét nyilvánossá teszi) és a többi szükséges feltétel egyidejű teljesülésénél jogosulatlan hozzáféréshez lehet jutni. Fontos tudnunk, hogy ez a módszer könnyebben felhasználható, ha a felhasználó proxi mögött helyezkedik el, mivel ekkor a süti minden az adott proxin átmenő kapcsolatra érvényes lesz, nem csak arra melyet a felhasználó kezdeményezett. * Hozzáférés a felhasználó termináljához: Ez is egy süti lopó módszer. Azonban ezt a sütik rövid élettartama nehezíti meg. Fogjuk fel annak, hogy a kényelemért meg kell elégednünk a csökkentett biztonságért, különben minden pillanatban gépelhetjük be a jelszavunkat. K. A listámról biztonsági másolatot (backup) akarok készíteni. Miket kell lementenem? A. A válasz a FAQ wizard-ban a következő címen található: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.006.htp K. Hogyan tudom a listát átnevezni? V. A listák átnevezése jelenleg még elég bonyolult művelet, főleg ha azt szeretnénk, hogy a régi hivatkozások is éljenek. A jövőben ezen majd változtatni fogunk. :( A legnagyobb problémát az okozhatja, hogy a lista átnevezése közbeni levélforgalmat hogyan lehet biztonságosan szüneteltetni. Teljesen biztonságos módszer nincsen, de a következőkben leírtak betartásával a hibalehetőséget nagy mértékben lehet csökkenteni: - Átmenetileg állítsuk le a qrunnert. Ehhez a mailman crontab bejegyzését kell módosítani. Adjuk ki a következő parancsot és tegyünk minden sor elé megjegyzés jelet ('#'). Mentsük el a változásokat és lépjünk ki a szerkesztőből. % crontab -u mailman -e - Állítsuk le a levelezőszervert. A legtöbb esetben ez nem fog gondot okozni, mivel a távoli MTAk addig próbálkoznak a levél kézbesítésével, amíg a rendszer át nem veszi, s mi nem sok ideig fogjuk a rendszert feltartani. - Állítsuk le a webszervert is, ha lehetséges. Ez természetesen azt jelenti, hogy nem lesz elérhető semelyik weboldalunk sem, ezt lehet hogy mégsem szeretnénk. Következő hasznos dolog lesz majd egy állandó átirányítás alkalmazása a régi listáról. Ez azt jelenti, hogyha bárki a régi lista oldalára látogat el, akkor az átirányítás az új listára teszi át. Amíg a lista átnevezésével nem végeztünk addig ez az átirányítás sem fog működni. Tegyük fel, hogy az "elavult" listát kell átnevezzük "hasznos" listává. Ekkor a következő Apache parancsokat kell használnunk: RedirectMatch permanent /mailman/(.*)/elavult(.*) http://www.dom.ain/mailman/$1/hasznos$2 RedirectMatch permanent /pipermail/elavult(.*) http://www.dom.ain/pipermail/hasznos$1 Ezeket a sorokat a httpd.conf állományba kell elhelyezni, majd indítsuk újra az Apache-ot. - Ezek után lépjünk be a telepített Mailman könyvtárába. Esetünkben legyen ez a /usr/local/mailman könyvtár: % cd /usr/local/mailman menjünk a 'lists' könyvtárba: % cd lists Itt találunk egy 'elavult' könyvtárat. Nevezzük át 'hasznos'-sá: % mv elavult hasznos - Most menjünk a privát archívum könyvtárába: % cd ../archives/private Az elavult.mbox könyvtárát és a benne található állományokat kell átneveznünk. Most még ne törődjünk a nyilvános archívum idemutató hivatkozásaival, később azokról is gondoskodunk: % mv elavult.mbox hasznos.mbox % mv hasznos.mbox/elavult.mbox hasznos.mbox/hasznos.mbox - Most már futtathatjuk a 'bin/move_list' programot az archívum elérési útjainak frissítéséhez. FONTOS: ha Mailman 2.1-et használunk, akkor hagyjuk ki ezt a lépést! % cd ../.. % bin/move_list hasznos - Hozzuk újra létre a nyilvános archívumot: % bin/arch hasznos - Ezek után néhány lista beállítást is meg kell változtatni, hogyha szeretnénk a régi listára küldött leveleket az új listán látni. Menjünk az új lista adminisztrációs oldalára: o Általános beállítások rész o A "real_name" résznél adjuk meg a lista új nevét, pl. "Hasznos" o Adjuk meg a levél tárgysorába beszúrandó részt (prefix), pl. "[Hasznos] " (igen, fontos a szóköz a végén). o Ha szükséges változtassuk meg más beállításokat is, mint például a lista rövid leírása, üdvözlő szövege, stb. o Mentsük el a változtatásokat. o Privát beállítások rész o Adjuk az acceptable_aliases részhez a régi lista címét. Pl. "elavult@dom.ain" Ezzel (ha a később leírt /etc/aliases módosítást is elvégezzük) a régi listára küldött levelek nem fognak szerkesztői jóváhagyásra várni "a címzett nem egyértelmű" hibával. o Mentsük el a változtatásokat. - Nos, most frissítsük az /etc/aliases állományunkat, hogy fogadja az új lista leveleit és átküldje a régi címre küldött leveleket. A következőkben tárgyaltak Sendmail típusú alias állományoknál működik, eltérő MTA esetén lehet, hogy módosítani kell rajtuk. o Keressük meg a régi listához tartozó alias sorokat. o Jelöljük ki és másoljuk át közvetlenül a régi alá ezeket a sorokat. o Az átmásolt részben minden "elavult" részt írjuk át "hasznos"-sá. o Most változtassuk meg a régi listához tartozó címeket, hogy azok az új lista megfelelő címeire mutassanak. Ha mindezt jól csináltuk, akkor a következőhöz hasonlót kell kapnunk: # A régi listát átirányítottuk az új címére elavult: hasznos@dom.ain elavult-request: hasznos-request@dom.ain elavult-admin: hasznos-admin@dom.ain elavult-owner: hasznos-owner@dom.ain hasznos: "|/usr/local/mailman/mail/mailman post hasznos" hasznos-admin: "|/usr/local/mailman/mail/mailman mailowner hasznos" hasznos-request: "|/usr/local/mailman/mail/mailman mailcmd hasznos" hasznos-owner: hasznos-admin o Futassuk a 'newaliases' programot. - Mielőtt mindent újraindítanánk nézzük meg, hogy van-e a qfiles/ könyvtárban a régi listára küldött, de még nem továbbított levél. Ezt a következőképen tehetjük meg: % cd /usr/local/mailman/qfiles % grep elavult *.msg Ha nincs találat, akkor ugorhatunk a következő lépésre, egy gonddal kevesebb. Ha van találat, akkor izzadni fogunk egy kicsit. Figyelmeztetlek, hogy a következő lépések nem lettek megfelelően tesztelve. :( A régi listára küldött minden egyes .msg állománynál a hozzátartozó .db állományt kell módosítani. Sajnos ez nem egy könnyű menet. No lássuk... Mentsük el a következő Python kód részletet 'hackdb.py' névvel: -------------------------hackdb.py import sys import marshal fp = open(sys.argv[1]) d = marshal.load(fp) fp.close() d['listname'] = sys.argv[2] fp = open(sys.argv[1], 'w') marshal.dump(d, fp) fp.close() ------------------------- Adjuk ki azokon az állományokon a következő parancsot, amelyekre a grep találatot jelzett. % python hackdb.py nagyonhosszuhexafilenev1.db hasznos - Ezek után indítsuk el az MTA-t. - Tegyük újra üzembe a qrunner-t. % crontab -u mailman -e Vegyük ki a megjegyzés jeleket azon sorok elől, ahova mi tettük azokat. Mentsük el a változtatásokat és lépjünk ki a szerkesztőből. - Dőljünk hátra és örüljünk, mert sikerült az átnevezés. Ha 100.000 $-al támogatod a Mailman fejlesztőgárdáját, akkor ígérjük, hogy hamarosan sokkal könnyebb lesz a listák átnevezése. :) Local Variables: mode: text indent-tabs-mode: nil End: