Az emberek már az ókorban is szükségét érezték az információcserének, és azt állami szinten szervezték meg. Ezért a posta a világ egyik legtisztábban szervezett intézménye.
Az e-mail az információtovábbítás új, modern eszköze. A hagyományos postától eltérően az üzenetek, fájlok, programok, különféle adatok elektronikus másolatai e-mailben kerülnek továbbításra - pl. számítógép által feldolgozott információk.
Az e-mail rendszert alkotó fő objektumok speciális számítógépek, amelyeket levelezőszervereknek neveznek.
A levelezőszerverek fogadó és küldő szerverek elektronikus üzenetek.
Az e-mail üzeneteket fogadó szerver a POP (Post Office Protocol) protokollt használja.
Az e-maileket küldő szerver fut SMTP protokoll(Simple Mail Transfer Protocol).
Levélszerver, e-mail szerver, levelezőszerver - az e-mail továbbítási rendszerben ez általában az üzenetátviteli ügynök neve (angol mail transfer agent, MTA). Ez számítógépes program, amely üzeneteket továbbít egyik számítógépről a másikra. Általában a levelezőszerver "a színfalak mögött" működik, és a felhasználók egy másik programmal foglalkoznak - egy e-mail klienssel (angol mail user agent, MUA).
Rizs. 1.
Például egy általános konfigurációban a felhasználói ügynök az Outlook Express. Amikor a felhasználó beírt egy üzenetet, és elküldi azt a címzettnek, a levelezőkliens az SMTP protokoll használatával kommunikál a levelezőszerverrel. A feladó levelezőszervere kölcsönhatásba lép a címzett levelezőszerverével (közvetlenül vagy egy köztes szerveren keresztül – közvetítés). A címzett levelezőszerverén az üzenet a postafiókba kerül, ahonnan az üzenet kézbesítő ügynök (MDA) segítségével kézbesítik a címzett klienséhez. Gyakran az utolsó két ügynököt egyesítik egy programban, bár vannak speciális MDA-k, amelyek többek között a spamszűréssel foglalkoznak. A fogadott üzenetek végső kézbesítése nem SMTP, hanem egy másik protokoll – gyakran POP3 vagy IMAP –, amelyet a legtöbb levelezőszerver szintén támogat. Bár az MTA legegyszerűbb megvalósításában elegendő a fogadott üzeneteket a felhasználó saját könyvtárába tenni fájlrendszer központi szerver („postafiók”).
Levélkiszolgáló, levelezőszerver, e-mail szerver – ez általában az üzenettovábbító ügynök neve az e-mail továbbítási rendszerben. Ez egy olyan szoftver, amely üzeneteket továbbít egyik számítógépről a másikra. A levelezőszerver általában nem látható a felhasználó számára. Maga a felhasználó egy másik szoftverrel – egy e-mail klienssel – foglalkozik.
Például a legáltalánosabb konfigurációban a levelezőkliens az Outlook Express. Bár mostanában gyakran használják a Mozilla Thunderbird klienst. Amikor a felhasználó beír egy üzenetet, és továbbítja azt a címzettnek, a levelezőkliens az SMTP protokollon keresztül lép kapcsolatba a levelezőszerverrel. A feladó levelezőszervere együttműködik a címzett szerverével. A címzett szerverén a neki küldött üzenet a postafiókba kerül, ahonnan az MDA üzenetkézbesítési ügynök (levélkézbesítési ügynök) segítségével eljut a címzett klienséhez. Vannak POP3 és IMAP protokollok is, amelyeket sok levelezőszerver támogat.
Sok rendszeradminisztrátor tapasztal bizonyos nehézségeket, amikor e-mail rendszerekkel dolgozik. Ez nem meglepő, a levelezőszerver sokkal összetettebb felépítésű, mint fájlszerver, router vagy terminálkiszolgáló. Ebben a cikkben megvizsgáljuk a levelezőszerverek felépítését és működési elvét, annak megértése nélkül, hogy egy e-mail rendszer felállítása képes arra, hogy sámáni táncokká alakuljon egy tamburával.
Ez az anyag elég sok egyszerűsítést és általánosítást tartalmaz annak érdekében, hogy adjon rendszergazdák a szükséges minimális tudást. Véleményünk szerint egy-két levelezőszerver adminisztrálása érdekében belépő szint Nem kell e-mail szakértőnek lenned.
A legtöbb felhasználó és kezdő adminisztrátor számára a levelezőszerver egyfajta „fekete doboz”, amely egy levél megérkezése után „ismeretlen” módon eljuttatja azt a címzetthez, és fordítva. Az ilyen szerverekkel való minden interakció abból áll, hogy a levelezőklienst bizonyos portokra, vagy akár a webes felületen keresztül címezzük. A belsejében azonban egy egész mechanizmus rejtőzik, melynek működésének megértése kulcsfontosságú az e-mail rendszer sikeres felállításához és karbantartásához. Ez különösen fontos a Linux platformon lévő szerverek adminisztrálása esetén. Ellentétben a Windows rendszerrel, ahol a levelezőszerver egy komplett szoftvermegoldás, és a fejlesztők már gondoskodtak a belső interakcióról, a Linuxban a levelezőszerver összetevői egyéni programokatés magának kell konfigurálnia az interakciójukat.
Vessünk egy pillantást a levelezőszerver felépítésére és arra, hogy mi történik, ha a felhasználó megpróbál levelet küldeni.
A levelezőszerver legfontosabb része az MTA (Levéltovábbító ügynök-- levéltovábbítási ügynök), amelynek feladatai közé tartozik a levél fogadása és továbbítása. Nagyon gyakran (Linux/UNIX esetén) az MTA-t levelezőszervernek is nevezik. Az MTA SMTP protokollon dolgozik, és ezek közül egy elvileg már elég egy levelezőrendszer létrehozásához. Valamikor pontosan ez volt a helyzet, és ahhoz, hogy hozzáférjen a postaládájához, bizonyos technikai ismeretekkel kellett rendelkeznie.
A haladás azonban nem áll meg, a levelet fogadó MTA azt a felhasználó postafiókjába helyezi azon a szerveren, amelyhez az utóbbinak hozzá kell férnie, lehetőleg a legegyszerűbb és érthető módon. Itt jön a színpad MDA (Levélkézbesítési ügynök-- levélkézbesítési ügynök), feladata, hogy a levelezőkliens kérésére a leveleket a szerveren lévő postafiókból továbbítsa neki. Az MDA működhet POP3 vagy IMAP protokollok használatával, bizonyos esetekben a levelezőkliens és a kézbesítő ügynök „kommunikálására”, saját, kiterjesztett funkcionalitással rendelkező protokolljaik, mint például a MAPI (Exchange Server) használhatók.
A közkeletű tévhittel ellentétben az MDA-nak semmi köze a levéltovábbítási folyamathoz. Ez az MTA előjoga. Hasonlatot levonva, elképzelheti az MTA-t egy postahivatalként, amely fogadja és küldi a leveleket, az MDA-t pedig a postással, aki a bejövő levelezést hazaviszi. Ha a postás beteg, akkor ez nem befolyásolja a posta munkáját, csak nem kap otthon leveleket. Szintén MDA, meghibásodása nem vezet a levelezőszerver működésképtelenségéhez, csak a levelek fogadása válik elérhetetlenné a levelezőkliens által, ugyanakkor más módon is könnyen elérhető, például webes felületen keresztül.
Lássuk, mi történik levélküldéskor. Példánkban az example.org tartományban található Ivanov felhasználó ( [e-mail védett]), levelet ír Kozlovnak az example.com domainben ( [e-mail védett]). Ivanov esetében a levélküldés egy üzenet létrehozásából és a levelezőkliens "Küldés" gombjának megnyomásából áll. A levelezőkliens az SMTP protokoll használatával csatlakozik az MTA-hoz, és először közli a hitelesítő adatait. A felhasználó engedélyezése után az MTA elfogadja az üzenetet és megpróbálja továbbítani.
Igazából az engedélyezés nem kötelező eljárás az MTA-nál, de felhatalmazás nélkül kapunk egy nyitott relét, pl. szerverünket bárki használhatja levelek küldésére, és a spammerek örülni fognak! Jelenleg a nyitott relék főként a szerver konfigurációs hibái miatt fordulnak elő. Azonban nagyon is lehetséges, hogy az MTA engedély nélkül kapjon leveleket megbízható felhasználóktól, például a következőtől helyi hálózat vállalkozások.
Az MTA saját felhasználói listát, rendszerlistát, LDAP vagy AD felhasználólistát használhat az engedélyezéshez. Van egy módszer is: POP engedélyezés az SMTP előtt, amikor a felhasználó levélküldés előtt bejelentkezik az MDA-ba, ami viszont megerősíti a felhasználó hitelesítését az MTA felé.
Az MTA következő lépéseként elemzi a levél szolgáltatási információit, meghatározza a címzett domainjét, ha az az MTA adatok által kiszolgált domainek közé tartozik, megkeresi a címzettet, és a levelet a postaládájába helyezi. Ez akkor történt, ha Ivanov levelet írt Petrovnak vagy Sidorovnak.
Ha a címzett tartományát nem szolgálja ki az MTA, akkor egy DNS-lekérdezés jön létre, amely lekéri az adott tartomány MX rekordjait. Az MX rekord egy speciális DNS-rekord, amely az adott tartományhoz tartozó bejövő leveleket kezelő levelezőszerverek nevét tartalmazza. Egynél több MX rekord is lehet, ilyenkor az MTA szekvenciálisan próbál kapcsolatot létesíteni, a legmagasabb prioritású szervertől kezdve. MX rekord hiányában a rendszer egy A rekordot kér (olyan címrekordot, amely leképez Domain név IP-címmel), és megkísérlik a leveleket az ott megadott gazdagépre kézbesíteni. Ha az üzenetet nem lehet elküldeni, akkor hibaüzenettel visszaküldik a feladónak (a felhasználó postafiókjába helyezve).
Nem vesszük figyelembe a fogadó szerver munkáját, feltételezzük, hogy minden rendben ment, Kozlov levelet kapott Ivanovtól, és válaszolt neki. Az example.com tartományt kiszolgáló szerver pontosan ugyanezt teszi, és megpróbál leveleket küldeni a szerverünknek. Miután megkapta bejövő üzenet Az MTA a helyi feladóhoz hasonlóan ellenőrzi a címzett domainjét, ha az a kiszolgált MTA-k egyike, az üzenetfeldolgozás folytatódik, ellenkező esetben a szerver megtagadja a levelek fogadását. A domain ellenőrzése után a címzett ellenőrzésre kerül, ha jelen van a felhasználók listájában, az üzenet a postafiókjába kerül, ellenkező esetben két lehetőség van: az üzenet fogadásának megtagadása vagy az üzenet fogadása az általános postafiókba (rendszergazda postafiókjába) ). Ez a beállítás egyrészt növeli a beérkező spamek számát, másrészt lehetővé teszi, hogy ne veszítsék el a hibásan írt címeket tartalmazó leveleket.
Egy másik levélszemét-ellenes intézkedés a PTR rekord kérése. A PTR rekord (pointer rekord) egy IP-címet társít egy tartománynévhez. PTR kérésekor az MTA csak akkor fogad levelet, ha a feladó domainje megegyezik a küldő szerver tartományával.
Tekintsünk egy példát részletesebben. Néhány spam.com szerver hamis feladóval próbál e-maileket küldeni, állítólag az általunk ismert example.com szerverről. Fehér/fekete listák alapján történő szűrés esetén ilyen levél érkezik, mivel a feladó egy megbízható domain felhasználója (amire számítottak a spammerek). A spam elleni küzdelem érdekében az MTA PTR kérést generál a küldő szerver IP-címére, amelyet az SMTP munkamenet során jelent. Az y.y.y.y címhez a PTR kérés olyan spam.com domain nevet ad vissza, amely nem egyezik a feladó domainjével, ami elutasítást eredményez. ez az üzenet. Ezzel egyidejűleg az x.x.x.x szerverről érkező üzenetek is megérkeznek, mivel az x.x.x.x PTR-rekordjának tartománya (example.com) megegyezik a feladó tartományával.
Tehát az üzenet megérkezett, és a felhasználó postafiókjában van. Hogyan kell elolvasni? A levéltár, ahol a felhasználói fiókok találhatók, sokféleképpen szervezhető: a banális mappáktól és fájloktól az adatbázisokig. Műszaki ismeretek nélkül nem valószínű, hogy el tudja olvasni a saját leveleit. De vajon az Ivanov felhasználónak kell aggódnia emiatt? Számára a levelek fogadásának folyamata a levelezőkliens "Fogadás" gombjának megnyomására redukálódik.
A levelek fogadásához a kliens kapcsolatot létesít az MDA-val a POP3 vagy IMAP protokollon keresztül, szükségszerűen átadva az adatokat az engedélyezéshez. Az MDA ellenőrzi, hogy a felhasználó szerepel-e a listákon, és ha sikeres, minden új üzenetet elküld a kliensnek a postafiókjába. Ivanov felhasználó megkapja levelezését, és a számára kényelmes módon dolgozhat vele.
Cikkünk itt véget is ér, erősen ajánljuk a benne bemutatott anyagok átgondolt olvasását és asszimilációját. A jövőben a levelezőszerverek gyakorlati megvalósításának mérlegelésekor abból adódóan fogunk anyagot benyújtani, hogy az olvasó legalább jelen cikk erejéig rendelkezik ismeretekkel.
Ha szeretnéd megtanulni, hogyan találd meg és használd ki a sebezhetőségeket információs hálózatok Javaslom ismerkedést online tanfolyam „Workshop on Kali Linux» az OTUS-ban. A tanfolyam azoknak szól, akik nem rendelkeznek gyakorlattal információ biztonság, a belépéshez át kell menni.
Kezdjük azzal, hogy mit értek középvállalkozás alatt. Nem tudom a pontos besorolást és nem néztem sehol, nem ellenőriztem. Intuitívan úgy tűnik számomra, hogy ez 10-15 felhasználótól 200-300-ig terjed. Megfontolom a szegmenst akár 100 felhasználó, hiszen szinte mindig kizárólag ebben a résben dolgozom. A nagyobb cégek problémáit és igényeit nem ismerem biztosan. Bár nem biztos, hogy valami alapvetően más lesz, mint 100 ember, de szerintem a megközelítések ugyanazok lesznek, csak a hardver erősebb. A terheléselosztás és a klaszterezés problémái itt nagy valószínűséggel még fel sem merülnek.
Van egy kis cégünk, több tucat fővel. Szükségünk van egy levelezőszerverre. Annak ellenére, hogy a technológia már régen előrelépett, rengeteg különféle kommunikációs eszközt biztosít, az e-mail továbbra is szilárdan megállja a helyét, és egyelőre nem ad fel. Ugyanakkor egy ilyen kis csapatban nincsenek nagy követelmények a levelezőszerverrel szemben. Leggyakrabban elég, ha a levél működik, különösebb funkcionális sallangok nélkül. Vagy egy e-mail kliens és imap protokoll, vagy webes felület. Nos, ha lehetséges az automatikus válasz beállítása, tegye meg megosztott mappák, egyetlen címjegyzék, de lehet élni nélküle is.
Mind között lehetőségek mail szolgáltatás, 3 alapvetően eltérő megközelítést emelek ki a szükséges funkciók megvalósításához:
Elemezzük mindegyiket részletesebben.
Mindjárt teszek pár megjegyzést. Nem vagyok benne biztos, hogy a Google most ingyenesen tud-e regisztrálni vállalati posta. Mindenki, aki regisztrált a használat előtt, ingyenes, és csak új felhasználók számára fizetett előfizetések. De ez nem alapvető, és nem kapcsolódik közvetlenül a cikk témájához. Ha a Google teljesen fizetett az üzletért, akkor egyszerűen kizárjuk a listánkból. A Yandex és a Mail.ru továbbra is határozottan ingyenes. Jómagam adminisztráltam levelezési domaineket a Google Apps-ben és a Yandexben. Nem dolgoztam a biz.mail.ru-val, csak azt tudom, hogy ott van valami hasonló. Valahogy magát a társaságot nem szeretem a régi idők óta. Bár most úgy tűnik, a felhasználók felé fordultak, de az Amigo még él és virul, így még nem fordultak meg.
Fontolja meg e levelezési szolgáltatások előnyeit.
Úgy tűnik, mindenből semmi sem hiányzik. Úgy tűnik, hogy az előnyök nyilvánvalóak és jelentősek. Mielőtt azonban elhamarkodott következtetéseket vonnánk le, nézzük meg a hátrányokat.
Amikor körülbelül 10 évvel ezelőtt elkezdtem dolgozni, nem volt kérdés, hogy milyen leveleket használjak a szervezetben. Mindenki beállította a levelezőszerverét és felügyelte azokat. Az ingyenes levelezési szolgáltatások akkoriban nem biztosítottak semmilyen eszközt az üzleti élet számára a levelezés kezelésére. Amikor elkezdtek megjelenni az ilyen eszközök, azt hittem, hamarosan senkinek sem lesz szüksége a levelezőszervereikre, mert már nem lesz értelme. És minden kínom (nem szeretek velük dolgozni) a levelezőszerverekkel értelmetlenné válik.
Lehetőséget kaptam a nyilvános levelezési szolgáltatásokon alapuló domain adminisztrálására. Ezt követően megjelent a fentebb írt hátrányok listája. És nekem személy szerint ezek a hátrányok meghaladták az előnyöket, és most is magam állítottam be a levelezőszervereket. Végső soron kényelmesebb és megbízhatóbb, ha együtt mérlegeljük a használat és az adminisztráció előnyeit és hátrányait.
A legnagyobb hátránynak a teljes értékű levélnaplók és a jó biztonsági mentési séma hiányát látom. Kényelmetlen a problémák elemzése naplók nélkül. A törölt levelet nem lehet gyorsan és egyszerűen visszaállítani az eredeti helyére, bár ez a nyílt forráskódú levelezőszervereknél egyszerű.
Fontolja meg a saját levelezőszerver előnyeit és hátrányait egy ingyenesen alapuló szoftver. Elvileg néhány fizetős is bekerülhet ide, például a szintén gyakran használt Kerio Mail Server. Szerintem ide is betudható, hiszen hasonló funkcionalitást biztosít. Az összes levelezőszervert összesítve veszem figyelembe, az egyes képviselők kiemelése nélkül. Bár Linuxban, a postfixen és az eximen kívül, én személy szerint semmit nem láttam élesben. Én magam mindig postfixet használok, mert megszoktam és jól ismerem. Gondosan mérlegelje az ilyen szerverek előnyeit.
A levelező szolgáltatásomnak ilyen hátrányait látom. A legfontosabb számomra az utolsó. Jómagam hozzászoktam, hogy a weben keresztül levelezzek. Nem szeretek levelezőklienseket használni, bár muszáj. Az ingyenes levelezőszerverek webes felületei kényelem és sebesség tekintetében nem maradnak el a gmailtől vagy a Yandextől, nincs értelme összehasonlítani. És mégis, szerintem egy átlagos szervezet számára ez a legtöbb legjobb lehetőség. Egy ilyen ingyenes levelezőszerver beállítására példa a .
Nincs sok csereadminisztrációs tapasztalatom. Nagyon régen teszteltem, amikor eldöntöttem, hogy melyik levelezőszerverekkel fogok dolgozni. Telepítve, tanulmányozta a funkcionalitást. Aztán egyszer beállítottam egy levelezőszervert a szervezetnek. Pontosan cserét akartak. Nem volt probléma, gyorsan beállítottam az interneten található számos útmutató szerint. Az Exchange levelezőszerver-konfigurátoraiba való belépési küszöb nagyon alacsony. Még az enikey is képes kezelni az alapvető funkciókat.
A közepes méretű szervezetek számára a megosztott naptárakat igazán hasznos és nehezen pótolható funkciónak tartom. És természetesen az AD-vel való integráció kényelme, ha van ilyen. És leggyakrabban AD van, hiszen 20-30 főnél több hálózati adminisztrációt el sem tudok képzelni anélkül Active Directory. Úgy gondolom, hogy értelmetlen itt spórolni, és meg kell vásárolni a Microsoft Servert.
Fontolja meg most az előnyöket és hátrányokat Microsoft Exchange szerver. Még egyszer figyelmeztetlek minden esetre. Csak az én elképzelésemet mondom el, kevés tapasztalatom van a szerverrel kapcsolatban, ezért saját magam is szeretnék észrevételeket kapni a hozzászólások között, hogy megfelelőbb megítélésem legyen ennek a rendszernek. Csere előnyei:
Az Exchange Server hátrányai ugyanolyan jellemzőek, mint a legtöbb Microsoft-termék előnyei:
Az Exchange Serverrel kapcsolatban az a következtetésem, hogy szinte mindenben jó, kivéve az árat. Ha ingyenes lenne, nagy valószínűséggel használnám. Egészen objektív okokból ez lehetetlen. A jó és kényelmes szoftver nem jelenik meg magától. Létre kell hoznia, és pénzt kell rá költenie, amit nyereséggel szeretne visszaadni.
Ma, tekintettel a Microsoft Exchange Server és a Microsoft Office költségeire, nem használom ezeket a Microsoft termékeket. Kevesen vállalják, hogy a levelezőszerver számára szükséges összeget lefektetik. Szeretném közelebbről megnézni az Exchange in valós körülmények legalább 60-80 ember, hogy objektívebben értékelje ezt a szervert. Ez a lehetőség azonban eddig nem adott.
Hadd foglaljam össze érvelésemet egy kis átlagos szervezet levelezőszerverével kapcsolatban. Bár a következtetés szerintem már világos. Én magam jobban szeretem az általam leírt második lehetőséget - egy levelezőszervert, amely ingyenes szoftveren alapul Linuxon. De a másik két lehetőséget nem zárnám le. Ingyenes posta a közszolgáltatásokból minden bizonnyal kényelmes lesz egy nagyon kis csapat számára - 10-15 fő számára. Nincs értelme elkeríteni a szervert egy ilyen szám miatt.
Javaslom az Exchange Server használatát, ha rendelkezik vele, és nem bánja, hogy pénzt költ a vásárlására. A termék egyedülállóan kényelmes, funkcionális és könnyen konfigurálható és adminisztrálható. Ha egyszerűen beszélünk, meg kell értened, hogy ez feltételes. A konfigurációk nagyon összetettek lehetnek, de ez az eset Belépő szinten nézem.
