From b4346b9b2dfe86a97907573086dff096850dcb1d Mon Sep 17 00:00:00 2001 From: Gabor Kovesdan Date: Mon, 1 Oct 2012 09:53:01 +0000 Subject: - Rename .sgml files to .xml - Reflect the rename in referencing files Approved by: doceng (implicit) --- hu_HU.ISO8859-2/books/handbook/mail/chapter.xml | 3029 +++++++++++++++++++++++ 1 file changed, 3029 insertions(+) create mode 100644 hu_HU.ISO8859-2/books/handbook/mail/chapter.xml (limited to 'hu_HU.ISO8859-2/books/handbook/mail/chapter.xml') diff --git a/hu_HU.ISO8859-2/books/handbook/mail/chapter.xml b/hu_HU.ISO8859-2/books/handbook/mail/chapter.xml new file mode 100644 index 0000000000..1ac404ad39 --- /dev/null +++ b/hu_HU.ISO8859-2/books/handbook/mail/chapter.xml @@ -0,0 +1,3029 @@ + + + + + + + + + + Bill + Lloyd + Eredetileg készítette: + + + + + Jim + Mock + Átdolgozta: + + + + + Elektronikus levelezés + + + Áttekintés + + e-mail + + Az elektronikus levelezés, más + néven e-mail, a kommunikáció egyik legjobban + elterjedt formája. Ebben a fejezetben bemutatjuk, hogyan + futtassunk &os;-n levelező szervert, illetve hogyan + küldjünk és fogadjunk e-maileket a &os; + használatával. Ez azonban semmiképpen sem + tekinthető egy teljes referenciának és + tulajdonképpen számos fontos + tényezőről szót sem ejtünk. A + témára úgy kaphatunk egy sokkal + átfogóbb rálátást, ha a ben felsorolt remek könyveket is + elolvassuk. + + A fejezet elolvasása során + megismerjük: + + + + milyen szoftverkomponensek játszanak szerepet az + elektronikus levelek küldésében és + fogadásában; + + + + &os;-ben hol találhatóak a + sendmail + konfigurációs állományai; + + + + mi a különbség a helyi és + távoli postaládák + között; + + + + hogyan akadályozzuk meg, hogy a levelező + szerverünk a kéretlen levélszemetet + továbbítson; + + + + rendszerünkön hogyan telepítsünk + és állítsunk be más levelező + szervereket a sendmail + helyett; + + + + hogyan oldjuk meg a levelező szerverekkel + kapcsolatban felmerülő általános + problémákat; + + + + hogyan használjuk az SMTP protokollt az UUCP + protokollal; + + + + hogyan kell rendszerüket csak + levélküldésre + beállítani; + + + + hogyan levelezzünk betárcsázós + kapcsolattal; + + + + hogyan növeljük rendszerünk + védelmét az SMTP + hitelesítésének + engedélyezésével; + + + + hogyan telepítsünk és + használjunk a levelek küldésére + és fogadására például a + mutthoz hasonló + levelező klienseket; + + + + hogyan töltsük le leveleinket egy távoli + POP vagy IMAP + szerverről; + + + + hogyan alkalmazzunk automatikusan adott szabályokat + vagy szűrőket az érkező + levelekre. + + + + A fejezet elolvasása előtt ajánlott: + + + + az internet-csatlakozásunk megfelelő + beállítása (); + + + + a névfeloldás + beállítása (); + + + + a külső fejlesztésű + alkalmazások telepítésének + ismerete (). + + + + + + + Az elektronikus levelezés használata + + POP + IMAP + DNS + + Öt fontosabb részre bonthatjuk a + levelezést. Ezek: a + felhasználói program (mail user agent), a levélküldő démon + (mail transfer agent), a + névfeloldás, a + helyi vagy távoli postaláda és + természetesen maga a + levelező szerver (mail host). + + + A felhasználói program + + Ide soroljuk a különböző parancssoros + programokat, mint például a + mutt, + pine, elm + és mail, valamint a + különféle grafikus alkalmazásokat, mint + például a balsa + és az xfmail, csak hogy + felsoroljuk néhány újabb, egy + webböngészőhöz hasonlóan + kifinomult eszközt is. Ezek a programok + egyszerűen átküldik az elektronikus levelekkel + kapcsolatos tranzakciókat a helyi levelező + szervernek vagy meghívják + valamelyik levélküldő + démont, esetleg közvetlenül a + TCP protokollon keresztül + kézbesítenek. + + + + + A levélküldő démon + + + levélküldő démon + sendmail + + + + levélküldő démon + postfix + + + + levélküldő démon + qmail + + + + levélküldő démon + exim + + + A &os; alapból a sendmail + nevű programot ajánlja fel erre a célra, de + támogat más levelező szervereket is, ezek + közül meg is említünk + néhányat + ízelítőként: + + + + exim + + + + postfix + + + + qmail + + + + Ez a démon általában két + feladatot lát el — a beérkező levelek + fogadásáért és a kimenő levelek + elküldéséért felelős. + Nem tartozik azonban a feladatai + közé, hogy a POP vagy + IMAP protokollokhoz hasonlóan + olvashatóvá tegye a leveleinket, illetve + csatlakozni engedjen a helyi mbox vagy + Maildir formátumú postaládáinkhoz. + Ezekhez a műveletekhez egy külön démon + szükségeltetik. + + + A sendmail régebbi + változatai tartalmaznak olyan komoly biztonsági + hibákat, amelyek kihasználásával + az illetéktelen behatolók helyi és/vagy + távoli hozzáférést tudnak szerezni + a gépünkön. Az ilyen jellegű + problémák elkerülése + érdekében igyekezzünk mindig a legfrissebb + verzióját használni. Vagy a &os; + Portgyűjteményéből + telepítsünk fel egy másik + levélküldő démont. + + + + + + Az elektronikus levelek és a + névfeloldás + + A névfeloldás (Domain Name System, DNS) + és a hozzá tartozó named + démon nagy szerepet játszik az elektronikus + levelek továbbításában. A + démon a leveleket úgy küldi át az + egyik gépről a másikra, hogy a + névfeloldáson keresztül megkeresi azt a + távoli gépet, amelynek a leveleket + címezték. Ez a folyamat szintén + végbemegy, amikor egy távoli gépről + levelet küldenek a mi szerverünkre. + + MX rekord + + A DNS valósítja meg a + hálózati nevek és az IP-címek + összerendelését valamint ez tárolja el + a levélküldésre vonatkozó + információkat is, amelyeket MX rekordoknak + hívnak. Az MX (Mail eXchanger, + levélváltó) rekord adja meg + azt a gépet vagy azokat a gépeket, amelyek az + adott névtartományban fogadják a leveleket. + Ha a hálózati nevünkhöz vagy + tartományunkhoz nem tartozik MX rekord, akkor a + levél közvetlenül a gépünkre + vándorol feltéve, hogy rendelkezik olyan A + rekorddal, amely összerendeli a gépünk + nevét az IP-címével. + + A &man.host.1; parancs használatával az + alábbi példához hasonlóan + tetszőleges tartomány MX rekordját meg tudjuk + nézni: + + &prompt.user; host -t mx +FreeBSD.org FreeBSD.org mail is handled (pri=10) by +mx1.FreeBSD.org + + + + + Az elektronikus levelek fogadása + + + elektronikus levél + fogadása + + + A tartományunkhoz tartozó leveleket + fogadását a levelező szerver végzi. + Összegyűjti a tartományunkba küldött + összes levelet és ezeket a + beállításainktól függően + vagy mbox (a levelek + tárolásának alapértelmezett + módja) vagy pedig Maildir formátumban + eltárolja. Ahogy eltárolt egy levelet, úgy + helyben egyből el is tudjuk olvasni például a + &man.mail.1; vagy a mutt + használatával, illetve távolról a + POP vagy IMAP és a + hasonló protokollokkal tudjuk elérni és + begyűjteni. Ezért tehát ha csak a helyi + gépen kívánjuk olvasni a leveleinket, akkor + ahhoz egyáltalán nem kell POP + vagy IMAP szervert + telepítenünk. + + + Távoli postaládák + elérése a <acronym>POP</acronym> és + <acronym>IMAP</acronym> használatával + + POP + IMAP + + A távoli postaládák + eléréséhez tudnunk kell csatlakozni egy + POP vagy IMAP + szerverhez. Ezeken a protokollokon keresztül + tudják a felhasználók minden + különösebb nehézség + nélkül elérni távolról a + helyi postaládáikat. Noha a + POP és az IMAP + segítségével egyaránt el tudjuk + így érni a postaládákat, az + IMAP használatának + mégis több előnye van, íme + néhány közülük: + + + + Az IMAP a levelek leszedése + mellett tárolni is képes a távoli + szerveren. + + + + Az IMAP támogat + párhuzamos lekéréseket. + + + + Az IMAP hihetetlenül hasznos + tud lenni lassabb összeköttetések + esetében, mivel lehetővé teszi a + felhasználók számára, hogy + csak az üzenetek vázát + töltsék le és ne az egészet. + Továbbá a szerver és a kliens + közti adatmozgás csökkentése + érdekében képes bizonyos feladatokat + a szerveren elvégezni, például + keresni. + + + + Egy POP vagy IMAP + szerver telepítéséhez az alábbi + lépések megtétele + szükséges: + + + + Válasszuk ki az igényeinket legjobban + kielégítő IMAP vagy + POP szervert. A következő + POP és IMAP + szerverek eléggé elterjedtek és + egyben remek példák: + + + + qpopper + + + + teapop + + + + imap-uw + + + + courier-imap + + + + + + + A Portgyűjteményből + telepítsük fel a kiválasztott + POP vagy IMAP + démont. + + + + Ha szükséges, akkor a + POP vagy IMAP + szerver betöltéséhez írjuk + át az /etc/inetd.conf + állományt. + + + + + Meg kell említenünk, hogy mind a + POP és az IMAP + az összes információt, tehát + belértve a felhasználók neveit + és jelszavait titkosítatlan formában + továbbítja. Ez azt jelenti, hogy ha ezeket a + protokollokat biztonságos módon + szeretnénk elérni, akkor az &man.ssh.1; + használatával hozzunk létre + hozzá egy tunnelt és azon keresztül + használjuk. Erről részletesebben a ban olvashatunk. + + + + + + A helyi postaládák + elérése + + A helyi postaládákat a szerveren levő + levelező kliensek közvetlen + használatával érhetjük el. Ilyen + alkalmazások például a + mutt vagy a &man.mail.1;. + + + + + + A levelező szerver + + levelező szerver + + A levelező szerver az a szerver, amely a + gépünk vagy akár az egész + hálózatunk irányába + érkező levelek fogadásáért + és elküldéséért + felelős. + + + + + + + + + Christopher + Shumway + Írta: + + + + + A <application>sendmail</application> + beállítása + + sendmail + + A &man.sendmail.8; a &os; alapértelmezett + levéltovábbító ügynöke (Mail + Transfer Agent, MTA). A + sendmail feladata fogadni a + levelező kliensektől (Mail User Agent, + MUA) érkező leveleket és + kézbesíteni azokat a konfigurációs + állományában megadott megfelelő + levelezőnek. A sendmail + hálózati kapcsolatokat is fogad, képes a + helyi postaládákba vagy akár más + programoknak is leveleket továbbítani. + + A sendmail a következő + állományban tárolja + beállításait: + + /etc/mail/access + /etc/mail/aliases + /etc/mail/local-host-names + /etc/mail/mailer.conf + /etc/mail/mailertable + /etc/mail/sendmail.cf + /etc/mail/virtusertable + + + + + + Állomány + Szerep + + + + + + /etc/mail/access + + A sendmail által + engedélyezett hozzáféréseket + tároló adatbázis + + + + /etc/mail/aliases + + A postaládák álnevei + + + + /etc/mail/local-host-names + + Azon nevek felsorolása, amelyek + számára a + sendmail leveleket + fogad + + + + /etc/mail/mailer.conf + + A levelező programok + beállításai + + + + /etc/mail/mailertable + + A levelező programok + kézbesítési + táblázata + + + + /etc/mail/sendmail.cf + + A sendmail központi + beállításait tároló + állomány + + + + /etc/mail/virtusertable + + Virtuális felhasználók és + tartományok táblázatai + + + + + + + <filename>/etc/mail/access</filename> + + Az engedélyezett hozzáféréseket + tároló adatbázis tartalmazza milyen + hálózati neveken vagy IP-címeken lehet + elérni a helyi levelező szervert és azok + milyen típusú hozzáférést + kapnak. A gépek az (rendben), + (visszautasít), + (továbbítás) + beállításokat alkalmazhatjuk, vagy + egyszerűen meghívhatjuk hozzájuk a + sendmail hibakezelő + rutinját egy adott kézbesítési + hibával. Ha egy gépet az + beállítással veszük fel a + listára, ami egyébként + alapértelmezés, akkor ez a gép levelet tud + küldeni egészen addig, amíg a + végső cél a helyi gép marad. A + beállítással + felsorolt gépek számára semmiféle + levelezés nem engedélyezett. Ha pedig egy + gép mellett a + beállítás jelenik meg, akkor a szerveren + keresztül tetszőleges címre + küldhet. + + + A <application>sendmail</application> + elérését szabályozó + adatbázis beállítása + + cyberspammer.com 550 Nem szeretjuk a spammereket +FREE.STEALTH.MAILER@ 550 Nem szeretjuk a spammereket +another.source.of.spam REJECT +okay.cyberspammer.com OK +128.32 RELAY + + + Ebben a példában öt bejegyzést + láthatunk. A táblázat bal felének + valamelyik sorára illeszkedő küldőkre a + táblázatban a sor jobb felén megjelenő + cselekvés érvényesül. Az első + két sorban a sendmail + hibakezelő rutinjának adunk át + hibakódokat. A hozzá tartozó üzenet + akkor fog megjelenni a távoli gépen, amikor a + tőle érkező levél illeszkedik a bal + oldali szabályra. Az ezeket követő + bejegyzésben visszalökünk minden olyan levelet, + amely az internetről egy adott + számítógéptől érkezik, + például az another.source.of.spam + címről. A következő bejegyzésben + az okay.cyberspammer.com + címről elfogadjuk a kapcsolódást, ami + viszont sokkal pontosabb megjelölés a fentebb + szereplő cyberspammer.com sornál. A + pontosabban kifejtett nevek + felülbírálják a kevésbé + pontosan megnevezetteket. Végül az utolsó + bejegyzésben engedélyezzük a levelek + továbbküldését minden olyan gép + számára, amelynek címe a + 128.32 előtaggal kezdődik. Ezek + tehát képesek ezen a levelező szerveren + keresztül bárhova leveleket küldeni. + + Az állomány módosítása + után az adatbázis + frissítéséhez mindig le kell futtatnunk egy + make parancsot az + /etc/mail/ könyvtárban. + + + + + <filename>/etc/mail/aliases</filename> + + Az álneveket tartalmazó adatbázis + virtuális postaládákat sorol fel, amelyek + más felhasználókra, + állományokra, programokra vagy további + álnevekre vonatkozhatnak. Íme + néhány példa az + /etc/mail/aliases állományban + szereplő bejegyzésekre: + + + Virtuális postaládák + + root: localuser +ftp-bugs: joe,eric,paul +bit.bucket: /dev/null +procmail: "|/usr/local/bin/procmail" + + + A formai szabályok egyszerűek: a kettőspont + bal oldalára kell írni azt a + postaládát, amely a jobb oldalán levő + célokra bomlik. A példa első sorában + egyszerűen megfeleltetjük a root + postaládáját a + localuser + postaládájának, majd ezt a nevet + keressük az álnevek adatbázisában. Ha + nem találunk már rá illeszkedést, + akkor az üzenetet a localuser + nevű helyi felhasználónak + továbbítjuk. A következő sorban + címek listáját láthatjuk. Ennek + megfelelően a ftp-bugs + postaláda címére küldött levelek + három további helyi postaládára + mennek tovább: ezek név szerint a + joe, eric és + paul felhasználók + postaládái. Itt a távoli + postaládák + felhasználó@példa.hu alakban + adhatóak meg. A következő sor az + állományok használatát + példázza, ahol konkrétan a + /dev/null állományba + irányítjuk át az adott címre + érkező leveleket. Az utolsó sorban pedig a + programok használatára láthatunk + példát, ahol ebben az esetben a levél egy + &unix;-os csövön keresztül a + /usr/local/bin/procmail szabványos + bemenetére kerül. + + Ha megváltoztatjuk ezt az állományt, + akkor utána az adatbázis + frissítéséhez ne felejtsük el + meghívni a make parancsot az + /etc/mail/ könyvtárban. + + + + + <filename>/etc/mail/local-host-names</filename> + + Ebben az állományban adhatjuk meg, hogy a + &man.sendmail.8; milyen hálózati neveket fogadjon + el helyi hálózati névként. Ide kell + raknunk azokat a tartományokat vagy címeket, + amelyektől a sendmail leveleket + fogad el. Például, ha a levelező szerver az + minta.com + tartományból és a level.minta.com címről fogad el + leveleket, akkor a local-host-names + valahogy így fog kinézni: + + minta.com +level.minta.com + + Az állomány módosításakor + a &man.sendmail.8; programot újra kell indítani a + változások + érvényesítéséhez. + + + + + <filename>/etc/mail/sendmail.cf</filename> + + Ahogy a sendmail központi + konfigurációs állománya, a + sendmail.cf irányítja a + sendmail átfogó + viselkedését, beleértve mindent az e-mail + címek átírásától + kezdve a távoli szervereknek küldött + elutasító üzenetek + küldéséig. Mivel ennyire sokfajta szerepet + tölt be egyszerre, ezért ez a + konfigurációs állomány + meglehetősen összetett és a + részletezése meghaladná ennek a + leírásnak a határait. Szerencsére + az átlagos levelező szerverek esetében ezt az + állományt nagyon ritkán kell + módosítani. + + A sendmail központi + konfigurációs állománya a + sendmail lehetőségeit + és viselkedését meghatározó + &man.m4.1; makrókból építhető + fel. A pontosabb részleteket a + /usr/src/contrib/sendmail/cf/README + állományban találjuk meg. + + Az állomány megváltoztatása + után a módosítások + érvényesítéséhez újra + kell indítani a sendmail + programot. + + + + + <filename>/etc/mail/virtusertable</filename> + + A virtusertable állomány + képezi le a virtuális tartományokhoz + tartozó címeket valódi + postaládák címeire. Ezek a + postaládák lehetnek helyiek, távoliak, az + /etc/mail/aliases állományban + megadott álnevek vagy állományok. + + + Példa a virtuális tartományok + leképezésére + + root@minta.com root +postmaster@minta.com postmaster@noc.minta.net +@minta.com joe + + + A fenti példában megadtunk egy + leképezést a minta.com tartományhoz. Ez az + állomány úgy dolgozódik fel, hogy + fentről lefelé illesztődnek a címek, + egészen az első egyezésig. Az első + bejegyzés szerint a root@minta.com a helyi + root felhasználó + postaládájára képződik le. A + következő bejegyzés szerint a + postmaster@minta.com a noc.minta.net címen + található postmaster + nevű felhasználó + postaládájára képződik le. + Végezetül, ha a minta.com címről eddig + még semmi sem illeszkedett volna, akkor az utolsó + leképezés veszi át, amely az minta.com tartományon + belül az összes többi címre + küldött levelet a helyi joe + nevű felhasználó + postaládájára képezi le. + + + + + + + + + Andrew + Boothman + Írta: + + + + + Gregory + Neil Shapiro + Levelei segítségül + szolgáltak: + + + + + A levéltovábbító ügynök + megváltoztatása + + + e-mail + a levéltovábbító + megváltoztatása + + + Ahogy arról már korábban szó + esett, a &os; alapból tartalmazza a + sendmail programot mint + levéltovábbító ügynököt + (MTA, Mail Transfer Agent). Ennélfogva + alapértelmezés szerint ez a felelős a + kimenő és beérkező levelek + kezeléséért. + + Számtalan okból eredően egyes + rendszergazdák azonban mégis szeretnék + lecserélni a rendszerükhöz tartozó + levéltovábbítót. Ennek oka lehet + egyszerűen csak annyi, hogy ki akarunk próbálni + egy másik programot vagy éppen egy olyan + eszközre van szükségünk, amely + kizárólag csak máshol található + meg. Szerencsére a &os; megkönnyíti ezt a + váltást. + + + Az új levéltovábbító + telepítése + + A levéltovábbítók széles + köre elérhető. A &os; + Portgyűjteményéből elindulva sok + ilyen programot találhatunk. Természetesen + teljesen mindegy, hogy melyik + levéltovábbítót választjuk + egészen addig, amíg képesek vagyunk &os; + alatt rendesen futtatni. + + Kezdjük tehát az új + levéltovábbító + telepítésével. Miután sikerült + telepíteni, lehetőségünk van + eldönteni, hogy valóban eleget tesz-e az + igényeinknek, sőt az új szoftvert még + az előtt be tudjuk állítani, hogy + átvenné a sendmail + helyét. Vigyázzunk azonban, hogy az új + szoftver telepítésekor ne írjon felül + olyan rendszerszintű binárisokat, mint + például a /usr/bin/sendmail. + Másrészt az új levelező szoftvert + szolgálatba helyezése előtt + mindenképpen fontos megfelelően + beállítanunk. + + A kiválasztott + levéltovábbító + beállításával kapcsolatban olvassuk + el a hozzá tartozó + dokumentációt. + + + + + A <application>sendmail</application> + letiltása + + + Amikor letiltjuk a sendmail + kimenő levél szolgáltatását, + soha ne felejtsük el pótolni valamilyen más + levelező rendszerrel. Ha nem így + cselekszünk, akkor például a + &man.periodic.8; és a hozzá hasonló + programok nem lesznek képesek a tőlük + megszokott módon e-mailben elküldeni a + futásuk eredményét. A rendszer bizonyos + részei ráadásul egy + működő, + sendmail-kompatibilis rendszert + feltételeznek. Ha letiltása után az + alkalmazások továbbra is a + sendmail + segítségével próbálnak + levelet küldeni, akkor ez a levél a + sendmail inaktív + sorába kerülhet, ahonnan soha nem kerül + kézbesítésre. + + + A sendmail teljes + leállításához, beleértve a + kimenő levelekhez tartozó + szolgáltatást is, a következőket kell + megadni az /etc/rc.conf + állományban: + + sendmail_enable="NO" +sendmail_submit_enable="NO" +sendmail_outbound_enable="NO" +sendmail_msp_queue_enable="NO" + + Ha csak a sendmail + beérkező levelekre vonatkozó + szolgáltatását akarjuk tiltani, akkor + ahhoz az /etc/rc.conf + állományban a következőt + állítsuk be: + + sendmail_enable="NO" + + A sendmail + indításával kapcsolatos további + beállításokat az &man.rc.sendmail.8; man + oldalon találjuk. + + + + + Az új levéltovábbító + elindítása a rendszerrel együtt + + Az új levéltovábbítót + úgy tudjuk elindítani a rendszerrel együtt, + ha az /etc/rc.conf + állományba felvesszük a következő + sort, például a + postfix esetében: + + &prompt.root; echo 'postfix_enable="YES"' >> /etc/rc.conf + + Az új levéltovábbító + így most már magától el fog indulni + a rendszer indításakor. + + + + + A <application>sendmail</application> mint a rendszer + alapértelmezett levelező eszközének + lecserélése + + A sendmail annyira elterjedt + szabványos szoftver a &unix; rendszereken, hogy egyes + szoftverek egyszerűen feltételezik a + jelenlétét. Emiatt sok + levéltovábbítóhoz tartozik egy + sendmail kompatibilis parancssoros + felület is, amellyel igyekeznek megkönnyíteni a + sendmail gyors + lecserélését. + + Ennek következtében tehát, ha egy + másik levelező eszközt használunk, akkor + valamilyen módon meg kell bizonyosodnunk róla, + hogy a szabványos sendmail + binárisok, mint például a + /usr/bin/sendmail, valóban a + kiválasztott levéltovábbítot + fogják aktiválni. Szerencsére a &os; + pontosan emiatt tartalmaz egy &man.mailwrapper.8; nevű + rendszert. + + Amikor a sendmail + telepítése szerint működik, valami + hasonlót fogunk találni az + /etc/mail/mailer.conf + állományban: + +sendmail /usr/libexec/sendmail/sendmail +send-mail /usr/libexec/sendmail/sendmail +mailq /usr/libexec/sendmail/sendmail +newaliases /usr/libexec/sendmail/sendmail +hoststat /usr/libexec/sendmail/sendmail +purgestat /usr/libexec/sendmail/sendmail + + Ez azt jelenti, hogy amikor az itt felsorolt + általános parancsok közül lefuttatjuk + valamelyiket (például magát a + sendmail parancsot), akkor a rendszer + magától meghívja a + sendmail néven szereplő wrapper + programot, amely pedig a mailer.conf + alapján kideríti, hogy az adott esetben a + /usr/libexec/sendmail/sendmail + hívására van szükség. Ez a + rendszer megkönnyíti az alapértelmezett + sendmail funkciók helyében + lefuttatandó binárisok + átállítását. + + Így tehát, ha a + /usr/local/supermailer/bin/sendmail-compat + állományt akarjuk futtatni a megszokott + sendmail helyében, akkor az + /etc/mail/mailer.conf + állományt a következőképpen kell + módosítanunk: + + sendmail /usr/local/kedvenclevelező/bin/sendmail-compat +send-mail /usr/local/kedvenclevelező/bin/sendmail-compat +mailq /usr/local/kedvenclevelező/bin/mailq-compat +newaliases /usr/local/kedvenclevelező/bin/newaliases-compat +hoststat /usr/local/kedvenclevelező/bin/hoststat-compat +purgestat /usr/local/kedvenclevelező/bin/purgestat-compat + + + + + A művelet befejezése + + Ahogy a céljainknak megfelelően mindent + beállítottunk, akkor vagy egyszerűen + leállítjuk a sendmail + neve alatt futó programokat és helyettük + elindítjuk az új szoftverhez tartozókat, + vagy csak újraindítjuk a gépet. Az + újraindítással mellesleg + ellenőrizhetjük azt is, hogy jól + állítottuk be a rendszerünket és az + új levélküldő tényleg elindul a + rendszerünkkel együtt. + + + + + + A hibák elhárítása + + + e-mail + hibaelhárítás + + + + + + Miért kell teljes hálózati neveket + megadni a gépemen? + + + + Előfordulhat, hogy a hivatkozni + kívánt gép valójában egy + másik tartományban szerepel. + Például, ha az ize.mize.edu gépen vagyunk + és a vagyis nevű gépet + akarjunk innen elérni a mize.edu tartományban, + akkor a teljes hálózati nevével, vagyis + a vagyis.mize.edu néven + kell rá hivatkoznunk, nem pedig egyszerűen csak + vagyis néven. + + BIND + + Régebben egyébként ezt a + BSD-típusú BIND névfeloldók + megengedték. A &os; jelenlegi változatai + azonban már olyan BIND + verziót tartalmaznak, amelyek + alapértelmezés szerint már nem engedik + a tartományunkon kívüli relatív + nevek használatát. Tehát a + vagyis vagy a vagyis.ize.mize.edu gép lesz, + vagy a legfelső, gyökér tartományban + keresi a rendszer. + + Ez eltér a korábbi + viselkedéstől, ahol a keresés + folytatódott a vagyis.mize.edu és vagyis.edu tartományokban + is. Az RFC 1535 elolvasásából ki + fog derülni, hogy miért nem vált be ez a + gyakorlat és hogy miért tekinthető + még akár biztonsági résnek + is. + + Ezt a problémát egyébként + megoldhatjuk annyival, hogy az + /etc/resolv.conf + állományba a + + search ize.mize.edu mize.edu + + sor helyett a + + domain ize.mize.edu + + sort írjuk be. Arra viszont ügyeljünk, + hogy a keresési rend ne lépje át a + helyi és nyilvános + adminisztráció között + meghúzódó határt, ahogy + azt az RFC 1535 nevezi. + + + + + + + MX rekord + + A sendmail szerint a + levél a saját farkába + harap + + + + Ezt a sendmail gyakran + ismértelt kérdései között a + következőképpen válaszolták + meg: + + A következő hibaüzenetet kapom: + +553 MX list for taromány.net points back to felé.tartomány.net +554 felhasználó@tartomány.net... Local configuration error + +Hogyan oldható meg ez a probléma? + +Azt kértük, hogy a tartományba (például tartomány.net) küldött levél +az MX rekord felhasználásával egy adott gépre legyen átirányítva +(ebben az esetben ez a felé.tartomány.net), de a továbbítást végző gép +nem ismeri fel magát a tartomány.net címen. Vegyük fel a tartomány.net +tartományt az /etc/mail/local-host-names állományba [melyet a 8.10 előtti +verziókban /etc/sendmail.cw állománynak hívnak] (ha a +FEATURE(use_cw_file) beállítást használjuk) vagy tegyük hozzá a +Cw tartomány.net sort az /etc/mail/sendmail.cf +állományhoz. + + A sendmail GYIK a címen + található meg (angolul) és + mindenképpen javasolt elolvasni, ha fel + szeretnénk piszkálni a levelező + rendszerünk beállításait. + + + + + + PPP + + Hogyan tudok levelező szervert futtatni egy + betárcsázós PPP kapcsolat + esetében? + + + + Egy helyi hálózaton levő &os;-s + gépet akarunk tehát az internethez kapcsolni. + Ez a &os;-s gép lesz a helyi hálózat + leveleket továbbító + átjárója. A PPP kapcsolat nem + dedikált. + + UUCP + + MX record + + + Legalább két módon meg tudjuk + oldani. Az egyik módszer szerint az UUCP + használatára lesz + szükségünk. + + A másik módszer szerint szereznünk + kell egy éjjel-nappal üzemelő internetes + szervert, amely majd szolgáltatja a másodlagos + MX rekordot a tartományunkhoz. + Például, ha a cégünk + tartománya a cég.hu + és az internet-szolgáltatónk a szolgáltató.net + névre beállította a + tartományunkhoz a másodlagos MX + rekordokat: + + cég.hu. MX 10 cég.hu. + MX 20 szolgáltató.net. + + Végső címzettként csak egy + gépet kell megadni (az + /etc/mail/sendmail.cf + állományba a cég.hu + címhez tegyük hozzá a Cw + cég.hu + sort). + + Amikor a leveleket küldeni akaró + sendmail megpróbál + kézbesíteni, először hozzánk + (cég.hu) + próbál csatlakozni a modemes + összeköttetésen keresztül. Ez + valószínűleg + időtúllépéssel befejeződik, + mivel nem vagyunk fenn minden pillanatban a neten. A + sendmail ekkor automatikusan a + másodlagos MX rekord által megadott + címre küldi a levelet, tehát a + szolgáltatónkhoz (szolgáltató.net). + Ez a másodlagos MX cím próbálja + majd időlegesen elérni a gépünket + és kézbesíteni a leveleket az + elsődleges MX rekord által megadott gépre + (cég.hu). + + A bejelentkezéskor ezért egy + hasonló szkriptet kell lefuttatnunk: + + #!/bin/sh +# Tegyük a /usr/local/bin/pppmyisp állományba: +( sleep 60 ; /usr/sbin/sendmail -q ) & +/usr/sbin/ppp -direct pppmyisp + + Ha készítünk egy külön + bejelentkező szkriptet a felhasználók + számára, akkor a sendmail + -qRcég.hu + parancsot is használhatjuk a fenti szkript helyett. + Ezzel a cég.hu + sorában található összes + levél azonnal feldolgozásra kerül. + + A helyzetet így lehetne még jobban + pontosítani: + + Az alábbi üzenet a &a.isp; + archívumából származik. + + > we provide the secondary MX for a customer. The customer connects to +> our services several times a day automatically to get the mails to +> his primary MX (We do not call his site when a mail for his domains +> arrived). Our sendmail sends the mailqueue every 30 minutes. At the +> moment he has to stay 30 minutes online to be sure that all mail is +> gone to the primary MX. +> +> Is there a command that would initiate sendmail to send all the mails +> now? The user has not root-privileges on our machine of course. + +In the privacy flags section of sendmail.cf, there is a +definition Opgoaway,restrictqrun + +Remove restrictqrun to allow non-root users to start the queue processing. +You might also like to rearrange the MXs. We are the 1st MX for our +customers like this, and we have defined: + +# If we are the best MX for a host, try directly instead of generating +# local config error. +OwTrue + +That way a remote site will deliver straight to you, without trying +the customer connection. You then send to your customer. Only works for +hosts, so you need to get your customer to name their mail +machine customer.com as well as +hostname.customer.com in the DNS. Just put an A record in +the DNS for customer.com. + + Az idézet fordítása: + + > Másodlagos MX rekordot biztosítunk az ügyfeleinknek. Az ügyfelek ezután automatikusan +> csatlakoznak naponta akár többször is a szolgáltatásunkhoz és leszedik az elsődleges MX +> rekordhoz tartozó leveleket. (Nem szólunk neki, amikor a tartományához levél +> érkezik.) A sendmail programunk minden 30 percben elküldi a sorban felhalmozódott +> leveleket. Tehát jelen pillanatban legalább 30 percig fenn kell lennie az ügyfélnek, hogy +> rendben megkapja az elsődlegesre MX rekordra. +> +> Létezik valamilyen parancs a sendmail programhoz, amellyel azonnal lekérhetjük az összes +> levelünket? A felhasználómnak természetesen nincsenek rendszergazdai jogosultságai az adott +> gépen. + +A sendmail.cf privacy flags beállításai között van egy definíció, az +Opgoaway,restrictqrun. + +Vegyük ki innen a restrictqrun beállítást, amivel a nem root felhasználók is megindíthatják a +sor feldolgozását. Valószínűleg az MX-ek átrendezésére is szükség lesz. Mi vagyunk az első MX +az ilyen típusú ügyfelek számára, és ezt adtuk meg: + +# Ha mi vagyunk a legjobb MX a levél számára, akkor ne generáljunk +# helyi beállítási hibát, hanem próbálkozzunk közvetlenül. +OwTrue + +Ezzel már a távoli gép közvetlenül nekünk küld anélkül, hogy próbálkozna az ügyfél kapcsolatával. +Ezt majd továbbküldjünk az ügyfélnek. Ez csak hálózati nevek esetében működik, tehát az ügyfelünknek +el kell neveznie a leveleket fogadó gépét customer.com-nak, valamint a fel kell venni a +hostname.customer.com címet is a DNS-be. Ehhez egyszerűen csak elegendő egy A rekordot +betenni a customer.com-hoz. + + + + + + + Miért kapok folyton Relaying + Denied hibát, amikor más + gépekről küldök levelet? + + + + A &os; alapértelmezett telepítése + során a sendmail + úgy állítódik be, hogy csak + arról a gépről küldhetünk vele + levelet, ahol fut. Például, ha + POP szerver is elérhető, + akkor a felhasználók meg tudják + nézni a leveleiket az iskolából, + munkából vagy bármilyen más + távoli helyről, de leveleket onnan + továbbra sem tudnak küldeni. + Általában pár pillanattal a + próbálkozás után a + MAILER-DAEMON küldeni fog + egy 5.7 Relaying Denied + (5.7 A továbbítás nem + engedélyezett) üzenetet. + + Több lehetőségünk is van ennek + megkerülésére. Az a legegyszerűbb + módszer, ha az internet-szolgáltatónk + címét felvesszük az + /etc/mail/relay-domains + állományba. Például + így: + + &prompt.root; echo "az.internet.szolgáltató.net" > /etc/mail/relay-domains + + Az állomány létrehozása vagy + módosítása után újra kell + indítanunk a sendmail + programot. Ez remekül működik abban az + esetben, ha rendszergazdák vagyunk és nem + akarunk a helyi gépről levelet küldeni, + vagy egy másik gépen vagy akár + másik internet-szolgáltatóval akarunk + valamilyen kattingatós levelező programot + használni. Olyankor is nagyon hasznos lehet, amikor + csak egy vagy két e-mail + hozzáférést állítottunk + be. Ha egyszerre több címet is fel + szeretnénk venni, akkor nyissuk meg ezt az + állományt a kedvenc + szövegszerkesztőnkkel és írjuk be a + tartományokat, soronként egyet: + + saját.internet.szolgáltató.net +másik.internet.szolgáltató.com +felhasználók-internet.szolgáltató.ja +www.minta.org + + Innentől kezdve a listában szereplő + bármelyik gépről tudunk levelet + küldeni (feltéve, hogy az adott + felhasználó hozzáfér a + gépünkhöz). Ezzel + gyönyörűen megoldhatjuk, hogy a + felhasználóink képesek legyenek + távolról is levelet küldeni a + rendszerünkön keresztül anélkül, + hogy mások pedig szemetet küldenének + át rajtunk. + + + + + + + + Komolyabb témák + + A következő szakaszban szóba kerülnek + olyan komolyabb témák, mint például a + levelek konfigurációja és a levelezés + beállítása az egész tartomány + számára. + + + Alapvető beállítások + + + e-mail + beállítás + + + Alapból képesnek kell lennünk leveleket + küldeni külső gépekre egészen + addig, amíg az /etc/resolv.conf + állomány a megfelelő + beállításokat tartalmazza vagy egy + saját névszervert futtatunk. Ha + szeretnénk, hogy a gépünkre + érkező levelek elérjék a &os;-s + gépünkön futó + levéltovábbító + ügynököt (például a + sendmail programot), akkor erre + két módszer kínálkozik: + + + + Futtassunk saját névszervert és + hozzunk létre magunknak egy tartományt. + Például FreeBSD.org. + + + + Közvetlenül a gépünkre + küldessük a leveleket. Ezt úgy + tehetjük meg, ha egyből a + gépünkhöz tartozó DNS névre + küldetjük a leveleket. Például az + enyem.FreeBSD.org + címre. + + + + SMTP + + Függetlenül attól, hogy a fentiek + közül melyik megoldást választjuk, a + levelek csak akkor tudnak eljutni közvetlenül a + gépünkre, ha állandó, statikus + IP-címmel rendelkezünk (tehát nem dinamikus + címmel, amit általában a + betárcsázós PPP kapcsolatokhoz szoktak + kiosztani). Ha tűzfal mögött vagyunk, akkor + valamilyen módon felénk kell + irányítani az SMTP forgalmat is. Ha + közvetlenül a gépünkön akarjuk + fogadni a leveleket, akkor a következő kettő + közül az egyik mindenképpen kelleni fog: + + + MX rekord + + Gondoskodjunk róla, hogy a hozzánk + tartozó DNS-ben (legkisebb sorszámú) MX + rekord a gépünk IP-címére + mutat. + + + + Gondoskodjunk róla, hogy a hozzánk + tartozó DNS-ben nincs semmilyen MX rekord a + gépünkhöz. + + + + A fentiek közül bármelyik elég + ahhoz, hogy közvetlenül a gépünkre + érkezzen meg a levél. + + Próbáljuk ki: + + &prompt.root; hostname +enyem.FreeBSD.org +&prompt.root; host enyem.FreeBSD.org +enyem.FreeBSD.org has address 204.216.27.XX + + Ha ezt látjuk, akkor minden gond nélkül + lehet küldeni levelet a nevem@enyem.FreeBSD.org a címre + (feltételezve, hogy a sendmail + megfelelően működik az enyem.FreeBSD.org címen). + + Ha viszont ehhez hasonlót tapasztalunk: + + &prompt.root; host enyem.FreeBSD.org +enyem.FreeBSD.org has address 204.216.27.XX +enyem.FreeBSD.org mail is handled (pri=10) by kozpont.FreeBSD.org + + A gépünkre (enyem.FreeBSD.org) küldött + összes levelet a kozpont szedi össze + ugyanazon felhasználói névvel ahelyett, + hogy közvetlenül a gépünkre küldeni + ezeket. + + Az iménti adatokat a DNS szerver határozza + meg. A levelek továbbításával + kapcsolatos információkat az + MX mint Mail + eXchange DNS-rekord tárolja. Ha + nincs ilyen MX rekord, akkor az IP-cím alapján + közvetlenül az adott géphez kerül a + levél. + + Például a freefall.FreeBSD.org MX rekordja + hajdanán így nézett ki: + + freefall MX 30 mail.crl.net +freefall MX 40 agora.rdrop.com +freefall MX 10 freefall.FreeBSD.org +freefall MX 20 who.cdrom.com + + Láthatjuk, hogy a freefall + esetében több MX bejegyzés is szerepel. A + legalacsonyabb MX-számú gép fogja kapni az + erre a címre beérkező leveleket, amennyiben + elérhető. Ha valamilyen okból nem + érhető el, akkor helyette ideiglenesen a + többiek (melyeket néha csak tartalék + MX-eknek neveznek) veszik át a levelet és + átadják a legalacsonyabb számúnak, + amint az újra elérhetővé + válik. + + A tartalék jelleggel megadott MX gépek akkor + érnek ténylegesen valamit, ha teljesen + máshonnan csatlakoznak az internethez. Az internet + szolgáltató vagy egy ismerősünk + gépe valószínűleg minden + további nélkül segít ennek + megoldásában. + + + + + Egy egész tartomány leveleinek + kezelése + + Egy levelező szerver + beállításához valahogy meg kell + tudnunk oldalni, hogy a különböző + munkaállomásokra küldött levelek + közvetlenül hozzá fussanak be. Alapvetően + tehát arról lenne szó, hogy a + tartományunkon (ez ebben az esetben a *.FreeBSD.org) belüli gépekre + címzett levelekre ez a gép tart + igényt és így ezek ide + irányítódnak át, majd a + felhasználók erről a központi + levelező szerverről kapják meg a + leveleiket. + + DNS + + Az életünk + megkönnyítéséhez minden + felhasználónak létrehozzuk a saját + felhasználói nevét a + levelező szerveren is. Ezt az &man.adduser.8; paranccsal + gyorsan el is végezhetjük. + + A levelező szerver lesz a hálózat + összes munkaállomásához kirendelt + levélváltó. Ezt a DNS + beállításai között így + adhatjuk meg: + + enyem.FreeBSD.org A 204.216.27.XX ; Munkaállomás + MX 10 kozpont.FreeBSD.org ; Levelező szerver + + Ezzel lényegében az A rekord figyelmen + kívül hagyásával + átirányítjuk a munkaállomások + számára érkező összes levelet a + levelező szerverre. A levelek tehát az MX rekord + által mutatott címre mennek ki. + + Ezt önállóan nem tudjuk elvégezni, + hacsak nem futattunk egy saját DNS szervert. Ha nincsen + vagy nem is tudunk DNS szervert futtatni, akkor ebben a + kérdésben egyeztessünk az + internet-szolgáltatónkkal vagy bárkivel, + aki a DNS beállításaiért + felelős. + + Ha virtuális e-mail címket is kezelünk, + akkor a most következő információ + még a hasznunkra lehet. A példa + kedvéért most feltesszük, hogy a + tartományunkban van egy ügyfelünk, jelen + esetben az ugyfel1.org, + és azt akarjuk, hogy az ugyfel1.org címére + küldött levelek a saját levelező + szerverünkre kerüljenek át, a level.sajat.com címre. A DNS-t + ehhez így kell beállítani: + + ugyfel1.org MX 10 level.sajat.com + + Ha csak az ugyfel1.org + levelezését akarjuk kezelni, akkor ahhoz + nem kell külön A rekord. + + + Vigyázzunk, mert az ugyfel1.org csak akkor + pingelhető, ha létezik hozzá A + rekord. + + + Befejezésül a levelező + szerverünkön futó + sendmail számára is fel + kell tárnunk, hogy milyen tartományokhoz + és/vagy hálózati nevekhez fogadjon + leveleket. Ezt több módon is + elvégezhetjük. A következők + bármelyik megfelel erre a célra: + + + + A FEATURE(use_cw_file) + használata esetén vegyük fel a + címeket az + /etc/mail/local-host-names + állományba. Ha a + sendmail 8.10 előtti + változatai esetében ehhez az + /etc/sendmail.cw + állományra lesz + szükségünk. + + + + Tegyük be a Cwsajat.cimunk.com + sort az /etc/sendmail.cf vagy a + sendmail 8.10 és + későbbi változatai esetén az + /etc/mail/sendmail.cf + állományba. + + + + + + + + SMTP és az UUCP + + A &os;-hez tartozó sendmail + olyan gépek számára lett kialakítva, + amelyek közvetlenül az internethez csatlakoznak. Az + UUCP használatával levelező rendszerek + számára egy másik konfigurációs + állományt kell telepíteni a + sendmail számára. + + Az /etc/mail/sendmail.cf + állítása kézzel + egyáltalán nem könnyű. A + sendmail 8. változata + ráadásul a konfigurációs + állományokat az &man.m4.1; előfeldolgozó + segítségével gyártja le, ahol a + tényleges beállítások egy magasabb + absztrakciós szinten jelennek meg. Az &man.m4.1; + típusú konfigurációs + állományok a + /usr/share/sendmail/cf + könyvtárban találhatóak. A + cf alkönyvtárban levő + README állomány igyekszik a + felhasználót bevezetni az &man.m4.1; alapú + beállítások világába. + + A mailertable nevű + lehetőség használatával tudjuk a + legjobban támogatni az UUCP protokollon keresztüli + kézbesítést. Ezzel felépül egy + olyan adatbázis, amelyet a + sendmail fel tud használni a + továbbítást érintő + döntésekben. + + Ehhez elsőként hozzuk is létre a + saját .mc állományunkat. + Ehhez a /usr/share/sendmail/cf/cf + könyvtár tartalmaz néhány + példát. Hívjuk most ezt az + állomnyunkat ize.mc néven. A + következő módszerrel tudjuk egy valós + sendmail.cf állománnyá + alakítani: + + &prompt.root; cd /etc/mail +&prompt.root; make ize.cf +&prompt.root; cp ize.cf /etc/mail/sendmail.cf + + Egy átlagos .mc + állomány egyébként valahogy így + épül fel: + + VERSIONID(`verziószám') OSTYPE(bsd4.4) + +FEATURE(accept_unresolvable_domains) +FEATURE(nocanonify) +FEATURE(mailertable, `hash -o /etc/mail/mailertable') + +define(`UUCP_RELAY', sajat.uucp.relay) +define(`UUCP_MAX_SIZE', 200000) +define(`confDONT_PROBE_INTERFACES') + +MAILER(local) +MAILER(smtp) +MAILER(uucp) + +Cw sajat.al.nev +Cw azuucpgepneve.UUCP + + Az accept_unresolvable_domains, + nocanonify és + confDONT_PROBE_INTERFACES + lehetőségekre hivatkozó sorok + megakadályozzák, hogy a levél + kézbesítésében a DNS is szerepet + játsszon. Az UUCP_RELAY az UUCP + alapú kézbesítés + támogatását engedélyezi. + Egyszerűen csak írjunk ide egy internetes + hálózati nevet, amely képes feldolgozni az + .UUCP áltartomány címeit. Az esetek + többségében ide az + internet-szolgáltatónk levelek + továbbküldéséért felelős + gépe kerül. + + Miután ezzel végeztünk, + szükségünk lesz még az + /etc/mail/mailertable + állományra is. Ha a külvilág + felé csak egyetlen összeköttetést + használunk a levelekhez, akkor az alábbi pontosan + megfelel: + + # +# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable +. uucp-dom:sajat.uucp.relay + + Egy bonyolultabb példa pedig így néz + ki: + + # +# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable +# +horus.interface-business.de uucp-dom:horus +.interface-business.de uucp-dom:if-bus +interface-business.de uucp-dom:if-bus +.heep.sax.de smtp8:%1 +horus.UUCP uucp-dom:horus +if-bus.UUCP uucp-dom:if-bus +. uucp-dom: + + Az első három sor azokat a speciális + eseteket kezeli, ahol a tartomány felé + küldött levelek nem az alapértelmezett + úton visszük tovább, hanem valamelyik UUCP + szomszéd felé és így le tudjuk + rövidíteni a kézbesítés + útvonalát. Az ezeket követő sor dolgozza + fel a helyi Ethernet tartomány felé STMP protokollal + továbbítható leveleket. Végül az + UUCP szomszédokat is felsoroljuk az .UUCP + áltartomány jelölése szerint, így + megengedjük, hogy a + uucp-szomszéd! + címzett + felülbírálja az alapértelmezett + szabályokat. Az utolsó sorban mindig egyetlen pont + szerepel, ami minden másra illeszkedik, így az UUCP + kézbesítés egy olyan UUCP szomszéd + felé halad, amely a világ felé egy + univerzális levelező átjárónak + tekinthető. A uucp-dom: kulcsszó + mögött szereplő összes csomópont + nevének érvényes UUCP szomszédra kell + utalnia, amelyet a uuname paranccsal le is + tudunk ellenőrizni. + + A feladatból már csak annyi maradt hátra, + hogy használat előtt ezt az állományt + át kell alakítani DBM adatbázis + formátumba. Az ehhez szükséges parancsot + érdemes mailertable + állomány elejére bejegyzésben + felírni. A mailertable + megváltoztatásakor mindig le kell futtatni ezt a + parancsot. + + Utolsó jótanács: ha nem lennénk + biztosak valamelyik kézbesítési + útvonal működésében, ne + felejtsük el a sendmail + beállítását. + Ezzel a sendmail az ún. + címtesztelő módban + (address test mode) indul el. Gépeljük be, hogy + 3,0, majd írjuk be a tesztelni + kívánt címet. Az utolsó sorban + láthatjuk a felhasznált belső + levéltovábbító + ügynököt, a célgépet, amellyel ezt + meghívjuk, és a (valószínűleg az + átfordított) címet. Innen a CtrlD + billentyűkombinációval léphetünk + ki. + + &prompt.user; sendmail -bt +ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) +Enter <ruleset> <address> +> 3,0 ize@pelda.com +canonify input: ize @ pelda . com +... +parse returns: $# uucp-dom $@ sajat.uucp.relay $: ize < @ pelda . com . > +> ^D + + + + + + + + Bill + Moran + Készítette: + + + + + Csak küldés + beállítása + + Gyakran előfordulhat, hogy csak leveleket akarunk + továbbküldeni. Mint például: + + + + Asztali számítógépünk + van, de használni akarunk olyan programokat, mint + például a &man.send-pr.1;. Ehhez az + internet-szolgáltatón keresztül kell + továbbküldeni a levelet. + + + + A számítógépünk egy olyan + szerver, amely nem helyben kezeli a leveleket, ezért az + összeset átküldi feldolgozásra. + + + + Szinte bármelyik levélküldő + ügynök képes betölteni ezt az űrt. + Sajnos eléggé bonyolult helyesen + beállítani úgy egy bármire + képes levélküldőt, hogy egyszerűen + csak szabaduljon meg a levelektől. Ilyenkor a + sendmail vagy a + postfix használatával + tulajdonképpen ágyúval lövünk + verébre. + + Továbbá, ha egy átlagos + internet-hozzáféréssel rendelkezünk, + adódhat, hogy a szerződés egyszerűen + tiltja a levelező szerver + futtatását. + + Legegyszerűbben úgy tudjuk + kielégíteni az ilyen jellegű igényeket, + ha feltelepítjük a mail/ssmtp portot. A + root felhasználóval adjuk ki a + következő parancsokat: + + &prompt.root; cd /usr/ports/mail/ssmtp +&prompt.root; make install replace clean + + Telepítése után a mail/ssmtp portot a mindössze + négysoros + /usr/local/etc/ssmtp/ssmtp.conf + állománnyal állíthatjuk be: + + root=valodiemail@minta.com +mailhub=level.minta.com +rewriteDomain=minta.com +hostname=_GEPNEV_ + + A root felhasználó + számára feltétlenül egy valódi + e-mail címet adjuk meg. A level.minta.com helyére az + internet-szolgáltatónk kimenő leveleket + továbbító szerverét adjuk meg + (bizonyos szolgáltatók ezt kimenő + levelező szervernek vagy SMTP + szervernek nevezik). + + Ne felejtsük el sendmail + démont sem letiltani, beleértve a kimenő + levelek kezelését. Ennek részleteit + lásd a ban. + + A mail/ssmtp + használatánál még adhatunk meg + további beállításokat is. A + /usr/local/etc/ssmtp + állományban vagy az ssmtp + man oldalán találhatunk példákat + és olvashatunk bővebben a + témáról. + + Az ssmtp ilyen fajta + beállításával a + számítógépünkön levő + szoftverek is helyesen fognak működni, miközben nem + sértjük meg az internet-szolgáltató + előírásait és nem tesszük + lehetővé, hogy a + számítógépünkről + levélszemetet küldhessenek. + + + + + Levelezés betárcsázós + kapcsolattal + + Ha statikus IP-címünk van, akkor az + alapértelmezett beállítások + tökéletesen megfelelőek számunkra. + Csupán a gépünkhöz tartozó + internetes címet kell megadnunk a gépünk + nevének és a sendmail + elvégzi a többit. + + Ha viszont dinamikusan kiosztott IP-címmel + rendelkezünk és betárcsázós + PPP kapcsolaton keresztül csatlakozunk az + internethez, akkor valószínűleg az + internet-szolgáltató levelező szerverén + van egy postaládánk. Most tegyük fel, hogy a + internet-szolgáltató tartománya a szolgaltato.net és a + felhasználói név a + felhasznalo, a gépünk neve pedig + otthoni.bsdm, valamint az + internet-szolgáltató részéről + levelezésre a + relay.szolgaltato.net gépet + használhatjuk. + + A postaládánkból úgy tudjuk + letölteni a leveleket, ha telepítünk hozzá + egy programot. Erre a feladatra a + fetchmail hibátlanul alkalmas, + mivel több különböző protokollt ismer. + Ez a program csomagként vagy a + Portgyűjteményből (mail/fetchmail) is elérhető. + Az internet-szolgáltatók erre + általában a POP protokollt + ajánlják fel. Ha a felhasználói + PPP alkalmazást használjuk, + állítsuk be az + /etc/ppp/ppp.linkup állományt a + következő módon és így a + csatlakozáskor maguktól letöltődnek a + leveleink: + + MYADDR: + !bg su felhasznalo -c fetchmail + + Ha a sendmail + segítségével küldjük tovább + a leveleket a nem helyi hozzáférések + felé (ahogy azt lentebb is láthatjuk), akkor minden + bizonnyal a csatlakozáskor arra is + szükségünk lesz, hogy a leveleket + tároló sor is feldolgozódjon. Ezt úgy + oldhatjuk meg, ha az /etc/ppp/ppp.linkup + állományba a fetchmail parancs + után a következőt tesszük: + + !bg su felhasznalo -c "sendmail -q" + + Ez a példa feltételezi, hogy az otthoni.bsdm gépen van egy + felhasznalo nevű + felhasználónk. Az otthoni.bsdm gépen a + felhasznalo felhasználói + könyvtárában hozzunk létre egy + .fetchmailrc állományt: + + poll szolgaltato.net protocol pop3 fetchall pass TitkosJelszo + + Ezt az állományt csak és + kizárólag a felhasznalo + olvashatja, mivel szerepel benne a hozzá tartozó + TitkosJelszo. + + Úgy tudunk a megfelelő from: + fejléccel küldeni, ha felvilágosítjuk a + sendmail programot, hogy ne az + felhasznalo@otthoni.bsdm címet, hanem a + felhasznalo@szolgaltato.net címet + használja. Sőt, a gyorsítás + kedvéért a sendmail + számára érdemes elárulni, hogy a + relay.szolgaltato.net címen + keresztül küldjön. + + A munka elvégzéséhez elegendő az + alábbi .mc + állomány: + + VERSIONID(`otthoni.bsdm.mc 1.0') +OSTYPE(bsd4.4)dnl +FEATURE(nouucp)dnl +MAILER(local)dnl +MAILER(smtp)dnl +Cwlocalhost +Cwotthoni.bsdm +MASQUERADE_AS(`szolgaltato.net')dnl +FEATURE(allmasquerade)dnl +FEATURE(masquerade_envelope)dnl +FEATURE(nocanonify)dnl +FEATURE(nodns)dnl +define(`SMART_HOST', `relay.szolgaltato.net') +Dmotthoni.bsdm +define(`confDOMAIN_NAME',`otthoni.bsdm')dnl +define(`confDELIVERY_MODE',`deferred')dnl + + Az előző szakaszban találhatjuk meg annak a + módját, hogy miként varázsoljunk + ebből az .mc + állományból egy + sendmail.cf állományt. A + sendmail.cf frissítése + után pedig ne felejtsük el a + sendmail + újraindítását! + + + + + + + + James + Gorham + Írta: + + + + + Az SMTP hitelesítése + + Levelező szerverünkön az + SMTP protokoll + hitelesítésének (SMTP + Authentication) engedélyezése több + szempontból is előnyökkel bír. Az + SMTP hitelesítésének + bekapcsolása egy újabb réteget képez a + sendmail védelmében, + és az olyan állandóan mozgásban + levő felhasználók számára is + megoldást nyújt, akik anélkül + képesek használni ugyanazt a levelező szervert, + hogy minden alkalommal újrakonfigurálnák a + levelező kliensüket. + + + + Telepítsük fel a security/cyrus-sasl2 portot. A + security/cyrus-sasl2 port + több fordítási idejű + beállítást támogat. Itt most az + SMTP hitelesítését + fogjuk használni, ezért gondoskodjunk a + opció + engedélyezéséről. + + + + A security/cyrus-sasl2 + telepítés után nyissuk meg + szerkesztésre a + /usr/local/lib/sasl2/Sendmail.conf + állományt (vagy ha még nem + létezne, hozzuk létre), és benne + vegyük fel a következő sort: + + pwcheck_method: saslauthd + + + + Ezt követően telepítsük a security/cyrus-sasl2-saslauthd + portot, és tegyük bele az + /etc/rc.conf állományba ezt + a sort: + + saslauthd_enable="YES" + + Végezetül indítsuk el a saslauthd + démont: + + &prompt.root; /usr/local/etc/rc.d/saslauthd start + + Ez a démon fog közvetíteni a + sendmail és a &os; + passwd adatbázisa közti + hitelesítésben. Ezzel elkerülhetjük + az új felhasználói nevek és + jelszavak felvételét az SMTP + hitelesítés használatához, + így a hozzáférések és a + levelezés jelszava ugyanaz marad. + + + + Most pedig írjuk hozzá az alábbi + sorokat az /etc/make.conf + állományhoz: + + SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL +SENDMAIL_LDFLAGS=-L/usr/local/lib +SENDMAIL_LDADD=-lsasl2 + + Ezek a sorok állítják be a + sendmail számára, + hogy fordítás közben a cyrus-sasl2 függvényeit + használja. A sendmail + újrafordítása előtt + mindenképpen legyen fenn a cyrus-sasl2 port. + + + + A sendmail + újrafordítását a + következő parancsok + végrehajtásával intézhetjük + el: + + &prompt.root; cd /usr/src/lib/libsmutil +&prompt.root; make cleandir && make obj && make +&prompt.root; cd /usr/src/lib/libsm +&prompt.root; make cleandir && make obj && make +&prompt.root; cd /usr/src/usr.sbin/sendmail +&prompt.root; make cleandir && make obj && make && make install + + A sendmail + fordítása esetén semmilyen + problémának nem szabadna előfordulnia, + kivéve ha a /usr/src + könyvtárat és a szükséges + osztott könyvtárakat nem változtatjuk + időközben túlságosan gyakran. + + + + A sendmail + lefordítása és + újratelepítése után + szerkesszük át az + /etc/mail/freebsd.mc + állományt (vagy azt az .mc + állományt, amelyet éppen + használunk). Sok rendszergazda a &man.hostname.1; + parancs válaszát használja fel az + .mc típusú + állományok egyedi elnevezéséhez). + Írjuk bele a következő sorokat: + + dnl set SASL options +TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl +define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl + + Ezek állítják be a + sendmail számára a + felhasználók hitelesítésére + alkalmas különböző módszereket. Ha + a pwcheck módszer helyett + valami mást akarunk használni, akkor + járjunk utána a + dokumentációban. + + + + Zárásul futassuk le a &man.make.1; parancsot + az /etc/mail könyvtárban. + Így lefut az új .mc + állományunk és létrejön egy + freebsd.cf (vagy amilyen nevet az + .mc állománynak megadtunk) + .cf állomány. + Ezután a make install restart + parancs kiadásával másoltassuk át + ezt a sendmail.cf helyére + és szabályosan indítassuk újra a + sendmail + szolgáltatást. A folyamatról + részletesebb tájékoztatást az + /etc/mail/Makefile állomány + tud nyújtani. + + + + Ha eddig minden a legnagyobb rendben történt, + akkor most már képesek vagyunk bejelentkezési + információt is átadni a levelező + kliensnek és elküldeni egy tesztüzenetet. A + hibák kiszűréséhez + állítsuk a sendmail + opcióját az 13 + értékre és figyeljük a + /var/log/maillog + állományt. + + További felvilágosításért + olvassuk el a sendmail + SMTP hitelesítéssel + foglalkozó oldalát (angolul). + + + + + + + + Marc + Silver + Készítette: + + + + + Levelező kliensek + + levelező kliensek + + A levelező kliens (Mail User Agent, + MUA) egy olyan alkalmazás, amelyik + elektronikus levelek küldésére és + fogadására használható. + Azonkívül, ahogy az e-mail + fejlődik és egyre bonyolultabbá + válik, a levelező kliensek is egyre inkább + erősebbé válnak abban a tekintetben, ahogy az + e-maileket kezelik. Ezzel együtt a + felhasználók is egyre több + lehetőséget és rugalmasságot kapnak. A + &os; számos levelező klienst támogat, + mindegyikük könnyedén telepíthető a + &os; Portgyűjteménye + segítségével. A felhasználók + választhatnak a grafikus kliensek, mint + például az evolution vagy + a balsa és a konzolos kliensek, + például a mutt, + pine vagy mail + között, esetleg használhatják a nagyobb + szervezetek részéről felkínált + webes felületeket is. + + + mail + + A &man.mail.1; a &os; alapértelmezett levelező + kliense. Egy olyan konzolos alkalmazás, amelyben + elérhetjük az e-mailek küldéséhez + és fogadásához szükséges + összes alapvető funkciót, habár a + csatolmányokat csak korlátozottan képes + kezelni és csak a helyi postaládákat + kezeli. + + Annak ellenére, hogy a mail + önmaga nem képes kommunikálni + POP vagy IMAP + szerverekkel, az ilyen postaládák tartalmát + egy fetchmail-szerű + alkalmazással (lásd ) le tudjuk tölteni a + számára is elérhető helyi + mbox állományba. + + A levelek küldéséhez és + fogadásához egyszerűen hívjuk be a + mail programot a következő + módon: + + &prompt.user; mail + + Ezután a /var/mail könyvtárban + található felhasználói + postaládánk tartalmát automatikusan + beolvassa a mail segédprogram. Ha a + postaláda üres, akkor a program egyből befejezi + futását és közli, hogy nem + talált levelet. Amikor viszont tudott beolvasni + leveleket, megjelenik egy felület, ahol a beérkezett + üzenetek listáját láthatjuk. Az + üzenetek automatikusan sorszámozódnak, ahogy + ezt az alábbi példa is szemlélteti: + + Mail version 8.1 6/6/93. Type ? for help. +"/var/mail/marcs": 3 messages 3 new +>N 1 root@localhost Mon Mar 8 14:05 14/510 "proba" + N 2 root@localhost Mon Mar 8 14:05 14/509 "felhasznaloi hozzaferes" + N 3 root@localhost Mon Mar 8 14:05 14/509 "minta" + + Az üzenetek olvasásának a + t paranccsal kezdhetünk neki, amelyet az + elolvasandó üzenet sorszáma követ. + Ebben a példában az első e-mailt nyitjuk + meg: + + & t 1 +Message 1: +From root@localhost Mon Mar 8 14:05:52 2004 +X-Original-To: marcs@localhost +Delivered-To: marcs@localhost +To: marcs@localhost +Subject: proba +Date: Mon, 8 Mar 2004 14:05:52 +0200 (SAST) +From: root@localhost (Charlie Root) + +Ezt az uzenetet probabol kuldom, valaszolj ra, ha megkaptad. + + Ahogy az a fenti példából is + látszik, a t billentyű + hatására az üzenet a teljes + fejlécével együtt jelenik meg. Az + üzenetek listáját a h + billentyűvel hozhatjuk vissza. + + Ha egy levélre válaszolni szeretnénk, + akkor ezt a mail paranccsal is + megtehetjük, vagy az R vagy az + r parancsokkal. Az R arra + utasítja a mail programot, hogy csak + az üzenet küldőjének válaszoljon, + míg az r hatására nem + csupán a küldő, hanem az üzenet + összes címzettje megkapja a válaszunkat. A + parancshoz hozzátűzhetjük egy levél + sorszámát is, ekkor az adott levélre fogunk + válaszolni. Miután kiadtuk a parancsot, + írjuk meg a válaszunkat és új sorban + kezdve zárjuk le az üzenetet egyetlen + . beírásával. Valahogy + így: + + & R 1 +To: root@localhost +Subject: Re: proba + +Koszonom, megkaptam a leveledet. +. +EOT + + Új levelet az m + segítségével tudunk küldeni, ami + után meg kell adnunk a címzettet. Egyszerre + több címzettet is meg tudunk adni, ha a + címzett helyén címeiket egy + , karakterrel elválasztva soroljuk fel. + Ezután a levél témája is + megadható, amit végül a levél + szövege követ. Az üzenetet egy új sorban + megadott egyetlen . + segítségével zárhatjuk le. + + & mail root@localhost +Subject: Elsajatitottam a mail hasznalatat + +Most mar en is tudok levelet irni es fogadni a mail hasznalataval... :) +. +EOT + + Amikor a mail segédprogramban + vagyunk, a ? használatával + bármikor segítséget kérhetünk, + valamint a mail + működésével kapcsolatban a &man.mail.1; + man oldalát érdemes felkeresni. + + + Ahogy azt már korábban is + említettük, a &man.mail.1; parancsot eredetileg + nem készítették fel az csatolt + állományok kezelésére, + ezért igen gyengén bánik velük. Az + újabb levelező kliensek, mint + például a mutt, a + csatolt állományokat sokkal intelligensebb + módon kezelik. Ha viszont ragaszkodunk a + mail használatához, akkor a + converters/mpack port + használatát érdemes megfontolnunk. + + + + + + mutt + + A mutt apró mérete + ellenére egy igen komoly levelező kliens és + remek lehetőségeket ajánl fel. Íme + ízelítésképpen + közülük néhány: + + + + Képes az üzeneteket szálakba + rendezni + + + + Az e-mailek titkosítására és + elektronikus aláírására + támogatja a PGP használatát + + + + MIME támogatás + + + + Maildir támogatás + + + + Nagyfokú testreszabhatóság + + + + Ezen lehetőségei révén a + mutt ez egyik legfejlettebb + levelező kliens. A mutt + részletesebb bemutatását a címen találjuk + (angolul). + + A mutt stabil változata a + mail/mutt port + használatával telepíthető fel, + miközben a fejlesztés alatt levő + változatot a mail/mutt-devel port telepíti. + Miután a portot sikerült felraknunk, a + mutt az alábbi parancs + begépelésével indítható + el: + + &prompt.user; mutt + + A mutt indulása + után automatikusan beolvassa a /var/mail könyvtárban + megtalálható felhasználói + postaládát és ha lehetséges, akkor + megjeleníti a tartalmát. Ha nincsen levél + a felhasználó postaládájában, + akkor a mutt a + felhasználó parancsaira vár. Ezen a + képen a mutt + üzenetlistája látható: + + + + + + + + A levelek elolvasásához egyszerűen csak + válasszuk ki a kurzorral és nyomjuk meg az + Enter billentyűt. Ezután a + mutt így mutatja a + levelet: + + + + + + + + Ahogy azt már a &man.mail.1; parancsnál is + megszokhattuk, a mutt is + lehetővé teszi, hogy vagy csak a küldőnek, + vagy pedig rajta kívül még az összes + címzettnek is válaszoljunk. A levél + küldőjének az r + lenyomásával tudunk válaszolni. A + csoportos válaszadáshoz pedig, ahol tehát a + küldőn kívül a címzettek is + megkapják a levelünket, a g + billentyűt kell használni. + + + A mutt az e-mailek + létrehozásához és + megválaszolásához a &man.vi.1; + szövegszerkesztőt használja. Ezt úgy + tudjuk átállítani, ha a + könyvtárunkban található + .muttrc állományban + átírjuk az editor + változót, vagy értéket adunk az + EDITOR környezeti + változónak. A mutt + beállításáról többet a + címen + tudhatunk meg. + + + Egy új levél megírásához + nyomjuk le az m gombot. Miután + elláttuk érvényes témával a + levelet, a mutt elindítja a + &man.vi.1; szövegszerkesztőt és + nekiláthatunk a levél szövegének. + Amint befejeztük, mentsük el és + lépjünk ki a vi + szerkesztőből. Ezután visszakapjuk a + mutt felületét, ahol a + küldendő e-mail összefoglalását + láthatjuk. A levelet végül az + y lenyomásával + küldhetjük el. Erre a következő + képen láthatunk egy példát: + + + + + + + + A mutt ezenkívül + még rengeteg segítséget is tartalmaz, + amelyet a legtöbb menüből a ? + gomb lenyomásával érhetünk el. A + felső sorban mindig láthatjuk a kiadható + parancsok rövid összefoglalását. + + + + + pine + + A pine alapvetően a + kezdő felhasználók számára + íródott, de számos komolyabb + lehetőséget is támogat. + + + A pine szoftverrel kapcsolatban + a múltban már rengeteg távolról + kihasználható sebezhetőség + látott napvilágot, és ennek + köszönhetően a támadók + megfelelően előkészített e-mailek + segítségével tetszőleges + kódot tudnak futtatni a rendszeren levő helyi + felhasználókon keresztül. Noha az + összes ilyen ismert hibát + javították, de a &os; biztonsági tisztje + szerint a pine kódját + biztonság szempontjából annyira hanyag + módon írták, hogy további, eddig + még felfedezetlen sebezhetőségeket is + magában rejt. Ennek megfelelően tehát a + pine használata mindenkinek + csak saját felelősségre javasolt. + + + A pine jelenlegi verziója + a mail/pine4 porton + keresztül telepíthető. A + telepítés lezajlása után a + pine a következő paranccsal + indítható: + + &prompt.user; pine + + A pine első futtatása + során egy üdvözlő üzenetet és + egy rövid bemutatkozást jelenít meg, valamint + a pine fejlesztői arra + kérik a felhasználókat, hogy küldjenek + nekik egy névtelen üzenetet, amiből le + tudják szűrni mennyien használják a + kliensüket. A névtelen üzenet + elküldéséhez a Enter + lenyomásával járulhatunk hozzá vagy + az E használatával + enélkül tudunk kilépni a + képernyőről. Ezt az üdvözlő + képernyőt itt láthatjuk: + + + + + + + + A felhasználó ezután a + főmenübe kerül, ahol a kurzorbillentyűkkel + minden gond nélkül tudunk mozogni. Ebben a + főmenüben a levelek megírására, a + leveleket tároló könyvtárak + tallózására vagy éppen a + címjegyzék karbantartására + gyorsbillentyűket is használhatuk. A + főmenü alatt szerepel az adott menüben + végrehajtható feladatokhoz tartozó + gyorsbillentyűk rövid felsorolása. + + A pine + alapértelmezés szerint az inbox könyvtárat nyitja + meg. A bennelévő üzenetek + listájának megtekintéséhez nyomjuk a + I gombot vagy válasszuk ki a lentihez + hasonló módon a MESSAGE + INDEX menüpontot: + + + + + + + + Az üzenetek listájában az adott + könyvtárban található üzenetek + láthatjuk, és köztük a + kurzorbillentyűkkel mozoghatunk. A kiemelt üzenet az + Enter lenyomásával + olvasható el. + + + + + + + + A lenti képen egy ilyen példa üzenetet + láthatunk a pine programban. + A rendelkezésünkre álló + gyorsbillentyűk ilyenkor is a képernyő + alján megjelennek referenciaként. Ilyen + gyorsbillentyű többek közt az r + gomb, amelynek hatására a klienssel + megválaszolhatjuk a éppen látható + üzenetet. + + + + + + + + A pine kliensen belül a + pico szövegszerkesztő + segítségével tudunk megválaszolni + egy e-mailt, amely alapból a + pine mellé települ. A + pico megkönnyíti a + navigációt az üzenetekben és sokkal + elnézőbb a kezdő felhasználókkal, + mint például a &man.vi.1; vagy a &man.mail.1;. Ha + befejeztük a választ, az üzenetet a CtrlX + billentyűkombinációval tudjuk elküldeni. + A pine erre + megerősítést fog kérni. + + + + + + + + A pine alkalmazás a + főmenüből elérhető + SETUP menüpont + meghívásával szabható testre. A + további részleteket a oldalon + találhatjuk (angolul). + + + + + + + + + Marc + Silver + Írta: + + + + + A fetchmail használata + + fetchmail + + A fetchmail egy mindentudó + IMAP és POP kliens, + amely lehetővé teszi a felhasználók + számára, hogy automatikusan töltsenek le + leveleket távoli IMAP és + POP szerverekről és + lementsék azokat a helyi postaládáikba. + Így a levelek sokkal könnyebben + elérhetőek. A fetchmail a + mail/fetchmail port + segítségével telepíthető, + és számos lehetőséget ajánl fel, + többek közt: + + + + A POP3, APOP, + KPOP, IMAP, + ETRN és az ODMR + protokollok ismerete. + + + + Képes SMTP + használatával levelet továbbítani, + és ennek révén a szűrés, + továbbküldés és az álnevek + használata a megszokott módon + működik. + + + + Démonként futtatva képes adott + időközönként ellenőrizni a frissen + érkező üzeneteket. + + + + Képes egyszerre több postaládát + is kezelni, majd ezek tartalmát a + beállításainak megfelelően + továbbküldeni a különböző + helyi felhasználóknak. + + + + Noha a fetchmail összes + lehetőségének aprólékos + bemutatása meghaladná ennek a + leírásnak a kereteit, azért szót + kerítünk néhány alapvető + funkciójára. A fetchmail + segédprogramnak a megfelelő + működéshez egy .fetchmailrc + nevű konfigurációs állományra van + szüksége. Ez az állomány tárolja + a szerverekre vonatkozó, valamint a bejelentkezéshez + szükséges információkat. Az + állomány kényes tartalmára tekintettel + azt javasoljuk, hogy csak a tulajdonosának + engedélyezzük az olvasását: + + &prompt.user; chmod 600 .fetchmailrc + + Az alább ismertetésre kerülő + .fetchmailrc állományban azt + láthatjuk, ahogy egyetlen felhasználó + postaládáját érjük el a + POP protokoll használatával. + Arra utasítja a fetchmail + programot, hogy csatlakozzon a levelezes.com címre a + joska felhasználóval és + az XXX jelszóval. Ebben a + példában feltételezzük, hogy a + joska nevű felhasználó + létezik a rendszerünkben is. + + poll levelezes.com protocol pop3 username "joska" password "XXX" + + A következő példában több + POP és IMAP + szerverhez csatlakozunk és ahol lehet, több helyi + felhasználónak irányítjuk át a + leveleket: + + poll levelezes.com proto pop3: +user "joska", with password "XXX", is "jozsi" here; +user "andrea", with password "XXXX"; +poll levelezes2.net proto imap: +user "jani", with password "XXXXX", is "hardstuff" here; + + A fetchmail program a + beállítás + megadásával démonként is + elindítható, amely után meg kell adni + (másodpercekben) azt az időközt, aminek + elteltével a fetchmail + lekérdi a .fetchmailrc + állományban felsorolt szervereket. Az alábbi + példában a fetchmail + 600 másodpercenként kéri el a + leveleket: + + &prompt.user; fetchmail -d 600 + + A fetchmail további + lehetőségeiről és + működéséről a oldalon olvashatunk + (angolul). + + + + + + + + Marc + Silver + Írta: + + + + + A procmail használata + + procmail + + A procmail segédprogram egy + hihetetlenül erős alkalmazás, mellyel a + beérkező leveleinket tudjuk szűrni. A + felhasználók számára olyan + szabályok megadását teszi + lehetővé, amelyekre aztán a rendszer illeszti a + bejövő leveleket, és az eredménynek + megfelelően elvégez bizonyos feladatokat vagy + átirányítja a levelet más + postaladákba és/vagy e-mail címekre. A + procmail a mail/procmail porttal + telepíthető fel. Miután ez sikerült, + akár közvetlenül be is + építhetjük a legtöbb levelező + kliensbe. Erről az adott levelező kliens + dokumentációjában olvashatunk többet. A + procmail úgy is + integrálható, ha a felvesszük a + következő sort a procmail + szolgáltatára igényt tartó + felhasználó könyvtárában + található .forward + állományba: + + "|exec /usr/local/bin/procmail || exit 75" + + A következő szakaszban láthatjuk a + procmail néhány + alapvető szabályát, valamint ezek rövid + leírását. Ezeket a szabályokat a + .procmailrc állományba kell + beleírni, amely szintén a felhasználó + könyvtárában leledzik. + + Ezen szabályok többsége a + &man.procmailex.5; man oldalon is olvasható. + + A felhasznalo@levelezes.com címről + érkező leveleket irányítsuk át a + jocim@levelezes2.com külső + címre: + + :0 +* ^From.*felhasznalo@levelezes.com +! jocim@levelezes2.com + + Minden 1000 byte-nál kisebb levelet küldjünk + át a jocim@levelezes2.com + külső címre: + + :0 +* < 1000 +! jocim@levelezes2.com + + Küldjük át az összes + masik@levelezes.com címre küldött + levelet a masik + postaládába: + + :0 +* ^TOmasik@levelezes.com +masik + + Küldjük az összes olyan levelet a + /dev/null eszközre, amelyek a + témájában szerepel a Spam + szó: + + :0 +^Subject:.*Spam +/dev/null + + Egy hasznos szabály, amellyel el tudjuk kapni a &os;.org levelezési + listáiról érkező leveleket és el + tudjuk raktározni ezeket a saját + postaládájukba: + + :0 +* ^Sender:.owner-freebsd-\/[^@]+@FreeBSD.ORG +{ + LISTNAME=${MATCH} + :0 + * LISTNAME??^\/[^@]+ + FreeBSD-${MATCH} +} + + -- cgit v1.2.3