next up previous contents
Next: A rendszergazda teendői Up: Sendmail telepítése és beállítása Previous: A Sendmail üzembe állítása   Tartalom

Szakaszok

Sendmail az intézetben


Elvárások a levelezőrendszertől

Az MFA levelezőrendszerétől a legfontosabb elvárás természetesen az, hogy a felhasználók tudjanak leveleket küldeni és fogadni. A kimenő levelekhez egy SMTP mailer szükséges, a bejövő üzeneteket pedig az MX (mail exchanger) gépen kell SMTP mailer-től fogadni, és a lokális mailer-nek átadni. Az intézeti PC-k előtt ülő felhasználók a levelezőprogramjukban SMTP szervernek beállított gépen futó sendmail-nek adják át a leveleiket egy távoli gépre címezve, tehát ekkor a mail relay szolgáltatást veszik igénybe. A szükséges mailer-ek tehát: local, smtp, relay (utóbbi az SMTP-nek egy változata).

További igény, hogy az MFA levelezését egy virtuális domain-név (mfa.kfki.hu) mögé rejtsük el, tehát a levelek címzésében ne jelenjen meg a levelezőszervernek beállított gép neve. Bejövő levelek esetén ehhez egy MX rekordot kell beállítani, valamint az így beállított gépen azt, hogy a virtuális domain számára érkezett leveleket fogadja. Kimenő leveleknél pedig a 3.4.2 pontban említésre kerülő masquerading használható.

Az MFA két intézet (ATKI és MÜFI) összevonásából született. Levelezés szempontjából ez azt jelenti, hogy megjelent egy új domain (mfa.kfki.hu), ugyanakkor a két régi domain-re (atki.kfki.hu és mufi.hu) is érkeznek még levelek. Az ATKI számára érkező leveleket felsőbb domain-szinten átírják úgy, hogy hozzánk már az MFA-nak címezve érkeznek. A MÜFI-s leveleket pedig regimufi.mfa.kfki.hu címre kapjuk. A hozzánk így beérkező két domain leveleit külön kell választani, mert megegyező felhasználónév is előfordul.

Fontos, hogy amennyiben rendszeresen nemkívánt (spam) levelek érkeznének hozzánk, lehetőség legyen ezek kiszűrésére. Ami ennél is fontosabb, hogy ne lehessen a mi levelezőszervereinkkel visszaélve ilyen leveleket küldeni másoknak, mert ez számunkra igen kellemetlen következményekkel járhat (mint ahogy volt is erre példa).


A Sendmail helye az intézeti szervereken

Az általunk használt sendmail disztribúció a
/u/pcpr/install/gnu/workversion/sendmail-x.y.z
alatt található meg, az aktuálisan használt verziót értelemszerűen behelyettesítve (jelenleg ez 8.9.3), a továbbiakban a relatív directory-hivatkozások ez alatt értendők. A sendmail rendszerfile-ok minden gépen a /etc/mail alá kerültek, és a /etc alól linkek mutatnak rájuk. Ezek: sendmail.cf, sendmail.st és aliases. Az adatbázis file-oknak a konfigurációban beállított helye: /etc/mail.

A levelezőrendszer elrendezése

Az MFA-ban jelenleg mind a kimenő, mind a bejövő levelezést egy szerver bonyolítja le. Ez a felix.mfa.kfki.hu nevű gép (Solaris 2.6). A mailbox-ok kezelése is itt történik. A fiok.mfa.kfki.hu (Debian Linux 2.1) tartalék szerverként van beállítva; gyakorlatilag azonos funkció ellátására képes, de arra van felkészítve, hogy a bejövő leveleket másik gépre (postas.mfa.kfki.hu) küldi tovább. A maradék két szerver (fuga.mfa.kfki.hu és forte.mfa.kfki.hu) minden kimenő levelezése a posta.mfa.kfki.hu, és minden bejövő levelezése a postas.mfa.kfki.hu szerverre van átirányítva.

A levelezőszerver konfigurálása

A levelezőszervernek beállított gép jelenleg a felix. A hozzá tartozó Master Configuration file: cf/cf/mfaconf.mc.

divert(-1)
#
# A bevezető megjegyzések.
# Ezeket most nem részletezem ...
#
divert(0)dnl
VERSIONID(`@(#)mfaconf.mc8.9 (Berkeley) 5/19/98')dnl
OSTYPE(solaris2)dnl
DOMAIN(mfa.kfki.hu)dnl
FEATURE(use_cw_file)dnl
FEATURE(limited_masquerade)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(masquerade_entire_domain)dnl
FEATURE(redirect)dnl
FEATURE(access_db, dbm -o /etc/mail/access)dnl
FEATURE(virtusertable, dbm -o /etc/mail/virtusers)dnl
FEATURE(mailertable, dbm -o /etc/mail/mailertable)dnl
FEATURE(domaintable, dbm -o /etc/mail/domaintable)dnl
MAILER(local)dnl
MAILER(smtp)dnl

Az itt felhasznált cf/domain/mfa.kfki.hu.m4 file a következő:

divert(-1)
#
divert(0)
VERSIONID(`@(#)mfa.kfki.hu.m48.9 (Berkeley) 5/19/98')
MASQUERADE_AS(mfa.kfki.hu)dnl
MASQUERADE_DOMAIN(mfa.kfki.hu)dnl
FE/etc/mail/sendmail.cE
define(`confFORWARD_PATH',
`$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
define(BITNET_RELAY, hugbox.sztaki.hu)dnl
define(`confHOST_STATUS_DIRECTORY', `.hoststat')dnl
define(`confCW_FILE', `/etc/mail/sendmail.cw')dnl

A következőkben az egyes beállítások értelmezése következik.

Levelek fogadása

Ha azt akarjuk, hogy a leveleket fogadó szerver ne csak a saját host-nevére küldött leveleket fogadja, a többi címet külön fel kell sorolni. A use_cw_file nevű ,,feature'' azt jelenti, hogy ezek a confCW_FILE makróban definiált file-ban találhatók. Ennek megfelelően a /etc/mail/sendmail.cw tartalma jelenleg:

mfa.kfki.hu
felix.mfa.kfki.hu
postas.mfa.kfki.hu
posta.mfa.kfki.hu
mufi.hu
falcon.mufi.hu

Ez megfelel annak, mintha ezeket a Cw parancsban soroltuk volna fel.

A saját levelek átirányítására minden felhasználó készíthet a confFORWARD_PATH szerinti file-okat. A legfontosabb az, hogy (az itt utolsóként szereplő) $z/.forward szerepeljen, tehát a UNIX rendszerekben szokásos $HOME/.forward szerinti átirányítás működjön. Az itt szereplő többi file a fogadó és a címzett gép host-neve szerinti átirányítást tesz lehetővé.


Címelrejtés: masquerading

Az ún. masquerading funkció szolgál arra, hogy a kimenő levelezés az mfa.kfki.hu virtuális domain-név mögé rejtve történjen. Amennyiben a MASQUERADE_AS makrót használjuk, a paraméterként megadott név kerül a kimenő levelek fejlécére feladóként. Ez alapértelmezésben a Cw osztályba tartozó host-nevekre vonatkozik (lásd sendmail.cw), de a MASQUERADE_DOMAIN használatával bővíthetjük ezt a listát. Amennyiben a limited_masquerade lehetőséget használjuk, csak az utóbbi módon felsorolt neveket rejti el (így nálunk pl. mufi.hu-t nem). A masquerade_entire_domain hatására az elrejtendő címeket teljes domain-eknek tekinti, tehát nálunk elrejt minden mfa.kfki.hu alatti nevet. A masquerade_envelope pedig azt jelenti, hogy az átírás nem csak a fejlécre, hanem a borítékra is vonatkozik (ennek a szerepe nem egészen világos, de amennyiben ez is elrejt valamit, érdemes használni).

Bizonyos felhasználók esetében nem szerencsés az ilyen átírás. Erre a legjellemzőbb példa a root lehet: minden rendszer küldhet ilyen címről leveleket pl. cron job-ok futtatása után, és jó tudni, hogy pontosan honnan jött a levél. Emellerr nálunk vannak az új lehetőségek kipróbálására létrehozott account-ok is, amelyek nem találhatóak meg az mfa.kfki.hu leveleket fogadó gépen. Az utóbbi eset alias-szal is megoldható lehet, de pillanatnyilag ezek is kivételt jelentenek a maszkolás alól. Az ilyen kivételek a CE osztályba tartoznak, de az EXPOSED_USER makróval is felsorolhatók; nálunk az FE parancsban megadott /etc/mail/sendmail.cE file-ban vannak:

root
hamor
gosz
harma


Levelek irányítása

Az új sendmail lehetőséget ad arra, hogy egyes címzett domain-ekhez mi magunk mondjuk meg, hogy milyen mailer-en keresztül és milyen címre küldjük el a levelet.

Ennek egyik módja a mailertable, ami szó szerint az előbb említett módon használható. Ez egy olyan adatbázis, amelyben a kulcsok a címzett domain-ek, az értékek pedig mailer:domain alakban adhatók meg. A mailer helyére alapértelmezésben relay-t helyettesít. A domain-re vonatkozó esetleges MX rekordot figyelmen kívül hagyhatjuk úgy, hogy a domain-t szögletes zárójelek közé zárjuk. Speciális célú mailer-ek: local, amelyhez helyi címzettet írhatunk (alapértelmezés: az eredeti címzett), így egy domain levelei összegyűjthetők egy felhasználónál; valamint error, ami után egy tetszőleges hibaüzenetet írhatunk, amit a sendmail visszaküld a feladónak.

Nálunk az utóbbi két speciális lehetőség van beállítva. A PC-kre (jellemzően az lpd által automatikusan) helyből elküldött leveleket az adott PC felelős felhasználója kapja meg. A MÜFI-ben régebben létező, de általunk valamilyen okból nem kezelt címekre küldött leveleket az 553 Address no longer exists hibaüzenettel küldjük vissza; az ilyen leveleket először a mufi-hiba.mfa.kfki.hu domain-re irányítjuk át, amihez az előbbi hibaüzenetet visszaküldő mailertable bejegyzés tartozik. Példa:



# mailertable -- üzenetek irányításának beállítása
# Ez csak az innen elküldött levelekre vonatkozik !
# Új mailertable beállítása:
# cat mailertable | makemap dbm /etc/mail/mailertable
 
# Erre a címre küldjük az általunk nem kezelt mufi-s leveleket.
 
mufi-hiba.mfa.kfki.hu error:553 Address no longer exists
   
# A PC-kre küldött leveleket letesszük a tulajdonos mailbox-ába.
 
adam1.mfa.kfki.hu local:adam



A mailertable mellett bizonyos ál-domain-ekhez beállíthatunk olyan relay szervereket, amelyek a megfelelő (általában nem SMTP alapú) levelezést képesek lebonyolítani. Mi a BITNET hálózatra küldött levelekkel járunk el így: a BITNET_RELAY definiálása azt jelenti, hogy az érvényes felső szintű domain-ek közé a .BITNET-et is felvesszük, és az ilyen címre küldött leveleket az ott megadott hugbox.sztaki.hu szervernek adjuk át továbbításra.

Virtuális domain-ek elkülönítése

Mint azt a 3.1 pontban is említettem, újabb problémákat vetett fel, hogy az MFA két intézet összevonásából született. Lényegében arról van szó, hogy a mufi.hu és az mfa.kfki.hu domain-eket kell különválasztani úgy, hogy néhány kivételtől eltekintve a MÜFI-s felhasználók azonos néven MFA-s account-ot kaptak (tehát külön gép használata értelmetlen lenne). Mivel előfordulhatnak azonos nevű MÜFI-s és ATKI-s account-ok, a két régi domain-t nem lehet egyszerűen összekeverni.

A virtusertable adatbázis az aliases-hoz hasonló, két fontos eltéréssel. Az egyik az, hogy kulcsként nem felhasználónevek, hanem teljes user@domain címek szerepelnek, ahol a domain-nek benne kell lennie a Cw osztályban. Értékként itt is címek szerepelhetnek, de a virtusertable esetében mindenhol csak egy lehet. A másik fontos különbség a későbbi hivatkozásban van: ha egy kifejtett alias-ra vonatkozó üzenet megy a feladónak, a tényleges címre hivatkozik, míg virtusertable esetén az eredeti címzettre -- ez a 3.4.3 pontban említett mailertable funkcióval együtt használható bizonyos címzettek saját hibaüzenettel való visszautasítására.

Példák a MÜFI-s levelek elkülönítésére:



# Virtual User Table
# mufi-s címek kezelése
 
# Az eredetitől eltérő MFA-s címmel rendelkeznek
   
makaijp@mufi.hu makaij@mfa.kfki.hu
makaijp@falcon.mufi.hu makaij@mfa.kfki.hu
gkiss@mufi.hu kissgy@mfa.kfki.hu
   
# Ismert távoli címmel rendelkeznek
   
major@mufi.hu major@pcmsr6.mpi-stuttgart.mpg.de
olah@mufi.hu ola7227@mail.iif.hu
   
# Müfi-sek, akiknek a levelét visszaküldjük a feladónak
   
karanyi@mufi.hu %1@mufi-hiba.mfa.kfki.hu
borsos@mufi.hu %1@mufi-hiba.mfa.kfki.hu
   
# Levelek vissza a futo-ra
   
erzekelo@mufi.hu %1@futo.mufi.hu
   
# Alapértelmezés: ugyanazon a néven MFA-s címre küldjük
   
@mufi.hu %1@mfa.kfki.hu



Ezzel kapcsolatban még problémát jelent az, hogy a mufi.hu címre érkező leveleket a KFKI szinten fogadják, és ott a regimufi.mfa.kfki.hu címre küldik tovább, ami azonban ugyanarra a címre mutat, mint a jelenlegi levelezőszerverünk neve. Ehhez a domaintable funkciót lehet alkalmazni: ezzel egyszerűen átírhatjuk a címekben található domain-neveket, így a regimufi.mfa.kfki.hu-t mufi.hu-ra. Ez is a virtusertable-hez hasonló adatbázis file.

Spam-védelem

Az utóbbi időben a nagy tömegben küldött kéretlen levelek (spam) egyre nagyobb problémát jelentenek az elektronikus levelezést rendeltetésszerűen használni kívánók számára. Bár nemkívánt hirdetéseket, esetleg megbotránkoztató tartalmú leveleket a hagyományos postán keresztül is lépten-nyomon kaphatunk, az elektronikus levelezés, egyszerűségéből eredően, erre sokkal kézenfekvőbb és kellemetlenebb lehetőségeket nyújt. Emellett egy nem megfelelően beállított rendszert akár le is lehet ültetni a levelezőrendszeren keresztül. Ezt felismerve a sendmail 8.9-es verziójába számos spam-elleni funkciót építettek be.

Ha megnézzük az SMTP alapú levelezőrendszereket a hozzáférés szempontjából, láthatjuk, hogy az egész nagyon hasonlít a klasszikus postához. Minden végső címzettnek megvan a saját postaládája (mailbox), amihez a saját jelszavával férhet hozzá. A közbülső MTA-ek (jellemzően a sendmail) pedig egy-egy postahivatalhoz hasonlóan viselkednek: beérkeznek a levelek, majd az MTA a megkapott címzett(ek)nek továbbítja a levelet. Ez utóbbihoz semmilyen felhasználó-azonosítás nem tartozik, és a levél feladójaként tetszőleges cím lehet megjelölve. A levél nyomonkövetését a postabélyegzőhöz hasonló Received: mező teszi lehetővé: minden MTA ráírja a borítékra, hogy honnan, milyen protokoll szerint és kinek címezve kapta az üzenetet. A levél ténye mindenhol naplózásra kerül egy egyedi azonosítóval ellátva.

Az egyik legfontosabb spam-elleni dolog, hogy lehetőség van bizonyos címekről érkezett levelek kitiltására. Ez mind az SMTP protokoll MAIL parancsával megadott feladóra, mind domain-ekre vonatkozhat, amelyek akárhol megjelenhetnek a levél útjában. Abban az esetben például, ha egy adott levelezőszerveren keresztül különböző feladóktól rendszeresen érkeznének ilyen levelek, az illető levelezőszerver feketelistára tehető.

Talán ennél is fontosabb az, hogy a saját levelezőszerverünk ne kerüljön ilyen listára, tehát azzal visszaélve ne tudjon akárki a mi nevünkben ilyen leveleket küldeni. Míg a 8.9-es sendmail előtt bármilyen kívülről érkezett levél bármilyen külső címre mehetett (relaying), addig mostantól az alapértelmezés ennek az ellentéte: csak a helyi érdekeltségű levelekkel foglalkozunk, tehát a helyből (azaz jelszóval belépett felhasználótól) indított leveleket küldjük távoli címre, a többit csak akkor fogadjuk el, ha az saját címre érkezik -- azaz csak a saját gépünkben bízunk meg ilyen értelemben. Ezt a kört természetesen ki kell bővíteni a hozzánk tartozó gépekkel.

A feladó ellenőrzését is bevezették: a MAIL parancsban feladóként megjelölt domain-nek (ennek a syslog-ban lesz nyoma, a levél fejlécében ezt könnyű becsapni) léteznie kell.

Nálunk a spam-védelmet egy adatbázis file, az ún. Access Database (access_db) irányítja. A következő műveletek lehetségesek egy adott címről érkező levéllel kapcsolatban:

Jelenleg az access tábla a következő:



mfa.kfki.hu RELAY
rmki.kfki.hu RELAY
iif.hu RELAY
atki.kfki.hu RELAY
dial.kfki.hu RELAY
148.6.168.85 RELAY
fpcrf.fujitsu.co.jp OK



A hozzánk tartozó (vagy közel álló) domain-ek számára tehát engedélyezzük a mail relay szolgáltatást, köztük egy olyan gépnek is, amely nincs a DNS-be bejegyezve (ez remélhetőleg nem lesz tartósan így). Egy olyan domain-ről pedig, ahonnan fontos adatok érkeznek, de a távoli DNS-konfiguráció miatt nem oldható fel rendesen, elfogadjuk a leveleket.

A tartalék levelezőszerver

A tartalék szerver feladata az, hogy az elsődleges levelezőszerver kiesése esetén minél kevesebb munkával beállítható legyen annak helyére. Ennek megfelelően ugyanazzal a relay és MX funkcióval működik, egy fontos eltéréssel: a DOMAIN konfigurációban be kell állítani a MAIL_HUB makrót postas.mfa.kfki.hu értékre, tehát minden bejövő levelet tovább kell küldeni az itt megadott gépre, hogy ne legyenek több helyen mailbox-ok. Jelenleg a teszt célú account-okra való tekintettel a LOCAL_USER makróval kivételeket sorolunk fel az előbbi alól. A tartalék szerveren lévő alias és adatbázis file-okat szinkronban kell tartani a levelezőszerverrel.

Levelezési funkcióval nem rendelkező szerverek

A többi szerver gépen a sendmail default beállításokkal konfigurálandó, és definiálni kell a MAIL_HUB makrót (postas.mfa.kfki.hu), valamint a SMART_HOST makrót (posta.mfa.kfki.hu). Előbbi a bejövő, utóbbi a kimenő levelek átirányítását állítja be. A bejövő levelekkel kapcsolatban a LOCAL_USER(root) sort is be kell írni, azaz a root-nak szánt leveleket helyben kezelje le.

A sendmail indítása

A sendmail boot-oláskor automatikusan indul, az /etc/init.d/sendmail script indítja (Solaris). Kézzel az /etc/init.d/sendmail start paranccsal indíthatjuk, ill. az /etc/init.d/sendmail stop paranccsal állíthatjuk le.

Debian Linux és sendmail

A sendmail konfigurálása természetesen más rendszerek alatt is hasonlóan történik. Debian Linux esetén a következőket érdemes tudni, amennyiben a sendmail-t csomagként telepítettük:


next up previous contents
Next: A rendszergazda teendői Up: Sendmail telepítése és beállítása Previous: A Sendmail üzembe állítása   Tartalom
Hamori Andras
1999-03-21