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

Transkript

1 Home» Články» Praxe» Správa linuxového serveru» Správa linuxového serveru: Úvod do... Předchozí kapitola Zpět na obsah Následující kapitola Správa linuxového serveru: Úvod do poštovního serveru 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. Čtvrtek, 22. březen 2012 Autor Michal Dočekal známka 1,50 Ú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) EHLO client.example.org server: 250 mail.example.org server: 250 PIPELINING server: 250 SIZE server: 250 ETRN server: 250 STARTTLS server: 250 AUTH LOGIN PLAIN 1/5

2 server: 250 AUTH=LOGIN PLAIN server: 250 ENHANCEDSTATUSCODES server: 250 8BITMIME server: 250 DSN MAIL FROM: server: Ok RCPT TO: server: Ok DATA server: 354 End data with <CR><LF>.<CR><LF> From: "Michal Docekal" To: "Jan Novak" Date: Tue, 20 Mar :54: Subject: Predmet zpravy Ahoj, posilam velmi dulezitou zpravu. Michal Docekal. server: Ok: queued as D882C297011E QUIT server: 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 EHLOby 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: [ ]). 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 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í 2/5

3 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.orgjsou 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 ( ) 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 [ ]) (using TLSv1 with cipher ADH AES256 SHA (256/256 bits)) (No client certificate requested) by example.net (Postfix) with ESMTPS id 84BA E for <michal@example.net>; Tue, 20 Mar :03: (CET) Received: from localhost (localhost.localdomain [ ]) by example.cz (Postfix) with ESMTP id C37 for <michal@example.net>; Tue, 20 Mar :03: (CET) X Virus Scanned: Debian amavisd new at server.example.cz Received: from server.example.cz ([ ]) by localhost (server.example.cz [ ]) (amavisd new, port 10024) 3/5

4 with ESMTP id G9yD4RqiBxFh for Tue, 20 Mar :03: (CET) Received: from localhost.localdomain (unknown [ ]) (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 Tue, 20 Mar :03: (CET) Date: Tue, 20 Mar :03: From: Michal =?UTF 8?B?RG/EjWVrYWw=?= To: Subject: =?UTF 8?B?VGVzdG92YWPDrQ==?= e mail Message ID: < df8d7b8@example.cz> X Mailer: Claws Mail (GTK ; 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 ( ový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. Předchozí kapitola Zpět na obsah Následující kapitola Odkazy Pokud si chcete přečíst více o této problematice, navštivte tyto odkazy: RFC 5321: Simple Mail Transfer Protocol Wikipedia (CZ), Protokol SMTP 4/5

5 Wikipedia (CZ), MX záznam Wikipedia (CZ), MTA Přidat názor Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích najdete v nápovědě. Diskuzi můžete sledovat pomocí RSS kanálu 5/5