přejít na obsah přejít na navigaci

Linux E X P R E S, Správa linuxového serveru: Úvod do poštovního serveru

Správa linuxového serveru: Úvod do poštovního serveru

debain_notext.png

Tímto dílem začíná menší exkurze do světa poštovních serverů a poštovních služeb. Podíváme se na základní terminologii a základní principy elektronické pošty.


Úvod

Elektronická pošta představuje jednu z nejzákladnějších, nejpoužívanějších a také nejstarších služeb internetu. Z pohledu správce představuje poštovní server jednu z nejnáročnějších služeb na konfiguraci, správu a zabezpečení, což platí dvojnásob, jedná-li se o větší nebo firemní poštovní server.

Pokud se na elektronickou poštu podíváte podrobněji, zjistíte, že se v žádném případě nejedná o jednu jedinou službu. Jedná se o řadu různě provázaných služeb používajících různé mechanismy a různé protokoly. Prakticky na každé úrovni máte k dispozici alternativy a široké možnosti nastavení. Díky tomu se nastavení poštovního serveru stává komplexní, až téměř tvůrčí činností.

Vezměme to ale popořadě. Z čeho všeho se tedy skládá nebo může skládat taková poštovní služba?

MTA: Mail Transport Agent

Tato komponenta je patrně tou nejzásadnější částí celého mechanismu – MTA je služba zodpovědná za přenos pošty z jednoho počítače na druhý, a to prostřednictvím klient–server architektury (server poštu přijímá, klient posílá). Poštu k odeslání může MTA získat buď z jiného MTA (pak se jedná o tzv. „relay“, tedy předání zprávy jinému „poštovnímu serveru“), nebo od MUA (pod čímž si zatím představte např. Thunderbird).

V GNU/Linuxu je k dispozici řada MTA. Tento seriál se bude zabývat Postfixem, nicméně existuje celá řada dalších jako sendmail, Exim, qmail atd.

SMTP

K přenosu zpráv je využíván protokol SMTP (port 25). Jedná se o velmi starý protokol, který byl postupem času poměrně dost rozšiřován, nicméně základní principy zůstaly stejné. Jedná se o klasický textový protokol, kde klient zadává určité příkazy a server na ně reaguje. To, jak protokol SMTP vypadá v praxi, můžete vidět v příkladu níže:

server: 220 mail.example.org ESMTP Postfix (Debian/GNU)
klient: EHLO client.example.org
server: 250-mail.example.org
server: 250-PIPELINING
server: 250-SIZE 10240000
server: 250-ETRN
server: 250-STARTTLS
server: 250-AUTH LOGIN PLAIN
server: 250-AUTH=LOGIN PLAIN
server: 250-ENHANCEDSTATUSCODES
server: 250-8BITMIME
server: 250 DSN
klient: MAIL FROM: michal.docekal@example_org
server: 250 2.1.0 Ok
klient: RCPT TO: jan.novak@example_com
server: 250 2.1.5 Ok
klient: DATA
server: 354 End data with <CR><LF>.<CR><LF>
klient: From: "Michal Docekal" <michal.docekal@example_org>
klient: To: "Jan Novak" <jan.novak@example_com>
klient: Date: Tue, 20 Mar 2012 10:54:50 +0100
klient: Subject: Predmet zpravy
klient:
klient: Ahoj,
klient:
klient: posilam velmi dulezitou zpravu.
klient: 
klient: Michal Docekal
klient: 
klient: .
server: 250 2.0.0 Ok: queued as D882C297011E
klient: QUIT
server: 221 2.0.0 Bye

Přirozeně, označení „klient“ a „server“ byly do výpisu přidány za účelem objasnění rolí klienta a serveru, nejsou součástí protokolu SMTP.

Jak je patrné, relace doručování e-mailu začíná příkazem EHLO (u hodně starých MTA/MUA to může být i HELO). Zde se klient identifikuje serveru – parametrem EHLO by mělo být plně kvalifikované doménové jméno klienta, přinejhorším specifikace IP adresy (IPv4 adresa se vkládá do hranatých závorek: [1.2.3.4]).

Klient dále pokračuje specifikací odesílatele MAIL FROM:, specifikací příjemce nebo příjemců RCPT TO:, načež následuje příkaz DATA, po kterém následuje tělo zprávy. Tělo začíná hlavičkami jako From:, To:, Date: a samozřejmě nechybí ani předmět zprávy Subject:. Text zprávy je ukončen sekvencí znaků konce řádku, tečky a dalšího konce řádku. Klient ukončuje relaci příkazem QUIT. Všimněte si také reakcí serverů, které jsou zde více či méně samovysvětlující. Máte-li zájem dozvědět se o SMTP protokolu více, podívejte se na RFC 5321, kde je nejnovější revize protokolu SMTP z roku 2008.

Interakci s MTA pomocí protokolu SMTP si můžete vyzkoušet sami, ručně, a to buď pomocí nástroje telnet, nebo nc:

telnet postovni-server.example.org 25
nc postovni-server.example.org 25

Tento postup je velmi vhodný také pro testování a diagnostiku vlastních poštovních serverů (a nejen poštovních serverů, tohoto postupu lze využít u jakéhokoliv textového protokolu), přeci jen, možnost si ručně vyzkoušet, jak se váš server chová v různých situacích, je nedocenitelná pomůcka.

DNS

Funkcionalita SMTP je přímo závislá na DNS. Asi vám nemusím připomínat, že e-mailová adresa má nejčastěji tvar jmeno@domena. Otázkou je, podle čeho určí MTA server, na který má poštu doručit. Odpovědí jsou tzv. MX záznamy příslušné domény. Ty specifikují jeden nebo více poštovních serverů a přiřazují jednotlivým serverům danou prioritu. Priorita je číslo, kde nižší číslo odpovídá vyšší prioritě (podobně jako „niceness“ u unixových procesů). MX záznamy si můžete poměrně snadno vypsat:

host -t MX example.org

Nebo, pokud preferujete nástroj dig:

dig -t MX example.org

Pro ilustraci, výstup prvního z uvedených příkazů může vypadat např. takto:

example.org mail is handled by 20 mail-backup.example.org.
example.org mail is handled by 10 mail.example.org.

Z výpisu je patrné, že MX záznamy domény example.org jsou v tomto případě dva. Nejvyšší prioritu má server mail.example.com, nižší prioritu má pak mail-backup.example.org. To znamená, že pokud se MTA nepodaří doručit poštu serveru s nejvyšší prioritou, měl by zkusit server s nižší prioritou. V případě, že má několik serverů stejnou prioritu, vybere si z nich MTA náhodně.

Pokud pro danou doménu neexistuje vůbec žádný MX záznam, použije se A záznam dané domény místo něj.

Nastavení poštovního serveru versus SMTP

Poštovní server lze nastavit různým způsobem. Můžete respektovat příslušná RFC, což určitě patří k „dobrým mravům“ správců serverů. Naneštěstí bývá podstatně jednodušší nechat se strhnout úmyslem efektivnějšího boje se spamem (popřípadě neznalostí RFC) a RFC porušit. Kupříkladu, některé servery jako parametr EHLO vyžadují plně kvalifikované doménové jméno, i když podle RFC tam být nemusí. Takových příkladů bychom určitě našli mnoho.

Je třeba mít na paměti, že čím striktněji svůj server nastavíte, tím méně pošty budete dostávat, a to platí pro spam i pro regulérní poštu, kterou dostávat chcete. Bohužel, v tomhle nepomáhá vždy ani důsledné respektování RFC, jelikož správci poštovních serverů je ne vždy správně nastaví (důvodem je mj. relativní složitost poštovních služeb zmíněná v úvodu), což, paradoxně, činí správu poštovních serverů ještě složitější.

Anatomie e-mailu

Pokud jste tak ještě nikdy neučinili, bylo by velmi vhodné si vyhlédnout jednu nebo několik zpráv ve vaší poštovní schránce a podívat se na jejich „zdrojový kód“. Ten může vypadat např. takto:

Return-Path: <michal@example_cz>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on example.net
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,
        SPF_PASS,T_DKIM_INVALID autolearn=ham version=3.3.1
X-Original-To: michal@example_net
Delivered-To: michal@example_net
Received: from mail.example.cz (mail.example.cz [1.2.3.4])
        (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by example.net (Postfix) with ESMTPS id 84BA8297011E
        for <michal@example_net>; Tue, 20 Mar 2012 16:03:33 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
        by example.cz (Postfix) with ESMTP id 27788214C37
        for <michal@example_net>; Tue, 20 Mar 2012 16:03:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at server.example.cz
Received: from server.example.cz ([127.0.0.1])
        by localhost (server.example.cz [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id G9yD4RqiBxFh for <michal@example_net>;
        Tue, 20 Mar 2012 16:03:32 +0100 (CET)
Received: from localhost.localdomain (unknown [4.3.2.1])
        (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
        (No client certificate requested)
        by server.example.cz (Postfix) with ESMTPSA id A759A214C36
        for <michal@example_net>; Tue, 20 Mar 2012 16:03:31 +0100 (CET)
Date: Tue, 20 Mar 2012 16:03:25 +0100
From: Michal =?UTF-8?B?RG/EjWVrYWw=?= <michal@example_cz>
To: michal@example_net
Subject: =?UTF-8?B?VGVzdG92YWPDrQ==?= e-mail
Message-ID: <20120320160325.5df8d7b8@example_cz>
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ahoj,

pos=C3=ADl=C3=A1m testovac=C3=AD e-mail.

Michal Do=C4=8Dekal

Všimněte si, že si e-mail s sebou tahá veškerou historii, kterými servery e-mail procházel (hlavičky Received:). Tuto historii čtěte v pořadí od posledního záznamu k prvnímu. Všimněte si, že jedním serverem může e-mail procházet více než jednou (e-mail je zpracováván různými dalšími službami a poté opět předán SMTP serveru). Jsou zde patrné i hlášky těchto dalších služeb (amavis, spamassassin atd.).

Samotné tělo obsahuje zprávu v kódování UTF-8, avšak jelikož SMTP protokol je skutečně čistě textovým protokolem, všechny netextové znaky musí být zakódovány (zde je použito „quoted-printable“). Tento postup samozřejmě zvětšuje objem přenášených dat, což je nejvíce patrné v případě přenosu binárních dat (e-mailových příloh), kde dojde v důsledku kódování ke zvýšení objemu přenášených dat přibližně o 1/3.

Jednotlivé parametry hlavičky mailu (např. pole From:) obvykle nejsou kontrolovány (ono v podstatě ani není jak je důsledně zkontrolovat) a mohou obsahovat různé hodnoty (včetně nesmyslných nebo podvržených). Není tedy problém vytvořit si „falešnou identitu“. To je problémem stáří a snahy zachování zpětné kompatibility protokolu SMTP – bezpečnost (MITM útoky), soukromí (e-mail je v řadě případů posílán a vždy skladován nešifrovaný, v čisté textové podobě) nebo autentizace (možnost si ověřit, že komunikuji skutečně s tím, s kým komunikuji) nebyly brány v úvahu při jeho tvorbě. Toto do jisté míry řeší nástroje jako GnuPG či PGP, které umožňují e-maily podepisovat a šifrovat. V praxi se, alespoň v mém případě, ukazuje jako největší problém neochota komunikačních protistran podepisovat a šifrovat.

Tím bych tento díl ukončil. Příště se budu věnovat zbytku úvodu do problematiky poštovního serveru.

Nahoru

Odkazy

Příspěvky

Správa linuxového serveru: Úvod do poštovního serveru
zdenda 22. 03. 2012, 21:14:10
Odpovědět  Odkaz 
Super,díky za článek a těším se na pokračování. Tenhle seriál nemá chybu a přeji autorovi aby mu jeho elán vydržel co nejdéle.
Lukáš Jelínek Re: Správa linuxového serveru: Úvod do poštovního serveru
Lukáš Jelínek 22. 03. 2012, 23:23:08
Odpovědět  Odkaz 
Též to autorovi přeji. Protože jsem velmi podobný seriál psal (byť zaměřený na konkrétní kombinaci Postfix+Dovecot) a v podstatě nedopsal :-(
Tomáš Crhonek Re: Re: Správa linuxového serveru: Úvod do poštovního serveru
Tomáš Crhonek 23. 03. 2012, 15:09:19
Odpovědět  Odkaz 
Těm 17 dílům říkáš nedopsal? Takovéto seriály bych tedy také chtěl "nedopisovat". :-)
Lukáš Jelínek Re: Re: Re: Správa linuxového serveru: Úvod do poštovního serveru
Lukáš Jelínek 23. 03. 2012, 16:50:39
Odpovědět  Odkaz 
Na konci toho 17. dílu si můžeš všimnout, že jsem připravoval další, ale už jsem pak neměl sílu ho dopsat. Něco podobného teď hrozí u seriálu o FlexiBee, ale tam už připravuji plán na další období, tak snad bude pokračovat. Seriály jsou vysilující...
Správa linuxového serveru: Úvod do poštovního serveru
Petr 28. 03. 2012, 22:13:31
Odpovědět  Odkaz 
Nevíte náhodou někdo, jak nakonfigurovat Postfix tak, aby umožnil posílat maily jen na předem definované domény (v adrese příjemce) a ostatní odmítal? Díky moc za každou radu.
Lukáš Jelínek Re: Správa linuxového serveru: Úvod do poštovního serveru
Lukáš Jelínek 28. 03. 2012, 22:47:03
Odpovědět  Odkaz 
STFW & RTFM!!! Jinak ve stručnosti - do relay_domains se nastaví domény, do kterých to má odesílat, např. takhle:

relay_domains = hash:/etc/postfix/relay_domains

Tohle dovolí odesílání do domén, které jsou uvedeny v hashové tabulce /etc/postfix/relay_domains. Podobně lze použít jiný způsob definice těchto domén (reg. výraz, LDAP, databáze...). Podrobnosti jsou v dokumentaci k Postfixu.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Top články z OpenOffice.cz

Michal Dočekal

GNU/Linuxový nadšenec a zastánce svobodného softwaru. Jeho pracovní náplň zahrnuje správu několika linuxových serverů. Snaží se být aktivním členem linuxové komunity, dlouhodobě vytváří dokumentaci pro začínající uživatele Linuxu.


  • Distribuce: Arch Linux
  • Grafické prostředí: Awesome

| blog



Public Relations

Bezpečné zálohování a spolehlivá obnova dat jsou odpovědí na všudypřítomnou hrozbu ransomwaru

VeeamUž to tak vypadá, že ransomware ze světa nezmizí, a organizace se tomu musí přizpůsobit, aby dokázaly tuto hrozbu přežít a zajistit odolnost svého podnikání vůči jejím dopadům. Na ransom­ware se musíme přestat dívat jako na náhodnou událost, ale vnímat ji jako stále přítomnou hrozbu, kdy už není otázka, zda a kdy, ale jak často nás zasáhne.

Pokračování ...



Public Relations

Jak se chránit před zranitelnostmi? MSP službou!

ZebraPočet softwarových zranitelností neustále roste – zatímco v roce 2021 bylo dle informací katalogu CVE zjištěno celkem 20 171 zranitelností, vloni došlo k dalšímu nárůstu na rekordních 25 277 případů. Navíc také roste jejich závažnost, a i v roce 2022 se zvýšil počet tzv. kritických zranitelností. Mezi nimi například proslulý Log4J.

Pokračování ...



Public Relations

Průkopnická automatizovaná obrana pohyblivých cílů

SophosS tím, jak se prostředí kybernetických hrozeb stává stále složitějším, bezpečnostní týmy čelí rapidnímu nárůstu počtu hrozeb. Mnoho organizací se potýká s vysokým počtem výstrah a falešně pozitivních hlášení, což vede k neustálému úsilí o jejich vyřešení a zbytečnému zatěžování zdrojů a snižování účinnosti zabezpečení.

Pokračování ...