1 files changed, 0 insertions, 464 deletions

diff --git a/mailman/messages/hu/FAQ.hu b/mailman/messages/hu/FAQ.hu
deleted file mode 100644
index 7430f1d22..000000000
--- a/mailman/messages/hu/FAQ.hu
+++ /dev/null
@@ -1,464 +0,0 @@
-Mailman - The GNU Mailing List Management System
-Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 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.hu á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: