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/<listaneve> könyvtárat
* szerkesztővel módosítsuk a következő állományt:
$prefix/archives/private/<listanave>.mbox/<listaneve>.mbox
* futtassuk a $prefix/bin/arch <listaneve> 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: