108.3 Lecke 1
Tanúsítvány: |
LPIC-1 |
---|---|
Verzió: |
5.0 |
Témakör: |
108 Alapvető rendszerszolgáltatások |
Fejezet: |
108.3 A Mail Transfer Agent (MTA) alapjai |
Lecke: |
1/1 |
Bevezetés
A Unix-szerű operációs rendszerekben, mint például a Linux, minden felhasználónak saját inbox-a van: egy speciális hely a fájlrendszeren, amely más, nem root felhasználók számára elérhetetlen, és a felhasználó személyes e-mail üzeneteit tárolja. Az új bejövő üzeneteket a Mail Transfer Agent (MTA) teszi hozzá a felhasználó postaládájához. Az MTA egy rendszerszolgáltatásként futó program, amely összegyűjti a más helyi fiókok által küldött üzeneteket, valamint a hálózatról érkező, távoli felhasználói fiókokból küldött üzeneteket.
Ugyanez az MTA felelős az üzenetek hálózatra küldéséért is, ha a célcím egy távoli fiókra mutat. Ezt úgy oldja meg, hogy egy fájlrendszeri helyet használ a rendszer összes felhasználója számára e-mail kimenő postafiókként (outbox): amint egy felhasználó új üzenetet helyez el a kimenő postafiókban, az MTA azonosítja a célhálózati csomópontot a cél e-mail cím által megadott domainnévből — a @
jel utáni részből --, majd megpróbálja az üzenetet a távoli MTA-nak továbbítani a Simple Mail Transfer Protocol (SMTP) segítségével. Az SMTP-t a megbízhatatlan hálózatok figyelembevételével tervezték, ezért megpróbál alternatív kézbesítési útvonalakatis létrehozni, ha az elsődleges levelezési célcsomópont elérhetetlen lenne.
Lokális és távoli MTA
A hálózatba kapcsolt gépek hagyományos felhasználói fiókjai alkotják a legegyszerűbb e-mail üzenetváltó forgatókönyvet, ahol minden hálózati csomópont saját MTA daemont futtat. Az MTA-n kívül nincs szükség más szoftverre az e-mailek küldéséhez és fogadásához. A gyakorlatban azonban gyakoribb, hogy távoli e-mail fiókot használnak, és nincs aktív helyi MTA szolgáltatás (azaz ehelyett egy e-mail kliensalkalmazást használnak a távoli fiók eléréséhez).
A helyi fiókokkal ellentétben a távoli e-mail fiók — más néven távoli postafiók (remote mailbox) — felhasználói hitelesítést igényel a felhasználó postafiókjához és a távoli MTA-hoz (ebben az esetben egyszerűen SMTP-szervernek nevezik) való hozzáféréshez. Míg a helyi postafiókkal és MTA-val interakcióba lépő felhasználót a rendszer már azonosítja, addig egy távoli rendszernek ellenőriznie kell a felhasználó személyazonosságát, mielőtt IMAP vagy POP3 segítségével kezelné üzeneteit.
Note
|
Napjainkban az e-mailek küldésének és fogadásának legelterjedtebb módja egy távoli szerveren lévő fiókon keresztül történik, például egy vállalat központi e-mail szerverén, amely az összes alkalmazott fiókját hostolja, vagy egy személyes e-mail szolgáltatáson keresztül, mint például a Google Gmail. A helyben kézbesített üzenetek összegyűjtése helyett az e-mail kliensalkalmazás a távoli postafiókhoz csatlakozik, és onnan kéri le az üzeneteket. Az üzenetek távoli szerverről való lekérdezésére általában a POP3 és az IMAP protokollt használják, de más, nem szabványos, saját protokollok is használhatók. |
Ha egy MTA-daemon fut a helyi rendszeren, a helyi felhasználók e-mailt küldhetnek más helyi felhasználóknak vagy egy távoli gépen lévő felhasználóknak, feltéve, hogy a rendszerükön is van olyan MTA-szolgáltatás, amely elfogadja a hálózati kapcsolatokat. A 25-ös TCP port az SMTP-kommunikáció szabványos portja, de más portok is használhatók a használt hitelesítési és/vagy titkosítási sémától függően (ha van ilyen).
Ha eltekintünk a távoli postafiókokhoz való hozzáféréssel kapcsolatos topológiáktól, akkor egy egyszerű Linux felhasználói fiókok közötti e-mail cserehálózat is megvalósítható, amennyiben minden hálózati csomópont rendelkezik egy aktív MTA-val, amely képes a következő feladatok elvégzésére:
-
Fenntartja az elküldendő üzenetek kimeneti várólistáját. Minden egyes sorbaállított üzenet esetében a helyi MTA a címzett címéről értékeli a cél MTA-t.
-
Kommunikáció távoli MTA-daemonokkal SMTP használatával. A helyi MTA-nak képesnek kell lennie az SMTP (Simple Mail Transfer Protocol) használatára a TCP/IP stack-en keresztül, hogy üzeneteket fogadjon, küldjön és átirányítson más távoli MTA daemonoktól/daemonokhoz.
-
Minden helyi felhasználói fiókhoz egyedi postafiók fenntartása. Az MTA általában mbox formátumban tárolja az üzeneteket: egyetlen szöveges fájl, amely az összes e-mail üzenetet sorban tartalmazza.
Általában az e-mail címek egy domainnevet adnak meg helyként, pl. lpi.org
az info@lpi.org
-ban. Ebben az esetben a feladó MTA lekérdezi a DNS-szolgáltatásból a megfelelő MX rekordot. A DNS MX rekord tartalmazza az adott domain e-mailjét kezelő MTA IP-címét. Ha ugyanannak a domainnek egynél több MX rekordja van megadva a DNS-ben, az MTA-nak meg kell próbálnia felvenni velük a kapcsolatot a prioritási értéküknek megfelelően. Ha a címzett címe nem ad meg domainnevet, vagy a domain nem rendelkezik MX rekorddal, akkor a @
szimbólum utáni részt a cél MTA hostjaként kezeli.
A biztonsági szempontokat figyelembe kell venni, ha az MTA-hostok láthatóak lesznek az interneten lévő hostok számára. Lehetséges például, hogy egy ismeretlen felhasználó a helyi MTA-t arra használja, hogy egy másik felhasználónak adja ki magát, és potenciálisan káros e-maileket küldjön. Az olyan MTA-t, amely vakon továbbít egy e-mailt, nyitott közvetítőnek (open relay) nevezzük, ha közvetítőként használható az üzenet valódi feladójának esetleges elrejtésére. Az ilyen visszaélések megelőzése érdekében az ajánlás szerint csak engedélyezett domainekből fogadjunk el kapcsolatokat, és alkalmazzunk biztonságos hitelesítési sémát.
Ezen kívül számos különböző MTA-implementáció létezik Linuxra, amelyek mindegyike olyan speciális szempontokra összpontosít, mint a kompatibilitás, teljesítmény, biztonság stb. Mindazonáltal minden MTA ugyanazokat az alapelveket követi és hasonló funkciókat biztosít.
Linux MTA-k
A Linux rendszerekhez elérhető hagyományos MTA a Sendmail, egy nagyon rugalmas, általános célú MTA, amelyet számos Unix-szerű operációs rendszer használ. Néhány más elterjedt MTA a Postfix, qmail és Exim. Egy alternatív MTA választásának fő oka, hogy könnyebben implementálhassunk speciális funkciókat, mivel az egyéni e-mail szerverek konfigurálása a Sendmailben bonyolult feladat lehet. Emellett minden disztribúciónak lehet saját preferált MTA-ja, a legtöbb gyakori beállításhoz megfelelő, előre definiált beállításokkal. Minden MTA a Sendmail cseréjeként szolgál, így minden Sendmail-kompatibilis alkalmazásnak működnie kell, függetlenül attól, hogy milyen MTA-t használunk.
Ha az MTA fut, de nem fogad hálózati kapcsolatokat, akkor csak a helyi gépen tud e-mail üzeneteket kézbesíteni. A sendmail
MTA esetében az /etc/mail/sendmail.mc
fájlt úgy kell módosítani, hogy a nem helyi kapcsolatokat is elfogadja. Ehhez a
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
bejegyzést a megfelelő hálózati címre kell módosítani és újraindítani a szolgáltatást. Egyes Linux disztribúciók, mint például a Debian, konfigurációs eszközöket ajánlhatnak fel, amelyek segítenek az e-mail szerver előre meghatározott, gyakran használt funkciókkal való felállításában.
Tip
|
A biztonsági problémák miatt a legtöbb Linux disztribúció alapértelmezés szerint nem telepít MTA-t. A leckében bemutatott példák teszteléséhez győződjünk meg arról, hogy minden gépen fut egy MTA, és hogy a 25-ös TCP porton fogadnak kapcsolatokat. Biztonsági okokból a tesztelés során ezeket a rendszereket nem szabad kitenni a nyilvános internetről érkező kapcsolatoknak. |
Amint az MTA fut és fogad kapcsolatokat a hálózatról, az új e-mail üzenetek SMTP-parancsokkal kerülnek továbbításra, amelyeket egy TCP-kapcsolaton keresztül küldenek. Az nc
parancs — egy hálózati segédprogram, amely általános adatokat olvas és ír a hálózaton keresztül — használható SMTP-parancsok közvetlen küldésére az MTA-nak. Ha az nc
parancs nem elérhető, akkor a ncat vagy nmap-ncat csomaggal együtt települ, a használt csomagkezelő rendszertől függően. Az SMTP parancsok írása közvetlenül az MTA-nak segít jobban megérteni a protokollt és más általános e-mail koncepciókat, de segíthet a levelek kézbesítési folyamatában felmerülő problémák diagnosztizálásában is.
Ha például az emma
felhasználó a lab1.campus
hoston üzenetet akar küldeni a dave
felhasználónak a lab2.campus
hoston, akkor az nc
paranccsal közvetlenül csatlakozhat a lab2.campus
MTA-hoz, feltéve, hogy az a 25-ös TCP porton figyel:
$ nc lab2.campus 25 220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:16:07 GMT HELO lab1.campus 250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you MAIL FROM: emma@lab1.campus 250 2.1.0 emma@lab1.campus... Sender ok RCPT TO: dave@lab2.campus 250 2.1.5 dave@lab2.campus... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Subject: Recipient MTA Test Hi Dave, this is a test for your MTA. . 250 2.0.0 xAG0G7Y0000595 Message accepted for delivery QUIT 221 2.0.0 lab2.campus closing connection
A kapcsolat létrejötte után a távoli MTA azonosítja magát, majd készen áll az SMTP-parancsok fogadására. A példa első SMTP-parancsa, a HELO lab1.campus
, a lab1.campus
-t jelöli a csere kezdeményezőjeként. A következő két parancs, a MAIL FROM: emma@lab1.campus
és az RCPT TO: dave@lab2.campus
a feladót és a címzettet jelöli. A megfelelő e-mail a DATA
parancs után kezdődik, és egy ponttal végződik egy sorban. Ha az e-mailhez subject
(tárgy) mezőt is hozzá szeretnénk adni, annak a DATA
parancs utáni első sorban kell szerepelnie, ahogy a példában látható. A tárgy mező használata esetén egy üres sornak kell azt elválasztania az e-mail tartalmától. A QUIT
parancs befejezi a kapcsolatot az MTA-val a lab2.campus
hoston.
A lab2.campus
gépen a dave
felhasználó a You have a new mail in /var/spool/mail/dave
üzenethez hasonló üzenetet kap, amint belép egy shell munkamenetbe. Ez a fájl tartalmazza az emma
által küldött nyers e-mail üzenetet, valamint az MTA által hozzáadott fejléceket (header):
$ cat /var/spool/mail/dave From emma@lab1.campus Sat Nov 16 00:19:13 2019 Return-Path: <emma@lab1.campus> Received: from lab1.campus (lab1.campus [10.0.3.134]) by lab2.campus (8.15.2/8.15.2) with SMTP id xAG0G7Y0000595 for dave@lab2.campus; Sat, 16 Nov 2019 00:17:06 GMT Date: Sat, 16 Nov 2019 00:16:07 GMT From: emma@lab1.campus Message-Id: <201911160017.xAG0G7Y0000595@lab2.campus> Subject: Recipient MTA Test Hi Dave, this is a test for your MTA.
A Received:
header azt mutatja, hogy a lab1.campus
üzenetét közvetlenül a lab2.campus
fogadta. Alapértelmezés szerint az MTA-k csak a helyi címzetteknek szóló üzeneteket fogadják el. Az alábbi hiba valószínűleg akkor fordul elő, ha emma
felhasználó megpróbál e-mailt küldeni henry
felhasználónak a lab3.campus
hoston, de a lab2.campus
MTA-t használja a megfelelő lab3.campus
MTA helyett:
$ nc lab2.campus 25 220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:31:44 GMT HELO lab1.campus 250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you MAIL FROM: emma@lab1.campus 250 2.1.0 emma@lab1.campus... Sender ok RCPT TO: henry@lab3.campus 550 5.7.1 henry@lab3.campus... Relaying denied
Az 5-tel kezdődő SMTP-válaszszámok, mint például a Relaying denied
(továbbítás megtagadva) üzenet, hibát jeleznek. Vannak olyan legitim helyzetek, amikor a továbítás elvárt, például amikor az e-maileket küldő és fogadó hostok nincsenek állandóan kapcsolatban: egy köztes MTA-t úgy lehet beállítani, hogy fogadja a más hostoknak szánt e-maileket, és relay SMTP-szerverként működik, amely továbbítja az üzeneteket az MTA-k között.
Az a képesség, hogy az e-mail forgalmat közbenső SMTP-szervereken keresztül lehet továbbítani, megakadályozza, hogy közvetlenül a címzett e-mail címe által megjelölt hosthoz csatlakozzanak, ahogyan azt az előző példák mutatják. Ráadásul az e-mail címekben gyakran domainnév szerepel lokációként (a @
után), így a megfelelő MTA-host tényleges nevét a DNS-en keresztül kell lekérdezni. Ezért ajánlatos a megfelelő célállomás azonosításának feladatát a helyi MTA-ra vagy távoli postafiókok használata esetén a távoli SMTP-szerverre bízni.
A Sendmail a sendmail
parancsot biztosítja számos, az e-mailekkel kapcsolatos művelet elvégzéséhez, beleértve az új üzenetek összeállításának segítését is. Ez is megköveteli, hogy a felhasználó kézzel írja be az e-mail fejléceket, de barátságosabb módon, mint az SMTP parancsok közvetlen használata esetén. Tehát a megfelelőbb módszer az emma@lab1.campus
felhasználó számára egy e-mail küldése a dave@lab2.campus
címre az alábbi lenne:
$ sendmail dave@lab2.campus From: emma@lab1.campus To: dave@lab2.campus Subject: Sender MTA Test Hi Dave, this is a test for my MTA. .
Ebben az esetben is az új sorban, önmagában álló pont fejezi be az üzenetet. Az üzenetet azonnal el kell küldeni a címzettnek, kivéve, ha a helyi MTA nem tudott kapcsolatba lépni a távoli MTA-val. A mailq
parancs, ha a root futtatja, megjeleníti az összes nem kézbesített üzenetet. Ha például a lab2.campus
MTA nem válaszolt, akkor a mailq
parancs felsorolja a nem kézbesített üzenetet és a hiba okát:
# mailq /var/spool/mqueue (1 request) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- xAIK3D9S000453 36 Mon Nov 18 20:03 <emma@lab1.campus> (Deferred: Connection refused by lab2.campus.) <dave@lab2.campus> Total requests: 1
A kimenő levelek várólistájának alapértelmezett helye a /var/spool/mqueue/
, de a különböző MTA-k más-más helyet használhatnak a /var/spool/
mappában. A Postfix például a /var/spool/postfix/
alatt hoz létre egy mappastruktúrát a várólista kezeléséhez. A mailq
parancs egyenértékű a sendmail -bp
paranccsal, és a rendszerben telepített MTA-tól függetlenül jelen kell lennie. A visszafelé kompatibilitás biztosítása érdekében a legtöbb MTA biztosítja ezeket a hagyományos levélkezelő parancsokat.
Ha az elsődleges e-mail célállomás — ha az a domain MX DNS rekordjából származik — nem elérhető, az MTA megpróbál kapcsolatba lépni az alacsonyabb prioritásúakkal (ha vannak ilyenek megadva). Ha egyik sem érhető el, az üzenet a helyi kimeneti várólistán marad, hogy később újra megpróbálhassa elküldeni. Ha így van beállítva, az MTA rendszeresen ellenőrizheti a távoli host elérhetőségét, és újabb kézbesítési kísérletet hajthat végre. Sendmail-kompatibilis MTA használata esetén a sendmail -q
paranccsal azonnal megpróbálja újra elküldeni az e-mailt.
A Sendmail a beérkező leveleket a megfelelő postaláda tulajdonosáról elnevezett fájlban tárolja, például /var/spool/mail/dave
. Más MTA-k, mint például a Postfix, a bejövő e-maileket olyan helyeken tárolhatják, mint a /var/mail/dave
, de a fájl tartalma ugyanaz. A példában a feladó hostján a sendmail
parancsot használták az üzenet összeállításához, így a nyers üzenetfejlécek azt mutatják, hogy az e-mail további lépéseket tett meg, mielőtt eljutott a végső célállomásra:
$ cat /var/spool/mail/dave From emma@lab1.campus Mon Nov 18 20:07:39 2019 Return-Path: <emma@lab1.campus> Received: from lab1.campus (lab1.campus [10.0.3.134]) by lab2.campus (8.15.2/8.15.2) with ESMTPS id xAIK7clC000432 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for <dave@lab2.campus>; Mon, 18 Nov 2019 20:07:38 GMT Received: from lab1.campus (localhost [127.0.0.1]) by lab1.campus (8.15.2/8.15.2) with ESMTPS id xAIK3D9S000453 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for <dave@lab2.campus>; Mon, 18 Nov 2019 20:03:13 GMT Received: (from emma@localhost) by lab1.campus (8.15.2/8.15.2/Submit) id xAIK0doL000449 for dave@lab2.campus; Mon, 18 Nov 2019 20:00:39 GMT Date: Mon, 18 Nov 2019 20:00:39 GMT Message-Id: <201911182000.xAIK0doL000449@lab1.campus> From: emma@lab1.campus To: dave@lab2.campus Subject: Sender MTA Test Hi Dave, this is a test for my MTA.
Alulról felfelé haladva a Received:
kezdetű sorok az üzenet útvonalát mutatják. Az üzenetet az emma
felhasználó küldte el a sendmail dave@lab2.campus
paranccsal a lab1.campus
címen, amint azt az első Received:
header is jelzi. Ezután, még mindig a lab1.campus
-on, az MTA használja az ESMTPS-t — az SMTP egy supersetje, amely titkosítási kiterjesztésekkel bővíti azt — az üzenet elküldéséhez a lab2.campus
-on lévő MTA-nak, ahogyan azt az utolsó (felső) Received:
header mutatja.
Az MTA befejezi a munkáját, miután az üzenet elmentésre került a felhasználó postaládájába. Gyakori, hogy van valamilyen e-mail szűrés, például spamblokkoló vagy a felhasználó által meghatározott szűrési szabályok érvényesítése. Ezeket a feladatokat harmadik féltől származó alkalmazások hajtják végre, az MTA-val együttműködve. Az MTA például meghívhatja a SpamAssassin segédprogramot, hogy annak szövegelemző funkciói segítségével jelölje meg a gyanús üzeneteket.
Lehetséges, hogy nem kifejezetten kényelmes a postafiókfájl közvetlen olvasása, ezért javasoljuk, hogy használjunk helyette valamelilyen e-mail kliensprogramot (pl. Thunderbird, Evolution vagy KMail), amely elemzi a fájlt és megfelelően kezeli az üzeneteket. Az ilyen programok extra funkciókat is tartalmaznak, például parancsikonokat a gyakori műveletekhez, almappákat a postaládán belül, stb.
A mail
parancs és a Mail User Agents (MUA)
Lehetőség van arra, hogy egy e-mailt közvetlenül a nyers formátumában írjunk meg, de sokkal praktikusabb egy kliensalkalmazás — más néven MUA (Mail User Agent) — használata a folyamat felgyorsítása és a hibák elkerülése érdekében. A MUA elvégzi a munkát a háttérben, azaz az e-mail kliens megjeleníti és rendszerezi a kapott üzeneteket, és a felhasználó által az e-mail összeállítása után a megfelelő kommunikációt intézi az MTA-val.
A Mail User Agents-nek számos különböző típusa létezik. Az asztali alkalmazások, mint a Mozilla Thunderbird és a Gnome Evolution támogatják a helyi és távoli e-mail fiókokat is. Még a Webmail interfészek is egyfajta MUA-nak tekinthetők, mivel közvetítik a felhasználó és a mögöttes MTA közötti interakciót. Az e-mail kliensek azonban nem korlátozódnak a grafikus felületekre: a konzolos e-mail klienseket széles körben használják a grafikus felülettel nem integrált postafiókok elérésére és az e-mailhez kapcsolódó feladatok automatizálására shell scripteken belül.
Eredetileg a Unix mail
parancsát csak a helyi rendszerfelhasználók közötti üzenetváltásra szánták (az első mail
parancs az 1971-ben kiadott első Unix-kiadásból ered). Amikor a hálózati e-mail üzenetváltás egyre inkább előtérbe került, más programok jöttek létre az új kézbesítési rendszer kezelésére, és fokozatosan felváltották a régi mail
programot.
Manapság a legáltalánosabb mail
parancsot a mailx csomag biztosítja, amely kompatibilis az összes modern e-mail funkcióval. A legtöbb Linux disztribúcióban a mail
parancs csak egy szimbolikus link a mailx
parancsra. Más implementációk, mint például a GNU Mailutils csomag, alapvetően ugyanazokat a funkciókat biztosítják, mint a mailx
. Van azonban néhány különbség közöttük, különösen a parancssori lehetőségek tekintetében.
A mail
parancs minden modern változata, függetlenül a megvalósítástól, kétféle üzemmódban működik: normál módban (normal mode) és küldés módban (send mode). Ha a mail
parancs argumentumaként egy e-mail címet adunk meg, akkor a parancs küldési módba lép, egyébként normál (olvasási) módba. Normál módban a beérkezett üzenetek egy-egy numerikus indexszel vannak felsorolva, így a felhasználó külön-külön hivatkozhat rájuk, amikor az interaktív promptban parancsokat ír be. A print 1
parancs például az 1. számú üzenet tartalmának megjelenítésére használható. Az interaktív parancsok rövidíthetők, így az olyan parancsok, mint a print
, delete
vagy reply
helyettesíthetők p
, d
vagy r
betűvel. A mail
parancs mindig az utoljára kapott vagy az utoljára megtekintett üzenetet veszi figyelembe, ha az üzenet indexszáma elmarad. A quit
vagy q
parancs kilép a programból.
A küldés mód különösen hasznos automatikus e-mail üzenetek küldéséhez. Használható például arra, hogy e-mailt küldjön a rendszergazdának, ha egy ütemezett karbantartási script nem teljesíti a feladatát. Küldési módban a mail
a standard input tartalmát használja az üzenet törzseként:
$ mail -s "Maintenance fail" henry@lab3.campus <<<"The maintenance script failed at `date`"
Ebben a példában az -s
kapcsolót használtuk, azért, hogy az üzenethez egy tárgymezőt is hozzáadjunk. Az üzenet törzsét a Hereline átirányítással a standard bemenetre adtuk meg, de egy fájl tartalma vagy egy parancs kimenete is átvezethető lenne a program stdin-jébe. Ha a szabványos bemenetre történő átirányítással nem adunk meg tartalmat, akkor a program megvárja, hogy a felhasználó megadja az üzenet törzsét. Ebben az esetben a Ctrl+D billentyűleütés befejezi az üzenetet. A mail
parancs azonnal kilép, miután az üzenet a kimenő levelek közé került.
A küldés testreszabása
Alapértelmezés szerint a Linux rendszeren lévő e-mail fiókok a szabványos rendszerfiókokhoz vannak társítva. Például, ha Carol felhasználó bejelentkezési neve carol
a lab2.campus
hoston, akkor az e-mail címe carol@lab2.campus
lesz. A rendszerfiókok és a postafiókok közötti egy-egy kapcsolat kiterjeszthető a legtöbb Linux disztribúció által biztosított szabványos módszerekkel, különösen az `/etc/aliases' fájl által biztosított e-mail-routing mechanizmussal.
Az e-mail alias egy “virtuális” e-mail címzett, akinek a fogadó üzeneteit a rendszer átirányítja a meglévő helyi postafiókokba vagy más típusú üzenettároló vagy -feldolgozási célhelyekre. Az aliasok hasznosak például a postmaster@lab2.campus
címre küldött üzenetek Carol fiókjába juttatására, amely egy közönséges helyi postafiók a lab2.campus
rendszerben. Ehhez a postmaster: carol
sort hozzá kell adni a lab2.campus
/etc/aliases
fájljához. Az /etc/aliases
fájl módosítása után a newaliases
parancsot kell lefuttatni az MTA alias adatbázisának frissítéséhez és a változtatások érvényesítéséhez. A sendmail -bi
vagy a sendmail -I
parancsok is használhatók az aliasok adatbázisának frissítésére.
Az aliasokból soronként egyet adunk meg, <alias>: <célállomás>
formátumban. A szokásos helyi postafiókokon kívül, amelyeket a megfelelő felhasználónév jelez, más célpontok is megadhatók:
-
Egy fájl teljes elérési útja (
/
karakterrel kezdődik). A megfelelő aliasra küldött üzenetek hozzá lesznek fűzve a fájlhoz. -
Egy olyan parancs, ami feldolgozza az üzenetet. A
<cél>
-nak pipe karakterrel kell kezdődnie, és ha a parancs speciális karaktereket (például szóközöket) tartalmaz, akkor dupla idézőjelek közé kell tenni. Például asubscribe: |subscribe.sh
alias alab2.campus
-ban asubscribe@lab2.campus
címre küldött összes üzenetet asubscribe.sh
parancs szabványos bemenetére továbbítja. Ha a sendmail korlátozott shell módban (restricted shell mode) fut, akkor az engedélyezett parancsoknak — vagy a rájuk mutató linkeknek — az/etc/smrsh/
mappában kell lenniük. -
Egy include fájl. Egy aliashoz több cél is tartozhat (vesszővel elválasztva), így célszerűbb lehet ezeket egy külső fájlban tartani. Az
:include:
kulcsszónak meg kell jelölnie a fájl elérési útját, mint az:include:/var/local/destinations
. -
Külső cím. Az aliasok külső e-mail címekre is továbbíthatják az üzeneteket.
-
Egy másik alias.
Egy jogosulatlan helyi felhasználó aliasokat adhat meg saját e-mailjeihez a saját mappájában található .forward
fájl szerkesztésével. Mivel az aliasok csak a felhasználó saját postafiókjára vonatkozik, csak a <cél>
rész megadása szükséges. Ha például az összes bejövő e-mailt egy külső címre szeretné továbbítani, a dave
felhasználó a lab2.campus
fájlban létrehozhatja a következő ~/.forward
fájlt:
$ cat ~/.forward emma@lab1.campus
A dave@lab2.campus
címre küldött összes e-mailt az emma@lab1.campus
címre továbbítja. Az /etc/aliases
fájlhoz hasonlóan más átirányítási szabályok is hozzáadhatók a .forward
fájlhoz, soronként egy. Ennek ellenére a .forward
fájlt csak a tulajdonosa írhatja, és nem szükséges futtatni a newaliases
parancsot a módosítás után. A ponttal kezdődő fájlok nem jelennek meg a normál fájllistában, ami miatt a felhasználó figyelmen kívül hagyhatja az aktív aliasokat. Ezért az e-mail továbbítás esetleges problémái esetén fontos ellenőrizni, hogy a fájl egyáltalán létezik-e.
Gyakorló feladatok
-
További kapcsolók és argumentumok nélkül a
mail henry@lab3.campus
parancs beviteli módba lép, így a felhasználó beírhatja az üzenetet ahenry@lab3.campus
címre. Az üzenet befejezése után melyik billentyűleütés zárja be a beviteli módot és küldi el az e-mailt? -
Melyik parancsot hajthatja végre a root felhasználó a helyi rendszerről származó, kézbesítetlen üzenetek listázásához?
-
Hogyan használhatja egy nem privilegizált felhasználó a standard MTA módszert arra, hogy minden bejövő levelét automatikusan továbbítsa a
dave@lab2.campus
címre?
Gondolkodtató feladatok
-
A
mailx
által biztosítottmail
parancs használatával melyik paranccsal küldhetnénk üzenetet azemma@lab1.campus
címre úgy, hogy az e-mail törzse auname -a
parancs kimenete, a csatolmány pedig alogs.tar.gz
fájl? -
Az e-mail szolgáltatás adminisztrátora szeretné figyelni a hálózaton keresztüli e-mail-átvitelt, de nem akarja tesztüzenetekkel telezsúfolni a postafiókját. Hogyan tud ez a rendszergazda úgy beállítani egy rendszerszintű e-mail aliast, hogy a
teszt
felhasználónak küldött összes e-mailt átirányítsa a/dev/null
fájlba? -
A
newaliases
mellett milyen paranccsal lehetne frissíteni az aliasok adatbázisát, miután újabbat adtunk hozzá az/etc/aliases
fájlhoz?
Összefoglalás
Ez a lecke a Mail Transfer Agents szerepével és használatával foglalkozik a Linux rendszerekben. Az MTA szabványos módszert nyújt a felhasználói fiókok közötti kommunikációhoz, és más szoftverekkel kombinálva extra funkciókat biztosíthat. A lecke a következő témákat tárgyalta:
-
Fogalmak az e-mailekkel kapcsolatos technológiákról, postafiókokról és protokollokról.
-
Hogyan váltanak egymással üzeneteket a Linux MTA-k a hálózaton keresztül.
-
Konzolos e-mail kliensek és MUA-k (Mail User Agents).
-
Helyi e-mail aliasing és továbbítás.
A bemutatott technológiák, parancsok és procedúrák a következők voltak:
-
SMTP és kapcsolódó protokollok.
-
Linuxhoz elérhető MTA-k: Postfix, qmail, Exim.
-
MTA és MUA parancsok:
sendmail
ésmail
. -
Adminisztrációs fájlok és parancsok:
mailq
,/etc/aliases
,newaliases
,~/.forward
.
Válaszok a gyakorló feladatokra
-
További kapcsolók és argumentumok nélkül a
mail henry@lab3.campus
parancs beviteli módba lép, így a felhasználó beírhatja az üzenetet ahenry@lab3.campus
címre. Az üzenet befejezése után melyik billentyűleütés zárja be a beviteli módot és küldi el az e-mailt?A Ctrl+D billentyűkombináció lenyomása a program bezárását és az e-mail elküldését eredményezi.
-
Melyik parancsot hajthatja végre a root felhasználó a helyi rendszerről származó, kézbesítetlen üzenetek listázásához?
A
mailq
vagysendmail -bp
parancs. -
Hogyan használhatja egy nem privilegizált felhasználó a standard MTA módszert arra, hogy minden bejövő levelét automatikusan továbbítsa a
dave@lab2.campus
címre?A felhasználónak hozzá kell adnia a
dave@lab2.campus
-t a~/.forward
-hoz.
Válaszok a gondolkodtató feladatokra
-
A
mailx
által biztosítottmail
parancs használatával melyik paranccsal küldhetnénk üzenetet azemma@lab1.campus
címre úgy, hogy az e-mail törzse auname -a
parancs kimenete, a csatolmány pedig alogs.tar.gz
fájl?uname -a | mail -a logs.tar.gz emma@lab1.campus
-
Az e-mail szolgáltatás adminisztrátora szeretné figyelni a hálózaton keresztüli e-mail-átvitelt, de nem akarja tesztüzenetekkel telezsúfolni a postafiókját. Hogyan tud ez a rendszergazda úgy beállítani egy rendszerszintű e-mail aliast, hogy a
teszt
felhasználónak küldött összes e-mailt átirányítsa a/dev/null
fájlba?A
test: /dev/null
sor a/etc/aliases
-ben minden,test
helyi postafiókjába küldött levelet a/dev/null
fájlba irányít át. -
A
newaliases
mellett milyen paranccsal lehetne frissíteni az aliasok adatbázisát, miután újabbat adtunk hozzá az/etc/aliases
fájlhoz?A
sendmail -bi
vagysendmail -I
parancs.