Även i antiken kände människor ett behov av att utbyta information och organiserade det på statlig nivå. Därför är posten en av de tydligast organiserade institutionerna i världen.
E-post är ett nytt modernt sätt att överföra information. Till skillnad från vanlig post, elektroniska kopior av meddelanden, filer, program, olika data överförs via e-post – d.v.s. information som behandlas av en dator.
Huvudobjekten som utgör e-postsystemet är speciella datorer som kallas e-postservrar.
E-postservrar är servrar som tar emot och skickar elektroniska meddelanden.
Servern som tar emot e-postmeddelanden använder POP-protokollet (Post Office Protocol).
Servern som skickar e-post körs på SMTP-protokoll(Simple Mail Transfer Protocol).
E-postserver, e-postserver, e-postserver - i systemet för vidarebefordran av e-post är detta vanligtvis namnet på meddelandeöverföringsagenten (engelsk e-postöverföringsagent, MTA). Detta datorprogram, som överför meddelanden från en dator till en annan. Vanligtvis fungerar e-postservern "bakom kulisserna", och användare hanterar ett annat program - en e-postklient (engelsk mail user agent, MUA).
Ris. 1.
Till exempel, i en vanlig konfiguration är användaragenten Outlook Express. När användaren har skrivit ett meddelande och skickar det till mottagaren kommunicerar e-postklienten med e-postservern med hjälp av SMTP-protokollet. Avsändarens e-postserver interagerar med mottagarens e-postserver (direkt eller via en mellanserver - relä). På mottagarens e-postserver kommer meddelandet in i brevlådan, varifrån det levereras till mottagarens klient med hjälp av en meddelandeleveransagent (MDA). Ofta kombineras de två sista agenterna i ett program, även om det finns specialiserade MDA:er som bland annat hanterar spamfiltrering. Den slutliga leveransen av mottagna meddelanden är inte SMTP, utan ett annat protokoll - ofta POP3 eller IMAP - som också stöds av de flesta e-postservrar. Även om det i den enklaste implementeringen av MTA räcker att lägga de mottagna meddelandena i användarens hemkatalog i filsystem central server ("brevlåda").
E-postserver, e-postserver, e-postserver - detta är vanligtvis namnet på meddelandeförmedlaren i systemet för vidarebefordran av e-post. Detta är programvara som överför meddelanden från en dator till en annan. E-postservern är vanligtvis inte synlig för användaren. Användaren själv har att göra med en annan programvara - en e-postklient.
Till exempel, i den vanligaste konfigurationen är e-postklienten Outlook Express. Även om Mozilla Thunderbird-klienten ofta används på sistone. När en användare skriver ett meddelande och vidarebefordrar det till mottagaren interagerar e-postklienten med e-postservern via SMTP-protokollet. Avsändarens e-postserver interagerar med mottagarens server. På mottagarens server går meddelandet som skickas till honom till brevlådan, varifrån det, med hjälp av MDA-meddelandeleveransagenten (postleveransagent), levereras till mottagarens klient. Det finns även POP3- och IMAP-protokoll som stöds av många e-postservrar.
Många systemadministratörer upplever vissa svårigheter när de arbetar med e-postsystem. Detta är inte förvånande, e-postservern har en mycket mer komplex struktur än fil server, router eller terminalserver. I den här artikeln kommer vi att överväga strukturen och principen för driften av e-postservrar, utan att förstå vilken, inställning av ett e-postsystem är ganska kapabelt att förvandlas till shamanistiska danser med en tamburin.
Detta material innehåller en hel del förenklingar och generaliseringar för att ge systemadministratörer erforderliga minimikunskaper. Enligt vår mening, för att administrera en eller två e-postservrar nybörjarnivå Du behöver inte vara en e-postexpert.
För de flesta användare och nybörjaradministratörer är e-postservern en sorts "svart låda", som, efter att ha fått ett brev, levererar den till adressaten på "okända" sätt och vice versa. All interaktion med en sådan server består i att adressera e-postklienten till vissa portar, eller till och med via webbgränssnittet. Det finns dock en hel mekanism gömd inuti, att förstå hur man fungerar är nyckeln till att framgångsrikt installera och underhålla ett e-postsystem. Detta är särskilt viktigt för att administrera servrar på Linux-plattformen. Till skillnad från Windows, där e-postservern är en komplett mjukvarulösning och utvecklarna redan har tagit hand om intern interaktion, är komponenterna i e-postservern i Linux individuella program och du måste konfigurera deras interaktion själv.
Låt oss ta en titt på e-postserverns struktur och vad som händer när en användare försöker skicka e-post.
Den viktigaste delen av e-postservern är MTA (Mail Transfer Agent-- mail forwarding agent) vars uppgifter inkluderar att ta emot och sända post. Mycket ofta (i Linux/UNIX) kallas MTA också för en e-postserver. MTA fungerar på SMTP-protokollet, och ett av dem räcker i princip redan för att skapa ett e-postsystem. En gång i tiden var det precis så och för att komma åt din brevlåda behövde du ha viss teknisk kunskap.
Framstegen står dock inte stilla, MTA, som tar emot ett brev, placerar det i användarens brevlåda på servern som den senare måste komma åt, helst på det enklaste och mest begripliga sättet. Här kommer scenen MDA (Mail Delivery Agent-- e-postleveransagent), dess uppgift, på begäran av e-postklienten, är att överföra e-post till den från postlådan på servern. MDA kan arbeta med POP3- eller IMAP-protokollen, i vissa fall för att "kommunicera" e-postklienten och leveransagenten, deras egna protokoll med utökad funktionalitet, såsom MAPI (Exchange Server), kan användas.
I motsats till den vanliga missuppfattningen har MDA ingenting att göra med e-postöverföringsprocessen. Detta är MTA:s privilegium. För att dra en analogi kan du föreställa dig MTA som ett postkontor som tar emot och skickar post, och MDA med brevbäraren som tar med den inkommande korrespondensen till ditt hem. Om brevbäraren är sjuk, kommer detta inte att påverka postkontorets arbete, du kommer bara inte att få brev hemma. Också MDA, dess misslyckande leder inte till att e-postservern inte fungerar, bara mottagandet av e-post från e-postklienten blir otillgängligt, samtidigt som det lätt kan nås på andra sätt, till exempel via webbgränssnittet.
Låt oss se vad som händer när du skickar e-post. I vårt exempel, användaren Ivanov, som finns i domänen example.org ( [e-postskyddad]), skriver ett brev till Kozlov i domänen example.com ( [e-postskyddad]). För Ivanov består processen att skicka e-post av att skapa ett meddelande och trycka på knappen "Skicka" i e-postklienten. E-postklienten ansluter till MTA:n med SMTP-protokollet och kommunicerar först dess autentiseringsuppgifter. Efter att ha auktoriserat användaren accepterar MTA meddelandet och försöker leverera det vidare.
Egentligen är auktorisation inte ett obligatoriskt förfarande för MTA, men utan auktorisation får vi ett öppet relä, d.v.s. vem som helst kan använda vår server för att skicka e-post, och spammare kommer att bli glada! För närvarande uppstår öppna reläer främst på grund av serverkonfigurationsfel. Det är dock fullt möjligt för en MTA att ta emot e-post från betrodda användare utan tillstånd, till exempel från lokalt nätverk företag.
MTA kan använda sin egen användarlista, systemlista, LDAP- eller AD-användarlistor för auktorisering. Det finns också ett sätt: POP-auktorisering före SMTP, när användaren loggar in på MDA innan han skickar e-post, vilket i sin tur bekräftar användarens autentisering till MTA.
Nästa steg i MTA:n analyserar brevets tjänstinformation och bestämmer mottagarens domän, om den tillhör de domäner som betjänas av MTA-data, söks mottagaren upp och brevet placeras i hans brevlåda. Detta hände om Ivanov skrev ett brev till Petrov eller Sidorov.
Om mottagarens domän inte betjänas av MTA genereras en DNS-fråga som begär MX-posterna för den domänen. En MX-post är en speciell typ av DNS-post som innehåller namnen på de e-postservrar som hanterar inkommande e-post för en given domän. Det kan finnas mer än en MX-post, i vilket fall MTA försöker upprätta en anslutning sekventiellt, med början från servern med högsta prioritet. I avsaknad av en MX-post begärs en A-post (en adresspost som mappar Domän namn med en IP-adress) och ett försök görs att leverera e-post till den värd som anges där. Om meddelandet inte kan skickas returneras det till avsändaren (placerat i användarens brevlåda) med ett felmeddelande.
Vi kommer inte att överväga den mottagande serverns arbete, vi kommer att anta att allt gick bra, Kozlov fick ett brev från Ivanov och skrev ett svar till honom. Servern som betjänar domänen example.com gör exakt samma sak och försöker skicka e-post till vår server. Efter att ha fått inkommande meddelande MTA, som i fallet med en lokal avsändare, kontrollerar mottagarens domän, om det är en av de serverade MTA:erna fortsätter meddelandebehandlingen, annars vägrar servern att acceptera e-post. Efter att ha kontrollerat domänen kontrolleras mottagaren, om han finns i listan över användare levereras meddelandet till hans brevlåda, annars finns det två alternativ: vägran att ta emot meddelandet eller ta emot meddelandet i den allmänna brevlådan (administratörens brevlåda ). Å ena sidan ökar den här inställningen antalet mottagna skräppost, å andra sidan låter den dig inte förlora brev med felstavade adresser.
En annan anti-spam-åtgärd är att begära en PTR-post. En PTR-post (pekarpost) associerar en IP-adress med ett domännamn. När du begär en PTR, accepterar MTA endast e-post om avsändarens domän matchar domänen för den sändande servern.
Låt oss överväga ett exempel mer i detalj. Någon spam.com-server försöker skicka e-postmeddelanden med en falsk avsändare, förmodligen från exempel.com-servern som vi känner till. Vid filtrering efter vita/svarta listor kommer ett sådant brev att levereras, eftersom avsändaren är en användare från en betrodd domän (vilket är vad spammare räknade med). För att bekämpa spam genererar MTA en PTR-begäran för IP-adressen för den sändande servern, som den rapporterar under SMTP-sessionen. För adressen y.y.y.y kommer PTR-begäran att returnera ett spam.com-domännamn som inte matchar avsändarens domän, vilket kommer att resultera i avslag det här meddelandet. Samtidigt kommer meddelanden från servern x.x.x.x att tas emot eftersom domänen från PTR-posten för x.x.x.x (example.com) matchar avsändarens domän.
Så meddelandet har tagits emot och ligger i användarens brevlåda. Hur läser man det? E-postlagringen, där användarboxar finns, kan organiseras på en mängd olika sätt: från banala mappar och filer till en databas. Utan teknisk kunskap är det osannolikt att du kommer att kunna läsa din egen mail. Men bör användaren Ivanov oroa sig för detta? För honom reduceras processen för att ta emot e-post till att trycka på knappen "Ta emot" i e-postklienten.
För att ta emot e-post upprättar klienten en anslutning till MDA via POP3- eller IMAP-protokollet, och skickar nödvändigtvis data för auktorisering. MDA kontrollerar om användaren finns i listorna och, om den lyckas, skickar kunden alla nya meddelanden i sin brevlåda. Användaren Ivanov tar emot sin korrespondens och kan arbeta med den på ett sätt som är bekvämt för honom.
Det är här vår artikel slutar, vi rekommenderar starkt en tankeväckande läsning och assimilering av materialet som presenteras i den. I framtiden, när vi överväger praktiska implementeringar av e-postservrar, kommer vi att skicka in material på grundval av att läsaren har kunskap om minst den här artikeln.
Om du har en önskan att lära dig hur man hittar och utnyttjar sårbarheter i informationsnätverk Jag rekommenderar att lära känna onlinekurs "Workshop om Kali Linux» i OTUS. Kursen riktar sig till dig som inte har erfarenhet av informationssäkerhet, för antagning måste du godkännas.
Låt oss börja med vad jag menar med medelstora företag. Jag vet inte den exakta klassificeringen och har inte letat någonstans, har inte kollat. Det verkar intuitivt för mig att detta är från 10-15 användare till 200-300. Jag kommer att överväga segmentet upp till 100 användare, eftersom jag nästan hela tiden uteslutande arbetar inom denna nisch. Problemen och behoven hos större företag känner jag inte till med säkerhet. Även om jag inte är säker på att något kommer att vara fundamentalt annorlunda än 100 personer, tror jag att tillvägagångssätten kommer att vara desamma, bara hårdvaran är mer kraftfull. Problemen med lastfördelning och klustring kommer med största sannolikhet inte att uppstå här ännu.
Vi har ett litet företag med flera dussin personer. Vi behöver en e-postserver. Trots att tekniken har gått framåt för länge sedan och tillhandahållit många olika kommunikationsmedel, står e-post fortfarande stadigt på sina positioner och kommer inte att ge upp dem ännu. Samtidigt finns det i ett så litet team inga stora krav på mailservern. Oftast räcker det med att posten bara fungerar, utan några speciella funktionella krusiduller. Antingen en e-postklient och imap-protokoll, eller webbgränssnitt. Tja, om det är möjligt att ställa in ett automatiskt svar, gör det delade mappar, en enda adressbok, men du kan leva utan den.
Bland alla alternativ e-posttjänst pekar jag ut 3 fundamentalt olika tillvägagångssätt för implementeringen av den nödvändiga funktionaliteten:
Låt oss analysera var och en av dem mer i detalj.
Jag ska göra ett par kommentarer nu. Jag är inte säker på om Google nu kan registrera sig gratis företagspost. Alla som har registrerat sig före användning gratis och endast för nya användare betalda prenumerationer. Men detta är inte grundläggande och relaterar inte direkt till ämnet för artikeln. Om Google har blivit helt betald för affärer kommer vi helt enkelt att utesluta det från vår lista. Yandex och Mail.ru är fortfarande definitivt gratis. Själv administrerade jag e-postdomäner i google apps och Yandex. Jag arbetade inte med biz.mail.ru, jag vet bara att något liknande är implementerat där. Jag gillar på något sätt inte själva företaget sedan gamla dagar. Fast nu verkar de ha vänt sig mot användarna, men Amigo lever fortfarande och mår bra, så de har inte vänt än.
Tänk på fördelarna med dessa e-posttjänster.
Allt verkar sakna något. Det verkar som om fördelarna är uppenbara och betydande. Men innan vi drar några slutsatser, låt oss titta på nackdelarna.
När jag började jobba för ungefär 10 år sedan var det ingen tvekan om vilken typ av post man skulle använda i organisationen. Alla satte upp sina e-postservrar och administrerade dem. Gratis posttjänster tillhandahöll inga verktyg för företag vid den tiden att hantera post. När sådana verktyg började dyka upp trodde jag att snart ingen skulle behöva deras e-postservrar, eftersom de inte längre skulle vara vettiga. Och all min plåga (jag gillar inte att arbeta med dem) med e-postservrar kommer att bli meningslösa.
Jag fick möjligheten att administrera domäner baserade på offentliga posttjänster. Efter det dök listan över nackdelar som skrivits ovan upp. Och för mig personligen uppvägde dessa nackdelar fördelarna, och nu sätter jag fortfarande upp e-postservrar själv. I slutändan är det bekvämare och mer tillförlitligt när man överväger fördelarna och nackdelarna med användning och administration tillsammans.
Den största nackdelen jag ser är bristen på fullfjädrade e-postloggar och ett bra backupschema. Det är obekvämt att analysera problem utan loggar. Det kommer inte att vara möjligt att snabbt och enkelt återställa ett raderat brev till sin ursprungliga plats, även om detta är en enkel fråga för e-postservrar med öppen källkod.
Tänk på fördelarna och nackdelarna med din egen e-postserver baserad på en gratis programvara. I princip kan även några betalda ingå här, till exempel Kerio Mail Server, som också ofta används. Jag tror att det också kan tillskrivas här, eftersom det ger en liknande funktionalitet. Jag betraktar alla e-postservrar samlade, utan att peka ut enskilda representanter. Fast i Linux, förutom postfix och exim, har jag personligen inte sett något i produktionen. Jag använder alltid postfix själv, för jag är van vid det och kan det väl. Tänk noga på fördelarna med sådana servrar.
Jag ser sådana nackdelar med min posttjänst. Det viktigaste för mig är det sista. Jag är själv van vid att jobba med post via webben. Jag gillar inte att använda e-postklienter, även om jag måste. Webbgränssnitt till gratis e-postservrar när det gäller bekvämlighet och hastighet faller inte långt ifrån Gmail eller Yandex, det är ingen mening att jämföra. Och ändå tror jag att detta är mest för en genomsnittlig organisation bästa alternativet. Ett exempel på att sätta upp en sådan gratis e-postserver är .
Jag har inte mycket erfarenhet av utbytesadministration. Jag testade det för länge sedan när jag bestämde mig för vilka e-postservrar jag skulle arbeta med. Installerade, studerade funktionaliteten. Sedan satte jag upp en mailserver för organisationen en gång. De ville ha precis utbyte. Det var inga problem, jag satte snabbt upp det enligt många guider på Internet. Tröskeln för att gå in i Exchange-postserverns konfigurerare är mycket låg. Även enikey kan hantera den grundläggande funktionaliteten.
För medelstora organisationer anser jag att delade kalendrar är en riktigt användbar och svår att ersätta funktionalitet. Och naturligtvis, bekvämligheten med integration med AD, om någon. Och oftast finns det AD, eftersom jag inte kan föreställa mig nätverksadministration för mer än 20-30 personer utan Active Directory. Jag tycker att det är meningslöst att spara här och du måste köpa Microsoft Server.
Tänk nu på för- och nackdelar Microsoft Exchange server. Jag varnar dig igen för säkerhets skull. Jag berättar bara min vision, jag har liten erfarenhet av servern, så jag skulle vilja ta emot kommentarer om det själv i kommentarerna för att få en mer adekvat bedömning av detta system. Utbytesproffs:
Nackdelarna med Exchange Server är lika karakteristiska som plusen för de flesta Microsoft-produkter:
Min slutsats om Exchange Server är att den är bra i nästan allt, förutom priset. Om det var gratis skulle jag med största sannolikhet använda det. Av ganska objektiva skäl är detta omöjligt. Bra och bekväm programvara dyker inte upp av sig själv. Du måste skapa den och spendera pengar på den som du vill returnera med vinst.
Idag, med tanke på kostnaden för Microsoft Exchange Server och Microsoft Office, använder jag inte dessa Microsoft-produkter. Få människor går med på att lägga ut det nödvändiga beloppet för e-postservern. Jag skulle vilja ta en närmare titt på Exchange in verkliga förhållanden minst 60-80 personer för att utvärdera denna server mer objektivt. Men än så länge har denna möjlighet inte funnits.
Låt mig sammanfatta mitt resonemang om e-postservern för en liten genomsnittlig organisation. Även om slutsatsen, tror jag, redan är klar. Själv föredrar jag det andra alternativet jag beskrev - en e-postserver baserad på gratis programvara på linux. Men jag skulle inte avstå från de andra två alternativen. Gratis post från offentliga tjänster kommer definitivt att vara bekvämt för ett mycket litet team - för 10-15 personer. Det är ingen mening att inhägna din server för ett sådant nummer.
Jag skulle rekommendera att använda Exchange Server om du har det och du inte har något emot att spendera pengar på att köpa den. Produkten är unikt bekväm, funktionell och enkel att konfigurera och administrera. Enkelt talat måste du förstå att detta är villkorat. Konfigurationer kan vara mycket komplexa, men det här fallet Jag tittar på ingångsnivå.
