Ú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 EHLOvyž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.