Úvod do poštovního serveru

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.

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