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

30.8.12

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

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) 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

www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-uvod-do-postovniho-serveru

1/5

30.8.12

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

server: 250­AUTH=LOGIN PLAIN server: 250­ENHANCEDSTATUSCODES server: 250­8BITMIME server: 250 DSN klient: MAIL FROM: [email protected] server: 250 2.1.0 Ok klient: RCPT TO: [email protected] server: 250 2.1.5 Ok klient: DATA server: 354 End data with . klient: From: "Michal Docekal" <[email protected]> klient: To: "Jan Novak" <[email protected]> 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í

www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-uvod-do-postovniho-serveru

2/5

30.8.12

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

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: <[email protected]> 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: [email protected] Delivered­To: [email protected] 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 <[email protected]>; 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 <[email protected]>; 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)

www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-uvod-do-postovniho-serveru

3/5

30.8.12

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

        with ESMTP id G9yD4RqiBxFh for <[email protected]>;         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 <[email protected]>; 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=?= <[email protected]> To: [email protected] Subject: =?UTF­8?B?VGVzdG92YWPDrQ==?= e­mail Message­ID: <[email protected]> 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. 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

www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-uvod-do-postovniho-serveru

4/5

30.8.12

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

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 

www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-uvod-do-postovniho-serveru

5/5