e GR..ó..D..ó..
O'REIl.Ly
KyZe D. Dent _____ _
Předmluva Wietse Venema
Kyle D. Dent
Postfix kompletní průvodce Přeložil Ludvik Roubíček
Z anglického originálu "Postfix: The Definitive Guide", vydaného v roce 2004 nakladatelstvím O'Reilly Media, Inc., 1 005 Gravenstein Highway North, Sebastopol, CA 95472, USA. Copyright © Grada Publishing, a.s., 2005. Authorized translation of the English edition. © 2004 O'Reilly Media, Inc. This translation is published and sold by permission of O'Reilly Media, Inc., the owner of all rights to publish and seli the same.
Vydala Grada Publishing, a.s. U Průhonu 22, Praha 7 jako svou 221 7. publikaci Odpovědný redaktor Martin Kysela Sazba Helena Krischke Grafická úprava obálky Matouš Přikryl Počet stran 252 První vydání, Praha 2005
V knize pou:ijté nát!!Y programorych produktů, firem apod mohou Idt ochrannými známkami nebo registrovanými ochrannými známkami příslušných vlastníků. Vytiskly Tiskárny Havlíčkův Brod, a.s. Husova ulice 1 88 1 , Havlíčkův Brod ISBN 80-247-1 029-3
Obsah
Předmluva ................................................................................................................... ix Úvod
..............................................................................................................................
1. Úvod
..................................................................................................................
Původ a ftlosofie Postfixu E-mail a internet Role Postfixu Zabezpečení Postfixu Další informace o získání Postfixu
2. Předpoklady
3. Architektura Postfixu
.....................................................................................
První spuštění Postfixu Konfigurační soubory Důležité úvahy o konfiguraci
��
Soubor master.cf Omezení příjmu Přepisování adres Příkaz chroot Dokumentace
9
9 11
Komponenty Postfixu Jak zprávy vstupují do systému Postfix Místní doručení Doručení pošty Trasování zprávy přes Postfix
4. Obecná konfigurace a správa
1 1 3 5 6 8
.....................................................................................................
Témata o systému Unix Témata týkající se e-mailů
x
.......................................................................
18 18 19 21 21 24
27 28 29 40 �
46 50 51 55 56
5. Řízení fronty
...................................................................................................
Jak funguje qmgr Nástroje fronty
6. E-mail a DNS
57 61
..................................................................................................
Úvod do DNS Směrování pošty Postfix a DNS Běžné problémy
66 66 67 70 72
7. Místní doručování a POP/IMAP
.....................................................................
.......................................................................................
Sdílené domény se systémovými účty Oddělené domény se systémovými účty Oddělené domény s virtuálními účty Oddělené úložiště zpráv Doručování do příkazů
9. Předávání pošty (Mail Relaying)
.................................................................
101 1 01 1 04 1 07 1 08 1 09
...................................................................................
Jednoduché elektronické konference Správci konferencí (MLM Mailing-List Managers) -
11. Blokování nevyžádaných zpráv
87 88 88 89 93 93
Záložní MX Transportní mapy Brána pro příchozí poštu Předávání odeslané pošty UUCP, fax a další doručování
10. E-mailové konference
75 75 76 78 81 82
Způsoby doručování Formáty úložiště zpráv Místní doručování POP a IMAP Protokol LMTP (Local Mail Transfer Protocol)
8. Hosting více domén
57
..................................................................
Povaha spamu Problém spamu Otevřené systémy (Open Relays) Detekce spamu Nastavení Postfixu Pravidla pro detekci klienta Kontrola obsahu Upravené třídy omezení Příklad nastavení Postfixu proti spamu
11O 111 115
123 1 23 1 24 1 24 1 25 1 28 1 28 1 41 1 44 1 45
1 2. Ověřování SASL
1 47
...........................................................................................
Seznámení se SASL Postfix a SASL Nastavení Postfixu pro SASL Testování nastavení ověřování Ověřování klienta SMTP
1 3. TLS (Transport Layer Security)
1 48 1 50 1 50 1 55 1 57 ...................................................................
1 59 1 59 161
Postfix a TLS Certifikáty TLS
1 4. Filtrování obsahu
.........................................................................................
1 69
Filtrování založené na příkazech Filtrování založené na démonu Další informace
1 5. Externí databáze
1 70 1 72 1 76
...........................................................................................
1 77
MySQL LDAP
1 78 1 83
A. Konfigurační parametry B. Příkazy Postfixu
...............................................................................
211
.............................................................................................
C. Kompilace a instalace Postfixu D. Často kladené dotazy
Rejstřík
1 87
...................................................................
213
...................................................................................
226
.....................................................................................................................
231
J sem vždy ohromen, když přemýšlím o původních návrhářích technologií internetu. Byli (a mnozí stále j sou) úžasnou skupinou lidí, kteří vyvíjeli software a technologie pro síť, která byla ve srovnání s dneškem nepatrná. Výsledky jejich práce fungují i v nejen mnohem větším, ale také ve velmi odlišném prostředí. Rozšíření nebylo zcela bezbo lestné, ale to nezmenšuje tento úžasný výkon. Sendmail je příkladem jedné z dávných technologií, které byly napsány pro jiný svět, a která je stále relevantní a používaná pro doručování velké části dnešní pošty. Postfix má tu výhodu, že byl postaven na základě znalostí měřítka a nepřátelského prostředí, kterému musí čelit. Ve skutečnosti bylo jeho vytvoření motivováno potřebou překonání některých problémů software napsaného v mnohem bezpečnější době. Nejprve j sem začal používat Postfix při práci se systémy v prostředí náročném na za bezpečení. Příslib vyšší flexibility a vyššího zabezpečení mě hned zaujal. A nebyl jsem zklamán. Netrvalo dlouho a zapojil jsem se a dal j sem přednost Postfixu. Tato kniha je mým pokusem o vytvoření referenční příručky a návodu k pochopení toho, jak Postfix funguje. Jejím hlavním cílem je vysvětlení podrobností a konceptů na pozadí Postfixu. Také nabízí instrukce pro provedení mnoha specifických úloh. Dokumentování software, který je stále aktivně vyvíjen, je tak trochu jako pokusem o zastavení tekoucí vody. Tato kniha bude proto nekompletní ještě dříve než bude vydána. Pokusil j sem se strukturovat informace v této knize tak, abych vypustil věci, které by se mohly stát rychle irelevantními nebo zastaralými, aby kniha obsahovala po co nejdelší dobu hodnotné informace. Samozřejmě můžete tyto informace doplňovat o online dokumentaci, webové stránky a e-mailovou konferenci Postfixu.
Audience Postfix je sít'ovou aplikací napsanou pro systém Unix. Čím více budete vědět o sítích a Unixu, tím lépe budete vybaveni pro správu Postfixu. Tato kniha se pokouší vysvětlit věci tak, aby byly pochopitelné i pro nové uživatele Unixu, ale je nerealistické si myslet, že byste se naučili spravovat Postfix bez znalosti (nebo alespoň získávání znalosti) systémů Unix. Tato kniha se zaměřuje na samotný Postfix. Další koncepty jsou vysvětleny jen
pro pochopení funkcí a konfigurace Postfixu. Pokud jste nováčky v Unixu, určitě byste si měli opatřit i jiné informace o Unixu. Výbornou volbou je kniha Unix System Adrni nistration Handbook, kterou napsal Evi Nemeth, et al. (prentice-Hall) a která obsahuje užitečnou část o elektronické poště. Užitečné mohou být napřfklad také dokumenty RFC zmíněné v této knize.
Organizace knihy Kapitoly 1 až 3 poskytují základní informace o Postfixu a elektronické poště, kapito ly 4 až 7 se zabývají obecnými aspekty provozu Postfixu a kapitoly 8 až 1 5 popisují konkrétní témata, která můžete a nemusíte potřebovat - podle toho, jak používáte Postfix:
Kapitola
1
Představuje Postfix a některé obecné koncepty elektronické pošty. Také se zabývá některými věcmi návrhu, které vedly k vytvoření Postfixu.
Kapitola 2 Zahrnuje témata potřebná pro pochopení ostatních konceptů uvedených v této knize. Kdokoliv se znalostí základů Unixu a elektronické pošty může tuto kapitolu bezpečně vynechat.
Kapitola 3 Vysvětluje části modulární architektury Postfixu a to, jak Postfix zpracovává elek tronické zprávy.
Kapitola 4 Obsahuje velké množstvi témat pro nastavování a správu serveru s Postfixem.
Kapitola 5 Vysvětluje, jak funguje správce fronty Postfixu a uvádí nástroje používané pro práci s frontou.
Kapitola 6 Popisuje používání DNS pro směrování e-mailových zpráv. Uvádí ohledy pro na stavování DNS tak, aby pracovalo s Postfixem.
Kapitola 7 Popisuje, jak Postfix provádí místní doručování a jak spolupracuje se servery POP a lMAP.
Kapitola 8 Se zabývá použitím Postfixu pro příjem pošty pro virtuální domény.
Kapitola 9 Popisuje práci Postfixu jako systému pro předávání pošty nebo poštovní brány.
Kapitola
10
Popisuje nastavování e-mailových konferencí v Postfixu a používánÚTI Postfixu ve spo jení se správci konferencí (MlM). Obsahuje příklady pro Majordomo a Mailman.
Kapitola
11
Tato kapitola se zabývá nástroji Postfixu pro blokování nevyžádané pošty.
Kapitola
12
Popisuje používání knihoven SASL pro ověřování SMTP pro klienty pro předávání zpráv prostřednictvím vašeho serveru s Postfixem.
Kapitola
13
Zabývá se použitím TLS pro zajištění šifrované komunikace mezi klienty a vaším serverem PostflX.
Kapitola
14
Popisuje externí f1ltry obsahu.
Kapitola
15
Seznamuje s používánÚTI externích datových zdrojů pro vyhledávací tabulky Postfixu.
PfílohaA Obsahuje abecední seznam konfiguračních parametrů Postfixu.
Pfí/oha B Obsahuje seznam nástrojů pro příkazový řádek, které jsou obsaženy v Postfixu, s krátkými popisy.
Příloha C Se zabývá kompilací a instalací Postfixu ze zdrojových souborů.
Příloha D Obsahuje seznam často kladených otázek o Postfixu.
Konvence používané v této knize Položky objevující se v této knize jsou někdy zdůrazněné jejich odlišením od běž ného textu. Zde je jejich popis:
Knrziva Je používána pro příkazy, e-mailové adresy, URl, názvy souborů, zdůrazněný text, první uvedení termínů a citace z knih a článků. Písmo Courier New
Se používá pro literály, konstantní hodnoty, V)'Pisy kódu a XML. Kurzivní písmo Courier New
Se používá pro nahraditelné názvy parametrů a proměnných.
Tučné
písmo Couríer Ne.
Používá se pro zdůraznění části výpisu kódu . . ...
II ..
[TI, ......:
:"
Tyto ikony označují tip, doporučení nebo obecnou poznámku. . .,�
Tyto ikony označují varování nebo upozornění.
Komentáře a dotazy Komentáře a dotazy týkající se této knihy prosím adresujte vydavateli: O'Reilly & Associates, Inc. 1 005 Gravenstein Highway North Sebastopol, CA 95472 (800) 998-9938 (in the United States or Canada) (107) 829-05 1 5 (international or local) (107) 829-0 1 04 (fax) O'Reilly udržuje webovou stránku pro tuto knihu, která obsahuje errata, příklady a případné další informace. Tato stránka je k dispozici na adrese:
http://www. oreil/y.com/catalog/postftx/ Komentáře nebo dotazy ohledně této knihy posílejte na adresu:
bookquestionS@oreil/y.com Více informací o knihách vydavatelství O'Reilly, konferencích, zdrojích informací a O'Reilly Network najdete na webu O'Reilly na adrese:
http://www. oreil/y.com/
Poděkování Můj dík si samozřejmě v první řadě zaslouží Wietse Venema za Postfix, ale také za mnoho příspěvků internetové komunitě. Díky cti spolupracovat s ním při vytváření této knihy je mi jasné, že věnuje stejnou pozornost všem detailům. Tato kniha značně čerpala z jeho příspěvků. Vždy jsem obdivoval O'Reilly & Associates jako společnost. Po zkušenosti se spoluprací s nimi můj obdiv přinejmenším neklesl. Můj redaktor, Andy Oram, perfektně zosob ňuje cíle společnosti. Rád jsem s ním diskutoval a jeho komentáře byly vždy užitečné. Oceňuji jeho enormní trpělivost. Lenny Muellner mi pomohl s nástroji pro zpracování textu a rád bych poděkoval Davidu Chu za jeho pomoc kdykoliv jsem ji potřeboval. Také bych rád poděkoval Robertu Romano za zpracování mých hrubých náčrtků do
profesionálních obrázků, které najdete v této knize, a Regovi Aubry za provedení této knihy redakčním procesem. Spolupracoval jsem s několika odbornými korektory, kteří mi pomáhali nejen opravovat detaily, ale také často nabídli užitečná doporučení ke stylizování textu. Mé díky patří Robu Dinoff, Vikto!u Dukhovni (a.k.a. Victor Duchovni), Lutzu Janicke, a Alanu Schwartz. Přál bych si mít takový tým hledící mi přes rameno při všem, co dělám. Také bych rád poděkoval mnoha členům konference
[email protected]. Je to aktivní konference s malým obsahem irelevantních informací, používaná velmi schopný mi lidmi. Její členové pomáhají nejen uživatelské komunitě, ale přispěli svými komentáři k vývoji samotného Postfixu. Nakonec jsem velkým dlužní'kem mé ženy a prvního korektora, Jackie. Podrobila pun tičkářskému testování mé počáteční návrhy. Tato kniha byla značně vylepšena díky její trpělivosti a hodnotnému přispění.
KAPITOLA 1
Úvod
Historie internetové elektronické pošty Ce-mailu) sahá až d o počátků 70. let minulého století, kdy docházelo k odesílání prvních zpráv přes síť Arpanet, což je předchůdce dnešního internetu. Od té doby je e-mail nejpoužívanější aplikací na internetu. Kdysi bylo doručování elektronické pošty relativně jednoduché a obvykle sestávalo z pře sunování malých poštovních souborů z jednoho velkého hostitele na jiného velkého hostitele, který sloužil mnoha uživatelům. Jak se internet vyvíjel a síť samotná byla stále složitější, byly zapotřebí pro přesun pošty mezi různými sítěmi a různými typy sítí stále flexibilnější nástroje. Balíček Sendmail, uvedený na počátku 80. let, měl za úkol vyrovnat se s mnoha odlišnostmi mezi jednotlivými poštovními systémy. Rychle převzal dominantní roli v doručování pošty na internetu. V současné době používá většina internetových sídel k odesílání a příjmu poštovních zpráv poštovní protokol SMTP. Sendmail je stále jedním z nejpoužívanějších serverů SMTP, trpí však také určitými problémy. Jeho monolitická architektura je zásadním zdrojem řady potíží se zabezpečením a jeho konfigurace a správa může být rovněž obtížná. Systém Postfix byl od samého počátku vyvíjen s tím záměrem, že nahradí převládající Sendmail. Jeho návrh odstraňuje řadu zdrojů bezpečnostních potíží. Postfix také elimi nuje většinu složitostí, které doprovázejí správu instalace Sendmailu. Správa Postfixu je řízena dvěma konfiguračními soubory a Postfix je již od základů vytvořen tak, aby se rozumným způsobem vyrovnal se všemi neočekávanými hardwarovými a softwarovými problémy.
Původ a filosofie Postfixu Postfix napsal Wietse Venema, který je znám zejména díky svým bezpečnostním nástro jům a dokumentům popisujícím zabezpečení. Program byl zpřístupněn jako software s otevřeným zdrojovým kódem v prosinci roku 1 998. Původní uvedení sponzorovala firma IBM Research, která podporuje i jeho neustálý vývoj . (IBM označuje tento balí ček za Secure Mailer.) Již na počátku byly stanoveny určité cíle, jež řídily návrh a vývoj Postfixu:
Spolehlivost Postf1x prokazuje svou skutečnou hodnotu zejména při práci ve vysokém zatížení. Dokonce i v jednoduchých prostředích se může software setkat s neočekávanými výjimkami. Mnoho softwarových systémů se například chová nepředvídatelně, když jim dojde paměť nebo diskový prostor. Postf1x detekuje takové podmínky a namísto zhoršení ptoblému nabídne systému možnost vzpamatovat se. Bez ohledu na různá rizika, kterým je vystaven, se Postf1x všemožnými způsoby snaží fungovat stabilně a spolehlivě.
Zabei/lečení Postf1x předpokládá, že běží v nepřátelském prostředí. K ochraně proti útočníkům zavádí několik obranných vrstev. Celým systémem Postf1xu prostupuje bezpečnost ní princip nejmenších oprávnění, takže každý proces, který může běžet izolovaně, běží s nejnižší sadou oprávnění neboli privilegií, jež skutečně potřebuje. Procesy běžící s vyššími oprávněními nikdy nedůvěřují neprivilegovaným procesům. Podob ně platí, že nepotřebné moduly lze deaktivovat, což vede ke zvýšení zabezpečení a zjednodušení instalace.
vykon Postf1x byl vytvořen s ohledem na dosažení vysokého výkonu. Ve skutečnosti musí činit určité kroky zajišťující, že jeho rychlost nezahltí jiné systémy. Speciálními tech nikami limituje jak počet nových procesů, které je nutné vytvořit, tak i počet přístupů k systému souborů, jež jsou zapotřebí v rámci zpracovávání zpráv.
Flexibilita Systém Postfix je tvořen několika různými programy a podsystémy. Tento přístup nabízí vysokou flexibilitu čili pružnost. Všechny součásti lze snadno dolaďovat prostřednictvím jednoduchých konfiguračních souborů.
Snadnépout/vání Postf1x je z hlediska nastavení a správy jedním z nejjednodušších balíčků pro zpracování elektronické pošty, protože pracuje s prostými konf1guračními soubory a jednoduchými vyhledávacími tabulkami zajišťujícími překlad adres a předávání zpráv. Základní princip nastavení Postf1xu lze označit za "nejmenší překvapení". To znamená, že Postf1x se do maximální možné míry chová právě tak, jak by vět šina lidí očekávala. Během rozhodování ve fázi návrhu se Dr. Venema přikláněl na tu stranu, která se zřejmě bude zdát většině lidí jako nejrozumnější.
Kompatibilita se Sendmailem Protože je kompatibilní se Sendmailem, může Postf1x jednoduše nahradit Sendmail, aniž by se v systému změny nějak dotkly uživatelů a aniž by došlo k narušení funkce aplikací, které jej využívají. Postf1x podporuje konvence Sendmailu jako letci aliases a soubory fonvard. Spustitelný program Sendmailu, sendmail, je nahrazen verzí Post f1xu, která podporuje téměř všechny původní argumenty přľkazového řádku, běží však ve spojení se systémem Postfix. I když vaše programy závislé na Sendmailu budou nadále fungovat, Postf1x byl vyvíjen nezávisle na Sendmailu a nemusí imple mentovat všechny prvky práce s elektronickou poštou stejným způsobem.
E-mail a internet Na rozdíl od mnoha proprietárních řešení elektronické pošty, kdy jediný softwarový balíček zajišťuje vše, je internetový e-mail sestaven z několika standardů a protokolů, které definují skladbu zpráv a jejich přenos od odesílatele k příjemci. Procesu se účastní mnoho různých softwarových součástí, přičemž každá se stará a jiný krok dodání zprávy. Postfix zajišťuje jen část celého tohoto procesu. Většina uživatelů elektronické pošty zná pouze software, který používá ke čtení a psaní zpráv. Ten se označuje za poftovního u�vatelského agenta (Mail User Agent - MUA). Příklady obvyklých agentů MUA jsou mutt, elm, Pine, Netscape Communicator a Outlook Express. Programy MUA jsou dobré pro čtení a psaní zpráv elektronické pošty, o dodání zpráv se však téměř nestarají. Právě zde nastupuje Postfix.
Součásti e-mailu Když řeknete MUA, aby odeslal nějakou zprávu, pak ji jen prostě předá poštovnímu ser veru, na kterém běží poštovní přenosový agent (Mail Transfer Agent - MTA). Obrázek 1 - 1 zachycuje komponenty, které se účastní jednoduchého vyslání e-mailu od odesílatele k příjemci. Agenti MTA Gako Postfix) mají na starosti veškerou práci s přesunem zprávy z jednoho systému na druhý. Když obdrží požadavek na příjem zprávy elektronické pošty, stanoví agent MTA, zda má danou zprávu přijmout nebo nikoli. MTA obvykle přijímá zprávy pro své vlastní lokální uživatele, pro jiné systémy, kterým umí zprávu předat, nebo zprávy od uživatelů, systémů či sítí, které mohou předávat poštu na jiné cíle. Jakmile daný MTA zprávu přijme, musí se rozhodnout, co s ní dále udělá. Může ji odeslat nějakému uživateli na svém systému, nebo ji může předat dál jinému agentovi MTA. Zprávy, určené pro jiné sítě, zřejmě projdou mnoha systémy. Nedokáže-li náš MTA zprávu doručit ani ji předat dále, odešle ji zpět původnímu odesílateli nebo na tuto skutečnost upozorní správce systému. Servery MTA obvykle spravují poskyto vatelé služeb internetu (Internet Service Provider - ISP) v případě jednotlivců, nebo podniková oddělení informačních systémů v případě zaměstnanců.
J c:p �
Odesnatel
I M;:
.......... ..
r-!a·§�!�··.1 �A � �
.
.
�.�
� I POP/:,IMAP L( IMAP ,,
.
.
•
...
r;;I �
Obrázek 1-1. fednodlldjprůchod iPrál!Y internetem
Zpráva nakonec dorazí na MTA, který je konečným cílem. Je-li zpráva je určena uži vateli na tomto systému, daný MTA ji předá agentovi doručení ifJrál!J (Message Delivery Agent - MDA), který zajistí její finální doručení. MDA si může zprávu uložit jako
prostý soubor, nebo ji může předat speciální databázi elektronické pošty. Termín
úloťiftl �ráv (Message Store) označuje nějaké trvalé úložiště zpráv a nezabývá se tím, jak konkrétně vypadá. Jakmile je zpráva umístěna do úložiště, zůstane tu, až dokud není příslušný příjemce připraven k jejímu vyzvednutí. Příjemce používá k převzetí zprávy a jejímu přečtení agenta MUA. -Tento agent kontaktuje server poskytující přístup k úložišti zpráv. Daný server je oddělen od MTA, který zprávu dodal, a je vytvořen specificky k zajišťování přístupu pro přebírání zpráv. Jakmile server žadatele úspěšně ověří, může zprávu tohoto uživatele odeslat jeho agentovi MUA. Protože internetové standardy jsou otevřené, existuje mnoho různých softwarových balíčků zpracování internetové elektronické pošty. Různé balíčky implementující tytéž protokoly mohou vzájemně spolupracovat bez ohledu na to, kdo je vytvořil, a na jakém typu systému běží. Budete-li sestavovat kompletní e-mailový systém, pak bude zřejmě software zpracovávající SMTP v jiném balíčku, než software zpracovávající POP /IMAP' Pro každý aspekt vašeho kompletního systému elektronické pošty existuje mnoho různých softwarových řešení.
Hlavní e-mailové protokoly Komunikace, k níž dochází mezi popisovanými komponentami e-mailového systému, je definována standardy a protokoly. Dokumenty standardů spravuje skupina Internet Engineering Task Force (lETF) a publikuje je jako Request For Comments (RFC - žá dost o komentář). To jsou číslované dokumenty vysvětlující určitou technologii nebo protokol. K odesílání zpráv se používá Simple Mail Transport Protocol (SMTP - jednoduchý protokol přenášení pošty), zatímco k jejich příjmu slouží Post Offtce Protocol (pOP poštovní protokol) nebo Internet Mail Application Protocol (lMAP - protokol aplikace internetové pošty). SMTP, definovaný v RFC 2821, popisuje konverzaci, k níž dochází mezi dvěma hostiteli na síti při výměně e-mailových zpráv. Protokoly lMAP (RFC 2060) a POP (RFC 1939) popisují, jak přebírat zprávy z úložiště zpráv. Protokol lMAP byl vyvinut až po protokolu POP a nabízí doplňkové funkce. V obou případech zůstávají na centrálním serveru zprávy elektronické pošty pro uživatele, kteří si je obvykle přes síť přebírají. Není nutné, aby MUA používal pro POP /IMAP stejný systém jako pro SMTP. Právě proto je zapotřebí na klientech elektronické pošty nakonfigurovat samostatně POP / lMAP a SMTP. Poskytovatel může nabízet svým klientům jiné servery pro každou funkci a podnikoví uživatelé, kteří jsou mimo kancelář, si často stahují zprávy z podni kového serveru POP /IMAP, přičemž ale k odesílání zpráv používají server SMTP nebo vytáčené připojení k ISP. Software MTA, běžící na serverech SMTP, neustále naslouchá požadavkům na příjem zpráv. Tyto požadavky mohou přijít od agentů MUA nebo jiných serverů MTA.
SMTP a předávání elektronické pošty SMTP se běžně používá k odesílání zpráv a jejich předávání mezi agenty MTA. Když nějaký MUA kontaktuje MTA a požaduje dodání zprávy, používá protokol SMTP. SMTP se také použije, když jeden MTA kontaktuje druhého MTA a chce mu předat zprávu. Protokol SMTP původně neobsahoval prostředky ověření uživatelů, jeho rozšíření však v případě nutnosti mohou tuto schopnost zajistit. Další informace o ověřování (auten tikovám) uživatelů SMTP najdete v sedmé kapitole.
POPil MAP a přístup k poštovní schránce Když si chtějí uživatelé stáhnout zprávy, použijí svého agenta MUA, který se připojí k ser veru POP nebo lMAP a vše pro ně zajistí. Uživatelé POP obvykle převezmou ze serveru všechny zprávy a pak s nimi pracují místně. lMAP nabízí prvky, které usnadňují správu pošty přímo na serveru. (Další informace o používání Postfixu ve spojení se servery POP a lMAP najdete ve dvanácté kapitole.) Mnoho serverů nyní nabízí oba protokoly, takže je budu společně označovat za servery POP /IMAP. Protokoly POP a lMAP nemají nic společného s odesíláním e-mailu. Zabývají se výhradně tím, jak uživatelé přebírají již dříve doručené a uložené zprávy. Ne všichni uživatelé potřebují přístup POP /IMAP k úložišti zpráv. Kupřľkladu uživatelé s přístupem k prostředí unixového počítače mohou mít své agenty MUA nakonfigu rované tak, že čtou elektronickou poštu přímo z poštovního souboru, který se nachází na témže stroji.
Role Postfixu Postfix je agent MTA; zpracovává předávání zpráv mezi servery a lokálně v rámci sys tému. Nezajišťuje komunikace POP ani lMAP. Obrázek 1 -2 představuje jednoduchý příklad odesílání zprávy, kdy má Postfix zodpo vědnost MTA a za místní doručení. Jako agent MTA Postfix přijímá a odesílá zprávy elektronické pošty přes síť protokolem SMTP. V případě místruno dodání může lokální agent Postfixu vkládat zprávy přímo do úložiště zpráv nebo je předávat specializovanému agentovi doručení pošty. Příklad ukazuje Postfix jako sever SMTP na obou koncích e-mailové transakce; jelikož ale Postfix vychází z internetových standardů, může být druhým serverem elektronic ké pošty našeho příkladu jakýkoli jiný server naplňující tytéž standardy. Postfix může komunikovat s jiným serverem hovořícím protokolem SMTP (a dokonce i některými dalšími, které SMTP tak dobře nezvládajD. V našem případě chce Heloisa odeslat zprávu Abélardovi ze své adresy (
[email protected]) na jeho adresu (
[email protected]). Heloi sa použije k sestavení zprávy svého klienta elektronické pošty, který ji následně předá agentovi MTA (prostřednictvím SMTP). Zde je jejím MTA server Postfix umožňující předávání zpráv. Po příjmu zprávy od poštovmno klienta Heloisa stanoví server Postfix podle Abélardovy e-mailové adresy, kam je zapotřebí zprávu odeslat. S V}"lžitím DNS
polnll prlllmel PolHlI odnnl'lla
PoIIovof servlr
PoIIovof IIlVIr
.
. ... . . ..... ............... ....... .. ....... . . ......... . ..... .
:. ......... �.................... •
"--�....
Slrvar DNS
I··· · · · · · · · · · · · · ·J
Obrázek 1-2. Pfi/eJad dorulení e-mailové :@ráty v síti
(další informace o DNS a e-mailu najdete v šesté kapitole) zjistí, který server SMTP by měl přijímat zprávy pro Abélardovu doménu (post6x.org) a tento server kontaktuje (pomocí SMTP). Abélardův server Post6x zprávu přijme a uloží ji až do okamžiku, než bude Abélard připraven k jejímu vyzvednutí. V tomto okamžiku práce Post6xu končí. Jakmile je Abélard připraven převzít své zprávy, jeho klient elektronické pošty převezme protokolem POP nebo lMAP zprávu od Heloisy. Náš příklad vypouští podrobnosti komplikovaných úkolů doručování počty Post6xem. V případě zpráv s více příjemci musí Post6x zjistit, kam odeslat kopie pro jednotlivé adresáty. Pokud nemohou nějací příjemci zprávu přijmout kvůli problému se sítí nebo systémem, musí Post6x zprávu zařadit do fronty a periodicky se pokoušet o její odeslání. Z hlediska uživatele je operace Post6xu téměř neviditelná. Z hlediska internetových poš tovních systémů zajišťuje Post6x většinu aspektů doručení zprávy elektronické pošty.
Zabezpečení Postfixu E-mailové systémy jsou pochopitelně vystavené útokům, protože už samotný princip jejich činnosti vyžaduje příjem dat z nedůvěryhodných systémů. Je poměrně obtížné vybudovat systémy, které odolají útoku, a každá dobrá strategie zabezpečení bude za hrnovat více ochranných vrstev. To platí především pro veřejné systémy a potenciálně nepřátelské prostředí. Post6x řeší zabezpečení aktivním a vícevrstvým přístupem. Již samotná architektura Post6xu omezuje nebezpečnost zranitelných míst pro případ, kdyby byly odhaleny chyby návrhu nebo kódu, jež by v monolitickém programu mohly vytvářet velmi citlivá místa.
Modulární návrh Modulární architektura Post6xu tvoří základ většiny jeho zabezpečení. Každý proces Post6xu běží s minimálními oprávněními nezbytnými k naplnění své úlohy. Mnoho bez-
pečnostních potíží Sendmailu mělo velmi nepříjemné dopady, protože systém Sendmail běžel většinou jako privilegovaný proces. Postfix pracuje s minimálním množství privi legií potřebných ke splnění určitého úkolu. Procesy Postfixu, které na systému nejsou zapotřebí, lze vypnout, takže je vůbec nebude možné zneužít. Kupříkladu systém se síťovým firewallem, jenž jen předává poštu a nepoužívá místní doručování, může mít vypnuté všechny postfixové komponenty lokálního doručování zpráv. Procesy Postfixu jsou vzájemně izolované a jen minimálně využívají meziprocesní komunikaci. Každý proces si sám zjišťuje to, co potřebuje vědět.
Prostředí a procesy Ve většině případů nevyžaduje doručování pošty unixový proces prostředí, když jej však konfigurace používá, Postfix informace před jejich umístěním do proměnných prostředí "desinfikuje". Postfix se pokouší odstranit všechny škodlivé znaky, které mohou mít pro prostředí zvláštní význam, a teprve potom údaje prostředí zpřístupňuje. Většinu procesů Postfixu vykonává důvěryhodný řídící démon. Neběží jako uživatelské podřízené procesy, takže j sou imunní vůči bezpečnostním potížím vyplývajícím z dě dičných vztahů nadřazený-podřazený a komunikací. Tyto útoky, které používají signály, sdtlenou paměť, otevřené soubory a další typy meziprocesní komunikace, jsou vůči Postfix v zásadě bezmocné.
Zabezpečení v samotném návrhu Dalším obvyklým typem útoku na aplikace j e přetečení bufferu (vyrovnávací paměti) . Při tomto typu útoku dosahují crackeři toho, že program zapisuje do oblasti paměti, kam by neměl zasahovat. To jim může umožnit změnit cestu vykonávání a převzít tak řízení procesu. Již jsem zmínil, že procesy Postfixu běží s minimem oprávnění, takže ani takový útok by se daleko nedostal; navíc se Postfix snaží nepoužívat buffery s pevnou velikostí pro dynamická data, takže úspěšný útok přetečením bufferu je velmi neprav děpodobný. Důležitou bezpečnostní ochranou na systémech Unix je schopnost měnit kořenový adresář aplikací (chrool). Tímto způsobem se stanovuje nový kořenový adresář běžící aplikace, například Ivar I spool /postfix. Když pak takový program běží, jeho pohled na systém souborů je omezený na strom pod Ivarlspool /postfix a nic nad tímto bodem nemůže pozorovat. Kritické systémové adresáře ani ostatní programy zneužitelné při útoku nejsou přístupné. V Postfixu je velmi jednoduché zařídit, aby jeho procesy běžely v rámci změněného kořenového adresáře (více si o tomto tématu povíme ve čtvrté ka pitole) . Když takový běh zadáte, bude Postfix vykonáván odděleně. I kdyby tedy došlo nějakým způsobem k rozvrácení ochran Postfixu, útočník si tím nezpřístupní mnohé z metod, které obvykle využívá ke kompromitování systému. Jelikož je Postfix navržen pro práci při velkém zatížení, jsou útoky odepřením služby (Denial-of-Service - DOS) mnohem méně efektivní. Dojde-li systému diskový prostor nebo paměť kvůli útoku DOS nebo díky jinému typu problému, pak se Postfix snaží
situaci nekomplikovat. Upustí od toho, co se snažil učinit, a umožní tak systému vzpa matovat se. Procesy Postfixu jsou nastaveny na práci s omezeným množstvím paměti, takže pod návalem zpráv v žádném případě nekontrolovatelně nerostou. Obtížnost plánování zabezpečení je v tom, že nikdy nevíte, jaký bude následující útok ani jak bude veden. Postfix je vytvořen tak, aby si dokázal poradit s nepříznivými podmínkami; ať už je jejich příčinou cokoli. Jeho vestavěná robustnost je zásadním faktorem ovlivňujícím stupeň zabezpečení zajišťovaný Postfixem. Dr. Venema řekl, že se ani tolik nestará o zabezpečení, jako jej zajímá vytváření softwaru, který funguje zamýšleným způsobem bez ohledu na okolní podmínky. Zabezpečení je jen přínosným vedlejším efektem.
Další informace o získání Postfixu Více informací o Postfixu získáte na oficiálním webovém sídle, domovské stránce Postftxu (http://www.postftx.org/) . Toto sídlo obsahuje zdrojový kód, dokumentaci, odkazy na doplňkový software, články a další informace o Postfixu. Najdete tu rovněž informa ce o přihlášení do aktivní e-mailové konference, v níž se diskutují všechny aspekty Postfixu. Nemáte-li zatím kopii Postfixu, můžete si stáhnout zdrojový kód z webového sídla Postfixu. Je však docela pravděpodobné, že tu najdete i předkompilovaný balíček pro vaši platformu, jehož použití může být pohodlnější. V takovém případě si obstarejte balíček Postfixu pro svůj operační systém a k jeho instalaci a konfiguraci využijte nor mální systémové nástroje. Při shánění softwaru pro svůj systém se podívejte na běžné používané servery s aplikacemi. Existuje mnoho dobrých důvodů, proč si sestavit Postfix vlastními silami: Nemusí exis tovat připravený balíček pro vaši platformu, nemusíte tvůrci balíčku důvěřovat v tom ohledu, že učinil pro vaše prostředí vše naprosto správně, můžete požadovat podporu doplňků, které v balíčku obsaženy nejsou, můžete potřebovat aktuálnější verzi, než je nabízena v balíčcích, nebo si prostě jen rádi aplikace sestavujete sami. Máte-li zkušenosti s kompilováním softwaru, nebudete mít se sestavením Postfixu žádné potíže. Rozhodně patří z hlediska kompilace mezi jednodušší balíčky otevřeného zdrojového kódu. Webové sídlo Postfixu obsahuje odkaz ke stažení, který zobrazuje seznam zrcadel, z nichž si můžete software nahrát. Měli byste použít zrcadlo, které je k vám nejblíže. Postfix je k dispozici bud' jako balíček Official Release (oficiální verze), nebo jako balíček Experi mental Release (experimentální verze). I když je označena za experimentální, její kód je v každém případě velmi stabilní. Experimentální verze obsahují nové funkce, které se před převodem na oficiální mohou změnit. Některé nové prvky jsou nabízené pouze v experimentální verzi, klidně je ale můžete používat. Jenom pamatujte, že se mohou v dalších verzích mírně vyvíjet, než budou jejich funkce natolik stabilní, že se stanou součástí oficiální verze. Žádný software Postfixu není uvolněn, dokud neprojde roz sáhlým testováním a zkoumáním. Přečtěte si soubor RELEASE_NOTES (poznámky k verzi), který je součástí balíčku. Dozvíte se, jaké jsou rozdíly mezi aktuální oficiální a experimentální verzí.
KAPITOLA 2
Předpoklady
Tato kapitola seznamuje s některými základními koncepty Unixu a elektronické pošty, které potřebujete pro sledování výkladu a příkladů uvedených dále v této knize. Pokud již máte nějaké zkušenosti se správou elektronické pošty, můžete tento materiál pře skočit a přejít k další kapitole. Tato kapitola neobsahuje systematické nebo komplexní informace o elektronické poště nebo systému Unix. Obě témata zahrnují nesmírné množství informací. Tato kapitola obsahuje pouze přehled položek, které jsou podrobně vysvětlovány dále v této knize.
Témata o systému Unix Č ím lépe budete znát systém Unix, tím lepším správcem serveru Postfix budete. Po stfix je unixový program spolupracující při vykonávání funkcí s operačním systémem, na kterém je nainstalován. Pokud se s operačním systémem Unix teprve seznamujete, měli byste si prostudovat úvodní text. Tato část vám mezitím představí některé základní koncepty, které budete potřebovat pro pochopení dalšího výkladu v této knize.
Přihlašovací jména a čísla UID Seznam uživatelů známých systému je uložen v souboru / ctc/passwd. Každý uživatel by měl mit unikátní přihlašovací jméno a číselný identifikátor uživatele (obecně zapisovaný jako uid nebo UlD) . Identifikátor UID, nikoliv přihlašovací jméno uživatele, je důleži tým atributem pro kontrolu identity a vlastnictví. Přihlašovací jméno je konvenční pro lidi a systém je používá zejména pro zjištění identifikátoru UID. Některé konfigurační parametry Postfixu vyžadují při odkazech na uživatelské účty UID namísto přihlašo vacího jména. Postfix někdy přijímá identitu různých uživatelů. Procesu je řečeno, aby použil práva daného účtu, když má předstírat jeho identitu.
Pseudoúčty Pseudoúčet je normálrú účet systému Unix s tím rozdílem, že neumožňuje přihlášení. Tyto účty se používají pro provádění úkolů správy nebo pro spouštění programů s určitými právy. Váš systém je s největší pravděpodobností nainstalován s několika pseudoúčty. Č asté jsou názvy účtů jako například bin a démon. Tyto účty obvykle brání v přihlášení pomocí neplatného hesla a neexistujících domovských adresářů a shellu. Pro správu PostflXu potřebujete alespoň jeden pseudoúčet, pod kterým procesy Postfixu poběží. Možná budete potřebovat další pro jiné funkce, jako například programy pro e-mailové konference a fJltry.
Standardní vstup a výstup Téměř všechny procesy v systému Unix mají při spuštění standardní vstup a stan dardní výstup. Č tou data ze standardního vstupu a zapisují data na standardní výstup. Standardním vstupem je obvykle klávesnice a standardním výstupem je obvykle mo nitor a uživatelé takto pracují se spuštěnými programy. Standardní vstup a výstup je možno přesměrovat a programy pak mohou vstup přijímat od jiných procesů nebo ze souboru nebo výstup předávat do jiného procesu nebo do souboru. Takto pracují často programy prováděné v systémových skriptech. Pro účely elektronické pošty byste si měli být vědomi standardního vstupu a výstupu, protože váš poštovní systém možná bude muset spolupracovat s jinými programy pomocí jejich standardrubo vstupu a výstupu. Například program pro fJltrování elektronické pošty může přijímat obsah elektronické zprávy na svém standardním vstupu standard a zkontrolovaný obsah zapisovat na svůj standardní výstup. Programy mají obvykle také standardní chybový výstup, kterým je podobně jako v případě standardrubo výstupu monitor uživatele, ale který může být také přesměrován. Standardní vstup, výstup a chybo vý výstup j sou často zapisovány jako stdin, stdout a stderr. Více informací najdete v knihách s úvodem do systému Unix.
Superuživatel Pro provádění správy systému Unix je používán účet root. Také bývá označován za účet superuživatele a měli byste s ním zacházet opatrně. Jako uživatel root byste se měli přihlašovat pouze v případě, že potřebujete jeho práva pro konkrétní úlohu. Správa Postfixu někdy vyžaduje práva uživatele root. Pokud nemáte superuživatelský přístup do systému, nemůžete provádět správu PostflXU.
Příkazový řádek Když pracujete s interaktivním shellem, normálně vás uvítá příkazový řádek, který oznamuje, že je systém připraven pro zadávání příkazů. Podle dohod obsahují příkazové řádky uživatelů znaky $ nebo %, zatímco příkazový řádek uživatele root obsahuje znak #. Účet uživatele root byste měli používat pouze pokud je to nezbytné. V příkladech
uváděných v této knize je přľkazový řádek běžného uživatele zobrazován jako $ a přľ kazový řádek uživatele root jako #. Pokud je v příkladu uveden znak #, víte, že musíte příkaz provést jako root.
Dlouhé řádky Obvykle se v systému Unix dlouhé přľkazy rozdělují do více řádků pomocí zpětného lomítka (\) na konci řádku, což indikuje, že dva nebo více řádků pokračují jako by se jednalo o jediný řádek. Pokračování pomocí zpětného lomítka může být použito na příkazovém řádku a v systémových skriptech a běžně se používá v konfiguračních sou borech (ale ne v konfiguračních souborech Postfixu - viz kapitola 4) . V této knize řádky, které se nevejdou na stránku, pokračují pomocí zpětných lomítek. Až budete procházet přľklady, budete moci zapisovat řádky přesně tak, jak jsou uváděny se zpětnými lomítky, nebo jednoduše spojit pokračující řádky do jednoho.
Manuálové stránky Dokumentace pro systémy Unix je udržována v dokumentaci známé jako manuálové strán�. Dokumentaci ke konkrétní položce si můžete přečíst po provedení přľkazu man s položkou předanou jako parametr. Pro přečtení dokumentace k příkazu rnailq například jednoduše napíšete: $ man mailq
Na obrazovce se objeví popis tohoto příkazu rozdělený na stránky. Pomocí mezerníku můžete procházet informace po stránkách. Manuálové stránky mají standardní strukturu obsahující syntaxi přľkazu, všechny volby a popis chování a další souvislosti. Některé uživatele manuálové stránky odrazují, ale prokážete sami sobe velkou službu, když se s nimi seznámíte. Všechny přľkazy systému Unix a Postfixu, stejně jako mnoho jiných funkcí, jsou zdokumentovány v manuálových stránkách. Více informací o manuálových stránkách najdete v úvodní dokumentaci systému Unix.
Témata týkající se e-mailů Internetová elektronická pošta j e složité téma s mnoha aspekty. Existují důležité principy používané při správě poštovního systému bez ohledu na MrA, se kterým pracujete. Tato část popisuje několik konceptů, které pomohou pochopit pozdější vysvětlování v knize, ale musíte se také snažit dozvědět co nejvice informací o elektronické poště z dalších knih a zdrojů na internetu.
RFC Dokumenty RFC (Request for Comments) definují standardy internetu. Elektronické pošty se týká několik dokumentů RFC, které pro vás budou důležité při správě poštovního
systému na internetu. Dvěma nejčastěji uváděnými dokumenty RFC elektronickou poštu jsou RFC 821 a RFC 822, které se zabývají tím, jak jsou elektronické zprávy přenášeny mezi systémy a jak by měly zprávy elektronické pošty vypadat. Tyto dokumenty byly zave deny před více než 20 lety. V dubnu roku 2001 byly aktualizovány navrženými standardy RFC 2821 a RFC 2822, i když se setkáte ještě s mnoha odkazy na původní dokumenty. Dokumenty RFC jsou spravovány organizací Internet Engineering Task Force, jejíž web najdete na adrese http://www. ieif.org/.
Agenti elektronické pošty V kapitole 1 bylo představeno několik agentů elektronické pošty používaných mezi vytvořením zprávy a jejím konečným doručením. Tabulka 2- 1 obsahuje souhrn těchto agentů. Tabulka 2- 1. Agenti elektronicképošty Agent
Název
Účel
MUA
Mail User Agent
Klientský software pro elektronickou poštu určený pro vytváření, odesílání a přijímání zpráv elektronické pošty. Odesílá zprávy prostřednictvím MTA. Zprávy načítá z úložíště pošty bud přímo nebo skrze server POPil MAP.
MTA
Mail Transfer Agent
Server, který přijímá a doručuje elektronickou poštu. Určuje směrování zprávy a možné přepsání adresy. Lokálně doručované zprávy jsou předány MDA pro jejich konečné doručen i.
MDA
Mail Delivery Agent
Program, který provádí konečné doručení zpráv pro místní příjemce systému. MDA zprávy při doručování často filtrují nebo zařazují do kategorii. MDA může také určovat, zda má být zpráva předána na jinou e-mailovou adresu.
Postmaster
Správce elektronické pošty je obvykle označován jako pos/master. Člověk s pověřením postmastera kromě jiného zajišťuje správnou funkci poštovruno systému, provádí změny v konfiguraci a přidává nebo odstraňuje e-mailové účty. Alias Pos/master musíte mít ve všech doménách a musí směrovat zprávy na konkrétní osobu nebo osoby. Dokument RFC 2 1 42 stanovuje, že je adresa postmas/er povinná.
Odmítnutí nebo odražení Pokud přijímající MTA zjistí v průběhu komunikace SMTP (viz Protokol SMTP dále v této kapitole), že zprávu nepřijme, odmítne ji. V tomto okamžiku by měl odesílající systém vygenerovat chybovou zprávu odeslanou původnímu odesílateli. Někdy MTA zprávu přijme a později zjistí, že nemůže být doručena - třeba proto, že daný příjemce neexistuje nebo je nějaký problém při konečném doručování. V takovém případě MTA, který přijal zprávu, ji odraiJ zpět k původnímu odesílateli zasláním chybové zprávy, obvykle obsahující důvod, proč původní zpráva nemohla být doručena.
Agent MTA, který přijme zprávu, přebírá zodpovědnost za zprávu dokud nebude doručena nebo předána jinému MTA. Když je systém zodpovědný za zprávu a nemůže ji doručit nebo předat dál, informuje odpovědný systém odesílatele, že je zpráva nedoručitelná.
Adresy obálky a záhlaví zpráv Pro mnoho uživatelů elektronické pošty je skutečnost, že adresa uvedená v To: v záhlaví elektronické zprávy nemá nic společného s tím, kam je zpráva skutečně doručena, nezná má. Doručení zprávy řídí adresa obálky. Když v praxi napíšete zprávu a předáte vašemu agentu MUA adresu To:, váš agent MUA použije stejnou adresu jako adresu obálky, což ale není vyžadováno a není to prováděno vždy. Z pohledu MTA jsou záhlaví zprávy součástí obsahu e-mailu. Doručení zprávy je určeno adresami předanými v průběhu komunikace SMTP. Tyto adresy jsou adresami obálk;y a jsou jedinou věcí, která určuje, kam budou zprávy přeneseny. Další informace najdete v části "Protokol SMTP" dále v této kapitole. E-mailové diskusní skupiny a nevyžádaná pošta j sou běžnými případy, kdy se cílová adresa obálky liší od adresy To: v záhlaví zprávy. Více informací najdete v dokumentech RFC 2821 a RFC 2822. Také se podívejte na část "Formát e-mailové zprávy" dále v této kapitole, kde najdete více informací o formátu elektronických zpráv. Podívejte se na relaci SMTP v přľkladu 2-2 a zkuste nahradit kteroukoliv adresu v poli To: v obsahu zprávy, abyste viděli, že nemá vliv na to, kam bude zpráva doručena.
Místní část e-mailových adres RFC 2822 popisuje formát e-mailových adres mnohem podrobněji. Udává, jak by měly věci jako používání uvozovek a komentárů fungovat v e-mailových adresách. Pokud vypustíme podrobnosti, skládá se e-mailová adresa obecně ze tří částí: místní části (kterou je obvykle jméno uživatele), oddělovače @ a nái}Ju domé'!J. Místní částí může být také alias na jinou adresu nebo na e-mailovou diskusní skupinu. Místní část je někdy označována jako levá strana Oefthand side, LHS) a doména je někdy označována jako pravá strana (righthand side,RHS) . Více informací najdete v dokumentu RFC 2822.
Formát e-mailové zprávy Jelikož dokument RFC 822 původně popisoval, jaký formát by měla mít zpráva elektronické pošty, j sou zprávy často uváděné jako "ve formátu RFC 822" nebo jako "zpráva RFC 822". Měli byste znát základy tohoto formátu, jelikož se na něj tato kniha odkazuje a pravděpodobně se s ním setkáte i jinde. Budu používat novější navržený standard a označovat jej jako "zprávy RFC 2822".
Zprávy RFC 2822 RFC 2822 udává formát e-mailových zpráv i e-mailových adres, které se používají v záhlaví zpráv (ale ne v adresách obálky) . Tato specifikace popisuje formát přenosu, ale mnoho implementací používá stejný nebo podobný formát i pro ukládání zpráv. Zpráva se skládá
ze dvou částí: Záhlaví a těla. Záhlaví obsahuje konkrétní pole s názvy jako např. To (komu), From (od) nebo Subject (předmět) následovanými dvojtečkou (:). Za dvojtečkou je obsah daného pole. Jedno pole záhlaví zprávy může zabírat více řádků. Pokračující řádky pole začínají mezerami nebo tabulátory, aby bylo zřejmé, že jsou pokračováním předchozího řádku. .
Dokument standardu obsahuje mnoho podrobností o polích záhlaví a k čemu by měla být používána. J sou zde pravidla, která udávají vztahy mezi poli a kdy musí být které pole použito, ale v nejjednodušším případě jsou jedinými povinnými poli Date: a From:. Standard také udává, jaká pole může konkrétní implementace elektronické pošty vytvářet pro vlastní potřebu. Pole záhlaví jsou oddělena od těla zprávy prázdným řádkem. Tělo zprávy obsahuje samotný obsah zprávy. Tělo zprávy má úmyslně volný formát, ale mělo by obsahovat pouze znaky ASCII. Některá definovaná záhlaví mají předepsanou strukturu, která je mnohem více restriktivní než tělo. Binární soubory, jako např. obrázky nebo spustitel né soubory, musí být nějakým způsobem převedeny na znaky ASCII, aby mohly být odeslány v souladu s tímto standardem. Převádění takových souborů pro jejich odeslání stanovují jiné standardy, jako např. kódování MIME nebo tradiční kódování uuencode. Příklad 2-1 ukazuje typickou zprávu se záhlavími a tělem. Pfíklad 2- 1. Formát �ráty Return-Path : < i n fo@ore i l l y . com> De l i vered-To : kdent@ma i l . example . com Received : from ma i l . orei l l y . com (ma i l . orei l l y . com [ 1 92 . 1 6 8 . 1 4 S . 3 4 J ) by ma i l . example . com ( Po s t f i x ) with SMTP id S FA2 6B3 DFE for
; Mon , 8 Apr 2 0 0 3 1 6 : 4 0 : 2 9 - 0 4 0 0 (EDT) Date : Mon , 8 Apr 2 0 0 3 1 5 : 3 8 : 2 1 - 0 5 0 0 From : Customer Servi c e To : < kdent @ example . com> Repl y-To : Me s s age - I D : < 0 1 a 4 e 2 2 3 8 2 0 0 8 4 2 @mai l . orei l l y . com> Subj ect : Have you read RFC 2 8 2 2 ? Thi s i s the start o f the body o f the me s sage . I t could conti nue for many l i ne s , but i t doe sn ' t .
Pole v tomto příkladu jsou většinou samovysvětlující. Záhlaví Received: není standar dem RFC 2822 vyžadováno, ale každý agent MTA, který zpracovává zprávu obvykle do zprávy doplňuje záhlaví Received:, jak je uvedeno v dokumentu RFC 282 1 , který je popsán v následující části.
Protokol SMTP Protokol SMTP je definován v dokumentu RFC 2821 . Tento protokol je ve skutečnosti docela jednoduchý a byl navržen tak, aby byl jednoduše srozumitelný pro lidi i počítače. Klient se připojuje k serveru SMTP, načež server začne komunikaci prostřednictvím protokolu SMTP, která se skládá ze série jednoduchých příkazů a odpovědí, včetně
přenosu e-mailu. Pro pochopení tohoto protokolu je nejlepší sledovat jej v akci. Po na stavení vašeho poštovního serveru si to můžete snadno vyzkoušet sami. Pomocí klienta Telnet se můžete vydávat za přenášejícího MTA. Přl1dad 2-2 ukazuje kroky a základní příkazy pro doručení zprávy. Pfík/ad 2-2. Doruéování e-mai/u $ telnet mail . example . com 25 Trying 1 0 . 2 3 2 . 4 5 . 1 5 1 Connected t o mai l . example . com . Escape character is
' A
]
' . '
2 2 0 ma i l . example . com ESMTP Postfix
HELO mail . oreilly . com
2 5 0 ma i l . orei l l y . com
MAIL FROM : 2 5 0 Ok RePT TO :
2 5 0 Ok
DATA 3 5 4 End data with .
Date : Mon , 8 Apr 2003 15 : 38 : 21 -0500 From : Customer Service To : Reply-To : <service@oreilly . com> Message-ID : <01a4e2238200842@mail . oreilly . com> Subject : Bave you read RFC 2822? This is the start of the body of the Dl8ssage . It could continue for many lines , but it doesn ' t . 2 5 0 Ok : queued a s 5 FA2 6B3 DFE
quit 2 2 1 Bye Connection closed by foreign host . $
Relace SMTP zobrazená v příkladu je ve skutečnosti přenos, který vyprodukoval vzoro vou zprávu z příkladu 2- 1 . Abyste si tento příklad mohli vyzkoušet sami, spusťte klienta Telnet a připojte se na port 25 poštovruno serveru maiLexample.com. Měli byste se připojit ke svému vlastnímu serveru Postflx a v adresách obálky psát své vlastní e-mailové adresy. Port 25 je známý port serverů SMTP. Po zprávách Telnetu: Trying 1 0 . 2 3 2 . 4 5 . 1 5 1 Connected t o localhost . Es cape character is
' A
]
' .
vás server vítá touto zprávou: 2 2 0 mai l . exampl e . com ESMTP Post fix
Odpovědi serveru SMTP, jako např. tato uvítací zpráva, vždy začínají tříčíselným kódem odpovědi, obvykle následovaným krátkou zprávou pro lidi. Tabulka 2-2 obsahuje úrovně kódů odpovědí a jejich význam. První číslice kódu odpovědi postačuje pro zjištění stavu
požadovaného příkazu. V dokumentaci jsou kódy odpovědí často zapisovány jako 2xx, což označuje úroveň odpovědi 200. Tabulko 2-2. Kótfy odpovědi SMIP Ú roveň kódu
Stav
2xx
Požadovaná akce byla úspěšné. Klient může pokračovat dalším krokem.
3xx
Příkaz byl přijat, ale server očekéívé další informace. Klient by měl odeslat jiný příkaz s dalšími informacemi.
4xx
Příkaz nebyl úspěšný, ale problém je dočasný. Klient by měl danou akci zkusit později.
Sxx
Příkaz nebyl úspěšný a problém je považovén za trvalý. Klient by to neměl zkoušet znovu.
Po přijetí uvítací zprávy se představíte pomocí příkazu HELO. Názvem hostitele za pří kazem HELO by měl být název systému, ze kterého se připojujete: HELO ma i l . ore i l l y . com
Server odpovídá zprávou o úspěšném provedení. Takže můžete pokračovat: 2 5 0 mai l . orei l l y . com
Pomocí příkazu MAI L FROM uveďte, od koho je zpráva: MAI L FROM :
Server přijme adresu odesílatele: 2 5 0 Ok
Pomocí příkazu RCPT TO uveďte, komu je zpráva určena: RCPT TO : < kdent@example . com>
Server přijme adresu příjemce: 2 5 0 Ok
Nyní jste připraveni odeslat obsah zprávy. Příkaz DATA říká serveru, že máte zprávu RFC 2822 připravenou k přenosu: DATA
Server odpovídá, že přijímá tento příkaz, a očekává, že začnete odesílat data: 3 5 4 End data with .
V tuto chvíli můžete přenést celý obsah zprávy. Obsah zpráv začíná záhlavími zpráv. Když je zpráva jako taková dokončena, označte konec odesílání jednou tečkou na sa mostatném řádku. Server potvrdí konec vaší zprávy a odpoví, že přenos byl úspěšně dokončen: 2 5 0 Ok : queued as 5 FA2 6B3 DFE
V tuto chvíli server převzal zodpovědnost za zprávu. Pokud byste chtěli pokračovat více příkazy, mohli byste to nyní provést. Jelikož již nemáte žádné další zprávy pro doručení na tento server, můžete se odpojit pomocí příkazu quit:
qu i t
Server odpoví, že byl úspěšně proveden a odpojí se: 2 2 1 Bye
Nakonec vám Telnet řekne, že připojení skončilo a vrátíte se na příkazový řádek: Connect i on closed by foreign hos t . $
To byl samozřejmě nejjednodušší příklad transakce SMTP. Základní protokol poskytuje další příkazy a byl rozšířen tak, aby umožňoval mnohá vylepšení. Dokument RFC 1 869 poskytuje systém pro přidávání dalších funkcí do základního protokolu SMTP. Roz šířený protokol je označován jako ESMTP. Klient oznamuje svou schopnost používat rozšířený protokol použitím příkazu EHLO namísto příkazu HELO, Pokud server také podporuje rozšíření, odpoví seznamem funkcí, které poskytuje. Mnohá rozšíření byla uvedena v různých dokumentech RFC. Najdete je vyhledáváním SMTP na webovém sídle IETF (http://www.ietf.org/) . O protokolech SMTP a ESMTP je na webu mnoho informací.
KAPITOLA 3
Architektura Postfixu
Postfix můžete snadno řídit a spravovat, arůž byste dokonale rozuměli celé jeho funkci. Chcete-li se již pustit do něčeho praktického, přeskočte tuto kapitolu a začněte až tou ná sledující. Může být trochu obtížné pochopit veškerý zde uvedený materiál, nemáte-li zatím s Postfixem mnoho zkušeností, tato kapitola je však přehledem různých součástí, které se vám při práci s Postf1Xem mohou hodit. Jakmile získáte s popisovaným systémem nějaké zkušenosti, můžete se k této kapitole vrátit a pokusit se absorbovat další vědomosti.
Komponenty Postfixu Architektura Postfixu se výrazně liší od monolitických systémů, jakým je např. Sendmail, které tradičně využívají k práci se zprávami elektronické pošty jediný rozsáhlý program. Postfix rozděluje úlohy na jednotlivé funkce v různých programech, které se pak starají o konkrétní činnosti. Většina těchto programů jsou démony, což jsou procesy běžící na pozadí vašeho systému. Nejprve se spustí démon master (řídícD a ten volá většinu ostatních procesů podle potřeby. Postfixové démony, které zavolá master, zpracují své přidělené úkoly a pak se ukončí. Mohou se rovněž ukončit po zadaném časovém úseku nebo po zpracování určitého nejvyššího počtu požadavků. Řídící démon je trvale rezi dentní a své konfigurační informace přebírá při spouštění ze souborů main.ifa master.if. Další informace o konfiguračních souborech Postfixu najdete ve čtvrté kapitole. Obrázek 3-1 znázorňuje základní architekturu Postfixu. Obecně řečeno, Postfix přijímá zprávy, řadí je do fronty a nakonec je doručuje. Každá fáze zpracování je ovládána jinou sadou součástí Postfixu. Jakmile je přijata nějaká zpráva a umístěna do fronty, zavolá
Dovnllr Místní doručení Sítová doručení Místní předávání Upozornění
Ven ...............
Obrázek 3-1. Celkovýpřehled architektury Postftxu
Správce fronty
..............
smtp. přenos. Imtp. lokální. virtuální. roura
správce fronty příslušného doručovacího agenta, který zprávu nakonec převezme. Ná sledující oddíly této kapitoly pojednávají o detailech jednotlivých fází zpracování.
Jak zprávy vstupují do systému Postfix Zprávy přicházejí do Postfixu jedrum ze čtyř způsobů: 1 . Zpráva může být do Postfixu přijata lokálně (odeslána uživatelem na témže po čítači) . 2. Zpráva může být do Postfixu přijata přes síť. 3. Zpráva již přijatá do Postfixu jednou z výše uvedených metod je znovu vložena pro předání na jinou adresu.
4. PostflX sám generuje zprávy, když musí odesílat upozorněru na nedoručitelné zásilky nebo odložené pokusy o doručeru. Vždy je možné, že dojde k odDÚtnutí zprávy ještě před jejím vstupem do systému Postfix, nebo že některé zprávy budou pozdrženy a doručeny až později.
Místní vkládání zpráv elektronické pošty Různé komponenty Postfixu fungují společně tím způsobem, že si zapisují zprávy do fronty a odtud je také čtou. Správce fronty zodpovídá za řízeru zpráv ve frontě a upo zorňování správných komponent na to, že mají nějakou práci. Obrázek 3-2 ilustruje tok při vstupu lokální zprávy elektronické pošty do systému Post fix. Místru zprávy se ukládají do adresáře maildrop fronty Postfixu příkazem postdrop, obvykle prostřednictvím programu sendmail zajišťujícího kompatibilitu. Démon pickup si takovou zprávu z fronty přečte a předá ji démonu cleanup. Některé zprávy dorazí ve
Obrázek 3-2. Místnípffdávání e-mailII
stavu, kdy neobsahují všechny informace požadované v platné e-mailové zprávě. Kro mě desinfekční kontroly zprávy tedy démon cleanup, ve spojení s démonem trivial -rewri te, vloží chybějíci hlavičky zprávy, převede adresy na formát uživatel@doména.tld očekávaný programy Postfixu a může také adresy přeložit podle kanonických nebo virtuálních vyhledávacich tabulek (další informace o vyhledávacich tabulkách najdete ve čtvrté kapitole). Démon cleanup zpracuje veškerou příchozí poštu a jakmile umístí vyčištěné zprávy do příchozí fronty, upozorní na to správce fronty. Správce fronty následně zavolá přísluš ného agenta doručení, který zajistí odeslání zprávy na další postupné místo nebo na konečný cíl.
Elektronická pošta ze sítě Obrázek 3-3 znázorňuje tok v případě vstupu síťové zprávy elektronické pošty do systému PostflX. Zprávy přijaté přes síť přijme démon smtpd Postfixu. Tento démon zajistí kontrolu "zdraví" a může být nakonfigurován tak, aby klientům umožňoval pře dávání pošty na systém nebo jim toto znemožnil. Démon smtpd předává zprávu démonu cleanup, který provede své vlastní kontroly a pak ji vloží do příchozí fronty. Správce fronty následně zavolá příslušného agenta doručení; ten zajistí odeslání zprávy na další postupné místo nebo na konečný cíl.
P&tJ·· _· · · ·
Sprévca fronty Postfllu
u
u
m
.. 1
Obrázek 3-3. E-mail ze sítě
Upozornění Postfixu Když je odeslání zprávy odloženo nebo není možné, pak Postfix pomoci démonů de fer nebo bounce vytvoří novou chybovou zprávu. Tato chybová zpráva je předána démonu cleanup. Ten zajistí její normální kontroly, než ji vloží do příchozí fronty, kde ji převezme správce fronty.
Předávání elektronické pošty Někdy po zpracování zprávy elektronické pošty PostflX stanoví, že cílová adresa ve sku tečnosti ukazuje na jinou adresu na jiném systému. V tomto okamžiku by mohl systém prostě jen zprávu předat klientovi SMTP k okamžitému doručení, v zájmu zajištění správného zpracování a zaprotokolování každého příjemce ji však Postfix znovu vloží jako novou zprávu, která se zpracuje jako kterákoli jiná lokálně vložená zpráva.
Místní doručení Správce fronty PostflXu má na starosti vše kolem zpracování elektronické pošty. Součásti Postfixu, které přijímají poštu, mají za základní úkol dodat e-mailovou zprávu právě správci fronty. Toho se dosahuje prostřednictvím deamona cleanup, který upozorňuje správce fronty v okamžiku, kdy umístí novou zprávu do fronty příchozí pošty. Jakmile má správce fronty novou zprávu, použije trivial-rewrite ke stanovení směrovacích informací: používané metody přenosu, následujícího hostitele pro doručení a adresy příjemce. Správce fronty udržuje čtyři odlišné fronty: příchozí, aktivní, odloženou a poškozenou. Po vykonání prvních čisticích kroků je prvním cílem nových zpráv příchozí fronta. Jsou-li k dispozici systémové prostředky, správce fronty dále zprávu přesune do aktivní fronty a zavolá jednoho z agentů doručení, který se postará o její dodání. Zprávy, jež nelze doručit, se přesunou do fronty odložených. Správce fronty také zodpovídá za práci s deamony bounce a defer při generování hlášení o stavu doručení u problémových zpráv. Takové hlášení se pak posílá zpět odesílateli, popřípadě správci systému nebo oběma. Kromě adresářů fronty zpráv ob sahuje adresář spool Postfixu také adresáře bOllnce a defer. Ty zahrnují stavové informace o tom, proč je určitá zpráva odložená nebo nedoručitelná. Deamoni bounce a de fer využívají informace, uložené v těchto adresářích, ke generování svých upozornění. Podrobnější informace o fungování správce fronty najdete v páté kapitole.
Doručení pošty Postfix používá ke stanovení, která cílová místa má přijmout k doručení a jak má toto doručení proběhnout, princip tříd adres. Hlavními třídami adres jsou local (místní), virtual alias (virtuální alias), virtual mai lbox (virtuální schránka) a relay (postoupe ní) . Cílové adresy, které nespadají do jedné z těchto tříd, doručuje přes síť klient SMTP (za předpokladu, že je přijal autorizovaný klient). Podle třídy adresy volá správce fronty příslušného agenta doručení, který zprávu zpracuje.
Místní doručení Agent doručení local zpracovává poštu uživatelů, kteří mají účet prostředí n a systé mu, kde běží Postfix. Doménové názvy lokálního doručení jsou uvedeny v parametru
mydest ination. Zprávy, odeslané uživateli v některé z domén v mydest inat ion, se do ručí příslušnému účtu prostředí daného uživatele. V jednoduchém případě vloží agent místrubo doručení e-mailovou zprávu do místrubo úložiště zpráv. Prověří také aliasy a soubory forward uživatelů a zjistí si, zda nemají být lokální zprávy doručeny jinam. Další údaje o lokálním doručování najdete v sedmé kapitole. Má-li se zprá�a předat jinam, znovu se vloží do Postfixu pro doručení na novou adresu. Jsou-li s doručením zprávy dočasné potíže, upozorní agent doručování správce fronty, který ji označí k pozdějšímu pokusu o doručení a uloží do fronty odložených zpráv. Trvalé problémy způsobí, že správce fronty vrátí zprávu zpět původnímu odesílateli.
Zprávy pro virtuální alias Všechny adresy s virtuálními aliasy se předávají dál na jiné adresy. Doménové názvy pro využívání virtuálních aliasů jsou uvedeny v parametru vi rtual_alias domains. Každá doména má svou vlastní množinu uživatelů, kteří nemusejí být mezi doménami jedineč ní. Uživatelé a jejich skutečné adresy se nacházejí ve vyhledávacích tabulkách zadaných parametrem vi rtual_alias _maps. Zprávy přijaté na adresy virtuálních aliasů se znovu vkládají pro doručení na skutečnou adresu. Další informace o virtuálních aliasech na jdete v osmé kapitole. _
Zprávy pro virtuální schránku Agent doručení virtual zpracovává poštu pro adresy virtuálních schránek. Tyto schránky nejsou přiřazeny určitým účtům prostředí na systému. Doménové názvy pro virtuální schránky jsou uvedeny v parametru vi rtual_ma i lbox_domains. Každá doména má svou vlastní množinu uživatelů, kteří nemusejí být mezi doménami je dineční. Uživatelé a jejich soubory schránky se nacházejí ve vyhledávacích tabulkách zadaných parametrem virtual_ma i lbox_maps . Další informace o virtuálních poštov ních schránkách najdete v osmé kapitole.
Postupované zprávy Agent doručení smtp zpracovává poštu pro domény relay. E-mailové adresy v domé nách relay jsou obsluhovány jinými systémy, Postfix však přijímá zprávy pro tyto domény a postupuje je správným systémům. Konfigurace relay jsou obvyklé, když Postfix přijímá poštu z internetu a postupuje ji systémům na interní síti. Názvy domén pro rday jsou uvedeny v parametru relay_doma ins. Další informace o principu relay (po stupovám') najdete v deváté kapitole.
Jiné zprávy Zprávy, které nespadají do žádné z popsaných tříd adres, jsou obvykle určeny pro jiné domény obsluhované na odlišném místě sítě. Postfix přijímá takové zprávy pouze od autorizovaných klientů, napřľklad systémů, které běží na stejné místní síti. Když má dojít
k doručení zprávy přes síť, správce fronty zavolá agenta doručení smtp. Tento agent stanoví, jaký hostitel nebo jací hostitelé mohou danou zprávy přijmout, a postupně se s ními spojuje, dokud nenajde takového, který zprávu přijme. Vyskytnou-li se dočasné potíže s doručením zprávy, agent doručení smtp upozorní správce fronty, aby danou zprávu vyhradil pro pozdější pokus o doručení a uložil ji do fronty odložených zpráv. Trvalé potíže způsobí, že správce fronty pošle zprávu zpět původnímu odesílateli. Jakmile je dříve nedostupný cílový systém opět online, Postftx se bude snažit nezahltit jej všemi čekajícími zprávami. Ať už se jedná o doručování dříve odložených zpráv nebo nových zpráv, Postftx zpočátku vytvoří jen omezený (nastavitelný) počet připojení k při jímajícímu systému. Jakmile Postftx zaznamená úspěšná doručení na určité sídlo, pomalu zvyšuje (až po nastavitelný limit) simultánní připojení k tomuto systému. Zjistí-li Postftx nějaké problémy na přijímajícím sídle, začne upouštět od okamžitých doručování.
Jiní agenti doručení Existují ještě jiní agenti doručení Postftxu, které lze nakonftgurovat n a zpracovávání zpráv určité třídy nebo cíle. Ostatní agenti doručení musejí být nastaveni v souboru master.cf. Volají se bud' prostřednictvím parametru tří da_transport, nebo přes zadání v transportní tabulce, jak je uvedena v parametru t ransport _maps. Dvěma běžnými alternativními agenty doručení jsou lmtp a agenti roury.
Doručení prostřednictvím LMTP Protokol LMTP se podobá SMTP, používá se však k doručování mezi poštovními systémy na jedné síti. (Další informace o SMTP najdete v sedmé kapitole.) Má-li být kupříkladu nějaká zpráva doručena jinému softwarovému balíčk�, který běží na témže počítači nebo na jiném systému v téže místní síti, pak správce fronty zavolá agenta doru čení lmtp. Nejběžnějším příkladem využívání LMTP je situace, kdy server POP /IMAP ukládá zprávy v nějakém proprietárním formátu. (Vzpomeňte si, že POP a lMAP jsou protokoly sloužící uživatelům k převzetí zpráv.) Jelikož má v tomto případě server POP / lMAP svůj vlastní formát ukládání zpráv, použije Postftx standard LMTP zajišťující předání zprávy danému serveru POP /IMAP' Jsou-li s doručením zprávy nějaké potíže, upozorní agent doručení lmtp správce fronty, který pak příslušnou zprávu označí pro další pokus o doručení a uloží ji do fronty odložených zpráv.
Doručení rourou Postftx nabízí možnost doručování zpráv jinému programu prostřednictvím deamona pipe. Tento démon doručuje zprávy externím příkazům. Démon pipe se obvykle používá k doručování e-mailu nějakému externímu fJltru obsahu nebo jinému komunikačnímu médiu, například zařízení FAX. Jsou-li s doručením zprávy nějaké potíže, upozorní dé mon pipe správce fronty, který pak příslušnou zprávu označí pro další pokus o doručení a uloží ji do fronty odložených zpráv.
Trasování zprávy přes Postfix Podívejme se na průchod typické zprávy systémem Postfix. Obrázky 3-4, 3-5 a 3-6 ilu
strují celý proces přechodu zprávy ze systému původu k cílovému agentovi MTA, který
ji zase předá konečnému MTA, kde je uchována až do okamžiku převzetí uživatelem. Na obrázku 3-4 chce Helena
(helene@orei/!y.com) odeslat zprávu Frankovi ([email protected]).
Helena má účet na systému s Postfixem. Její e-mailový klient jí umožní zprávu sestavit
a při jejím odesílání pak zavolá příkaz sendmai/Postfixu. Tento příkaz zajistí příjem zprávy
od e-mailového softwaru Heleny a vloží ji do adresáře mai/drop. Démon pickup následně
zprávu vyzvedne, prověří ji a postoupí démonu cleanup, který zajistí finální zpracování nové zprávy. Jestliže Helenin poštovní klient nezadal adresu From: nebo v adrese nepoužil
plně kvalifikovaný název hostitele, cleanup zprávu příslušným způsobem doplní.
orllUy.com
SpnvcI fronty .�
Semr DNS
Obrázek 34. Doruéování tPrá'!Y 1 Po dokončení umístí cleanup zprávu do fronty incoming (příchozí) a upozorní správce fronty na skutečnost, že k doručení je připravena nová zpráva. Je-li správce fronty při
praven ke zpracování nových zpráv, přesune danou zprávu do aktivní (active) fronty.
Jelikož je daná zpráva určena pro uživatele na vnějším systému, správce fronty musí vyzvat agenta smtp k zajištění jejího doručení.
Agent smtp použije DNS (viz šestá kapitola) a získá seznam systémů elektronické pošty, které mohou přijmout poštu pro doménu postftx.org. Agent doručení smtp vybere z to
hoto seznamu přednostruno hostitele MX a kontaktuje jej ohledně doručení Heleniny zprávy.
Obrázek 3-5 ukazuje, že na Frankově poštovním serveru postftx.org také běží Postfix, i když
tento systém by mohl využívat jakéhokoli jiného standardního agenta MTA. Postfixový smtpd na Frankově serveru převezme zprávu
od Helenina agenta doručení smtp. Jakmile
démon smtpd prověří, že má danou zprávu skutečně převzít, předá ji démonu c leanup,
který zajistí její kontrolu a pak ji umístí do fronty incoming (příchozí).
Spr6VCI fronty pollll ll.ol1l
Obrázek 3-5. Dorulování :@ráty 2 Správce fronty přesune zprávu do aktivní fronty, zajistí její zpracování a stanoví, že má
zavolat agenta local, který se postará k její fmální doručení. Agent místního doručování
zjistí, že frank je alias a zprávu přes démon cleanup znovu vloží do systému k odeslání
na novou adresu.
Démon c l eanup i správce fronty volají při zpracovávání zpráv démon trivi a l - rewrite.
Ten pomáhá s převodem e-mailových adres do standardního formátu a s určením typu přenosu a následným krokem doručení.
Když má být nová zpráva doručena do jiné sítě, zavolá správce fronty smtp. Ten se spojí
s DNS a zjistí poštovní servery přijímající poštu pro doménu
Spr6VCI fronty onlamp.com
Obrázek 3-6. Doruéování :@ráty 3
onlamp.com.
Na obrázku
3-6 nakonec MTA na systému onlamp.com (znovu se náhodou jedná o systém Postfix) předá zprávu doručovacímu agentovi loeal, který ji umístí do úložiště zpráv na daném systému. V tomto okamžiku práce Postfixu končí. Frank si nyní může zprávu přečíst pomocí svého poštovního klienta, který ji může stáhnout přímo z lokálního úložiště zpráv nebo využít jiný protokol, kupříkladu POP či lMAP. .
V našem jednoduchém příkladu mohlo dojít k několika alternativám. Zpráva například nemusela být v některém z kroků dočasně doručitelná; v takovém případě by upozornil doručovací agent správce fronty, který příslušnou zprávu umístí do fronty odloženého doručení a pokusí se o její předání později. Další možností je, že docl není skutečný systémový účet, ale účet e-mailového systému lMAP. V takovém případě může správce fronty doručit zprávu prostřednictvím agenta Imtp nebo specializovaným příkazem nastaveným přes doručovacího agenta pipe. Postfix se musí vyrovnat s mnoha variantami a potenciálními komplikacemi. Naštěstí je jeho architektura natolik robustní, že si dokáže poradit téměř se všemi situacemi. Zároveň je tak flexibilní, že lze v budoucnu jednoduše zavádět změny.
KAPITOLA 4
Obecná konfigurace a správa
Jednou ze skutečně pozoruhodných věcí na PostfIxu je to, že v mnoha případech funguje okamžitě po instalaci, přičemž jeho konfIguraci je zapotřebí upravit jen minimálně nebo dokonce vůbec. V prvním oddílu této kapitoly si projdeme kontrolu nastavení a prvního spuštění PostfIxu. Další oddíly se zabývají detailnějším popisem nastavení PostfIxu. PostfIx je ve výchozím stavu nakonfIgurován jako tradiční unixový poštovní server, který odesílá a přijímá zprávy pro všechny účty na systému. Vaši uživatelé mohou ode sílat a přijímat zprávy pomocí libovolného klientského poštovrubo softwaru, jaký je na systému k dispozici. Ve většině prostředí funguje PostfIx ve spojení s různými jinými softwarovými systémy. Měli byste sestavovat jednotlivé součásti svého e-mailového systému a všechny je testovat jako oddělené moduly, než se je pokusíte integrovat. Po každém přidání dalšího modulu systém otestujte a pak se teprve pusťte do další části. V tomto okamžiku byste již měli mít PostfIx instalovaný na svém systému. Můžete si jej nainstalovat z balíčku určeného pro vaši platformu, nebo si jej můžete také sami zkompilovat. Pomoc s kompilováním PostfIxu, pokud se rozhodnete pro tuto cestu, na jdete v příloze C. Podívejte se na své obvyklé zdroje softwaru a zjistěte si, zda tu nejsou k dispozici nějaké balíčky PostfIxu. Jestliže jste PostfIx zatím neinstalovali, pak si buď obstarejte balíček pro svůj systém, nebo jej sestavte podle instrukcí v příloze C. Jakmile skončíte s instalací, vraťte se k této kapitole a pusťte se do fInální konfIgurace. V příkladech celé knihy budu předpokládat, že vaše instalace PostfIxu využívá standardní adresáře:
letcipostftx KonfIgurační soubory a vyhledávací tabulky
I usrl libexeclpostftx Démony PostfIxu
Ivarls,Poollpostftx Soubory front
/usr/ sbin Příkazy Postfixu Budu také předpokládat, že jste vy nebo váš instalační program vytvořili uživatele pos tfix a skupinu postdrop. Tento uživatel a skupina by neměly být na vašem počítači používány k žádnému jin�mu účelu. Jestliže jste změnili nějaká výchozí zadání, nebo to učinil váš balíček Postfixu, pak na to nezapomínejte při čtení příkladů uvedených v knize.
První spuštění Postfixu Před prvním spuštěním Postfixu je zapotřebí zvážit dva důležité aspekty. První spočívá v tom, jak se váš systém identifikuje. Postfix používá konfigurační parametr označený za myhostname, který musí být nastaven na plně kvalifikovaný název hostitele systému, na němž Postfix běží. Jakmile Postf1X zná plně kvalifikovaný název hostitele, může tento ná zev použít k nastavení výchozích hodnot dalších důležitých parametrů, jako je mydomain. Není-li parametr myhostname zadán, Postf1X standardně využije název hostitele hlášený samotným systémem. Detailnější pojednání o myhostname najdete dále v této kapitole. Název hlášený vaším systémem si můžete zobrazit unixovým příkazem hostname: $ hostname mai l . example . com
Plně kvalifikovaný název hostitele je složený jak z daného názvu hostitele, tak i domé ny, v níž se nachází. Některé systémy mají nakonfigurován jednoduchý název hostitele a nikoli jeho plně kvalifikovanou verzi: $ hostnule ma i l
Je-li váš systém nastaven j e n n a prosté jméno hostitele, nedokáže Postfix stanovit plně kvalifikovaný název. Proto musíte explicitně zadat parametr myhostname. Toho lze snadno dosáhnout příkazem postconj Postfixu. Příkaz postconj je utilitou Postfixu zajišťující jednoduchý způsob přebírání různých informací o vašem systému Postfix. Jednou z jeho funkcí je zobrazit nebo změnit specifický konfigurační parametr. Můžete jej využít k nastavení parametru myhostname: • postconf -e myhostname=mail . example . com
Volba -e říká příkazu postconJ, aby upravil konfigurační soubor dále zadanými parametry a hodnotami. Je-li váš systém nakonfigurován s plně kvalifikovaným názvem hostitele, nemusíte nastavení Postfixu nijak měnit. Druhou důležitou věcí před prvním spuštěním Postfixu je zajistit správný formát data báze aliasů vašeho systému. Při provozování poštovruno serveru v produkčním prostředí byste měli nastavit určité vyžadované aliasy. O souboru a/iase! si povíme dále v této kapitole. Zatím jen musíte vědět, že se jedná o textový soubor, který musí být mapován do indexovaného, binárruno formátu. Binární formát vašeho existujícího souboru a/iases se může lišit od toho, jaký Postfix standardně na vašem systému používá. Indexovaný soubor můžete znovu sestavit příkazem newa/iases:
# newaliases
Tento příkaz nevyžaduje žádné argumenty a prostě jen znovu vytvoří vaši databázi aliasů, aniž by vlastní soubor aliasů nějak změnil. Jakmile se vyrovnáte s uvedenými dvěma kritickými položkami, budete připraveni ke spuštění Postfixu. Vykonejte následující příkaz: • postfix start
Zjistí-li Postfix při spouštění nějaké potíže, nahlásí je na váš terminál. Po počátečním nastavení se Postfix odpojí od terminálu a od toho okamžiku již nemůže hlásit pro blémy na obrazovku. Bude však i nadále odesílat spoustu informací do systémového protokolu Oogu). Kdykoli spouštíte nebo opakovaně nahráváte Postf1X, podívejte se do systémového protokolu a přesvědčte se, že tu nejsou žádné hlášené chyby ani varování. Informace o protokolování Postf1Xu a instrukce k nalezení daného používaného souboru protokolu najdete v oddílu Protokolování této kapitoly. Postfix se většinou spustí bez problémů a vy se tedy stanete hrdým správcem (administrá torem) aktuálně běžícího, plně funkčního systému Postfix. Další informace o konfiguraci Postf1Xu pro práci se serverem POP lIMAP takovým způsobem, aby uživatelé nepotře bovali přístup k prostředí vašeho poštovního systému, najdete v sedmé kapitole. Podívejte se rovněž do šesté kapitoly, kde jsou důležité údaje o DNS a e-mailu. Postfix se naučíte zastavovat a restartovat v oddílu Zastavení, spuštění a opětné nahrání Postfixu dále v této kapitole. V následujících oddílech se budeme věnovat konfiguraci a správě Postfixu.
Konfigurační soubory Adresář l elcipostftx obsahuje konfigurační soubory Postfixu. Dvěma nejdůležitějšími soubory využívanými k nastavení Postfixu jsou masler.if a main.if. Tyto soubory by měl vlastnit uživatel root, který by do nich také jako jediný měl mít možnost zapisovat. Č íst by je měl moci kdokoli. Kdykoli zadáte nějaké změny v těchto souborech, budete muset Postfix znovu nahrát, aby se uplatnily:' # postfix reload
Démon masler je základní proces, který řídí jiné postfixové démony zpracování pošty. Démon masler využívá ke své konfiguraci soubor masler.cf. Ten obsahuje jeden řádek pro každou službu nebo transport Postfixu. Každý řádek má sloupce specifikující, jak mají jednotlivé programy běžet jako součásti celého systému Postfix. Další informace o architektuře Postfixu a vzájemné interakci jednotlivých jeho komponent najdete ve třetí kapitole. V mnoha instalacích nebudete muset soubor masler.if vůbec měnit. Další údaje o tom, kdy a jak učinit změny v souboru masler.if, najdete v oddílu Soubor master.cf této kapitoly.
. Změníte·li parametr
inet _ inter faces,
musíte Postfix zastavit a spustit.
Konfigurační soubor main.cf Soubor
main.cf j e
jádrem nastavení Postfixu. Téměř všechny konfigurační změny se
zadávají právě zde. Výchozí soubor
main.cf zahrnuje
jen část téměř tří stovek para
metrů Postfixu. Většinu parametrů není zapotřebí měnit, v případě nutnosti však
máte dostatečt'J.ou flexibilitu. Veškeré parametry Postfixu j sou uvedeny a popsány
v různých souborech ukázkových konfigurací. Tyto ukázkové soubory se nacházejí v adresáři specifikovaném parametrem sample_ directory, který je obvykle totožný s adresářem souboru
main.cf. Jak
soubor
main.cj,
tak i ukázkové soubory, které j sou
součástí distribuce Postfixu, obsahují komentáře vysvědující jednodivé parametry.
Gil ,: tl ..
II:. 'IlO•.
Soubor
Kdykoli je v této knize řečeno, že máte změnit nějaký parametr, vždy
..•:
to znamená určitý parametr v souboru main.if, neni-li specificky řečeno .. k. JIna
main.cfmůžete editovat příkazem postcon], jak jsme
si v této kapitole již ukázali.
Máte rovněž možnost daný soubor změnit přímo v nějakém textovém editoru· (napří klad
vi nebo emacs).
Soubor obsahuje prázdné řádky, řádky komentářů a řádky přiřazující
hodnoty parametrům. Komentáře začínají znakem t a trvají až na konec řádku. Postfix
prázdné řádky a komentáře ignoruje. Parametry mohou být v konfiguračním soubory
uvedené v libovolném pořadí a zapisují se způsobem, jaký zřejmě očekáváte: parame tr
=
hodnota
Definice parametru musí začínat na prvním sloupci řádku. Mezery okolo rovnítka jsou
volitelné.
Zde máme příklad přiřazení parametru s komentářem:
• Hodnota myhos tname mu s í být plně kva l i f i kovaným ná zvem hostitele . myhos tname
=
ma i l . example . com
t Dále je zbytek souboru . . .
Komentář nelze uvést na jeden řádek s parametrem. Následující příklad je tedy chybný a v případě určitých parametrů může způsobit neočekávané chování, jehož příčina je
obtížně odhalitelná: #
• Toto j e nesprávné přiřazení pa rametru . Ni kdy j e nez adáve j te . • myhos tname
=
ma i l . example . com
# mus í být plně kva l i f i kovaným názvem hos titele
Kolem hodnot nepoužívejte apostrofy ani uvozovky. V konfiguraci Postfixu nemají žádný význam, takže budou považovány za součást hodnoty, což zřejmě nezamýšlíte.
•
Postfix očekává, že konfigurační soubory obsahují běžná ukončení řádků ve stylu Unixu. Budete-li editovat kon
figurační soubory na jiné platformě, například na Windows nebo Macu, zajistěte, aby váš editor používal správné unixové znaky konců řádků.
Pokračování řádku Řádek, který začíná prázdným znakem (tabulátory nebo mezerami), je považován za pokračování předchozího řádku. To vám umožňuje rozdělit dlouhé parametrické hod noty na více řádků. Přiřazení myde s t ination
=
example . com ore i l l y . com ora . com pos t f i x . org
je totéž jako: myde s t i n a t i o n
e x amp l e . com
o r e i l l y . com
ora . com pos tfix . org
Konfigurační proměnné Na hodnotu nějakého definovaného parametru se můžete odkázat tím způsobem, že
před název příslušného parametru vložíte znak $ : mydoma in
=
exarnple . com
myorigin
=
$mydomain
Hodnotou parametru myorigin bude nyní "example.com". Na hodnotu se můžete v souboru odkazovat i předtím, než je zadána. Následující příklad funguje úplně stejně, jako ten předchozí: myorigin
=
$mydomai n
mydomain
=
example . com
Více hodnot Mnoho parametrů má více než jednu hodnotu. Více hodnot lze oddělovat čárkami, mezerami, tabulátory nebo novými řádky. Pamatujte, že když oddělujete hodnoty no
vými řádky, musejí se před dalšími údaji hodnotami nacházet mezery nebo tabulátory indikující pokračování předchozího řádku: myde s t ination
=
myde s t i nation
=
$mydoma i n , example . com, ore i l l y . com $mydoma in example . com ore i l l y . com
myde s t i nation
=
$mydoma in
example . com ore i l l y . com
Tato tři přiřazení parametru mydest ination si v konečném důsledku odpovídají. Určité parametry vám umožňují vložit více hodnot do něj akého textového souboru
a příslušný parametr pak na tento soubor nasměrovat v main.if. O hodnotě, která začíná
lomítkem, se předpokládá, že je to ukazatel na soubor. Přijímá-li váš systém poštu lokálně pro mnoho cílů (destinací), bude vhodné udržovat seznam cílů v samostatném souboru. Parametr mydest ination pak nasměrujete na tento soubor: mydest ination
=
/etc/postfix/dest inations
Parametry. které mohou k ukládání hodnot využívat externí soubory, přijímají seznamy,
v nichž není pořadí uvedených položek významné, jako např. mynetworks, mydestination a relay_domains. Z dokumentace zjistíte, zda určitý parametr tento prvek podporuje.
Máte-li v nějakém seznamu tisíce položek, může být výhodnější uložit je spíše do vyhle dávací tabulky. Vyhledávací tabulky si popíšeme hned v následujícím oddílu . .
Kdykoli zadáte nějakou změnu do konfiguračrubo souboru main.cj, musíte Postfix znovu nahrát, aby se úpravy projevily: •
poltfix reload
Další informace o zastavení a spuštění Postfixu najdete v oddílu Zastavení, spuštění
a opětné nahrání Postfixu.
Vyhledávací tabulky Postfix nepoužívá komplikované přepisy ani pravidla transformace vzorů jako Send
mail, ale pracuje s jednoduchými a přesto flexibilními vyhledávacími tabulkami. Mnoho parametrů směřuje na vyhledávací tabulky, odkud získávají důležité konfigurační infor
mace. Jedním takovým parametrem je canonical_maps . Používá se k přepisování adresy
elektronické pošty ve zprávách. Představme si sídlo, které interně používá pro adresy
elektronické pošty názvy účtů, zároveň ale požaduje, aby měly všechny veřejně viditel né adresy tvar j méno . př í j mení@example . com. Kupříkladu adresa kdent@example . com se
musí jevit jako kyle . dent@example . com. Vyhledávací tabulka canonical_map s zajišťuje
mapování
klíle (kdent@example . com)
na
hodnotu (kyle . dent@example . com).
Vyhledávací tabulky využívá mnoho parametrů, všechny však fungují n a stejném princi pu. E-mailová zpráva (neboli klient) poskytuje nějaký klíč použitý k vyhledání hodnoty. Na základě zjištěné hodnoty zajistí Postfix nějakou akci nebo něco změní.
Fonnát vyhledávací tabulky Vyhledávací tabulky PostflXu jsou obvykle unixovými databázovými soubory, což jsou speciálně indexované soubory zajišťující rychlejší přístup k uloženým položkám. Vyhle
dávací tabulky j sou zpočátku jednoduché textové soubory, přičemž každý klíč a hodnota se nacházejí na jednom řádku a jsou odděleny mezerami nebo tabulátory: t
t kanon i c ké mapování
•
kdent @ example . com
kyle . dent@ example . com
Každá položka má jednoznačný klíč. Tyto klíče se často označují za LHS neboli levou stranu (LeftHand Side) zadání a hodnoty se pak podle stejného principu označují jako RHS neboli pravou stranu (RightHand Side) zadání. U klíčů ve vyhledávacích tabul
kách se nerozlišují velké a malé znaky. Takové soubory mohou obsahovat komentáře
a prázdné řádky stejně jako
main.if a pokračování řádku
funguje tím způsobem, že se
na začátek pokračovacích řádků zapíše nějaký prázdný znak. Vyhledávací tabulky také žádným zvláštním způsobem nezpracovávají otazníky.
Jakmile máte vytvořený textový soubor se všemi mapováními (přiřazeními), musíte na něm vykonat příkaz pos/map, který vytvoří jeho vlastní indexovanou verzi: • postmap /etc/postfiz/canonical
Kdykoli výchozí textový soubor změníte, musíte na něm znovu spustit pos/map. Příkaz pos/map lze rovněž používat k dotazování se vyhledávacích tabulek. K dotazu na hodnotu použijte přepínač q : -
i postmap -q kdent@ezample . com /etc/postfiz/canonical
kyl e . dent @example . eom
Databázové formáty Různé typy unixových databázových souborů mají různé interní formáty. Použitý for mát závisí na databázových knihovnách dostupných na vašem systému. Postftx běžně podporuje jeden nebo více z následujících tří typů: btree, dbm a hash. V závislosti na systémových knihovnách můžete mít k dispozici více nebo méně než uvedené tři typy. Je důležité vědět, jaký typ mapování používáte. Příkaz pos/corif s přepínačem -m vypíše všechny typy mapování podporované vaší instalací Postftxu: $ postconf
-m
statie pere nis regexp environ proxy btree unix hash
výstup uvedeného příkazu uvádí všechny typy mapování, přičemž některé z nich se používají pro přístup k jiným druhům úložišť. Měli byste tu ale objevit přinejmenším jeden ze tří vyjmenovaných typů databází (btree, dbm a hash) . Parametr de fa u lt _database_type říká, jaký typ databáze bude PostflX standardně po užívat: $ postconf default_database_type de faul t_database_type
=
hash
Všechny příklady v knize využívají typ hash. Funguje-li na vašem systému něco jiného, nesmíte na tuto skutečnost při studování zde uvedených poKladů zapomínat. Nezadáte-li v po'kazu postmap typ databáze, automaticky použije váš výchozí typ. Obecně platí, že je možné použít výchozí typ nakonftgurovaný na vašem systému, při přiřazování vyhledávacích tabulek mapovacím parametrům jej však musíte znát. Když přiřazujete parametru nějakou vyhledávací tabulku, musíte speciftkovat jak typ mapy, tak i cestu k dané vyhledávací tabulce. Formát mapování vyhledávání vypadá takto:
parametr
=
t yp : název
Zde je typ metodou přístupu k úložišti a název je prostředek obsahující klíče a hodnoty. V případě vyhledávání v indexovaných datových souborech je název názvem souboru.
Příklad kanonického přiřazení následuje: canonical_mags
=
hash : /etc/po s t f i x/ canonical
Parametru lze přiřadit více vyhledávacích tabulek. Postfix prohledává tabulky v zadaném
pořadí a skončí, jakmile nalezne shodu. Některá prohledávání tabulek jsou rekurzivní; to závisí na parametru. Jedním příkladem rekurzivrubo hledání je parametr canonical_maps.
V případě rekurzivních vyhledávání platí, že jakmile je nalezena hodnota, PostflX ji
opět porovnává se všemi ostatními klíči, až dokud neodpovídá klíč sám sobě nebo není
taková položka nalezena.
Možná si povšimnete, že kdyžpostmop indexuje soubory, vytváří dodatečné soubory. Příkaz postmop vytvoří v závislosti na databázovém formátu bud' jeden další soubor s příponou .db, nebo dva další soubory s příponami .dir a .pag. Když přiřazujete parametru takovou vyhledávací tabulku, zadejte cestu a název souboru bez přípony.
Pořadí vyhledávání Protože klíče j sou často e-mailové adresy, Postfix automaticky dělí adresy na jejich části.
Můžete mít klíče odpovídající celé adrese, jenom doménové části nebo pouze lokální části. Způsob, jakým PostflX hledá adresy nebo jejich části, závisí na typu mapovacího
parametru. Určitá mapování mohou rozumně zahrnovat jednoduchou lokální část adresy, jako je tomu u canonical_maps . Jiná nebudou očekávat klíč lokální části; příkladem je t ransport_maps. Pořadí, v jakém Postfix hledá shodu, se mírně liší podle typu parame
tru, s jakým pracuje. Podívejte se na popis příslušné vyhledávací tabulky, kde zjistíte jí
využívané pořadí hledání.
Pořadí hledání v místech, kde jsou očekávány lokální části, například u canonical_maps,
relocated_map s a vi rtual_alias _maps, vypadá následovně: 1 . Celá adresa. Příklad: [email protected] 2. Pouze lokální část. Příklad: kdent
3. Pouze doménová část včetně znaku @. Příklad: @example.com U vyhledávacích tabulek, kde nemá lokální část smysl, jako je kupříkladu transport maps, _
zjišťuje Postfix shodu v následujícím pořadí:
4. Celá adresa. Příklad: [email protected] 5. Samotná doména. Příklad: example.com 6. Doména zadaná včetně úvodní tečky, která odpovídá všem subdoménám. Přl1dad: .example.com Chcete-li, aby domény vždy odpovídaly samy sobě plus všem subdoménám, můžete
své vyhledávací tabulky poněkud zjednodušit nastavením parametru parent _doma in_
matches _ subdomains. Tento parametr obsahuje standardně mnoho seznamů. Chcete-li k tomuto seznamu přidat transport _maps , doplňte jej takto: parent_domain_matches_subdoma ins
=
debug_pee r_l i s t fast f l u s h doma ins mynetworks permi t_mx_backup_networks qmqpd_authori zed_clients relaLdoma ins smtpd_acces s_maps transport_maps t ransport_maps
=
hash : / etc/po s t f i x / t ransport
Nyní bude zadání v letcipostftxl tranporl automaticky odpovídat samo sobě a všem svým subdoménám. Už nepotřebujete žádná zadání, jako kupříkladu třetí položku
fe.com)
z předchozího seznamu.
(.examp
Vyhledávací tabulky a jednoduché seznamy Některým parametrům, které běžně přebírají jednoduchý seznam, jako kupříkladu my
destination, lze rovněž zadat vyhledávací tabulku. Položkami seznamu jsou samotné
klíče LHS. Stále sice musíte každému klíči přiřadit nějakou hodnotu RHS, ta je však prostě ignorována. Můžete tedy zadat libovolný text. To je vhodné místo napřt1dad pro
zadání komentáře. Náhrada prostého seznamu vyhledávací tabulkou je užitečná, když
máte tisíce položek; jinak je jednoduchý textový soubor více než dostačující a zajistí také zřejmě vyšší výkonnost. Používáte-li vyhledávací tabulku pro seznamy síťových adres IP, nemůžete k zadání celé podsítě využít zápis síť I maska sítě. Každou adresu je
nutné uvést jednotlivě. Z dokumentace zjistíte, zda určitý parametr seznamu podporuje
funkci vyhledávací tabulky.
Tabulky regulárních výrazů Postfix nabízí speciální typ vyhledávací tabulky využívající
regulární '!Ýra�.
Ten posky
tuje dokonce ještě více flexibility při hledání shod s klíči ve vyhledávacích tabulkách. Regulární výrazy se používají v mnoha unixových utilitách. Představují mocný nástroj
pro specifikování odpovídajících vzorů. Existují dva typy knihoven regulárních výrazů, které můžete v Postfixu používat. To záleží na tom, jaké knihovny máte na svém sys tému k dispozici.
Postfix standardně používá rozšířené regulární výrazy POSIX, které budu označovat za
regexp.
POSIX, což znamená Portable Operating System Interface (rozhraní přenositel
ného operačrubo systému), je standard podporující přenositelnost neboli portovatelnost
mezi různými operačními systémy. Zahrnuje také specifikace regulárních výrazů. Postfix podporuje i regulární výrazy kompatibilní s jazykem Perl, které budu označovat za pere.
Jste-li zvyklí na regulární výrazy z Perlu, pak se vám budou zřejmě zdát vzory regexp
poněkud odlišné. Chcete-li podporu pcre, musíte mít při sestavování Postfixu k dispozici
knihovnu pcre. Ve formátu pcre se některé prvky liší od regexp a výkonnost je obvykle
vyšší. Je možné, že vaše distribuce Postfixu již zahrnuje podporu pcre. To si můžete zjistit vykonáním příkazu pos/con! s parametrem rn jak bylo uvedeno již dříve v této kapitole. -
,
Je-li mezi typy mapování uvedena položka pcre, pak můžete u svých vyhledávacích tabu lek používat regulární výrazy ve stylu jazyka Perl. Nemusíte ale zoufat a snažit se přidat podporu pcre, pokud ji zatím nemáte; výchozí regexp je velmi silný a správcům, kteří potřebují použ'ívat regulární výrazy, obvykle plně dostačuje. Nainstalujte si pcre, pouze víte-li o určitých prvcích regulárních výrazů ve stylu Perlu, které budete potřebovat. Regulární výrazy ve stylu Perlu i POSIXu jsou dobře zdokumentované na mnoha místech. Každá kniha o Perlu téměř jistě obsahuje informace o jeho regulárních výrazech a máte -li na svém systém Perl instalovaný, měli byste objevit manuálovou stránku nazvanou perIre ( 1 ) . Dokumentace regexp je obvykle v manuálové stránce nazvané re_ forrnat ( 7 ) . Pokud váš systém tuto stránku neobsahuje, najděte si ji na Webu. Informace o regulár ních výrazech POSIXu najdete v sed & awk od Dala Doughertyho a Arnolda Robbinse (O'Reilly). Chcete-li používat tabulky regulárních výrazů, zadejte při jejich přiřazování mapovacím parametrům jako typ mapování bud' regexp, nebo pere: body_checks
=
regexp : / etc/po s t f i x / re_body_checks
Položky v re_body_eheeks se zadávají konvenčně - vzorem regulárního výrazu mezi dvěma lomítky - jako klíč, za nímž následuje prázdný znak a pak mapovaná hodnota: /vzor/
hodnota
Tabulky regulárních výrazů se nejčastěji používají v header_ eheeks a body_ eheeks za účelem blokování nevyžádané pošty (spamu) . Další informace najdete v jedenácté kapitole.
Ostatní formáty Postfix dokáže využívat jako své vyhledávací tabulky i jiné podpůrné systémy. 01 dalších kapitolách si popíšeme použití vyhledávacích tabulek MySQL a LDAP.) Když budete chtít využívat takové externí zdroje pro vyhledávací tabulky, měli byste začít některým z jedno duchých databázových formátů, jako je dbrn nebo hash. Přesvědčte se, že vaše konfigurace funguje podle očekávání. Po nastavení externího zdroje dat si ověřte, že vrací stejné výsledky jako vaše jednoduché tabulky. Příkaz postmap s volbou -q je důležitým nástrojem testování všech druhů vyhledávacích tabulek. Kupříkladu následující dva příkazy by měly při testu databáze MySQL vrátit stejné hodnoty: $ postmap -q hash : /etc/postfix/transport $ postmap -q mysql : /etc/postfix/transport . cf
Další informace o používání Postfixu ve spojení s externími zdroji dat najdete v patnácté kapitole.
Soubory aliasů Soubory aliasů jsou speciálním případem postfixových vyhledávacích tabulek, protože používají formát kompatibilní se systémem Sendmail. Tento soubor se tradičně nazývá a/iases a jeho umístění závisí na používané platformě, většinou je však v adresáři / etc nebo nějakém jeho podadresáři. Postfix je standardně nakonfigurován tak, že směřuje na váš původní soubor aliases. Pokud tedy přecházíte na Postfix ze systému Sendmail, vaše existující aliasy budou stále fungovat.
Vyhledání aliasů Dříve používaly e-mailové systémy jen jednu databázi aliasů. V Postfixu jich můžete mít, kolik jen chcete. Více souborů aliasů vám může pomoci s uspořádáním konfiguračních informací. Administrátoři často nastavují více souborů aliasů kvůli pohodlí při konfi guraci oddělených seznamů zasílání pošty. Na vaše soubory aliasů směřuje parametr alias_maps. Podporuje-li váš systém NIS, což je síťová databáze uživatelů (včetně jejich aliasů), pak standardně Postfix zahrne NIS mezi vaše mapy aliasů. Typický výchozí parametr alias _maps vypadá takto: a l i as_maps
=
hash : / e t c / a l i a s e s , n i s : ma i l . a l iases
Zahrnuje-li váš systém podporu NIS, přičemž ji však nevyužíváte, pak byste tento pa rametr měli změnit tak, aby směřoval pouze na soubor a/iases: a l i a s_maps
=
hash : /etc/aliases
Kvůli konzistentnosti bude vhodné umístit soubor aliases do konfiguračrubo adresáře Postfixu. Někteří správci raději umisťují všechny konfigurační soubory elektronické pošty dohromady. Stačí jen alias maps přesměrovat na nové umístění: _
a l i a s_maps
=
hash : /etc/postfix/al iases
Měli byste také opakovaně přiřadit al ias _da tabase, aby přt'kaz newaliases i nadále správně fungoval (viz následující oddíl) : a l i a s_database
=
hash : /etc /pos t f i x / a l iases
Sestavení databázových souborů aliasů Protože se formát mapovaných aliasů liší od vyhledávacích tabulek Postfixu, nemůžete použítpostmap k sestavení databáze aliasů z textového souboru. K tomu Postfix zajišťuje přt'kaz postalias. Jeho syntaxe přt'kazového řádku je shodná s nástrojem postmap, takže vám dovoluje vytvářet mapování aliasů nebo se na ně dotazovat. Chcete-li sestavit databázi aliasů ze souboru aliasů, zadejte následující: # postalias /etc/aliases
Dalším přt'kazem kompatibilním se systémem Sendmail souvisejícím se soubory aliasů je přt'kaz newaliases. Nabízí pohodlnou možnost opakovaného sestavení databází aliasů.
Instalace Postfixu zahrnuje nahrazující verzi tohoto příkazu, která má stejnou syntaxi
jako originál. Obvykle se vykonává bez argumentů a opakovaně sestavované soubory
aliasů stanovuje pomocí parametru alias_database. Tento parametr se liší od alias _maps
v tom, že zahrnuje pouze standardní unixové databázové mapované soubory (ty, které
musejí být indexovány pomocí newaliases), zatímco alias maps může také obsahovat další _
typy mapování�ako nis. Př1'kaz
newaliases používá ke stanovení použitého databázového formátu parametr de fault_database_type jak již byl popisován. ,
Formát souboru aliasů Textový soubor databází aliasů se podobá vyhledávacím tabulkám Postfixu, liší se jen definice samotného aliasu. Soubory aliasů mohou obsahovat prázdné řádky a komen
táře, které se ignorují. Komentáře se označují znakem # na začátku řádku a nemohou se nacházet na jednom řádku s definicí aliasu. Jednu definici aliasu lze rozdělit na více
řádků tím způsobem, že pokračující řádky začínají prázdným znakem.
Forma definice aliasu sestává z názvu používaného jako alias, dvojtečky a následným jedním
cílem nebo více cíli vytvářeného názvu. Aliasy lze směrovat na různé druhy cílů
(viz dále) .
Více cílů se odděluje čárkami. Aliasy a cíle je zapotřebí uzavřít do uvozovek, obsahují-li prázdný znak nebo některý ze speciálních znaků, jako jsou t, : a
@:
a l i a s : cí l l , cí 1 2 , . . .
Aliasy LHS j sou vždy lokální adresy, takže nemůžete specifikovat název domény klíčem aliasu. Cíl je často jednou nebo více adresami, může se ale jednat o kteroukoli z násle
dujících položek:
Adre.ry elektronicképof!} Lze použít jakoukoli adresu RFC 2822. To znamená, že cílové adresy mohou být
lokální nebo předávané dál jinému sídlu k doručení. Kupř1Kladu: kyle . dent :
kdent , kdent@ore i l l y . com
Název souboru Zadejte úplnou cestu k souboru. Nové zprávy se připojí na konec zadaného souboru. K doručení do souboru dochází stejným způsobem, jako do kterékoli
lokální poštovní schránky. Další informace o lokálním doručování do poštovních schránek a zadání různých formátů poštovních schránek najdete v sedmé kapitole.
Kupř1Kladu: info :
/usr/ local /ma i l / info box
PříkaZ Zadejte znak roury a nějaký př1'kaz. Další informace o doručování př1'kazům odhalíte
ve čtrnácté kapitole. Kupř1Kladu: i n fo :
" I /usr/ loca l /bin/autoreply"
: include : Zahrnutý soubor obsahuje seznam dalších cílů aliasu. Cíle v tomto souboru mohou
být kteréhokoli platného zde popsaného typu, standardně však nejsou povoleny
názvy souborů a přľkazy. Dalšľ oddíl popisuje konfiguračnľ parametry přepisujľcľ tato výchozí omezenľ. Kupříkladu: info :
: i nclude : / u s r / local /ma i l / info l i s t
Obvykle platí, že když Postfix zpracovává lokálnľ doručenľ, přebírá identitu přľjemce zprávy. V případě aliasů používá Postfix identitu vlastnľka daného souboru aliasů; vý jimkou je přľpad, kdy ten je vlastněn uživatelem root. Pokud by mělo dojít k doručenľ jako root, Postfix místo toho použije identitu účtu nakonfigurovaného parametrem de fault_pri vs.
Omezení aliasů Parametry all ow_ma i l_to_comrnands a a l l ow_ma i l_to_files máte možnost řľdit, jaké druhy cílů jsou ve vašich souborech aliasů povolené. Oba parametry přebľrají seznam mechanismů aliasů s povoleným provedenľm. Mechanismy aliasů jsou "alias", což je výše popsaný soubor aliasů, "include" představujícľ zahrnutý cíl a "forward", což je soubor forward probíraný v sedmé kapitole. Výchozí nastavenľ obou parametrů vypadá tak, že umožňují doručovánľ příkazům a souborům jak ze souborů aliasů, tak i souborů forward, nikoli však ze zahrnutých (include) souborů; to z bezpečnostnľch důvodů. Chcete-li úplně zakázat doručovánľ příkazům a souborům z vaší databáze aliasů, nastavte tyto parametry na prázdné hodnoty: al low mai l to commands -
-
-
a l low ma i l to f i l e s
=
=
Chcete-li zpřľstupnit doručovánľ přľkazům a souborům ve všech mechanismech aliasů, nastavte parametry takto: a l l ow_mai l_to_commands a l l ow_mai l_to_f i l e s
=
=
a l i a s , forward, include
a l i a s , forward, include
Toto nastavenľ odpovľdá výchozímu chovánľ systému Sendmail. Může však otevřľt přľ stup ke zranitelným správcům e-mailových konferencľ (mailing-lists), které lze zmást takovým způsobem, že jako novou cílovou adresu přidají nějaký název souboru nebo příkaz. Nepotřebujete-li dodatečnou volbu zahrnutí pro soubory a přľkazy, je nejlepší neměnit výchozí nastavenľ Postfixu.
Důležité aliasy Existuje několik běžných aliasů, které jsou standardně nastaveny. Podle konvence směřují tyto systémové aliasy na účet root. Musíte tedy zajistit pravidelné čtenľ pošty uživatele root. Toho se obvykle dosahuje tím způsobem, že se vytvořľ alias pro root v normálnľm přihlašovacľm účtu osoby nebo osob, které zodpovľdají za správu systému. RFC 2 1 42 definuje několik názvů pOštovnľch schránek, které by měly být ve všech doménách v závislosti na tom, které služby provozují na internetu. Minimálně byste
měli mít alias postmaster a měli byste se také podívat do zmíněného dokumentu RFC a zjistit, zda nebude vhodné vytvořit i nějaké další aliasy.
Důležité úvahy o konfiguraci Na začátku této kapitoly j sme si řekli, že Postfix ke správnému fungování vyžaduje jen minimální změny konfigurace. Podle toho, jak plánujete svůj systém Postfix používat, můžete zvážit i některé další běžné volby. Tento oddíl popisuje, jak se váš systém iden tifikuje, a následně se věnuje velmi důležitému tématu řízení relay.
Konfigurace identity MlA Bez ohledu na to, jakým způsobem budete Postfix využívat, se musíte podívat na čtyři parametry související s hostitelským názvem a doménou vašeho počítače: myhostname, mydomain, myorigin a mydestination.
Parametry myhostname a mydomain Význam a důležitost parametru myhostname jsme si popsali již dříve v této kapitole. Není-li myhostname zadán, Postfix pomocí funkce gethostname zjistí, jaký je hostitelský název vašeho systému. Nahlásí-li váš systém správně plně kvalifikovaný název hostite le, můžete nechat parametr myhos tname v konfiguračním souboru bez zadání. Některé systémy ale nemusejí být řádně nastaveny nebo nemusejí hlásit plně kvalifikovanou verzi názvu hostitele. V takových případech můžete bud' nastavit myhostname na plně kvalifikovaný název hostitele, nebo mydomain na doménu vašeho systému. Je-li explicit ně zadán parametr mydomain, Postfix automaticky nastaví myhos tname na určený název domény spojený s lokálním názvem hostitele hlášeným funkcí gethostname, čímž vytvoří plně kvalifikovaný název hostitele. Nastavíte-li myhos tname na plně kvalifikovaný hostitelský název systému, přičemž však vynecháte mydoma in, Postfix použije k automatickému nastavení mydomain hodnotu myhostname bez první komponenty plně kvalifikovaného názvu hostitele. Kupříkladu hodnota maiLexample.com parametru myhos tname způsobí, že mydomain bude mít hodno tu example.com, pokud jej tedy přímo nenastavíte na jiný údaj . Podobně platí, že název hostitele maiL'!J.example.com bude převeden na hodnotu '!).example.com. Jestliže váš systém nehlásí svůj plně kvalifikovaný název a nenastavíte parametry mydoma in ani myhos tname, pak Postfix nahlásí v protokolovém souboru potíže. Viz odchl Protokolování dále.
Parametr myorigin Když vaši uživatelé odesílají nebo přijímají poštu prostřednictvím systému Postfix, aniž by na obálce neboli v hlavičkových adresách byl uveden název domény, pak parametr myorigin stanoví, jaký doménový název se má přidat. Standardně se používá hodno ta myhostname. Běží-li Postfix na systému, jehož názvem hostitele je maiL example. com, pak mají zprávy od uživatele kde nt adresu původu [email protected]. Uživatelé
však často chtějí odesílat poštu z názvu domény bez doplňkových informacích o hostiteli (kdenf@,example.com namísto kdenf@,maiLexample.com). V takovém případě nastavte myorigin na hodnotu $mydomain: myorigin
=
$mydoma in
Parametr mydestination Parametr mydest ination uvádí všechny domény, pro něž bude váš systém Postfix přijí mat poštu a doručovat ji lokálním uživatelům. Postfix ve výchozím stavu přijímá poštu určenou pro $myhostname a localhost . $mydomain. Požadujete-li po svém systému příjem pošty pro celou doménu a nikoli jen jednoho na ní běžícího hostitele, přidejte na tento seznam ještě $mydoma in: mydestination
=
$myhostname , localhos t . $mydoma i n , $mydomai n
Nyní může váš poštovní server fungovat jako brána příjmu veškeré pošty pro zadanou doménu.
Řízení relay Kromě příjmu pošty a doručování zpráv lokálním uživatelům dokáže Postfix také postu povat (relay) zprávy na jiné systémy. Je velmi důležité omezit to, kdo může postupovat zprávy přes váš systém. Systémy na vaší síti mohou vyžadovat schopnost odesílat zprávy kamkoli, vy ale určitě nechcete poskytovat stejnou službu také zbytku světa. Řízení relay je důležitou záležitostí související se správou elektronické pošty - kvůli nevyžádané hro madné poště (Unsolicited Bulk Email - UBE) neboli spamu. (Další informace najdete v jedenácté kapitole.) Spammeři si obvykle najdou nějaký kvalitně připojený systém, který jim umožní postupování pošty. Vy musíte zajistit, aby funkci relay pošty vašeho systému nemohl využívat nikdo neautorizovaný. Když necháte systém nakonfigurovaný jako otevřené relay, nejenže tím přispějete k problémům s nevyžádanou poštou, ale navíc se váš vlastní počítač může stát nepoužitelným, když jej budou zneužívat spammeři. Můžete také zjistit, že ostatní systémy začínají odmítat poštu od vás, jak zjišťují, že jste zdrojem nevyžádaných zpráv. Odmítnou spam i normální zprávy odesílané vašimi systémy. Poš tovní servery, které umožňují všem předávání pošty, se označují za open rel'!}s.
Omezení přístupu relay Postfix standardně není systémem open relay. Parametry mynetworks _ style a mynetworks určují, jaké jiné systémy mohou používat váš poštovní server k odesílání zpráv. Výchozí konfigurace umožňuje předávání pouze z jiných počítačů připojených do téže podsítě IP, v jaké je i váš server. Rozsah adres, které mohou používat funkci relay, máte mož nost zúžit nebo rozšířit nastavením parametru mynetworks _style. Dáváte-li přednost omezení relay jen na lokální počítač, nastavte mynetworks _style na hodnotu "host". Můžete rovněž nastavit mynetworks_style na hodnotu "class", čímž umožníte relay všem hostitelům v téže třídě A, B nebo C sítě, jako je váš server. V řadě sítí otevírá nastayení
třídy funkci relay příliš mnoha systémům. Neznáte-li význam tříd adres IP, zůstaňte raději u výchozího nastavení "subnet" nebo restriktivnějšího "host". Alternativně můžete explicitně zadat hostitele, kterým má být umožněno postupování pošty, nastavením parametru mynetworks. Zadáte-li mynetworks, pak se parametr my networks style ignoruje. Máte možnost zadat jednotlivé adresy IP nebo specifikovat podsítě zipise� sít'/maska sítě - kupHkladu 1 92.1 68. 1 00.0/28. Tento parametr se vám bude hodit, potřebujete-li zajišťovat relay pošty hostitelům mimo vaši síť, protože zde můžete uvést jednotlivé adresy IP bez ohledu na jejich vztah k vaší vlastní podsíti. Chcete-li kupříkladu zajišťovat postupování vzdáleným uživatelům, stačí jen do tohoto seznamu přidat pHslušnou adresu IP. V takovém pHpadě však musejí mít vaši vzdálení uživatelé nějakou statickou adresu IP, nebo alespoň adresu přiřazovanou z omezeného rozsahu adres. Nemají-li vaši vzdálení uživatelé statické adresy IP, pak budete muset nakonfigurovat nějaký druh ověřování SMTP.
Ověřování SMTP Všechny techniky ověřování SMTP zavádějí své vlastní komplikace. Před volbou ur čité techniky ověřování je rozumné zvážit jednodušší možnosti. Mohou vaši vzdálení uživatelé nějakým způsobem získat statické adresy IP? Mohou se obrátit na jiný server SMTP? Možná poskytovatel pHstupu vašich vzdálených uživatelů nabízí také nějaký server SMTP. Může vás napadnou povolovat předávání pošty v pHpadech, kdy adresa odesílatele v obálce zprávy patří do lokální domény. To ale nedělejte. Adresy na obálkách lze velmi snadno falšovat a spammeři umějí za tímto účelem využívat lokální adresy. Jakmile svůj poštovní server takto nastavíte, stáváte se systémem open relay.
Řešení s dynamickými adresami IP Dvanáctá kapitola popisuje použití SASL k ověřování SMTP. SASL je obecný pro tokol definující, jak si mohou server a klient vyměnit ověřovací údaje. Vyžaduje, aby byly k vašemu serveru SMTP připojené další knihovny. Existují tři alternativy SASL, které pracují podobně: pop-bifore-smtp, DRAe (Dynamic Relay Authorization Control) a WHOSON. Každá z těchto metod je určena pro práci s klienty, kteH mají dynamicky přiřazované adresy IP. Vyžadují, aby se uživatel nejprve přihlásil k serveru POP /IMAP, čímž vašemu systému nebo síti dodá aktuálně přiřazenou adresu IP. Adresa IP klienta se předá serveru SMTP, jenž následně povolí relay pošty z klientského systému po nastavitelnou dobu. Tato technika je pro koncové uživatele z větší části transparentní, nejprve se však musejí podívat na nové zprávy (přihlásit se k serveru POP /IMAP), ještě než se pokusí nějaké odeslat. Metody pop-before-smtp a DRAC fungují ve spojení s Postfixem tak, že dynamicky aktualizují vyhledávací tabulku Postfixu, do níž přidávají nové adresy ověřených uživa telů a zase je odstraňují po uplynutí zadané časové periody. Postfix nepotřebuje žádné speciální knihovny ani nastavení. Stačí jen zadat, že má sledovat vyhledávací tabulku, která se aktualizuje při přihlašování uživatelů přes váš server POP /IMAP' Oproti tomu
váš server POP /IMAP může ke správnému fungování vyžadovat změny a rekompilaci. DRAC se od pop-before-smtp liší v tom, že dokáže pracovat přes síť, zatímco pop -before-smtp vyžaduje, aby byl daný server POP /IMAP instalován na témže systému, jako je server SMTP. WHOSON je vlastně protokol poskytující rozhraní serverům POP /IMAP i SMTP. Na své síti musíte provozovat server WHOSON a navíc si musíte obstarat doplněk přidá vající do PostfIxu nový typ vyhledávání. Po sestavení PostfIxu s tímto rozšířením dokáže váš systém komunikovat se serverem WHOSON a stanovovat, zda je možné z určité klientské adresy IP poštu postupovat dále.
Ověřování certifikáty Můžete rovněž zvážit použití ověřování klientskými certifIkáty. (Ú plný popis Transport Layer Security a certifIkátů najdete ve třinácté kapitole.) CertifIkáty obvykle považujeme za prostředek šifrování komunikace, lze je ale také používat jako silnou metodu ověřo vání. Vyžadují však správu certifIkátů a podporu protokolu TLS . Ž ádný z těchto doplňků není ideálním řešením. Všechny vyžadují zkompilování doda tečného kódu k existujícím démonům a mohou následně vyžadovat speciální přístup pro zápis do systémových souborů. Na vytížené správce systémů navíc kladou další nároky. Nemůžete-li použít žádnou z výše zmíněných alternativ bez ověřování nebo požadujete-li, aby pošta všech vašich uživatelů prošla systémem bez ohledu na to, kde na internetu se nacházejí, pak je zřejmě SASL řešením nabízejícím nejspolehlivější a nejškálovatelnější metodu ověřování uživatelů.
Správa Provozování poštovrubo serveru představuje neustálou správu. Nemůžete tuto službu jen spustit a zapomenou na ni. Musíte zajišťovat periodické úkoly správy a měli byste rovněž pravidelně zjišťovat, zda nemá váš systém nějaké problémy. V tomto oddílu si popíšeme mnohé z podobných činností a jejich zajištění v PostfIxu. PostfIx nabízí prostřednictvím příkazu posifix utilitu umožňující prověřit řadu aspektů vaší instalace. Tento příkaz zjišťuje problémy s nastavením, zkoumá vlastnictví adresářů a souborů a vytváří všechny chybějící adresáře. Vykonání # postfix check
nesmí na správně instalovaném systému hlásit žádné potíže. J sou-li nějaké problémy, tento příkaz vám je nahlásí na obrazovce i v protokolovém souboru.
Protokolování Jelikož je PostfIx dlouhodobě běžící program, měli byste s e pravidelně dívat d o pro tokolového souboru svého systému a hledat zde varování nebo jiné zprávy. Na vašem systému se mohou změnit věci, které ovlivní i PostfIx. Téměř veškerá aktivita Postf1Xu, ať
už je nebo není úspěšná, se protokoluje. Kdykoli spustíte nebo znovu nahrajete Postfix, je rozumné podívat se na zprávy v proto kolovém souboru.
Protokolování Postfixu zajišťuje démon
.ryslog vašeho
systému. Systémové soubory
protokolů j sou aspektem správy systému, která je v různých verzích Unixu odlišná,
takže k plnému pochopení protokolování Postfixu si budete muset prostudovat také
dokumentaci vašeho systému.
Obecně platí, že démon syslog (syslogd) přijímá zprávy od různých systémových procesů
a zapisuje je na příslušná cílová místa (často do souboru) . syslogd uspořádává zprávy
podle jejich důležitosti a aplikace nebo nástroje, který je generuje. Soubor
letci .ryslog.conf
řľká démonu syslogd, kam se mají jednotlivé typy zpráv zapisovat. Protokolovacím
nástrojem využívaným Postfixem je mai l . Nevíte-li, kde hledat zprávy protokolované
Postfixem, pak vás správným směrem zaměří soubor
letci .ryslog.conf
Některé operační
systémy konvenčně protokolují téměř vše do jediného souboru, napřľklad
I varl logl .ryslog,
zatímco jiné upřednostňují oddělování zpráv podle aplikací nebo služeb, takže zprávy
Postfixu se ukládají např. do souboru můžete v souboru
I varl Iog1 mmllog. V případě těchto druhých systémů letci .ryslog.conf najít podobné zadání:
- /var/ log/ma i l log
ma i l . *
Jakmile zjistíte umístění souboru protokolu pošty, pravidelně jej kontrolujte. Měli byste se do něž podívat přinejmenším každý den, to si ale musíte určit sami podle objemu
pošty zpracovávané vaším serverem a zavedeného schématu rotování protokolů. Ke zjištění zajímavých zpráv Postfixu můžete použít přľkaz $ eqrep
I
(reject I warninq I error l fatal I panicI
je-li tedy vašľm proto kolovým souborem svého souboru protokolování.
:
I
/var/loq/ruilloq
I varl logl maillog. V jiném případě zadej te název
Spouštění, zastavování a restart Postfixu V této kapitole j ste již viděli, jak spustit Postfix pomocí přľkazu pOSifix. t postfix start
Jakmile Postfix běží, budete jej muset po změnách v souborech přinutit k opakovanému
main.if nebo master.cf načtení konfigurace vykonáním přľkazu posifix s argumentem
reload: # postfix reload
Postfix správně ukončí běžící procesy, jakmile dokončí úkoly, na nichž pracují, znovu
načte své konfigurační soubory a bez přerušení pokračuje v příjmu pošty.
Při spouštění nebo opakovaném nahrávání Postfixu je nejdůležitější prověřit systémový
protokol a podívat se, zda Postfix nehlásí nějaké chyby nebo varování.
Postfix můžete zastavit pomocí argumentu stop. Spuštěné procesy ještě dokončí všechny
úkoly, na nichž pracují, a pak skončí:
t
postfix stop
Postfix byste neměli zastavovat a spouštět za situace, kdy stačí opakované nahrání.
Operace zastavení, restartu a nahrání také nezadávejte často, protože mají nepříznivý
dopad na výkonnost.
Spuštění Postfixu při startu systému Většina systémů při startu automaticky spouští Postfix, což je dáno kompatibilitou tohoto programu se systémem Sendmail. Sendmail se většinou spouští při startu po
dobným příkazem:
sendma i l -bd -q15m
Přľkaz
sendmail Postfixu
rozumľ téměř všem volbám jako Sendmail, takže obsahuje-li
váš systém skripty spouštějící Sendmail, spustí také Postfix. Jednou z běžných voleb
Sendmailu, kterou Postfix ignoruje, je -q (Sendmail ji používá ke specifikování doby
mezi skeny fronty) . Doba mezi skeny fronty se v Postfixu nastavuje v souboru
parametrem queueJun _delay, jehož výchozí hodnota je 1 000 sekund.
main.cf
Váš systém může zahrnovat konfigurační volbu zapnutí automatického spuštění Send
mailu. Po instalaci Postfixu by měla aktivace této volby postačovat k zajištění spuštění Postfixu během inicializace systému. Různé verze Unixu obsahují odlišné idiomy kon
figurace serveru na spouštění procesů během inicializace systému. Nefunguje-li vám skript spuštění Sendmailu nebo dáváte-li přednost použití skriptu přímo pro Postfix,
můžete si jednoduše vytvořit spouštěcí skript.
Udělej si sám Požadavky a konvence inicializačních skriptů se v různých verzích Unixu odlišují. MÍs
to a způsob přidání voleb spouštění si tedy budete muset zjistit z dokumentace svého systému. Na platformách typu System V si můžete nainstalovat skript podobný tomu
v přľkladu 4-1 .
Pfíklod 4-1. UkáZkotý inicializalní skriptpro SysV t ! / sbin/sh t
* Nastavte cestu k vašim příkazům protokolování a pos t fixu .
#
LOGGER= " /usr /bin / l ogge r " POSTFIX= " / u s r / sbin /pos t f i x " rc=O if [ ! - f $ POSTFIX 1 ; then $ LOGGER -t $0 - s -p mai l . err "Ne l z e nalézt Pos t f i x " exit ( 1 ) fi
i f [ ! - f /etc/po s t f i x /ma in . c f 1 ; then $LOGGER -t $0 - s -p ma i l . e rr "Nelze nalézt kon figuraci Pos t f ixu· exit ( 1 )
fi case " $ 1 " in start ) echo -n " Spouštění Postfixu" $ POSTFIX start rc = $ ? ' echo " . "
stop) echo -n " Zas tavování Pos tfixu" $ POSTFI X s top rc = $ ? echo " . " ;i
re start ) echo -n "Restartování Pos t fixu " $ POSTFIX reload rc = $ ? echo " . "
*) echo " Použ i t í : $ 0 ( start l s top l restart ) " rc = l esac exit $rc
Podle používaného prostředí může být vhodné k našemu příkladu přidat doplňkové
předběžné a následné kontroly. Tento skript musíte nainstalovat do správného adre sáře ve svém systému, kterým je obvykle
/sbin/init.d.
/ etc/ init.d, i když kupříkladu HP-UX používá
Jakmile je s kript umístěn, budete ještě muset vytvořit jeho symbolický
odkaz v adresáři s příslušnou úrovní spouštění na serveru (často
/ etc/ rc2.d) .
Když
například výše uvedený skript nazvete postftx, vytvořte symbolický odkaz podobný následujícímu:
t ln -I letc/init. d/poltfix letc/init . d/rc2 . d/S95poltfix
Detaily ohledně své platformy najdete v dokumentaci.
Správa fronty Fronta Postfixu je také důležitou součástí správy elektronické pošty. Více se o správci fronty Postf1Xu dozvíte v páté kapitole.
Soubor master.cf Démon
master Postfixu
spouští všechny ostatní postf1Xové služby podle potřeby. Tyto
služby a způsob jejich spouštění se zadávají v souboru
master.if.
Hlavní konfigurační soubor funguje stejně jako jiné soubory nastavení Postfixu. Komentář se označuje znakem t na začátku řádku. Komentáře a prázdné řádky se přeskakují. Dlouhé řádky mohou pokračovat na následujících řádcích, které začínají prázdným znakem. Příklad 4-2 je ukázkovým souborem. Jednotlivé sloupce zahrnují specifické konfigurační volby. Proškrtnutí ve sloupci značí použití výchozího nastavení. Některé výchozí hod noty pocházejí z parametrů v souboru
main.cf.
Pfík1ad 4-2. UIeáZkotý soubor ",aster.if t=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
t service type private unpriv chroot wa keup ( yes )
t
name t= =
( yes )
( yes )
smtp
inet
n
y
pickup
f i to
n
n
cIeanup
unix
n
n
qmgr
f i to
n
n
rewrite
unix
-
n
bounce
unix
-
n
( neve r )
=
=
=
=
=
=
=
=
maxproc command + args (100)
smtpd 60
1
O
pickup cIeanup qmgr
300
trivial - rewrite
O
bounce
O
bounce
de fer
unix
-
n
flush
unix
n
n
proxymap
unix
-
n
proxymap
smtp
unix
-
y
smtp
reIay
unix
-
y
smtp
1000?
O
flush
-o smtp_heIo_t imeout = 5 -o smtp_connect_timeout = 5 showq
unix
n
n
showq
error
unix
-
n
error
10caI
unix
-
n
n
10caI
virtual
unix
-
n
n
virtual
Imtp
unix
n
Irntp
p�e n n mai I drop unix fIags = DRhu user =vmai l argv= / u s r / Iocal/bin/mai ldrop -d $ ( recipient ) cyrus
unix
-
n
n
pipe
user = cyrus argv = / cyrus/bin/deI iver -e - r $ ( sende r ) - m $ ( extension ) $ ( user ) uucp
unix
-
n
n
fIags = Fqhu user =uucp argv= uux - r -n
pipe -z
-a$ sender -
$ nexthop ! rmai l ( $ recipien t )
Následující výčet popisuje jednotlivé sloupce v souboru včetně jejich výchozích na stavení:
service name (název sluŽi?Y) Název komponenty. Způsob vytváření názvů služeb závisí na typu služby, jak je zadán sloupcem t ransport type (viz dále).
transport type (typ transportu) Platnými transportními typy j sou inet, unix a f i to. Každý představuje určitou metodu komunikace s danou službou.
Typ inet představuje síťové sokety. Komponenta síťového soketu může komu nikovat s jinými procesy na témže počítači nebo ostatními počítači na síti. Síťové sokety využívají kombinaci adresy IP systému a portu používaného pro připojení. Běžně se zapisují v kombinaci hostitele nebo adresy IP a dvojtečkou odděleného portu. Názvem přenosu inet v souboru master.ifje soket zadaný jako hostitel a port. Tento název může být tvořen pouze portem, je-li na lokálním systému. Jako hostitele můžete zadat jeho název nebo adresu IP a port může být skutečným číslem portu nebo jeho symbolickým názvem. (Symbolické názvy portů pocházejí ze souboru letci services. Viz dokumentace.) Typ unix představuje sokety unixové domény a fifo zase pojmenované roury. Oba typy se používají pro komunikaci mezi procesy na jednom počítači. Jak sokety unixové domény, tak i FIFa využívají ke komunikaci speciální soubory. Názvy komponent unix a fifo odpovídají stejným pravidlům vytváření názvů, jaká platí pro unixové názvy souborů bez adresářů. Postfix vytváří s využitím názvu služby speciální komunikační soubory. Sokety unixové domény a pojmenované roury jsou standardní unixové nástroje komunikace mezi procesy. Chcete-li se o nich dozvědět více, najděte si nějakou knihu o programování Unixu. Tabulka 4- 1 představuje příklady platných názvů služeb pro různé typy přenosů. Tabulko 4-1: Příklad nátf'Ň služeb Název služby
Typ transportu
Popis
smtp
Název démonu smtpd. Tento název je symbolickým názvem portu SMTP.
1 27.0.0. 1 : 1 0025
inet inet
Komponenta naslouchající na rozhraní zpětné smyčky na portu 1 0025.
465
inet
Komponenta naslouchající na lokálním hostiteli na portu 465.
maildrop
unix
Komponenta volaná prostřednictvím démonu pipe Postfixu.
pickup
fifo
Komponenta FIFO Postfixu.
private (soukrond) Přístup k některým komponentám je omezen na samotný systém Postfix. Tento sloupec je označen y v případě soukromého přístupu (standardně) nebo n u veřej ného přístupu. Komponenty inet musejí mít povolen veřejný přístup zadáním n, protože síťové sokety musejí být k dispozici jiným procesům. unpri v (neprivilegoVa1if) Komponenty Postfixu běží s nejmenšími oprávněními nezbytnými k naplňování sta novených úkolů. Svou identitu nastavují na tu odpovídající neprivilegovanému účtu zadanému parametrem mai l_owner. Výchozí instalace používá pos t fix. Standardní hodnota y v tomto sloupci značí, že daná služba běží pod normálním neprivilego vaným účtem. Služby vyžadující oprávnění root jsou označeny písmenem n. chroot (i!"ěna kořenového adresáře) U mnoha komponent lze v zájmu zvýšení zabezpečení změnit jejich kořenový adresář (vykonat operaci chroot) . Umístění chroot se zadává parametrem queue_directory v souboru master.if. Služby standardně běží v prostředí chroot; normální instalace však
označuje všechny komponenty písmenem n, takže při jejich běhu se nemění koře nový adresář. Změna kořenového adresáře služby znamená výrazné zkomplikování nastavení, kterému byste měli plně porozumět, než se pokusíte tohoto dodatečného zabezpečení využít. Více si o provozování služeb Postfixu v prostředí chroot povíme v oddílu Po'kaz chroot. wakeup (probuzení) Určité komponenty vyžadují časovač probouzení, který v nich v zadaném intervalu vyvolá nějakou akci. Jedním poKladem je démon pickup. Při svém výchozím nasta vení 60 sekund jej démon master probouzí každou minutu, aby se podíval, zda do fronty umístěné pošty nepřibyly nějaké nové zprávy. Dalšími službami, které vyža dují probouzení, jsou démony qmgr ajlush. Na konec času lze přidat znak otaZnl'ku (?) indikující, že se má událost probuzení odeslat, pouze je-li daná komponenta využívána. Hodnota O časového intervalu značí, že probouzení není zapotřebí. Výchozí hodnotou je právě nula, protože probouzení vyžadují jen ony tři zmíněné komponenty. Hodnoty nastavené v distribuci Postfixu by měly vyhovovat téměř všem situacím. U jiných služeb by nemělo být probouzení aktivované. maxproc (nqtjfe procesů) Omezuje počet procesů, které lze současně zavolat. Není-li zadána zde, pak se tato hodnota přebírá z parametru defaul t_process _l imi t v souboru main.if, který má normálně hodnotu 1 00. Nastavení O značí, že počet procesů není omezen. Provo zujete-li PostflX na systému s omezenými prostředky nebo chcete-li optimalizovat jeho různé aspekty, můžete si nastavení maxproc upravit. command (příkaz) Vlastní po'kaz použitý k vykonání služby je uveden v posledním sloupci. Po'kaz je specifikován bez cesty, protože se očekává jeho existence v adresáři démonů Post fixu zadaném parametrem daemon di rectory v souboru main.if. Tímto adresářem je standardně / usr/ libexec/postftx. Všechny po'kazy PostflXu lze zadat s jednou nebo více volbami v které zapínají stále detailnější protokolovací informace. Ty mohou být užitečné v případě řešení nějakého problému. Informace pro ladicí program můžete rovněž aktivovat volbou -D. Další informace o ladění najdete v souboru DEBUG_README, jenž je součástí distribuce Postfixu. _
-
,
Každý z démonů Postfixu má svou vlastní sadu voleb, které lze zadat za po'kazem samotným. (Více se o možných volbách jednotlivých démonů dozvíte z jejich manu álových stránek.) Ve sloupci příkazů lze zadávat pouze postflXové po'kazy. Chcete-li vykonávat své vlastní po'kazy, použijte démonpipe Postfixu. Další informace najdete v manuálové stránce pipe PostflXU. Pokud main.if nabízí konfigurační informace pro určitou komponentu, můžete tuto informaci překrýt v souboru master.if zadáním alternativy ve volbě -o. Chcete-li kupří kladu vytvořit specializovanou klientskou službu smtp, přidejte do souboru master.ifdalší zadání podobné následujícímu: smtp-quick
unix
-
-o smtp_connect_timeout= 5 s
n
smtp
Časové jednotky Některé parametry Postfixu přijímají jako své hodnoty časové období. Časové hod noty lze v Postfixu zadat ve spojení s příslušnou zkratkou označující jejich jednotky:
ý
s (sekund ), m (minuty), h (hodiny), d (dny) nebo w (týdny) . Není-li zadána časová jednotka, pak každý časový parametr využije svou výchozí jednotku, jejíž zadání předpokládá. Výchozí hodnotu konkrétnI'ho parametru zjistíte z dokumentace; můžete ale také vždy zadat s časem i jeho jednotku.
Mezi parametrem, znakem rovnítka a přiřazenou hodnotou nesmějI' být žádné mezery. V našem příkladu je smtp-quick specializovanou službou smtp, která nečeká na reakci serveru tak dlouho, když se snaží o připojení. Tento klient SMTP odpovľdá nastavení v souboru
main.if, používá však jinou hodnotu parametru smtp_connect_timeout. Další
přľklady jsou j eště v této kapitole i v jiných kapitolách knihy.
Omezení příjmu Démon smtpd může příchozI' poštu mnoha způsoby omezovat. Tato omezení jsou nasta
vitelná prostřednictvťm několika parametrů v souboru main.cf. Máte možnost omezit veli kost zpráv, počet příjemců jednoho doručení a délku řádků ve zprávě. Lze rovněž omezit počet chyb povolených pro jednoho klienta, než dojde k přerušení komunikace. Chcete-li omezit počet příjemců jediné zprávy, použijte parametr smtpd_recipient_limi t. Výchozím nastavením je 1 000 příjemců, což by mělo běžnému provozu dostačovat. Parametr me s s age_ si ze_l imit limituje velikost zpráv, jaké bude váš systém přijímat. Výchozí hodnotou je 1 0 MB. Máte-li omezený diskový nebo paměťový prostor, mů žete tento údaj snížit. Přijímají-li naopak vaši uživatelé rozsáhlé přílohy, můžete jej zase zvýšit. Stále častěj ší chyby od jednoho klienta mohou značit problém nebo útok. Postftx ak tualizuje čítač chyb a potenciální problémy s klienty řeší tím způsobem, že s každou chybou zavádí zpoždění. Tato zpoždění mohou pomoci v ochraně vašeho systému před nesprávně nastavenými nebo útočícími klienty. Se vzrůstajícím počtem chyb roste také délka každého zpoždění. Počáteční zpoždění je zadáno parametrem smtpd_error_ sleep_
time s výchozí hodnotu jedné sekundy. Jakmile počet chyb překročí hodnotu zadanou v smtpd_ soft _error_l imi t, Postfix zvýší zpoždění o sekundu při každé chybě, takže bude postupně docházet k nárůstu zpoždění. Jakmile nakonec počet chyb dosáhne hodnoty zadané v parametru smtpd_hard_error_limi t, Postfix na klienta zanevře a odpojí se. Když se nějaký zákeřný program připojí k vašemu poštovnímu serveru a bude mu ode sílat nesmyslné přľkazy za účelem jeho zhroucení, budou se dané přľkazy jevit Postftxu jako chyby od nevychovaného klienta. Předpokládejme následující hodnoty parametrů zpoždění:
smtpd_e rror_s leep_t ime
=
smtpd_soft_e rror_l imit
=
ls 10
smtpd_hard_e rror_l imit
=
20
V tomto případě n a začátku čeká PostflX jednu sekundu (smtpd_error_ s leep_ time) po každé chybě, než klientovi odpoví. Po deseti takových zkouškách (smtpd_ soft_error_
l imi t), začne PostflX zvyšovat délku každého zpoždění. Po 1 1 chybách bude PostflX čekat 1 1 sekund. Po 1 2 chybách to již bude 1 2 sekund atd. Jakmile dosáhne počet chyb hodnoty 20 (smtpd_hard_error_l imi t), PostflX se odpojí a zákeřný program tak odřízne. Když se tento program znovu připojí, bude s ním zacházeno stejně, jakmile začne činit problémy.
Přepisování adres Postfix se snaží porozumět adresám elektronické pošty v e-mailu a zapisuje je ve stan dardním formátu RFC 2822. K určitému přepisování adres dochází automaticky. Již dříve v této kapitole jsme viděli, jak Postfix přidává myorigin k lokálnímu názvu bez doménové části. Postfix rovněž přidává hodnotu mydomain k adresám, jež zahrnují pouze hostitelskou část bez doménového názvu. Tím se opraví adresy ve formátu ledent@hostitel na formu
[email protected].
Kanonické adresy Postfix nabízí ještě další typ přepisování adresy, který vám umožňuje mapovat nesourodé adresy na standardní formát na celém vašem sídle. Parametr canonical_maps směřuje na vyhledávací tabulku přiřazení adres. (I když má slovo
kanonickj mnoho významů, mezi
počítačovými profesionály značí "obvyklý, standardní, normální".) Vytvářejí-li různé poštovní systémy na vaší síti adresy odlišnými způsoby, můžete je všechny postupovat přes svou postflXovou bránu a nechat ji převést adresy na standardní formát. Kanonické mapy se často používají ke změně adres z interrubo tvaru na veřejný. Do své kanonické tabulky začleňte zadání podobná tomu následujícímu: jl jl /etc /pos t f i x / canon ical #
pabe la rd@ example . com
peter . abe lard@example . com
hfulbert@ example . com
heloi se . fulbert@ example . com
Můžete také adresy úplně přepisovat. i
jl /etc/po s t f i x / canon ical t
pabe lard@ example . com
abe lard@ore i l l y . com
h fulbert@ exampl e . com
he loise@ore i l l y . com
V souboru
main.if nasměrujte parametr canonical_maps na soubor canonical:
canon ica l_maps
=
hash : /etc/postfix/ canon ical
Vypnutí dokončování adres Rozšiřování nedokončených adres elektronické pošty v Postfixu je pro koncové uživatele občas matoucí. Hostí-li váš systém doménu example.com a přijme-li e-mai lovou zprlivu, v níž hlavička From: obsahuje neúplnou adresu jako: From : Marketing To : kdent@ example . com
Postfix zajistí běžnou opravu a hlavičku zprávy změní na: From : Marketing@ example . com To : kdent@ example . com
Neúplné adresy, jako je ta v našem příkladu, často zneužívají spammeři. Když se pak někteří naivní uživatelé podívají na upravenou adresu, předpokládají, že pří slušná nevyžádaná zpráva má původ na vašem serveru. Postfix lze nakonfigurovat tak, aby vaši doménu nepřidával. To ale nebudete chtít učinit, pokud tedy není váš poštovní systém používán výhradně jako poštovní brána a z počítače samotného se žádné zprávy neodesílají. Mnoho aplikací očekává adresy odpovídající standardu RFC 2822 a nej sou-li vaše adresy úplné, můžete narazit na potíže. Chcete-li Postfixu zabránit v přidávání domén v myo r i g i n nebo mydoma i n k částečným adresám, můžete upravit parametry append_at_myorigin a append_ dot_mydomain: append_at_myorigin append_dot_mydomain
no
= =
no
To ale ve většině případů není vhodné. Nejen mnoho ostatních aplikací zpracování zpráv elektronické pošty, ale i Postfix sám předpokládá, že adresy mají správný formát. Lepším řešením je odmítnout zprávy, které nezahrnují úplné e-mailové adresy. Další informace o problematické poště najdete v jedenácté kapitole.
Nezapomeňte vykonat znovu postmap na svém souboru canonical a opakovaně nahrát Postfix, aby rozpoznal změny v main.if. # postmap /etc/postfix/canonical # postfix reload
Parametr canon ical_maps ovlivňuje všechny adresy včetně hlaviček obálky a zprávy. Najde-li PostflX nějakou shodu, pak změnu uskuteční. Požadujete-li, aby změny ovlivnily pouze adresy odesílatelů nebo příjemců, můžete využít doplňkové parametry sender_ca nonical_maps a recipient_canonical_maps PostflXU. Fungují stejně jako canonical_maps, ale pouze na příslušných třídách adres. Použijete-li některý z těchto dvou parametrů navíc k canonical_maps, pak Postfix nejprve opraví adresy podle sender_canonical_map s a recipient_canonical_maps, následně pak podle canonical_maps .
Maskování názvů hostitelů Princip maskování adres spočívá v tom, že se skryjí názvy interních hostitelů a zajistí se, aby všechny adresy zdánlivě pocházely od samotného systému brány. Můžete mít kupříkladu interní systémy, které využívají server Postfix j ako bránu. Když se odesílá pošta z těchto systémů a adresy odesílatelů zahrnují plně kvalifikovaný název hostitele, můžete nechat zobrazovat adresy pouze s názvem domény. Parametr masquerade doma ins ořezává názvy hostitelů a ponechává jen jejich jednodušší doménové názvy. _
Tento parametr přebírá seznam domén. Jakákoli adresa, jejíž plně kvalifikovaný název hostitele odpovídá doménové části, se ořízne jen na doménový název: masquerade_domains
=
example . com
Adresy jako [email protected] [email protected] se převedou na heloi [email protected] a [email protected]. Můžete rovněž zadat více domén a subdomén. PostflX porovnává adresy s maskovanými názvy domén v pořadí, v jakém je uvedete. Představme si síť zahrnující dvě subdomény, acct.example.com a hr.example.com. Chcete, aby adresy z těchto domén zahrnovaly subdomé nu, adresy z jakékoli jiné domény nebo hostitele v síti však mají zobrazovat mateřskou doménu. Nastavte parametr masquerade domains následovně: _
masquerade_doma ins
=
acct . example . com hr . example . com example . com
V případě uvedeného nastavení adresa [email protected] odpovídá acct.examp le.com, takže se převede na [email protected]. [email protected] odpo vídá hr.example.com a stane se [email protected]. Konečně [email protected] odpovídá až poslední hodnotě, example.com, takže se převede na [email protected]. Chcete-li zachovat nějaký název domény, který by se jinak odřízl, můžete před zadanou doménu uvést vykřičník: masquerade_doma ins
=
! i t . example . com, example . com
V takovém případě se doména it. example. com nepřepíše, takže adresa [email protected] zůstane beze změny. Z maskování můžete také vyřadit konkrétní názvy účtů. Chcete-li kupříkladu zachovat beze změny adresu jako [email protected], přidejte do parametru masquerade excep tions příslušný účet: _
masquerade_exceptions
=
adm i n , root
Když pracujete s maskováním, obvykle se aplikuje na všechny adresy obálky a hlavičky, nikoli však na adresy příjemce obálky. To umožňuje dodání pošty adresované specifické mu hostiteli z poštovní brány příslušnému systému, přičemž stále dochází k přepisování adres u zpráv odeslaných z tohoto hostitele. Dáváte-li přednost maskování všech adres, nastavte parametr masquerade classes tak, aby zahrnoval úplný seznam tříd adres roz poznávaných PostflXem: _
masque rade_classes
=
envel ope_recipien t , envel ope_sende r ,
header_sende r , header_recipient
Dávejte si pozor na to, že nastavíte-li masquerade _ classes tímto způsobem, nemusí systém poštovní brány nadále vědět, kam má doručit zprávu původně adresovanou
[email protected], jakmile dojde k jejímu přepsání na [email protected].
Přemístě.ní uživatelé Parametr relocated_maps směřuje na vyhledávací tabulku, do níž můžete vložit seznam adres nebo domén, které se přesunuly na jiné místo: relocated_maps
=
hash : /etc /pos t f i x / relocated
Tato vyhledávací tabulka používá jako klíče staré adresy a jako hodnoty jejich nová umístění. Jakmile je doručena zpráva pro přemístěnou adresu, Postfix odmítne po kus o dodání zprávou zahrnující novou adresu uživatele, jak si ji najde ve vyhledávací tabulce. Můžete rovněž uvést jen doménový název, má-li s vaší zadanou zprávou dojít k odmítnutí u všech příjemců v zadané doméně. Soubor
letcipostjixl relocated obsahuje položky jako:
kdent@ora . com
kdent@ore i l l y . com
heloise@ora . com
hfulbert@ore i l l y . com
@exampl e . com
ore i l l y . com
Zprávy odeslané [email protected] nebo
he/[email protected] jsou odmítnuty chybovou zprávou
zahrnující příslušné nové adresy. Všechny zprávy odeslané na example.com jsou odmítnuty bez ohledu na jejich lokální část. Vracená zpráva říká, že se zadaná adresa změnila na
orei/lY.com.
Neznámí uživatelé Lokální adresa, která není uvedena v mapách přemístěných uživatelů ani jiných a která není ani účtem na systému, je neznámým uživatelem. Když Postfix obdrží poštu pro neznámého uživatele, běžně ji odmítne. Upřednostňujete-li zachytávání všech zpráv odeslaných neexistujícím účtům, můžete využít parametr luserJelay. Nastavte jej na adresu elektronické pošty určenou pro příjem zpráv cílených na neznámé uživatele. Mu síte zároveň nastavit local_ recipient_map s na prázdnou hodnotu, aby Postfix neodmítal poštu pro neznámé uživatele: luser_re lay
=
catcha l l
local_recipient_maps
=
Je-li catcha l l platnou adresou (aliasem nebo uživatelským účtem) na vašem systému, bude přijímat všechny zprávy odeslané neexistujícím uživatelům. Při používání luser_ re
lay si dávejte pozor, protože spammeři často spouštějí slovníkové útoky, kdy zkoušejí enormní seznamy adres s tím, že třeba nějakou platnou na vašem sídle objevL Je-li nakonfigurován parametr luser relay, pak zachytí všechen tento spam. _
Příkaz chroot PostflX zajišťuje několik vrstev zabezpečení. Jednou takovou vrstvou je možnost povolit většině postfixových služeb běžet v prostředí chroot (změněném kořenovém adresáři) . Unixová funkce chroot umožňuje procesům změnit jeho pohled na systém souboru a přístup k němu tím způsobem, že se změní kořenový adresář na jinou cestu, než je normální f. Prvek chroot je přínosný zejména pro procesy, které musejí komunikovat s externími, potenciálně nepřátelskými klienty. Pokud se útočníkovi nějakým způsobem podaří podkopat kupříkladu démon smtpd, pak získá jen velmi omezený přístup k systému souboru. Nastavení prostředí změněného kořenového adresáře je pokročilou funkcí Postfixu, které zavádí další vrstvu komplexnosti, s níž se vy sami nebo váš správce možná nechce potýkat. Obecně platí, že chroot není zapotřebí. Výjimkou jsou sídla používající Postfix ve vysoce zabezpečeném prostředí nebo zvláště vystavené servery, jako jsou vyhrazené firewallové systémy. Všechny procesy Postfixu, které využívají chroot, mění svůj kořenový adresář na adre sář zadaný parametrem queue_directory, jenž má většinou hodnotu I varl spoollpostfix. Když běží nějaký proces se změněným kořenovým adresářem, pak se kupříkladu adresář I varl spoollpostfixlpid změní pro daný proces na Ipid. Tento proces nemůže přistupovat k žádným souborum s výjimkou těch pod jeho novým kořenovým adresářem. Chcete-li změnit kořenový adresář jednotlivých komponent, musíte upravit soubor master.if. Změňte pátý sloupec na y. Volba chroot je nabízena všemi komponentami s výjimkou služeb pipe, virtual, local a proxymap. V příkladu 4-1 je chroot aktivní u klientů a serveru SMfP. Jelikož chroot mění prostředí příslušného procesu, musejí být všechny prostředky vyžadované daným démonem k dispozici pod novým kořenovým adresářem. Bohužel však konkrétní prostředky, které mohou postflXové démony potřebovat, závisejí na vaší platformě. Obecně platí, že Postfix může vyžadovat prostředky poskytující informace o uživatelích (/ etclpasswd), konfiguraci převádění názvů (nsmtch.con! nebo resolv.con.!J, in formace o časové zóně či sdílené knihovny. Některé platformy rovněž vyžadují určité soubory zařízení. Existují také platformě specifické skripty obsažené v distribuci Postfixu. Ty se nacházejí v podadresáři examplesl chroot-setupl hlavního distribučrubo adresáře. Vykonání toho správného skriptu by mělo dostačovat k nastavení prostředí chroot na vašem systému. Není-li pro vaši platformu nabízen odpovídající skript, budete muset trochu experimentovat a sami zjistit vše potřebné. Zvažte všechny výše zmíněné pro středky a podívejte se na ukázkové skripty pro jiné platformy. Jakmile změníte kořenový adresář nějakého procesu, sledujte chybová hlášení v protokolech. Položka podobná pos t f i x / smtp [ 1 5 7 5 ] : fatal : un known serviee : smtp/ tep
znamená, že Postfix nedokáže stanovit, jaký port používá služba smtp. Tuto potíž od straníte umístěním souboru letci services do změněného kořene, tedy jeho zkopírováním do I varl spoollpostfixl etcl services. Podobným způsobem se zprávami v protokolu projevují i jiné problémy.
Neposkytuje-li normální protokol Postfixu dostatek informací, budete muset spustit trasování a sledovat, kde program selže. Vyhledejte si na systému nástroje jako truss, strace a tusc. Tyto nástroje lze použít ke stanovení místa, kde nějaká služba selže, když se pokusí běžet v prostředí chroot. Odhalíte-li, že k selhání dochází kvůli nějaké chybějící komponentě, zkopírujte příslušnou součást do prostředí se změněným kořenovým adresářem. Více se o připojení trasovacích nástrojů k Postfixu dozvíte v souboru DEBUG_README, který je obsažen v Postfixu. Jakmile vám běží Postfix v prostředí chroot, musíte zajistit synchronizování prostředků ve změněném kořenovém adresáři s normálními systémovými soubory. Vyžaduje-li váš chroot kupříkladu letcipasswd, pak kdykoli se změní systémový letcipasswd, musí být aktualizovaná také jeho verze chroot. Vytvoření souborů odkazů nefunguje, protože symbolické odkazy nemohou překračovat hranice změněného kořenového adresáře a pevné odkazy nefungují mezi systémy souborů.
Dokumentace Distribuce Postfixu obsahuje spoustu dokumentace. Podle příslušného instalačrubo balíčku můžete, ale také nemusíte obdržet všechny dokumenty. V každém případě byste měli mít přinejmenším manuálové stránky a ukázkové konfigurační soubory. Ukázkové soubory se nacházejí v adresáři zadaném parametrem sample_di rectory, který obvykle odpovídá adresáři, v němž se nachází váš soubor main.if. Všechny parametry Postfixu jsou zdokumentované v jednom nebo více ukázkových souborech. Při instalaci Postfixu zřejmě došlo také k nainstalování manuálových stránek na nějaké rozumné místo vašeho systému. Nacházejí-li se v adresáři, kde je váš systém očekává, stačí zadat jen kupřt1cladu $
man
postfix
přičemž příslušná stránka se zobrazí na monitoru. Zareaguje-li váš systém chybovou zprávou jako $
man
postfix
No manual entry found for postfix .
pak buď nejsou dané stránky nainstalované, nebo se nenacházejí na místě, kde je váš systém očekává. Přečtěte si dokumentaci k systému a zjistěte nastavení proměnné MAN PATH nebo přesuňte manuálové stránky na nějaké standardnější místo vaší platformy. Existuje mnoho manuálových stránek pro různé příkazy, démony a vyhledávací tabulky Postfixu. Veškerá tato dokumentace je rovněž k dispozici ve formě souborů HTML. Nejsou-li tyto soubory HTML instalované na vašem systému, najdete je na webovém sídle Postftxu na adrese http://www.post.ftx.org/. Online dokumentace se vždy týká aktuální uvolněné verze Postfixu.
KAPITOLA 5
Ř ízení fronty
Démon správy fronty qmgr je z mnoha hledisek srdcem vašeho systému Postfix: Všechny zprávy, jak odchozí, tak i příchozí, musí projít frontou. Bude tedy vhodné plně poro zumět frontě a tomu, jak ji Postftx používá, pro případ, kdy budete muset řešit nějakou potíž. Správce fronty ovládá pět odlišných front: příchozí, aktivní, odloženou, zadrženou a po škozenou. Postftx využívá pro každou frontu samostatný adresář pod cestou zadanou v parametru queue _d i r e c t o r y . Touto cestou je standardně I varl spoollpostfix, takže získáváte adresářovou strukturu podobnou té následující: /var/ spoo l /po s t f i x / active /var/ spoo l /pos t f i x/bounce /var/ spool /postfix/ cor rupt /var/ spool /pos t f i x / de ferred /var/ spool /post fix/hold
Démon qmgr běžící na pozadí automaticky zajišťuje většinu úloh souvisejících se správou fronty. Příkazy postsuper a postqueue používají administrátoři k manuální správě fronty. Tato kapitola zkoumá, jak funguje qmgr a nástroje příkazového řádku. Zabývá se rovněž parametry Postftxu ovlivňujícími frontu.
Jak funguje qmgr Obrázek 5-1 ilustruje, jak se zprávy pohybují frontou. Příchozí fronta představuje mís to, kde zprávy prvně vstupují do Postftxu. Správce fronty zajišťuje ochranu systému souborů fronty prostřednictvím parametru queue rninfree. Výchozí hodnotou je o. Chcete-li zajistit, aby nemohlo dojít k nedostatku prostoru na disku ukládajícího tuto frontu, můžete zde nastavit limit . _
nqmgr. Dřívější verze Postfixu obsa qmgr a nqmgr. Původní správce qmgrbyl nahrazen tím aktuálním, který nabízí lepší algoritmus plánování. Názvem nqmgr se označoval aktuální démon řízení fronry, dokud se dodával i ten původní. Jakmile byl připraven k fungování jako jediný správce fronry Postfixu, byl přejmenován na qmgr. •
Ve starších konfiguračních souborech a dokumentaci můžete najít odkazy na
hovaly dva démony správy fronry:
Agenti vstupu
Agenti dorueenf
Obrázek 5- 1. Pol?Jb !(/Jráv ve.frontě.
Správce fronty přesunuje zprávy z příchozí fronty do aktivní fronty a k jejich zpraco vání volá příslušné agenty doručení. Nejsou-li s doručením problémy, pak je většinou pohyb frontou tak rychlý, že v ní nespatříte žádné zprávy. Pokouší-li se Postf1X doručit zprávu nějakému pomalému nebo nedostupnému serveru SMTP, můžete v aktivní frontě spatřit nějaké zprávy. Postf1X čeká 30 sekund než stanoví, zda je vzdálený systém nedosažitelný. Zpráva, kterou není možné doručit, se umístí do fronty odložených neboli pozdrže ných zpráv. Zprávy se odloží, pouze když dojde k nějakému dočasnému problému s doručením, kupřľkladu výpadku DNS nebo situaci, kdy dočasnou potíž hlásí cílový poštovní server. Zprávy, které jsou odmítnuty nebo narazí na trvalou chybu, se okamžitě s chybovým hlášením vrátí zpět odesílateli a nezůstávají ve frontě.
Odložená pošta Zprávy zůstanou v odložené frontě až do doby, než budou bud' úspěšně doručeny nebo vyprší doba jejich doručení a vrátí se zpět odesílateli. Parametr bounce si ze limit určuje, kolik ze zprávy, jež nemohla být doručena, se vrátí zpět odesílateli s chybovým hlášením. Výchozí hodnotou je 50 000 bajtů. _
_
Když není možné zprávu doručit, Postf1X ji označí časovou značkou určující, kdy má dojít k dalšímu pokusu o doručení. Postfix si vytváří krátkodobý seznam systémů s výpadky, aby se zbytečně nepokoušel o doručení. Existují-li nějaké odložené zprávy s napláno vaným opakovaným doručením a v aktivní frontě je místo, správce fronty alternativně bere zprávy z odložené a příchozí fronty, takže nové zprávy nemusejí čekat za velkým počtem odložených zpráv.
Časové plánování ve frontě Postf1X periodicky skenuje frontu a sleduje, zda tu nejsou nějaké odložené zprávy s ča sovými značkami indikujícími připravenost k dalšímu pokusu o doručení. Další selhavší pokusy o doručení způsobí zdvojnásobení naplánovaného zdržení, takže Postfix bude čekat stále déle, než se pokusí o další doručení zprávy. Maximální zpoždění můžete zadat parametrem maximal_queue _li fet ime. Jakmile uplyne tato doba, Postfix vzdá
další doručování zprávy a vrátí ji zpět odesílateli. Touto periodou je standardně pět dnů (Sd) . Můžete zadat libovolnou dobu nebo hodnotu O, má-li se nedoručitelná pošta vrátit okamžitě. Ke skenování fronty dochází v intervalu zadaném parametrem queue _run _delay. Tento parametr je standardně nastaven na 1 000 sekund (1 000s). V takovém případě prověří Postfix každých 1 000 sekund odloženou frontu a zjistí, zda tu nejsou nějaké zprávy určené k dalšímu pokusu o doručení. Parametry minimal_backoff_time a maximal_backoff_time určují minimální a maximální časové limity toho, jak často se Postfix opakovaně pokouší doručit odložené zprávy. Při každém odložení zprávy zvýší správce fronty dobu čekání na opětné doručení zprávy. Vypočtené zvýšení doby nemůže nikdy překročit maximal_backoff_time (stan dardně 4000 sekund) a nikdy nemůže být nižší než minimal_backoff_time (standardně 1 000 sekund) . Zjistíte-li, že máte velké množství odložených zpráv, můžete zvýšit maximal_backoff_t ime tak, aby Postfix neztrácel systémové prostředky při pokusech doručit zprávy nedostupným serverům.
Doručování zpráv Správce fronty zařizuje doručování zpráv zavoláním příslušného doručovacího agenta. Postfix se stará o to, aby cílové systémy nezahltil, a nabízí několik parametrů řídících prostředky pro odchozí zprávy. Ve většině situací vyhovují výchozí nastavení, máte-li však nějaké potíže s prostředky nebo se pokoušíte o optimalizaci doručování, můžete experimentovat s nastavením správce fronty. Odchozí zprávy mohou být doručeny kterýmkoli z prostředků dostupných v souboru master.if. Každý transport může mít limit svého celkového počtu procesů, což se zadává ve sloupci maxproc (viz oddíl Soubor master.cf). Není-li tu zadána žádná hodnota, Postfix použije k omezení hodnotu de faul t _proces s _l imi t. Parametr ini tial_destination_concurrency omezuje počet zpočátku odeslaných zpráv (výchozím nastavení je pět) . Tuto hodnotu můžete zvýšit, nemůže však přesáhnout hodnotu maxproc ani de fault_proces s_l imi t pro používaný transport. Po počátečním doručení zpráv Postfix zvyšuje počet souběžných pokusů o doručení, jsou-li ve frontě ještě nějaké zprávy pro daný cíl. To činí tak dlouho, dokud nezjistí nějaké potíže cílového systému při aktuálním zatížení. Postfix pokračuje ve zvyšování počtu souběžných doručo vání až do počtu zadaného parametrem default_dest ination_concurrency_l imit, který má ve výchozím nastavení hodnotu 20. Obecně není dobré zvyšovat limit souběžnosti, protože riskujete zahlcení přijímajícího systému. Hodnotu de fau l t _de s t ination _ concurrencL l imit libovolného transportu můžete přepsat nastavením parametru ve formě t ransport _destination_concurrency_l imi t . Souběžná spojení k externím systémům tak můžete kupříkladu omezit parametrem smtp_dest ination_ concurrencL l imi t, lokální doručování pak pomocí local_de stina tion_concurrency_l imi t.
Existují také parametry ve tvaru t ransport_destinationJecipient _lirni t řídící, kolik příjemců Postfix specifikuje pro jedinou kopii e-mailové zprávy. Není-li nakonfigurován parametr specifický transportu, použije se výchozí hodnota z defaul t_destination_recipi ent_lirni t. Pokud počet příjemců zprávy převýší tento údaj, Postfix rozdělí seznam příjemců na menší sku�iny adres a na každou skupinu adres odešle samostatnou kopii zprávy.
Poškozené zprávy Fronta poškozených zpráv se používá prostě k ukládání poškozených nebo z jiného důvodu nečitelných zpráv. Je-li zpráva natolik poškozená, že s ní nelze nic dělat, pak ji Postfix umístí právě sem. Chcete-li odhalit nějakou potíž, pak problematickou zprávu najdete právě v této frontě, kde si ji v případě potřeby můžete manuálně zobrazit. Poško zené zprávy jsou velmi výjimečné. Setkáváte-li se s nimi častěji, mohou být symptomem nějaké chyby používaného operačrubo systému nebo hardwaru.
Upozornění na chyby Postfix může oznamovat určité chyby odesíláním chybových zpráv administrátorovi. Postfix klasifikuje chyby k upozornění, jak uvádí tabulka. Parametr notifL classes v souboru main.cfobsahuje seznam tříd chyb, které by měly generovat chybová hlášení. Tento parametr standardně zahrnuje chyby "resource" (prostředek) a "software". Každou třídu chyb lze nastavit na odesílání upozornění na určitou e-mailovou adresu; k tomu slouží parametry ve tvaru class _notice_ recipient. Standardně všechny chodí postrnasterovi. Tabulka představuje seznam možných tříd chyb i s parametry indikují cími, kdo by měl tato upozornění na chyby přijímat. Tabulka 5- 1. Upozornéní na cl[yl?Y elektronicképofty Parametr třídy chyby
Popis
Parametr příjemce u pozornění
bounce
Odeslat hlavičky všech vrácených zpráv.
bounce_notice_recipient
2bounce
Odeslat nedoručitelné vrácené zprávy.
2bounce_not i ce_recipient
delay
Odeslat hlavičky zpožděných zpráv.
delay_noti ce_recipient
policy
Odeslat transkript transakce SMTP, kdy je zpráva odmítnuta proti-spamovými omezeními.
protocol
Odeslat transkript všech transakci SMTP s chybami.
resource
Odeslat upozomění,že zpráva nemohla být doručena kvůli potižím se systémovými prostředky.
error_notice_ recipient
so ftware
Odeslat upozoměn í ,že zpráva nemohla být doručena kvůli softwarovým potížím.
error_notice_ recipient
Chcete-li přijímat všechna upozornění na problémy, nastavte popisovaný parametr takto: noti fy_classes
=
bounce , 2bounce , de lay, policy, protocol ,
resource , software
Nástroje fronty PostfIx nabízí několik nástrojů příkazového řádku, které lze využít k zobrazení a správě zpráv ve frontě. Základními příkazy jsou postsuper a postqueue. Se zprávami ve frontě můžete provádět následující úkoly: •
Vypisovat zprávy,
•
odstraňovat zprávy,
•
zadržovat zprávy,
•
zprávy znovu vkládat do fronty,
•
zobrazovat zprávy,
•
vyprazdňovat zprávy.
V následujících oddílech j sou popsány jednotlivé úkoly a příkazy potřebné k jejich splnění.
Výpis fronty Zobrazení fronty obsahuje položku pro každou zprávu a ukazuje její identifikátor, veli kost, čas přijetí, odesílatele a adresu příjemce. Odložené zprávy rovněž uvádějí důvod, proč nemohly být doručeny. Zprávy v aktivní frontě jsou za identifikátorem ve frontě označeny hvězdičkou. Zprávy ve frontě držených jsou vyznačeny vykřičníkem. Odložené zprávy nemají žádnou značku. Všechny zprávy ve frontě si můžete vypsat příkazem postqllelle -po Postftx nabízí kvůli kompatibilitě se Sendmailem příkaz mailq. Náhrada příkazu mailq v PostfIxu vytváří stejný výstup jako postqllelle -po Typická položka fronty vypadá nějak následovně: $ poatqueue -p -Queue 1 D- --Si ze-- ----Arrival Time---- -Sender /Rec ipient------DBA3 F1A9
5 5 3 Mon May
5 14 : 42 : 15
kdent@ example . com
( connect to ma i l . o ra . com [ 1 92 . 1 6 8 . 1 5 5 . 6 3 } : Connection refused) kdent@ora . com
Jelikož není tato položka označena ani hvězdičkou, ani vykřičníkem, nachází se ve frontě odložených zpráv.
Odstraňování zpráv Příkaz postsllper vám dovoluje odstraňovat zprávy z fronty. Chcete-li odstranit zprávu odpovídající naší výše uvedené ukázkové položce, vykonejte postsuper s přepínačem -d: # poatauper -d DBA3F1A9 postsuper : DBA3 F 1A9 : removed postsupe r : De leted : 1 mes s age
Chcete-li odstranit velké množství zpráv, můžete vymazat celou frontu použitím argu mentu ALL: •
poluuper
-d ALL
postsuper : Deleted : 23 mes sages
Argument AU. musí být zapsán velkýtni písmeny. Při práci s tímto příkazem buďte velmi opatrní, protože bez dalších otázek odstraní všechny zprávy ve frontě. Č asto budete potřebovat odstranit všechny zprávy s určitou e-mailovou adresou, při čemž ale nechcete vymazat celou frontu ani zprávy odstraňovat jednotlivě. Příklad 5-1 představuje skript jazyka Perl zajišťující možnost jednoduše zadat adresu elektronické pošty a vymazat všechny odpovídající zprávy z fronty.
Pfilelad 5- 1,' SkripljaiYko Per! odstraňujíd tJ!ráry ve.fronllpodle adresy elektronicképolty ' ! /usr/bin/perl
-
w
•
• pfdel - odstraňu j e zprávu obsahuj ící zadanou adresu
• z fronty Postfixu . Kontroluj e adresu ode s í latele i příj emce . •
t Použ i t í : pfdel t
use s t r i c t ; • Je- l i to zapotřeb í , t y t o c e s t y změňte .
my $ L I STQ = " /usrl sbin /pos tqueue -p" ; my $ POSTSUPER = " /u s r l sbin/postsuper " ; my $emai l_addr = " " ; my $qid = " " ; my $euid = $ > ; i f ( @ARGV ! =
1 ) {
die " Použití : p fdel \n " ; else $emai l_addr = $ARGV [ O ] ;
if
$euid ! = O ) { die "Abyste mohl i odst raňovat soubory fronty, mus í te být root . \ n " ;
open ( QUEUE , " $ L I STQ I " ) I I die "Ne l z e obdr žet rouru k $LI STQ : $ ! \ n " ; m y $entry = ; $1 = "";
# Přeskočit j eden řádek záhlaví .
• Zbytek položek fronty vyt i s knout
• na více řádků .
while ( $entry = ) { if ( $entry =� I $emai l_addr$/m ) ( $qid) = spl i t ( / \ s + l , $entry, 2 ) ; $qid =� s / [ \ - \ ! ] I I ; next unless ( $qid) ;
I Vykonat pos t super -d s i den t i f i kátorem ve frontě .
• Příka z postsuper vrací při odstraňování zpráv
• informace . Nechme j eho výstup proj í t . I
if ( sys tem ( $ POSTSUPER, " -d" , $qid) ! = O ) { • Má- l i postsuper problém, selhat .
die " Chyba vykonávání $ POSTSUPER : chyba " " kód " .
($?/256) . "\n";
close ( QUEUE ) ; if ( ! $qid ) { die " Zprávy a adresou <$emai l_addr> " "nebyly ve frontě nalezeny . \ n " ; exit O ;
Zadržení zpráv Fronta zadržených zpráv slouží pro zprávy, které byste rádi nechali ve frontě po neome zenou dobu. Obrázek 5-2 znázorňuje frontu zadržených zpráv a způsob, jakým můžete přesunovat zprávy do této fronty, odkud nebudou doručeny, dokud je specificky neod straníte nebo je nevrátíte zpět do normálrubo zpracování ve frontě. K vložení ukázkové zprávy do fronty zadržených zpráv použijte příkaz Pos/super s přepínačem h: -
I poatauper
-
h DBA3F1A9
Položka fronty nyní zobrazí vykřičník označující, že daná zpráva je zadržená: -Queue I D- --Size-- ----Arrival Time - - - - -Sender/Recipient ------DBA3 F1A9
!
5 5 3 Mon May
5 1 4 : 42 : 15
kdent@example . com
( connect to ma i l . ora . com [ 1 92 . 1 6 8 . 1 5 5 . 6 3 ] : Connection refused) kdent@ora . com
Obrázek 5-2: Zadtf!ní iPráv
Chcete-li danou zprávu vrátit zpět do normální fronty k běžnému zpracování, vykonejte stejný příkaz, tentokrát ale s přepínačem -H (velké písmeno) : * poatsuper -B DBA3F1A9
Jakmile je zpráva vrácena, označí ji správce fronty za určenou k doručení podle svého běžného časového plánu. Zprávu můžete rovněž nechat odeslat okamžitě (viz oddíl Okamžité odesílání zpráv) .
Opakované zařazování zpráv do fronty Máte-li nějaké zprávy, které byly zadrženy kvůli určitému konfiguračnímu problému, jenž byl napraven, můžete je znovu zařadit do fronty a nechat je doručit. Pokud ne správná konfigurace způsobila, že Postfix uložil nesprávné informace o následujícím skoku nebo transportní metodě, popřípadě adresu nesprávně přepsal, pak opětné zařazení do fronty způsobí, že Postfix aktualizuje nesprávné informace na základě nového nastavení. K opakovanému zařazení zpráv do fronty slouží příkaz postsuper s přepínačem r Můžete zadat identifikátor ve frontě, chcete-li zařadit jedinou zprávu, nebo slovo ALL velkými písmeny, chcete-li do fronty znovu zařadit vše: -
i postsuper
.
-
r !LL
Opakovaně zařazené zprávy obdrží nový identifikátor ve frontě a dodatečnou hlavičku Received : .
Zobrazování zpráv Obsah souboru fronty si zobrazíte příkazem postcat. i postcat -q DBA3F1A9
Dřívější verze příkazu pos/cat nepodporovaly volbu -q, ale vyžadovaly celou cestu k dané mu souboru fronty. Jelikož může být příslušná zpráva v kterékoli části fronty (nová pošta, příchozí, aktivní, odložená, zadržená) a jelikož má každá z těchto částí několik podadresá řů, není cesta ke konkrétnímu souboru fronty ihned zřejmá. Používáte-li nějakou dřívější verzi příkazu postcat, která nepodporuje volbu -q, můžete si vytvořit skript podobný tomu v příkladu 5-2. Tím si zjednodušíte zobrazování souboru ve frontě, protože stačí jen zadat jeho identifikátor ve frontě. Skript přijímá jako argument jeden identifikátor ve frontě, prověřuje všechny adresáře fronty, kde hledá příslušný soubor fronty, a následně vykonává př!.'kaz postcat s celou cestou jako argumentem. Zobrazí se obsah souboru. Náš jednoduchý skript zobrazí jen jeden soubor fronty. Příklad 5-2: Skriptová obálko příko� postcat # ! /bin/sh PATH=/usr/bin : / u s r / sbin QS= " deferred act ive incoming ma i l drop hold" QPATH= ' postconf -h queue_di rectory ' i f [ $ i -ne 1 )
;
then
echo " Pou ž i t í : pfcat < iden t i f i kátor_veJrontě>" exit 1
echo "Abyste mohl i zobra zovat soubory fronty, musíte být root . " exit 1 fi if
-d $QPATH ] ; then echo "Ne l z e nalézt adre sář fronty $QPATH . " exit 1
fi for q in $QS do F I LE= ' f ind $QPATH / $ q -type f -name $ 1 ' i f [ -n " $ F I LE " ] ; then postcat $ F I LE exit O fi done if [ -z $ F I LE ] ; then echo " Neex i s t u j e soubor fronty $ 1 " exit 1 fi
Okamžité odesílání zpráv Vyprázdnění fronty (Flush) způsobí, že se Postfix pokusí doručit zprávy ve frontě oka mžitě. Fronty ve zprávě můžete okamžitě odeslat pomocí příkazu postqueue 1- Pokud však nemáte důvod očekávat úspěšné doručení, je nejlepší nechat pokusy o opakované doručení na správci fronty Postfixu. Opakované pokusy o vyprázdnění fronty mohou mít zásadní nepříznivý dopad na výkon vašeho poštovního serveru. Pomocí volby -s můžete odeslat jen zprávy určené pro určitý server. Tento server musí mít umožněno zpracování rychlého vyprázdnění, aby celá technika fungovala. To umožníte tím způsobem, že daný server uvedete v parametru fast flush domains. Standardně obsahuje fast flush domains všechny hostitele uvedené v relay_domains, můžete však přidat další servery, chcete-li zprávy odeslat před obvykle naplánovaným pokusem o opětné doručení. _
_
_
_
fast_f lush_doma ins = $relay_domains example . com
Víte-li, že je nějaký dříve nedostupný server nyní přípraven na příjem pošty, spusťte postqueue s volbou -s a názvem serveru: jl postqueue -s example . com
Další informace o rychlém odesílání a příkazu ETRN protokolu SMTP najdete v deváté kapitole.
KAPITOLA 6
E-mail a DNS
Systém DNS (Domain Name System) je nesmírně rozsáhlá distribuovaná databáze, jejímž hlavním úkolem je mapování názvů hostitelů na adresy IP. Hraje důležitou roli také při směrování e-mailů. V této kapitole se podíváme na to, jak MTA používají DNS a na některé z problémů s DNS, které se týkají Postfixu a jeho konfigurace. Mějte na paměti, že pro vaše poštovní servery a DNS jsou důležité dvě věci: •
Pro odesílání e-mailů musí mít systém s poštovním serverem Postfix přístup ke spolehlivému serveru DNS pro překlad názvů hostitelů a informace o směrování e-mailů.
•
Pro přijímání pošty musí být vaše domény nastaveny tak, aby správně směrovaly zprávy na váš poštovní server.
Špatná konfigurace serverů DNS je nejčastějším zdrojem problémů při nastavování poštovních serverů.
Úvod do DNS Kdysi bylo mapování názvů hostitelů n a adresy I P prováděno pomocí jednoho velkého, centrálně spravovaného textového souboru, který obsahoval položku pro každého hosti tele dostupného na internetu. Každý server si periodicky stahoval kopii tohoto souboru, aby měl nejnovější informace o hostitelích. Toto schéma se rychle stalo těžkopádným a byla vytvořena služba DNS. Byla definována v roce 1 983 v dokumentu RFC 882 a zavedla dvě klíčové myšlenky: data jsou distribuována a pojmenování hostitelů je hie rarchické. To, že byla data distribuována, znamená, že každý server aktualizuje své vlastní informace a aktualizace jsou dostupné takřka okamžitě. Hierarchické pojmenování za braňuje konfliktům v názvech hostitelů a poskytuje nám aktuální systém názvů domén, jak jej dnes známe. Každé sídlo obdrží alespoň jeden název domény a všichni hostitelé v tomto sídle jsou pojmenováni připojením jednoduchého názvu hostitele před název domény tohoto sídla. Například sídlo, které řídí název domény example . com by mohlo mít libovolný počet hostitelů s názvy jako např. server1 . example . com, hp4 1 0 0 . examp le . com nebo www . example . com.
Každá doména má alespoň dva názvové servery, které jsou pro danou doménu považo vány za autoritativní. Autoritativní názvové servery by měly mít přímý přístup do databáze, která obsahuje všechny informace o doméně. Data se skládají z různých druhů záznamů, které se nazývají záif1amy prostředků. Různé záznamy prostředků poskytují různé druhy informací, jako například adresy IP, názvo vé servery, aliasy názvů hostitelů a směrování pošty. Záznamy prostředků, o kterých potřebujete vědět, jsou:
A Mapování názvů na adresy IP je prováděno záznamy A. Tyto záznamy obsahují název hostitele a jeho adresu IP. Názvy, které lidé používají pro odkazy na hostitele, musí být převedeny na adresy IP používané pro směrování v internetu. Záznamy A umožňují tento překlad názvu na adresu IP.
CNAME Některé názvy hostitelů jsou aliasy, které ukazují na jiné názvy hostitelů namísto adres IP. To může být užitečné pro směrování požadavků na služby Gako např. HTTP nebo POP), které mohou běžet na systémech, které jsou jinak známé pod odlišným názvem. Záznam CNAME poskytuje "skutečný" nebo k.anonicAif název, na který alias názvu hostitele ukazuje. Správce může například uvádět název hosti tele www. example.com. což je ve skutečnosti záznam CNAME většinou ukazující na server1 .example.com. Ale v průběhu správy serveru serverl.emaple.com by mohlo www.example.com dočasně ukazovat například na server2.example.com.
MX Záznamy MX umožňují směrování e-mailů. Udávají servery pro vyřizování pošty pro dané domény (mail exchangers) - tzn. názvy poštovních serverů, které se starají o veškerou poštu pro daný název domény. Záznamy MX říkají MTA, kam se mají poslat zprávy. Jelikož může mít doména více poštovních serverů, záznamy MX obsahují preferenční hodnotu pro stanovení pořadí priority při výběru poštovrubo serveru, na který mají být zprávy doručovány.
P7R Záznamy PTR umožňují reverzní vyhledávání - převod adres IP na názvy hostitelů. Tyto záznamy obvykle odpovídají záznamům A, aby dopředné vyhledávání názvů hostitelů vracelo adresu IP, jejíž reverzní vyhledávání vrací stejný název hostitele. Mnoho názvů hostitelů může samozřejmě ukazovat na stejnou adresu IP, takže by měl být záznamy PTR mapovány zpět na kanonický název spojený s adresou IP. Některé aplikace používají záznamy PTR jako formu ověřování, aby se ujistili, že je adresa IP připojujícího se klienta mapována na očekávaný název hostitele.
Směrování pošty Na moment se zamysleme nad jedním způsobem, jak by směrování pošty mohlo fungo vat. Uživatel horatio v doméně example . com má pracovní stanici s názvem denmark. Mohl
by přijímat poštu na adrese horatio@denmark . example . com. MTA se zprávou, která má být doručena, by jednoduše vyhledal adresu IP počítače denmar k . example . com a doručil ji na tento systém pro uživatele horatio. Tento scénář vyžaduje, aby byla pracovní stanice uživatele Horatio vždy zapnuta, aby měla funkční MTA běžící po celou dobu pro příjem zpráv a aby byla přístupná pro neznámé MTA odkudkoliv v internetu. Namísto správy stovek nebo' tisíců MTA na pracovních stanicích a jejich vystavení na internetu téměř všechny domény používají poštovní servery, které přijímají všechnu poštu pro doménu.
MTA, jako např. Postfix, potřebují způsob, jak určit, který hostitel nebo kteří hostitelé jsou poštovními servery pro doménu. Tuto informaci poskytují záznamy MX .
Poštovní server (Mail Exchanger, odtud MX) buď doručí poštu, kterou přijme nebo ji předá dál na jiný poštovní server. Doména může mít z důvodu spolehlivosti více poštovních systémů a proto i více záznamů MX Jeden hostitel je obecně primárním .
poštovním serverem a ostatní slouží jako záložní nebo sekundární poštovní servery. Každý záznam MX v DNS obsahuje úroveň priority, která řadí poštovní systémy od nejvíce preferovaného po nejméně preferovaný. Jednou z nejběžnějších aplikací serveru DNS je BIND (Kniha DNS and BrNO od Paula Albitze a Cricket Liu z vydavatelství O'Reilly plně vysvětluje systém DNS a dokumen tuje B1ND) . Jednoduchý konfigurační soubor serveru BIND pro doménu vypadá takto: example . com . IN SOA ns . example . com . kdent . example . com . ( 1 0 4 93 1 0 5 1 3 10800 3600 604800 900 ) Narneservers example . com .
IN NS ns . example . com .
; Host Addre sses exarnple . com .
IN A 1 92 . 1 6 8 . 1 0 0 . 5 0
serve r 1 . exarnple . com .
IN A 1 92 . 1 6 8 . 1 0 0 . 2 2 0
ns . exarnple . com .
IN A 1 92 . 1 6 8 . 1 0 0 . 5
ma i l 1 . example . com .
IN A 1 92 . 1 6 8 . 1 0 0 . 5 0
ma i 1 2 . example . com .
IN A 1 92 . 1 6 8 . 1 0 0 . 5 4
mai 1 3 . exampl e . com .
IN A 1 92 . 1 6 8 . 1 0 0 . 1 2 3
; Mai l Exchange rs exarnple . com . example . com . exarnple . com . CNAME Records
IN MX 10 mai l 1 . example . com . IN MX 2 0 mai 1 2 . example . com .
IN MX 30 mai 1 3 . example . com .
exampk.com
pop . example . com .
IN CNAME ma i l 1 . example . com .
www . example . com .
IN CNAME serve r 1 . example . com .
My se budeme zajímat hlavně o záznamy MX: example . com . examp1e . com . example . com .
IN MX 1 0 ma i l 1 . example . com .
IN MX 20 ma i 1 2 . example . com .
IN MX 30 ma i 1 3 . example . com .
V prvrum sloupci je název domény. Druhý sloupec řiká, že položky j sou záznamy tňdy internet, a třeti řt'ká, že se jedná o záznamy MX. Posledru sloupec ukazuje název poš tovního serveru a předposledru sloupec ukazuje hodnotu jeho preference. Hodnotou preference může být libovolné číslo mezi O a 65.536, přičemž nižší hodnota označuje vice preferovaný server. ČÍsla mají význam pouze ve spojeru se všemi ostatrúmi a mo hou to být jakákoliv čísla z povoleného rozsahu. Většina správců vytván tyto hodnoty v násobcích 1 0, což umožňuje určitou flexibilitu pro vkládárú nebo dočasnou změnu preference. V našem jednoduchém přtKladu uvedeném výše server maill .example.com přijímá veš kerou poštu pro doménu example.com. V tomto p npadě musí všechna pošta nakonec dorazit na mail1 .example.com. Když musí MTA doručit zprávu uživateli v doméně example . com, načte všechny záznamy MX a seřadí je podle priority. Nejprve se pokusí o její doručeru na server mai l l . example . com. Pokud je server mai l l . example . com do stupný a přijme zprávu, je doručeru dokončeno. Pokud samozřejmě z nějakého důvodu neru server ma i l l . example . com schopen zprávu přijmout, MTA prochází seznam dále dokud nenajde poštovru server schopný zprávu přijmout. Pokud druhý poštovru server zprávu přijme, přebírá zodpovědnost za její doručeru na více preferovaný poštovru server (třeba primární) až bude nedostupný server opět online. Pokud nejsou pro doménu nalezeny žádné záznamy MX, MTA zkontroluje, zda exis tuje záznam A spojený s názvem domény. Pokud existuje záznam A, MTA se pokusí o doručení na systém na této adrese IP. Toto schéma směrováru pošty vypadá celkem jednoduše, ale je trochu komplikovaněj ší. Vezměme pnklad, kdy MTA na adrese mai 1 2 . example . com zprávu pro adresu ophe l i a@ exampl e . com. Server ma i l 1 . example . com je pravděpodobně nedostupný, jelikož zprávu přijal server mai l 2 . MTA běžící na serveru mail2.example.com vezme seznam poštovruch serverů pro doménu example . com, určí, že by zpráva měla být doručena na server ma i l l . example . com, a zjisti, že server mai l l je nedostupný. Dalším serverem na seznamu je on sám. Doručeru sobě samému by nemělo smysl. Takže dalším poštovrum serverem na řadě je mai l 3 . example . com. MTA by mohl doručit zprávu sem, ale mai l 3 by provedl to samé a okamžitě by zkus zprávu předat zpět n a mai 1 2 , což by vytvořilo smyčku (MTA ve skutečnosti převádějí pro porovnáváru názvy hostitelů na adresy IP, jelikož hostitelé MX by mohli rfÚt vice záznamů A. Postfix porovnává adresy IP se svým seznamem adres v inet interfaces a proxL interfaces.) _
Řešeru je takové, že pokud MTA načte seznam poštovruch serverů a zjisti, že je jedrum z nich, zahodí svůj vlastru záznam i záznamy všech ostatruch poštovruch serverů se stejnou nebo nižší preferencí (vyšší číslo) . V našem přtKladu server mail2 eliminuje sám
sebe a server mai 1 3 , takže omezí seznam poštovních serveru pouze na ma i l l . Jelikož server mai l l není dostupný a mai l 2 nemá další možnost doručení, zařadí zprávu do fronty a provede doručení až bude server mai l l opět dostupný. Aby směrování pošty fungovalo správně, měli byste být velmi opatrní při nastavová ní záznamů MX. Hlavně byste se měli držet následujících pravidel pro záznamy MX v konfiguraci vašeho DNS:
Po/tavní seroery musí mítplatné záif1amy A. Poštovním serverem, na který ukazuje záznam MX musí být název hostitele s plat ným záznamem A. Jakmile MTA zjistí, který hostitel by měl poštu přijmout, musí být schopen tohoto hostitele najít.
Po/tavní servery nesmí Idt alia.ry. Hostitelem, na kterého ukazuje záznam MX by neměl být alias (záznam CNAME) . Za normálních okolností MTA zná sám sebe pod svým kanonickým názvem a hledá tento název při kontrole seznamu poštovních serveru, aby zabránil vytvoření smyčky. Server musí být schopen najít sám sebe, takže se ujistěte, že váš seznam obsahuje kanonický název v záznamu MX protože jinak riskujete vytvoření smyčky. Dokonce i když použije MTA záznamy CNAME (vyhledáním a použitím kanonického názvu), způsobuje to neefektivitu při doručování pošty. ,
,
Pro po/tavní servery pouijvqte nái!:'Y hostitelů a ne adre!J IP. Pro poštovní servery uvádějte název hostitele a ne adresu IP. I když můžete vystačit se samotnou adresou IP, dokument RFC 974 říká, že musíte použít název hostitele. Pozdější změny (např. IPv6) by mohly způsobit problém ve směrování pošty.
Ujistěte se, žejste zadali hodnoty preference. Vynechání hodnoty preference u záznamů MX může mít ruzné důsledky, v závis losti na vašem serveru DNS a MTA. V nejlepším případě tento problém vytváří nejednoznačnost. V horším případě může znemožnit doručování pošty.
Postfix a DNS Při odesílání pošty Postfix používá resolvery systému, což jsou programy nebo knihovny, které provádí požadavky na informace z DNS. Pro příjem pošty musí být DNS pro vaši doménu nastaven tak, aby směroval zprávy na váš server s Postfixem. V této části se podíváme na problémy DNS týkající se odesílání i přijímání pošty.
DNS a odesílání pošty Doručovací agent SMTP serveru Postfix musí být schopen pro směrování pošty získat adresu IP a záznamy MX Postfix musí provádět alespoň dvě hledání v DNS: jedno pro načtení názvu hostitele MX a jedno pro načtení adresy IP pro tento název hostitele. Jelikož Postfix používá pro dotazy na DNS normální knihovny resolveru operačního .
systému, musí mít systém, na kterém běží Postfix, přístup k serveru DNS. Server DNS nemusí být na stejném systému, i když by ve většině případů měl. Pokud se zdá, že systém nepřekládá názvy domén správně, j sou k dispozici tři běžné nástroje pro příkazový řádek, které můžete použít při řešení problému: nslookup, dig a host. Měli byste se podívat do dokumentace vašeho systému a zjistit, které z těchto nástrojů jsou k dispozici na vašem serveru a jak se používají. Tyto nástroje můžete použít pro dotazy na všechny druhy záznamů pro doménu, včetně záznamů :MX které Postfix potřebuje pro úspěšné doručování pošty na doménu. ,
Problémy DNS mohou pramenit z konfigurace vašeho systému nebo z problému nasta vení serveru DNS pro doménu, na kterou se PostflX pokouší odeslat poštu. Když řešíte problém, je velmi důležité si zapamatovat, že PostflX nejprve hledá záznamy :MX a ne záznamy A. Dokonce i když můžete zjistit z názvu domény adresu IP, Postfix nemusí být schopen doručit poštu pro tuto doménu pokud je problém v záznamech :MX .
Volby konfigurace Postfix při doručování pošty provádí hledání v DNS pro načtení všech záznamů :MX cílové domény. Řadí je podle preference a zkouší je podle jejich priority. Jakmíle Postfix vytvoří spojení se serverem SMTP, tento server odpoví na požadavky serveru Postfix stavovým kódem. Kódy v rozsahu 2xx indikují, že je vše v pořádku. Chybové kódy v rozsahu 4xx označují dočasný problém a ty v rozsahu 5xx indikují trvalý problém. Více informací o kódech odpovědí serveru SMTP najdete v kapitole 2. Pro kompatibilitu se serverem Sendmail, PostflX implicitně pracuje se servery SMTP, které odpověděly kódy 4xx nebo 5xx, jako kdyby neodpověděly vůbec. Pokud byste byli raději, kdyby Postfix reagoval na chybové kódy vrácené serverem :MX a neignoroval je, nastavte parametry smtp s kip 5xx_greeting a smtp s kip 4 xx_greet ing: _
_
smtp_s kip_4 xx_greeting
=
no
smtp_s kip_5xx_greeting
=
no
_
_
Pokud je parametr smtp s kip 4xx_greeting nastaven na no a Postfix se pokouší o doru čení pošty na server, který odpověděl kódem 4xx, nepokouší se o doručení na další poš tovní servery cílové domény. Zařadí zprávu do fronty a pokusí se o doručení později. _
_
Pokud je parametr smtp s kip 5xx_greeting nastaven na no a Postfix se pokouší o do ručení pošty na server, který odpověděl kódem 5xx, nepokouší se o doručení na další poštovní servery cílové domény. Místo toho vrátí zprávu odesílateli. _
_
Některé domény mají záznamy :MX nastavené na stejné úrovně preference. Klient SMTP serveru Postfix implicitně náhodně zkouší adresy :MX se stejnou preferencí. Toto impli citní chování můžete změnit nastavením parametru smtp randomi ze_addresses: _
smtp_randomize_addresses
=
no
Nastavení tohoto parametru způsobí, že se PostflX pokusí o doručení na servery :MX ve stejném pořadí, v jakém je načetl.
Reverzní záznamy PTR Z důvodu nárůstu výskytu spamu nyní mnoho serverů vyžaduje, aby měli připojující se klienti platné záznamy PTR spojené s jejich adresami IP. Adresa IP systému s Postfixem by měla mít reverzní mapování PTR na název hostitele, který bude vracet stejnou adresu IP, abyste mohli doručovat poštu na všechny poštovní servery.
DNS a příjem pošty Aby Postfix přijímal poštu pro konkrétní doménu, musí být systém uveden jako hostitel MX v nastavení DNS dané domény a Postfix musí být nastaven tak, aby přijímal poštu pro tuto doménu. Postfix přijímá poštu pro místní domény, relay domény nebo virtuál ní domény. Virtuální domény mohou používat virtuální aliasy nebo virtuální poštovní schránky (viz kapitola 8) . Každý druh domény musí být uveden v odlišném parametru Postfixu, jak je uvedeno v tabulce 6-1 . Tabulko 6- 1. Dmf?y domén ajejich parametry D ruh domény
Parametr
Místní
mydest ination
Relay
relay_domains
Virtuální poštovní schránky
virtual mai lbox domains virtual alias doma ins
Virtuální aliasy
Doménu neuvádějte ve více než jednom z těchto parametrů. Postfix vydá varování, po kud zjistí, že je doména uvedena ve dvou z těchto parametrů. Když dokjnfigurace DNS ukazuje na váš poštovní server, objeví se chybová zpráva "mail for example.com loops back to myself", ale Postfix nebyl nastaven pro příjem pošty pro tuto doménu. Pokud váš server Postfix přijímá poštu pro dvě místní domény examp l e . com a porcupine . org, pak by měl parametr mydest ination ve vašem souboru main.cf vypadat takto: myde s t i nation
=
example . com, porcupine . org
V kapitole 9 je vysvědeno nastavení pro relay domény. Kapitola 8 popisuje virtuální poštovní schránky a domény s virtuálními aliasy.
Běžné problémy Následující chybové zprávy v souborech protokolu pošty indikují problémy s vyhledá váním hostitelů:
mailfor domain loops back to nryse!f Toto je jedna z nejčastěj ších chyb rýkajících se DNS. Objevuje se pokud máte nastavený Postfix jako hostitele MX na vašem serveru DNS, ale neřekli jste Post-
fIxu, že je cílovou stanicí pro tuto doménu. Přidejte danou doménu do parametru mydestination nebo ji nastavte jako virtuální doménu nebo relay doménu. Pokud je váš server s PostflXem za serverem proxy nebo zařízením provádějícím NAT, možná nemůže zjistit, že je hostitelem MX dané domény. V tomto případě přidejte adresu IP zařízení proxy do proxL interfaces. Položky v souboru protokolu pro tuto chybu se podobají těmto: pos t f i x /qmgr [ 3 9 8 1 J : 2CC3B2 2 9 : from= , \ s i ze=3 0 6 , nrcpt=l ( queue act ive ) pos t f i x / smtp [ 3 9 8 3 J : warning : mai ler loop : best MX host for example . com i s local pos t f i x / smtp [ 3 9 8 3 J : 2CC3B2 2 9 : to= , \ relay=none , de lay=O , s tatu s=bounced (ma i l for example . com \ loops back to myse l f )
Hostfound but no data record 0/ requested rype KonfIgurace DNS pro doménu nemá žádné záznamy MX a pro samotnou doménu neexistuje žádný záznam A. Pro vyřešení tohoto problému budete muset kontakto vat správce domény. Ujistěte se, že všechny vaše vlastní domény obsahují záznamy MX ukazující na váš poštovní server. Položky souboru protokolu pro tuto chybu vypadají podobně jako: pos t f i x /qmgr [ 3 8 1 8 J : D31CD2 0 F : from= , \ s i ze=3 1 2 , nrcpt=l ( queue act ive ) pos t f i x / smtp [ 3 8 2 4 J : D31CD2 0 F : to= , relay=none , de lay= l , s tatu s=bounced (Name service error forname=example . com type=A : Host found but \ no data record of requested type )
no MX hostfor domain has a valid A record KonfIgurace DNS domény obsahuje záznamy MX ale vyhledávání adres IP selhalo. Pro vyřešení tohoto problému budete muset kontaktovat správce domény. Ujistěte se, že hostitelé MX uvádění u všech vašich domén jsou platní a mají správné záznamy A. Položky souboru protokolu pro tuto chybu vypadají podobně jako: ,
pos t f i x /qmgr [ 3 8 1 8 J : 0 6 8 DB2 0 F : from= \ s i ze=3 0 6 , nrcpt=l ( queue active ) pos t f i x / smtp [ 3 8 4 6 J : warning : n o MX host for example . com has a va l i d A record pos t f i x / smtp [ 3 8 4 6 J : 0 6 8 DB2 0 F : to= \ relay=none , de lay= l , status=de ferred ( Name service error for name=ma i l . seaglas s . com type=A : Host not found)
Host notfound, try again Na dotaz DNS nebyla žádná odpověď. Server DNS buď není dostupný nebo je poškozený. Za předpokladu, že server DNS pro tuto doménu běží a funguje práv ně, může být tato chybová zpráva způsobena chybou v síti nebo je třeba špatně nastavený resolver vašeho systému. Podívejte se do dokumentace k souborům nsswitch.confa resolv.confpro vaši platformu. Než se budete pokoušet hledat problém v Postfixu, ujistěte se pomocí jednoho z nástrojů uvedených dříve, že váš systém
vyřizuje dotazy DNS správně. Položky souboru protokolu pro tuto chybu vypadají podobně jako: pos t f i x /qmgr [ 3 8 1 8 ] : CCBEDIE 8 : from= \ s i ze=30 6 , nrcpt=l ( queue active ) postfix/ smtp [ 3 93 7 ] : CCBEDIE8 : to= \
� elay=none , del a y= l , status=de ferred ( Name service error \ for name=example . com t ype=MX : Host not found, try aga i n )
Pokud spouštite PostfIx v prostředí se změněným kořenovým adresářem, musíte mít ve vašem prostředí některé konfIgurační soubory týkající se DNS. Více infor mací o spouštění PostfIxu v prostředí se změněným kořenovým adresářem najdete v kapitole 4.
KAPITOLA 7
Místní doručování a POP/IMAP
V kapitole 1 bylo vysvětleno, ž e POP a lMAP jsou protokoly, které umožňují uživatelům načítat jejich e-mailové zprávy z úložišť zpráv. Postfix je agent pro přenos pošty a ne obsahuje implementaci protokolů POP nebo lMAP. V této kapitole se podíváme na to, jak Postfix doručuje zprávy a jak j sou předávány servery POP l IMAP. Existuje mnoho serverů POP l IMAP a informace zde uvedené by měly být použitelné pro jakýkoliv ser ver řídící se standardy. V poslední části této kapitoly je popsáno nastavení Postfixu pro spolupráci se serverem Cyrus lMAP. Než se podíváme na místní doručování, budeme se nejprve zabývat různými způsoby doručování, které Postfix používá. Jiná než místní doručování jsou popisována v dalších kapitolách.
Způsoby doručování Postfix umožňuje doručování pro čtyři různé druhy adres příjemců: místní, relay, vir tuální aliasy a virtuální schránky. To, jak nastavíte domény, pro které přijímáte poštu, určuje metodu doručování použitou Postfixem. Zde j sou metody doručování, které Postfix používá:
místní Doručuje poštu do místrubo systému. Každá adresa má účet v systému nebo pochází ze souboru místních aliasů (z historických důvodů l etci aliases). Doručené zprávy jdou do systémové fronty pošty nebo souborů pošty v jednotlivých domovských adresářích. Doručování je prováděno místním agentem pro doručování nebo je pošta předávána vlastnímu programu pro doručování. Místní domény j sou uvedeny v parametru mydest ination.
re/qy Doručuje poštu do jiných systémů, obvykle ve stejné síti. Předávání pro domény je obecně nastavováno na bránách, když Postfix přijímá poštu pro celou síť. Systém brány předává zprávy do správného interrubo poštovrubo systému. Doručování je prováděno pomocí relay, což je zkrátka klon agenta smtp, ale je optimalizován pro doručování na interní systémy v místní síti. Předávané domény jsou uvedeny v parametru relay domains. Předávání pošty je popsáno v kapitole 9. _
virtuální Doručuje poštu pro domény s virtuálními poštovními schránkami. Domény s vir tuálními poštovními schránkami se používají při hostingu více domén s oddělený mi poštovními frontami, které obsahují schránky pro mnoho oddělených domén. Uživatelé elektronické pošty typicky nemají v systému účty. Domény s virtuálními schránk:1mi jsou uvedeny v parametru virtual_mai lbox_domains. Virtuální hosting je popsán v kapitole 8. Doručování na jiné než místní domény je prováděno pomocí přenosu smtp. Ten určuje, kam se mají doručit zprávy pro jiné než místní domény prostřednictvím vyhledávání v DNS. Virtuální adresy aliasů jsou opětovně předány Postfixu pro doručení na novou adresu, na které jsou zpracovávány jednou z výše uvedených metod přenosu. Zbytek kapitoly popisuje místní doručování.
Formáty úložiště zpráv Když Postfix provádí místní doručování, přenáší obsah zpráv do místrubo úložiště zpráv. Nejběžnějšími druhy úložišť zpráv jsou tradiční formát mbox a nověj ší maildir. Oba používají pro uložení zpráv běžné soubory, ale mají jinou strukturu. V Postfixu se zadává formát maildir zadáním koncového lomítka při zadávání souboru nebo adresáře pošty (viz informace o nastavování dále v této kapitole) .
Formát Mbox Systémy Unix dříve používaly pro uložení e-mailů každého uživatele jediný soubor. Tento druh formátu ukládání zpráv je běžně označován jako mbox. Každá zpráva v souboru začíná řádkem se slovem From. Je důležité, aby řetězec začínal prvním znakem řádku a aby byla za koncem tohoto slova mezera. Řádek From je běžně označován jako From_ s podtržítkem pro označení mezery následující za slovem. Nepleťte si řádek From_ používaný pro oddělování zpráv v souboru mbox s řádkem From: obsaženým v záhlaví zpráv. Posledním řádkem zprávy je vždy prázdný řádek. Kompletní řádek From_ vypadá takto: From j mbrown@ examp1e . com Sun Feb
3 1 6 : 54 : 01 2002
Jak u ž bylo uvedeno, řádek začíná slovem From následovaným mezerou. Z a mezerou j e e-mailová adresa, kterou je obvykle adresa obálky zprávy. Z a adresou obálky je datum doručení v běžném formátu data v systému Unix zabírající 24 znaků. Formát mbox umožňuje za datem uvádět volitelně komentář, ale běžně se nepoužívá. Když Postfix doručuje zprávu do souboru mbox, nejprve vytváří řádek From z ode sílatele uvedeného v obálce a aktuálrubo data. Postfix pak kopíruje obsah doručované zprávy do souboru mbox. Pokud Postfix narazí na řádky, které začínají slovem From následovaným mezerou, musí před ně přidat > na začátek řádku, aby nemohlo dojít k jejich záměně se začátkem další zprávy. _
Když server POP /IMAP čte zprávy ze souboru mbox, hledá v souboru řádky From_ označující začátek každé zprávy. Může číst až do dalšího řádku From_ (nebo do konce souboru), aby zjistil konec zprávy. Server POP /IMAP může zrušit citaci kterékoliv z řádků ,,> From" nebo mohou zůstat v původní podobě. Jelikož servery Postfix i POP /IMAP provádí přístup do souboru schránky, musí používat zamykání souborů. Postfix musí před doručením získat exkluzivní zámek pro soubor, aby mohl zapsat zprávu do souboru. Postfix nabízí mnoho mechanismů zamykání, které závisí na platformě. Pomocí příkazu pos/con! -I můžete zjistit, které mechanismy Postfix jsou k dispozici ve vašem systému: $ postconf -1 floek fenU doUoek
Pokud chcete získat více informací o druzích zámků používaných serverem Postfix ve vašem systému, podívejte se do manuálových stránek systému zadáním názvu konkrét runo zámku: $
man
floek
Druh dot l oek, který by měl být k dispozici ve všech systémech, pravděpodobně ve vašem systému není zdokumentován, protože to není funkce operačruno systému nebo podpůrných knihoven jako jsou floek a fent l . dotloek je jednoduše soubor. Název souboru zámku je rvořen z názvu souboru, který má být zamknurý, a rozšíření . loek. Pokud takový soubor zámku existuje, pak Postfix ví, že soubor pošty používá jiný pro ces. Pokud tento soubor neexistuje, Postfix jej vyrvoří, aby sděW ostatním procesům, že soubor používá. Když Postfix skončí, odstraní soubor zámku a soubor pošty bude znovu dostupný. Nedostatkem zamykání dot loek je to, že je citlivý na zastaralé zámky (soubory zámku mohou zůstat v systému i když už měly být odstraněny) a není moc efektivní. O zamykání a dostupné druhy zámků se většinou nebudete muset starat, protože Postfix vybere nejlepší volbu.
Formát Maildir Formát schránky maildir se liší o d formátu mbox v tom, ž e používá pro uchovávání elektronických zpráv strukturu adresářů. Byl navržen pro vyřešení některých problémů se spolehlivostí a zamykáním ve formátu mbox. Pokud dojde například k havárii systému v okamžiku, kdy je doručována zpráva do souboru mbox, je možné, že zpráva bude zkrácena. Až bude systém znovu dostupný, agent MTA se znovu pokusí o doručení této zprávy. Č ástečně zapsaná zpráva na konci souboru mbox může způsobit problémy, když bude do souboru připojena další zpráva. Jiné problémy mohou nastat pokud se server POP /IMAP pokouší o přístup k souboru mbox ve stejném okamžiku jako server SMTP. Pokud tyto programy nepoužívají stejný mechanismus zamykání, soubor pošty bude pravděpodobně poškozen. Existuje několik
mechanismů zamykání souboru pošty (viz výše), které nemusí používat všechny poštov ru programy. U formátu maildir nejsou potřeba žádné zámky, protože je každá zpráva umístěna ve vlastIÚm souboru. Odlišné procesy pošty nepotřebují přístup ke stejným souborům ve stejný okamžik. Adresář ve stylu maildir má tři podadresáře, které musí být všechny na stejném systému souborů: tmp, new a eur. Tyto podadresáře jsou obvykle v adresáři s poštou v domovském adresáři uživatele: $ II Ihome/kdent/maildir total 1 2 drwxr-x- -
2 kdent
kdent
4 0 9 6 Mar 13 1 2 : 2 4 eur
drwxr-x--
2 kdent
kdent
4 0 9 6 Mar 13 1 2 : 2 4 new
drwxr-x---
2 kdent
kdent
4 0 9 6 Mar 13 1 2 : 2 4 trnp
Soubory v adresáři new jsou zprávy, které byly doručeny, ale ještě nebyly přečteny. Č as úpravy souboru je datem doručeru zprávy. Soubor obvykle obsahuje zprávu ve formátu RFC 2822 a neru potřeba žádný řádek From _.
Jakmile byla zpráva zobrazena, je přesunuta do adresáře eHr. Adresář tmp se používá v průběhu doručováru zprávy pro uložeru obsahu souboru před potvrzeIÚm a uložeIÚm do adresáře new.
Mbox nebo Maildir? Pro volbu nejlepšího formátu pošty neexistuje žádná jednoduchá odpověď. Formát mbox má tu výhodu, že je téměř univerzálně podporovaný, ale má problémy se zamy kárum souboru, které si vyžádaly vyvinutí formátu maildir. Na druhou stranu existují obavy o možnosti použití formátu maildir pro práci s velkým počtem zpráv na ně kterých systémech souborů. Pro podporu obou formátů existují argumenty výkonu: při hledáru a zpřístupňováru nebo odstraňováru konkrétIÚ zprávy je pravděpodobně rychlejší maildir, ale doručeru jednoduchým připojerum textu zprávy na konec jediné ho souboru je pravděpodobně rychlejší ve formátu mbox. Vaše volba bude s největší pravděpodobností dána volbou serveru POP /IMAP. Pokud budete používat server POP /IMAP, který vyžaduje formát maildir, je volba provedena za vás. Postfix jednodu še podporuje oba formáty, takže můžete se můžete bezpečně rozhodnout podle jiných ohledů. Pokud si myslíte, že to bude ve vašem prostředí důležité, měli byste otestovat oba formáty a simulovat své vlastru úlohy pošty.
Místní doručování Všechny cílové domény, které by měly být zpracovávány místIÚm doručováIÚm, by měly být uvedeny v parametru mydest ination. Můžete zadat domén kolik chcete, ale jednot liví místru uživatelé přijímají poštu ze všech uvedených domén. Pokud jsou například v parametru mydest ination uvedeny domény ora.eom a orei/fy.eom, pak zprávy na adresy [email protected] i kdent@orei/fy.eom jdou do stejné poštovru schránky.
Všichni místní příjemci by měli být uvedeni v tabulkách nastavených v parametru 10ca1_recipient_maps, aby nedocházelo k přijímání zpráv pro neznámé uživatele. Parametr 10ca1_recipient_maps je implicitně nastaven na soubor systému s hesly a mapy aliasů, takže normálně nemusíte provádět žádné změny. Jakmile Postf1x zjistí, že je cílovým serverem a že by zpráva měla být doručena místně, musí se rozhodnout, co se zprávou provede. Před hledáním uživatelského účtu pomocí porovnání místní části e-mailové adresy se Postf1x podívá do svých map aliasů (viz kapitola 4) . Pokud existuje alias pro předávání dál, který odpovídá adrese příjemce, Postf1x znovu pošle zprávu dál podle informace o předávání z vyhledávání aliasů. Jinak se pokusí zprávu doručit uživateli systému. Postf1x nejprve zjišťuje existenci souboru .jof7ZJord pro místrubo uživatele a podle in formací zde uvedených může zprávu znovu poslat dál. Pokud uživatele nemá soubor jOf7ZJord, Postf1x doručí zprávu do schránky uživatele.
Soubory .forward Soubory .jof7ZJord umožňují místním uživatelům vytvářet jejich vlastní aliasy. Obsah sou boru .jof7ZJord je stejný jako pravá strana položky aliasu. Pokud má položka aliasu více hodnot na pravé straně, jsou odděleny čárkami. I když soubory .jof7ZJordpoužívají stejnou konvenci, také umožňují zadávání více položek na více řádků. Vlastru'kem souboru .jof7ZJord musí být příjemce a normálně jsou umístěny v domovských adresářích uživatelů. Jiné umístění můžete zadat pomocí parametru forward_path. Při zadávání cesty v parametru jsou v okamžiku doručení expandovány hodnoty těchto osmi proměnných: $user Jméno příjemce jak je uvedeno v souboru I etclpasswd $home Domovský adresář příjemce jak je zadán v souboru letciposswd $ shell shell příjemce jak je uveden v souboru letcipasswd $ recipient Kompletní e-mailová adresa příjemce $extension Volitelné rozšíření místní části adresy příjemce, oddělené oddělovačem, napřtKlad znakem + $domain Doména z e-mailové adresy příjemce $ 1oca1 Kompletní místní část e-mailové adresy příjemce (zahrnuje případná rozšířeru)
$ recipient_de l imi ter Znak oddělovače z e-mailové adresy příjemce, pokud existuje rozšíření Pokud byste chtěli přidat podporu pro nestandardní soubor forward, nastavili byste parametr forward_path takto: forward_Rath
=
/home / Suser/ . forward /home / Suser/other_forward
Více informací o zadávání cest pomocí expandování proměnných najdete v manuálové stránce /oea/ serveru Postfix.
Doručování pro aliasy Když Postfix doručuje do příkazu nebo souboru daného v souborech aliasů, provádí doručení nebo spouští přI'kaz jako uživatel, který je vlastru'kem souboru aliasů. Výjim kou je to, když je vlastru'kem souboru uživatel root. V tom případě Postfix použije účet zadaný v parametru de fault_privs. Ten je implicitně nastavený na účet nobody. Aliasy byly popsány v kapitole 4.
Doručování do schránky Když Postfix doručuje zprávu místnímu uživateli, zapisuje zprávu do úložiště zpráv systému. Postfix implicitně používá při doručování formát mbox. Když nainstalujete Postfix, může normálně zjistit implicitní umístění adresáře se zprávami v závislosti na tom, jaký druh systému Unix používáte. Pro zadání jiného než implicitrubo adresáře můžete použít parametr mai l_ spool_di rectory. Pro změnu adresáře na jiný než impli citní adresář vašeho systému upravte soubor main.cf a přidejte nebo upravte parametr mai l_spool_di rectory: mai l_spoo l_di rectory
=
/var/spool/ma i l
Aby Postfix používal pro doručování formát maildir, zadejte za názvem adresáře ukon čovací lomítko: rnai l_spool_directory
=
/var/ spoo l / rna i l /
Postfix může být také nastaven pro doručování zpráv do schránek v domovských ad resářích uživatelů. Přiřaďte parametru home _ma i lbox relativní cestu pro určení souboru, který by měl být použit pro schránky: horne rna i lbox
=
rnbox
Aby Postfix používal formát maildir, zadejte za cestu lomítko: horne rna i lbox
=
rna ildir/
To způsobí, že Postfix bude doručovat zprávy do adresáře s názvem mai/dir v domov ských adresářích uživatelů.
Při doručování ve formátu maildir Postfix normálně vytváří potřebné adre sáře a soubory, když to práva uživatele umožňují. Pokud budou nastavena práva k adresáři tak, že do něj bude moci zapisovat každý, nebudou agenti serveru Postih pro doručování z bezpečnostních důvodů vytvářet žádné další soubory nebo adresáře.
POP a IMAP Poté, co Postfix doručí zprávy, musí mít uživatelé přístup k jejich čtení. Mnoho serverů poskytuje uživatelům server POP /IMAP pro načítání jejich zpráv přes síť. Ve většině případů Postfix funguje se servery POP /IMAP bez problémů, takže není na žádné straně potřeba žádné zvláštní nastavování.
POP vS. IMAP Když máte omezený přístup k síti nebo nemáte trvalé připojení, je protokol POP nej lepší, protože umožňuje připojení k poštovnímu serveru, načtení všech zpráv a odpojení od sítě. Pak máte místní kopie, které můžete číst i když nej ste připojeni k síti. Většina klientů POP má možnost nastavení odstraňování zpráv ze serveru po jejich načtení, jelikož pak máte místní kopie. Pokud je neodstraňujete, zprávy se hromadí a zabírají čím dál více místa na poštovním serveru. Protokol POP byl navržen s ohledem na jednodu chou implementaci, ale největším problémem protokolu POP je to, že pokud pracujete na více než jednom počítači, vaše zprávy nemusí být tam, kde byste je potřebovali. Také nespolupracuje moc dobře s více schránkami a vyžaduje, abyste stahovali celé zprávy. Není možné načítat pouze předměty a rozhodnout se, zda danou zprávu chcete. Protokol lMAP byl navržen pro vyřešení některých omezení protokolu POP. Ucho vává všechny zprávy na serveru. Když pracujete se zprávami, musíte být připojeni, ale můžete s nimi pracovat j ako by to byly místní kopie. Jelikož vše probíhá na serveru, nezáleží na tom, zda pracujete na počítači doma, na jiném počítači v práci nebo do konce na přenosném počítači. lMAP také v případě potřeby umožňuje místní ukládání zpráv a také poskytuje větší flexibilitu než POP. Můžete stahovat pouze záhlaví zpráv a pak se rozhodnout, že chcete načíst zbytek zprávy, když si ji chcete přečíst. Nemusíte stahovat velkou zprávu nebo přílohu, která vás nemusí zajímat. Na serveru lMAP můžete udržovat více schránek a adresářů.
Postfix a servery POP/IMAP Spolupráce mezi Postfixem a servery POP /IMAP je jednoduchá. Když Postfix při jme zprávu, umístí ji do úložiště zpráv. Když je uživatel požaduje, server POP /IMAP zprávy jednoduše načítá ze stejného úložiště. Na obrázku 7-1 je vidět, j ak je spolupráce mezi Postfixem a servery POP /IMAP jednoduchá. Postfix a server POP /IMAP se musí shodnout na formátu schránky a na druhu zamykání. Postfix by měl pracovat se všemi standardními servery POP /IMAP, které používají jedno z tradičních úložišť
zpráv. Možná budete muset upravit parametr ma i l_spool_directory, jak bylo popsáno dříve v této kapitole, ale u většiny serverů POP /IMAP, můžete jednoduše postupovat podle standardních pokynů pro instalaci a server spustit. Pro servery POP /IMAP, které nepoužívají tradiční úložiště zpráv může Postfix doručovat zprávy pomocí protokolu LMTP (Local Mail Transfer Protocol), který je popsán v další části.
Obrázek 7- 1. Posifix a servery POp/lMAP
Protokol LMTP (Local Mail Transfer Protocol) Některé servery POP /IMAP používají nestandardní úložiště zpráv. Jelikož by bylo ne smyslné předpokládat, že budou MfA, jako např. Postfix, znát mnoho různých vlastních formátů, používá se pro předávání zpráv z jedné místní poštovní služby do jiné protokol IM7P (Local Mail Transfer Protocol), který není závislý na společném úložišti zpráv. Protokol LMTP je založen na protokolu SMTP a je jeho zjednodušenou verzí. Pomocí protokolu LMTP může server přijmout zprávu okamžitě nebo ji nepřijmout vůbec. Server LMTP neřadí zprávy do fronty a nepokouší se znovu doručit zprávy, které ne mohou být doručeny okamžitě. Když MTA provádí doručení na server SMTP a zpráva je určena pro více příjemců, z nichž jeden nebo více příjemců nemůže z nějakého důvodu zprávu přijmout, přebírá server SMTP odpovědnost za doručení zprávy později a hlásí úspěšné doručení ode sílajícímu MTA. Servery LMTP neřadí zprávy do fronty, takže musí vrátit odpovědi o stavu doručení pro všechny příjemce konkrétní zprávy. Pro ty příjemce, kterým zpráva nemohla být doručena, přebírá odpovědnost za zařazení do fronty a pozděj ší pokus o doručení odesílající MTA a ne server LMTP. Přenos LMTP může nastat mezi poštovními subsystémy na stejném počítači nebo na různých počítačích v místní síti. Protokol není doporučeno používat v sítích WAN, jelikož je závislý na rychlé odpovědi, zda zpráva byla doručena. U protokolu SMTP je známý problém se synchronizací mezi odesílajícími a přijímajícími poštovními systémy, což někdy způsobuje duplicitní doručení zpráv. Všeobecně se má za to, že protokol LMTP v síti WAN by tento problém ještě zhoršil.
0 .,' ll ..
II:. \t>,'
Kromě doručování do nestandardních úložišt' zpráv je skutečnou výhodou protokolu
LMTP
to, že umožňuje vysoce škálovatelný a spolehlivý
�. poštovní systém. Jeden nebo více •
serverů Postfix může přijímat poštu
z veřejného internetu a doručovat ji do více systémů
LMTP
na pozadí.
Jak se zvyšuje zátěž, je jednoduché přidávat více prvků do systémů v popředí i na pozadí.
Nejběžnější implementací LMTP je server Cyrus lMAP vyvinutý univerzitou Car negie Mellon University. Je k dispozici na webu projektu Cyrus na adrese http: / /asg.web.cmu.edu/cyrus/. Jak je vidět na obrázku 7-2, Cyrus lMAP používá vlastní úložiště zpráv. Tato část se zabývá tím, jak může PostflX používat protokol LMTP pro předávání zpráv na server Cyrus lMAP. Více informací o nastavování serveru Cyrus lMAP najdete v knize Managing [MAP, kterou napsali Dianna Mullet a Kevin Mullet (O'Reilly) .
Postfix a Cyrus IMAP Cyrus lMAP je určen k provozování na serverech, které poskytují pouze přístup POP / lMAP, kde uživatelé nepotřebují účet s přístupem k shellu. Pokud vytváříte poštovní server pro stávající uživatele v systému, pravděpodobně budete chtít použít jednodušší řešení POP /IMAP, jako např. Qualcomm's Qpopper (pouze pro přístup prostřednic tvím protokolu POP) nebo lMAP Toolkit z University of Washington, který nevyžaduje pro spolupráci s Postfixem žádné speciální nastavování. Tato část se zabývá problémy konfigurace při spolupráci PostflXu se serverem Cyrus lMAP. E-mlllový servef
� ... ..."
Obrázek 7-2. Postjix a Cyrus [MAP
Cyrus lMAP musí čekat na doručení prostřednictvím protokolu LMTP přes unixové sockety nebo sockety protokolu TCP. Abyste mohli správně nastavit PostflX, musíte vědět, kterou metodu používáte. Pokud chcete používat unixové sockety, pak musí být servery PostflX i Cyrus lMAP na stejném počítači. Pokud používáte sockety TCP, může být server Cyrus lMAP na stejném systému i na jiném systému ve vaší síti. Doručování prostřednictvím LMTP je nastaveno v souboru main.if nebo v mapě doručování. Aby PostflX přijímal zprávy, které mají být předány místně serveru Cyrus lMAP, musí být název cílové domény e-mailové adresy uveden v parametru mydest ination (možná také budete chtít nastavit doručování serveru Cyrus prostřednictvím přenosu virtual - viz kapitola 8). Pak musíte nastavit PostflX pro předávání zpráv serveru Cyrus lMAP. Po mocí parametrů mai Ibox_transport, local_t ransport nebo fal lbaek_transport řeknete PostflXu, jak se mají zprávy místně zpracovat před jejich předáním serveru Cyrus. Pokud používáte loeal_ transport nebo fal lbaek_t ransport, zajistěte zadáním uživatelských jmen do vyhledávací tabulky uvedené v parametru loeal Jeeipient_maps, aby PostflX znal všechny uživatele serveru Cyrus.
mai lbox_transport Zpráva je předána nejprve agentovi pro místní doručování. Agent pro místní doru čování zkontroluje a expanduje všechny aliasy nebo položky v souborech forward. Po expandování původní adresy je zpráva delegována klientovi LMTP serveru Postfix, který ji doručí na server LMTP .
.
local_t ransport Když zadáte, že místním doručováním by mělo být LMTP, Postfix předá zprávu pří mo klientovi LMTP serveru PostflX. Normální agent pro místní doručování zprávu vůbec nezpracovává, takže neproběhne expandování aliasů nebo souborů forward. fal lback_transport Když je pro fallback použit protokol LMTP, Postfix předává zprávu nejprve agentovi pro místní doručování. Normální aliasy a soubory forward j sou expan dovány a pokud má příjemce normální účet v systému, je provedeno doručení do příslušného systémového úložiště pošty. Pokud takový účet neexistuje, je doručení delegováno na klienta LMTP serveru Postfix pro doručení na ser ver LMTP. Pokud máte v systému skutečné účty, které by měly dostávat poštu v konvenčním úložišti zpráv a zbytek uživatelů elektronické pošty nemá účty v systému, ale přijímají poštu prostřednictvím serveru Cyrus lMAP, měli byste nastavit fal lback_transport pro doručování prostřednictvím LMTP. Zadejte zvolený přenos v následujícím formátu: xxx_t ransport
=
service : socket_type [ : /path/to/ socke t l
Pro doručování prostřednictvím LMTP musí být volba service nastavena n a hodnotu lmtp, která se odkazuje na službu lmtp v souboru letcipostftxl master.if. socket _type je unix pro unixovou doménu nebo inet pro sockety TCP. Výchozí hodnotou je inet, která znamená, že pokud váš server LMTP používá socket inet, můžete jednoduše zadat službu jako: local_transport
=
lmtp
Typické nastavení přenosu prostřednictvím protokolu LMTP v souboru letcipostftxl main.ifpomocí volby local_t ransport a unixových socketů vypadá takto: local_transport
=
lmtp : unix : /var/ imap/ socket/ lmtp
Příklad konfigurace serverů Postfix a Cyrus IMAP Pro sestavení serveru Cyrus lMAP potřebujete knihovnu Cyrus SASL, která se používá pro ověřování uživatelů serveru lMAP.* Nejprve musíte sestavit a nainstalovat knihovnu Cyrus SASL a pak můžete sestavit server Cyrus lMAP. Software Cyrus vyžaduje alespoň verzi 3 software Berkeley DB. Pokud používáte verzi Berkeley DB nižší než 3, možná
. Je to stejná knihovna, jaká se používá pro přidávání podpory ověřování do Postfixu. Více informací o přidávání podpory ověřování
SMTP do
Postfixu najdete v kapitole
1 2.
budete muset aktualizovat celý systém. Kombinace více odlišných verzí Berkeley DB v jednom systému pravděpodobně povede k problémům, který může být obtížné najít. Pokud musíte inovovat knihovny, zvažte opětovné sestavení dalších balíčků, které použí vají Berkeley DB Gako např. Per! a Postfix), aby všechny programy v systému používaly stejnou verzi knihovny. Při kompilování a instalaci se řiďte instrukcemi v distribucích Cyrus SASL a lMAP. Pro vaši platformu mohou být k dispozici binární distribuce. Podívejte se do vašich normál ních zdrojů software, zda si můžete ušetřit problémy se sestavováním software Cyrus. V tomto příkladu předpokládejme, že máte server Postfix přijímající poštu pro doménu example . com. Všechny emailové účty jsou nastaveny na serveru Cyrus lMAP běžícím na stejném systému, takže je v systému velmi málo přihlašovacích účtů. Samozřejmě chcete, aby byla pošta určená pro účet root nebo alias postmaster odeslána správné osobě, což znamená, že potřebujete expandovat místní aliasy před předáním zpráv na server Cyrus lMAP. Za tímto účelem nastavte parametr mai lbox_transport tak, aby ukazoval na doručovacího agenta lmtp, který bude nastaven pro doručování pošty na server Cyrus lMAP: 1 . Proveďte instalaci a nastavení serveru Cyrus lMAP ve vašem systému. Zkont rolujte konfigurační soubor Cyrus (obvykle letci ryrus.conj), abyste se ujistili, že je nastaven tak, aby používal unixové sockety a všimněte si umístění souboru socketu. Měli byste vidět položku podobnou této: SERVICES {
• add or remove based on preferences imap
cmd= " imapd" l i s ten=" imap" prefork=O
pop3
cmd= "pop3d" l i s ten="pop 3 " prefork=O
• LMTP is requ i red for de l ivery cmd= " lmtpd" l i s ten= " /va r/ imap/ socket/ lmtp" prefork=O
lmtpunix
Položka lmtpunix ukazuje správnou cestu k souboru socketu. 2. Podle dokumentace, která je dodávána k vašemu balíčku přidejte uživatele na server Cyrus lMAP. 3. Zkontrolujte letcipostfixl master.cf, abyste se ujistili, že je služba lmtp nastavena správně. Řádek by měl vypadat takto: lmtp
unix
-
n
lmtp
Pokud máte implicitní instalaci Postf1Xu, řádek lmtp již bude v souboru, jak je uvedeno v tomto příkladu. Pátý sloupec říká, zda by měl doručovací agent LMTP běžet v pro středí se změněným kořenovým adresářem. Doručovací agent LMTP serveru Postf1X v tomto poKladu musí číst soubor socketu vytvořený serverem Cyrus lMAP, takže nechte v tomto sloupci hodnotu n:
•
Je možné nastavit systém tak, aby umožňoval doručovacímu agenru LMTP číst soubor sockeru dokonce i v pro
středí se změněným kořenovým adresářem, ale pravděpodobně to nebude nutné.
4. Zkontrolujte soubor main.cf, abyste se ujistili, že je doména, pro kterou přijímáte poštu, uvedena v parametru mydestination. Může být uvedena explicitně: rnydest ination
=
$rnyhostnarne , localhos t . $rnydorna i n , $rnydorna i n ,
exarnple . com
nebo může být převzata z proměnné $mydomain: .
rnydornai n
=
exarnple . com
rnyde s t ination
=
$rnyhostnarne , localho s t . $rnydornai n , $rnydornai n
5. Zadejte parametr mai lbox_transport, aby byla používána služba lmtp ze souboru master.ifa odkažte se na soubor socketu serveru Cyrus lMAP, jehož cestu zadáte v konfiguračním souboru Cyrus (viz položka 1 ) : rnai lbox_transport
=
lrntp : unix : /va r / irnap / socke t / lrntp
6. Znovu spusťte Postfix: t poltfix reload
KAPITOLA 8
Hosting více domén
Dnes j e běžné, že j e na jediném systému umístěno více domén. Domény oreillynet.com a onlamp.com by mohly být napřfklad na jediném hostiteli, ale chovat se, jako by se jednalo o dva naprosto odlišné hostitele. Systém má obvykle kanonickou doménu, která v systému reprezentuje obvyklé nebo společné doménové jméno. Další domény jsou nastavené jako virtuální. Každá virtuální doména může poskytovat služby jako je web a pošta, jako by se jednalo o jedinou doménu na serveru. Tato kapitola popisuje vfce různých mechanismů pro hosting vfce domén. Tyto techniky jsou popsány odděleně, ale, když musíte pracovat odlišným způsobem s různými doménami, je možno je kom binovat. Před volbou techniky nebo technik, které potřebujete, se musíte rozhodnout, jak má Postfix doručovat zprávy pro virtuální domény. Na způsob nastavení PostflXu pro ho sting vfce domén mají vliv především dvě věci: •
Měly by mít vaše domény oddělené jmenné prostory? Měla by být napřfklad pošta pro e-mailové adresy [email protected] a [email protected] doručována do stejné schránky nebo do dvou různých schránek? Situaci se stejnou schránkou budeme označovat jako sdílené domény a druhou jako oddělené domény.
•
Potřebuje každý uživatel účet v systému? Budeme odlišovat systémové účty, které jsou skutečnými účty v systému, a virtuální účty. U virtuálních účtů mohou mít uživatelé na vašem serveru schránky, ale nepřihlašují se jinak do systému a nemusí mít položku v souboru I ctclpasswd.
Postfix může zpracovávat poštu pro virtuální domény čtyřmi různými způsoby: •
sdílené domény se systémovými účty,
•
oddělené domény se systémovými účty,
•
oddělené domény s virtuálními účty,
•
virtuální domény s vlastním úložištěm zpráv, které není spravováno PostflXem.
Váš server POP llMAP bude hlavním faktorem v rozhodování o použité technice. Po kud váš server POP llMAP neumí pracovat s virtuálními doménami, pak bude s nej-
větší pravděpodobností vyžadovat účty v systému pro všechny adresy. Některé servery POP / IMAP podporují více domén a doručují zprávy do konkrétní adresářové struktury na místním systému souborů. Jiné servery POP / IMAP používají vlastní úložiště zpráv. Postfix do nich může doručovat zprávy pomocí LMTP. Bez ohledu pa použitou techniku musí být všechny domény správně nastaveny v DNS. Konfiguraci DNS byste měli nastavit pro virtuální domény stejným způsobem jako pro kanonickou doménu vašeho systému. Více informací o Postfixu a DNS najdete v kapitole 6.
Sdílené domény se systémovými účty Příjem pošty pro více domén, kde každý uživatel přijímá poštu z každé domény, je nej jednodušším nastavením virtuálních domén. Jednoduše přidejte své virtuální domény do parametru mydestination. Poté vytvoříte systémové účty a uživatelé mohou začít přijímat poštu adresovanou do kterékoliv z domén. Tato technika používá agenta pro místní doručování a poskytuje stejné funkce jako váš normální hosting kanonické domény. Uživatelé mohou vytvářet své vlastní soubory
forward a
mají k dispozici místní aliasy.
V systému, jehož kanonický název je oreillynet.com a jsou v něm umístěny dvě virtuální domény ora.com a oreilly.com, je parametr mydomain nastaven jako kdyby oreillynet.com byla jedinou doménou a parametr mydest ination je nastaven takto: mydoma in : ore i l l ynet . com myde s t i nation : $myhostname , $mydoma i n , ora . com, orei l l y . com
Po provedení změn restartujte Postfix. Uživatelé nyní mohou přijímat poštu pro kte roukoliv z domén, které jste uvedli v parametru mydest ination: • poltfix reload
Zprávy adresované na [email protected] a info@orei//y.com jsou předávány stejnému místnímu uživatelskému účtu.
Oddělené domény se systémovými účty Pokud potřebujete oddělené jmenné prostory pro každou z virtuálních domén, je kon figurace jen o málo komplikovanější. Při oddělených doménách by měla být pošta pro
[email protected] doručována do jiné schránky než pošta pro itifo@ orei//y.com. V tomto případě neuvádějte další domény v parametru myde s t ination. Místo toho použij te parametr virtual alias domains: -
-
vi rtual_a l i a s_doma ins : ora . com, orei l l y . com
Pro každou e-mailovou adresu, která bude přijímat poštu ve vašem systému, musíte vytvořit uživatelský účet. Vaše systémové účty nemusí vůbec odpovídat e-mailovým adresám, protože budete mapovat adresy na účty odděleně, ale každý účet musí být unikátní. Pokud vaše platforma podporuje dlouhá uživatelská jména, je dobré při vytvá ření unikátních názvů účtů a pro vyvarování se omylů týkajících se toho, které účty mají
přijímat poštu pro kterou doménu, používat název domény jako součást názvu účtu. Možnou konvencí pojmenování je vytváření účtů jako
irifo.ora.com a irifo.orei/fy.com.
Jakmile Postf1x ví, pro které domény má přijímat poštu, a máte účty pro každou adresu, použijte parametr virtual_alias _maps pro mapování e-mailových adres na účty, které jste vytvořili. V souboru
main.cf nastavte parametr virtual_al ias_maps na soubor pro vyhle / etc/postjix/virtuaLalias:
dávání virtuálních aliasů. V tomto příkladu je použit soubor virtual_a l i as_maps
Soubor
=
hash : /etc/postfix /vi rtual_a l i a s
/ etc/posifžx/ virtuaLalias obsahuje položky s e-mailovými adresami odkazujícími
se na systémové účty, které j ste vytvořili, a potřebné předávání zpráv na jiné adresy: info@ora . com
helene @ localhost
info@ore i l l y . com
frank@ localhost
kdent@ore i l l y . com
kyle . dent@onlamp . com
Kdykoliv vytvoříte nebo upravíte soubor s virtuálními aliasy, nezapomeňte pro daný soubor spustit přľkaz postmap: • postmap virtual_alias
Pokud uživatelé helene a frank plánují odesílat zprávy ze systému, pravděpodobně bu dete také chtít nastavit kanonické mapy, aby odesílané zprávy obsahovaly správné adresy odesílatele. Přiřaďte vyhledávací tabulky, jako je ta následující, do canonical_maps: info@ora . com
helene frank
info@ore i l l y . com
A nezapomeňte provést přľkaz postmap: • postmap canonical
Oddělené domény s virtuálními účty Nevýhodou předchozích technik je to, že musíte spravovat systémové účty pro všechny e-mailové adresy na vašem serveru. Se zvyšujícím se počtem domén se zvyšuje i náročnost správy účtů. Zejména pokud uživatelé na vašem serveru pouze přijímají poštu a jinak se nepřihlašují, pravděpodobně nebudete chtít, aby každý z nich měl systémový účet. Namísto toho můžete nastavit Postf1x pro doručování do místruno úložiště zpráv, kde bude mít každá virtuální e-mailová adresa svůj vlastní soubor schránky. Vaši uživatelé pak přijímají své zprávy prostřednictvím serveru POP /IMAP' Místní úložiště zpráv funguje jako běžné místní doručování, ale nevyžaduje pro každý soubor pošty odpovídající místní uživatelský účet. Při tomto nastavení uveďte každou virtuální doménu v parametru virtual_ma i lbox_domains: virtua l_ma i lbox_doma ins
=
ora . com, orei l l y . com
Pokud máte mnoho domén, můžete je uvést v souboru a nastavit parametr virtu
al mai lbox doma ins n a tento soubor: -
-
virtua l_ma i lbox_doma ins
=
/etc/postfix/vi rtua l_domains
Soubor
1 etc!postfixl virtuaLdomains pak obsahuje jeden řádek pro
každou doménu:
t
t /etc/po s t f i x /vi rtual_doma ins t ora . com
ore i l l y . c()m
Zprávy pro virtuální domény uvedené v parametru virtua l_ma i lbox _ doma i n s j sou doručovány virtuálním doručovacím agentem, který je ve skutečnosti upravenou verzí agenta pro místní doručování. Doručování je velmi bezpečné a efektivní, ale místní ali asy, soubory
forward a programy pro e-mailové diskusní skupiny nejsou k dispozici.
Pro
aliasy můžete použít parametr virtual_alias _maps, který jste viděli dříve v této kapitole. Technikou doručování do programů se budeme zabývat dále v této kapitole. Při nastavování virtuálních schránek byste měli vytvářet s trukturu adresářů, jakou očekává server POP lIMAP. Nyní předpokládejme, že jsou všechny virtuální schránky umístěny pod základním adresářem
1 IIsrlloeall vmaiL
Každá virtuální doména má svůj
vlastní podadresář, takže máte adresáře jako jsou tyto: / u s r / local/vma i l /ora . com / u s r / l ocal/vma i l /ore i l l y . com
Toto je běžné nastavení serverů POP lIMAp, které podporují virtuální hosting. V po dadresáři každé domény jsou soubory pošty pro každého uživatele. Pomocí parametru
vi rtual_mai lbox_base zadejte v konfiguraci Postfixu základní adresář úložiště zpráv: vi rtua l_mai lbox_base
=
/usr/ local/vma i l
Musíte vytvořit vyhledávací soubor, který bude mapovat e-mailové adresy n a soubory schránek. Vyhledávací tabulku zadejte pomocí parametru vi rtual_ma i lbox_maps: vi rtua l_ma i lbox_maps
=
hash : /etc/postfix /virtual
Každý uživatel přijímající poštu do souboru virtuální schránky musí mít položku ve vyhledávací tabulce Postfixu. Soubor schránky je zadán relativně vůči vi rtual_mai l
box_base. Soubory pošty mohou být uloženy ve formátu mbox nebo maildir (viz kapitola 7). Pro použití formátu maildir zadejte na konci cesty lomítko. Soubor pro mapování virtuálních schránek vypadá takto: i n fo@ora . com
ora . com/ info
i n fo@ore i l l y . com
ore i l l y . com/info
Pošta pro adresu
[email protected]
je umisťována do jiné schránky než pošta pro adresu
[email protected].
Vlastník souboru schránky Vlastníkem souborů virtuálních schránek musí být uživatel a soubory musí mít přiřaze nu skupinu. To, jak vaši uživatelé načítají své zprávy, určuje, kdo by měl být vlastníkem souborů schránek. Server POP llMAP často běží pod svým vlastním uživatelským účtem a očekává, že bude vlastníkem těchto schránek tento uživatel. Pokud je to ale nutné,
Postftx umožňuje podle potřeby nastavit vlastníka souboru schránek jinak. Každý z nich může mít jiného vlastníka nebo může všechny schránky pro jednu doménu vlastnit jeden uživatel, zatímco vlastníkem schránek jiné domény bude jiný uživatel. Parametry virtual_uid_maps a virtual_gid_maps určují vlastníka a skupinu, které Po stftx používá při doručování do souboru virtuálních schránek. Pomocí druhu mapy
static můžete zadat, že by měl být vlastníkem všech virtuálních schránek stejný uži vatel. Pro tento příklad předpokládejme, že máte účet s názvem vmail, který má UID 1 003, a skupinu vmail s GID 1 005. Chcete, aby všechny soubory virtuálních schránek vlastnili tento uživatel a tato skupina. Nastavte parametry virtual_uid_maps a virtual_gid_maps v souboru vi rtual_uid_maps
=
static : 1 0 0 3
vi rtua l_gid_maps
=
static : 1 0 0 S
main.cf.
Pokud chcete používat ruzná UID pro různé soubory schránek, musíte vytvořit vy hledávací soubor mapující adresy na UID. Pak nastavte parametr pro mapování na váš vyhledávací soubor: virtual_u id_maps
=
hash : / etc/postfix/virtual_uids
Pokud by měla mít většina virtuálních schránek stejného vlastníka, ale některé vyžadují odlišné UID, můžete kombinovat statické a tabulkové vyhledávání: virtual_uid_maps
=
hash : /etc /pos t f ix/virtual_uids static : 1 0 0 3
Pokud potřebujete také oddělené mapování skupin, můžete použít stejný způsob. Soubor / etc!postftx/ virtuo'-uids obsahuje položky s mapováním každé adresy na správné UID. V tomto případě schránky pro ora.com používají jeden identiftkátor a schránky pro oreilly.com jiný: •
• /etc /post fix/vi rtual_uids •
info@ora . com
1004
kdent@ ora . com
1004 1007
info@ore i l l y . com service@ore i l l y . com
1007
Virtuální aliasy Je možné, aby byly některé adresy virtuálních domén doručovány do místního úložiště zpráv a jiné předávány na jiné adresy. Jelikož jsou pro všechny adresy příjemců kontro lovány virtuální aliasy bez ohledu na jejich třídu, jednoduše umístěte předávané adresy do souboru vi rtual_alias _maps namísto souboru virtual_mai lbox_maps. Ujistěte se, že parametr virtual_alias _maps ukazuje na vyhledávací tabulku virtuálních aliasů: virtual_a l i a s_maps
=
hash : / etc/po s t f ix/vi rtual_a l i a s
Soubor letcipos!ftxl virluaLalias obsahuje položky pro adresy, které by měly být předány někam jinam: kdent@ore i l l y . com
kyl e . dent@onlamp . com
Neuvádějte domény v parametru vi rtual_ma i lbox_domains i virtual_a l i a s _doma ins najednou. Parametr virtual_mai lbox_doma ins používejte pro domény, které mají ali asy i schránky, a parametr virtual_a l i a s _domains pouze pokud jsou všechny adresy aliasy.
Doménový koš Pro virtuální schránky nebo aliasy může vaše vyhledávací tabulka obsahovat název domény bez místní části pro zachytávání všech zpráv určených pro danou doménu, ale adresovaných na neexistující adresu. Doménové koše by měly být používány s rozmys lem, jelikož se v nich může hromadit mnoho nevyžádané pošty. Odesílatelé nevyžádané pošty často posílají zprávy na neexistující účty v doméně tyto zprávy jsou pak zachyceny v doménovými koši.
Doménový koš pro virtuální schránky Prvním krokem je zadání schránky, která by měla přijímat zprávy odeslané na neexistu jící adresy. Můžete použít již existující schránku nebo můžete vytvořit novou. Zadejte novou položku vi rtual_mai lbox_maps podobnou té následující pro doručování zpráv s neznámou adresou příjemce do schránky service: @ora . com
ora . com/service
Doménový koš pro virtuální aliasy Adresy doménových košů s virtuálními aliasy fungují podobně jako virtuální schránky, ale doménový koš pro aliasy byste měli nastavit pouze pokud jsou všechny adresy v doméně nastaveny jako aliasy a ne schránky. Jelikož jsou virtuální aliasy kontrolovány dříve než vir tuální schránky, zachytí doménový koš všechny zprávy, včetně těch, které by jinak skončily ve virtuálních schránkách. Po zadání adresy, na kterou by měly být posílány zprávy posílané na neexistující adresy zadejte novou položku virtual_alias maps podobnou této: _
@ora . com
customer . service@onlamp . com
Adresu doménového koše pro virtuální aliasy je možné používat společně s virtuálními schránkami vytvořením položek pro všechny virtuální schránky ve vyhledávacích mapách virtuálních aliasů. Za předpokladu, že máte virtuální schránky: info@ora . com
ora . com/ info
info@ore i l l y . com
orei l l y . com/ info
musí vyhledávací tabulka virtuálních aliasů, která obsahuje doménový koš pro aliasy obsahovat také položky schránek:
@ora . com
customer . servi ce@onlamp . com
kdent@ore i l l y . com
kyle . dent@onlamp . com
info@ora . com
info@ora . com
info@ore i l l y . com
info@ore i l l y . com
Pak nebudou zprávy adresované na [email protected] zachyceny doménovým košem pro aliasy @ora.com.
Oddělené úložiště zpráv Poslední nastavení, na které se podíváme, je hosting virtuálních domén na systému používajícím vlastní úložiště zpráv. Při práci s těmito systémy Postfix předává zprávy pomocí protokolu jako LMTP, což umožňuje vlastnímu systému provádět doručení do správné schránky. Jelikož musí Postfix přijímat zprávy před jejich předáním serveru LMTP, musí vědět, že by měl přijímat poštu pro všechny virtuální domény. Zadejte je do vi rtual_mai l box domains: virtua l_ma i lbox_doma ins
=
ora . com, orei l l y . com
Také musíte uvést každou e-mailovou adresu, aby mohl Postfix přijímat zprávy pro platné adresy a odmítat neznámé uživatele. Pomocí parametru virtual_ma i lbox_map s zadejte soubor pro vyhledávání s platnými adresami: vi rtua l_ma i lbox_maps
=
hash : /etc/postfix/vi rtual
V souboru letcipostfixl virtual se hodnota pravé strany nepoužívá, protože jsou všechny zprávy předávány serveru POP lIMAP. Stále musíte uvádět hodnotu pravé strany, protože vyhledávací tabulky musí mít klíč a hodnotu, ale na hodnotě, kterou použijete, nezáleží: info@ora . com
General I n formation Addres s
info@ore i l l y . com
General I n forma t i on Addre s s
Aby Postfix předával poštu pro virtuální domény na server POPlIMAP, zadejte správný přenos v parametru vi rtual_t ransport v souboru main.if. Musíte vědět, jak je nastaven socket serveru LMTP. Za předpokladu, že je na stejném hostiteli jako PostflX a používá soubor socketu umístěný v I varl imapl socketl Imtp, bude vyhledávací tabulka pro předá vání pro tento přľklad vypadat takto: virtual_transport
=
lmtp : unix : /var/ imap / s ocket/ imap
Díky tomu budou všechny vaše vi rtual_ma i lbox_doma ins předávány na váš server POP llMAP před LMTP.
Doručování do příkazů Jak bylo uvedeno dřľve v této kapitole, ve spojení s virtuálními doménami nemůžete používat místní aliasy, soubory fonvard a programy pro e-mailové konference. Viděli jste, že prostřednictvím parametru vi rtual_alias _maps můžete snadno nastavovat aliasy, ale nemůžete doručovat zprávy do příkazů. V této poslední části se podíváme na to, jak
obejít tento problém a doručovat virtuální adresy do externích programů. V prvním přľkladu je nastaveno doručování do programu pro automatickou odpověď a ve druhém do programu pro správu e-mailové konference. N ástroje pro automatické odpovědi j sou skripty nebo programy, které zpracovávají přľchozí zpr�vy a vrací odpověď odesílateli zprávy bez zásahu člověka. Program pro generování automatické odpovědi použitý v tomto přľkladu,
inforep!J.p1, je uveden v přľ
kladu 8-1 . Tento program je určen ke zpracování pošty pro danou e-mailovou adresu. Uživatelé nebo zákazníci mohou odeslat zprávu na adresu pro vyžádání speciálních informací. Pamatujte si, že tento jednoduchý příklad není obecným programem pro automatické odpovědi, j ako napříldad přľkaz systému Unix
vacation. Neukládá adresy, na
které odpovľdal a neprovádí plnou kontrolu adres, které by neměly přijímat automatické odpovědi (viz sidebar). Také byste možná program chtěli vylepšit, aby vracel různé druhy informací v závislosti na předmětu nebo klíčovém slovu v těle zpráv požadavků.
Pfiklad 8- 1. fednoducijprogram pro automatické odpovédi f ! / u s r /bin/perl -w •
• in forepl y . pl - Automatic ema i l repl y .
f
t All mes s ages are logged to your ma i l log . Check the t log after executing the s cript to see the resul t s . •
• Set $ U I D to the uid of the proces s that runs the script .
• Check the entry in master . c f that c a l l s this sc ript . Use
t the uid o f the account you a s s ign to the user= attribute . t I f you want to test the s cript f rom the command line,
J set $ U I D to your own uid . •
• Set $ENV_FROM to the envelope FROM addres s you want on f outgoing replies . By de fau l t i t ' s blank, which w i l l
f use t h e NULL sender addre s s <> . Y o u c a n set i t to a n
• addres s to receive bounce s , b u t make s u r e y o u don ' t set
f i t t o the s ame addres s that invokes the program, or t you ' l l create a mai l l oop .
•
• Point $ I NFOFI LE to a text f i l e that contains the text o f
• t h e outgoing repl y . Incl ude a n y heade rs you w a n t in the
• mes s age such a s Subj ect : and From : . The To : header is
t set automa t i c a l l y based on the sender ' s addre s s . Make
f sure you have an empty l i ne between your headers and the
• body o f the me s sage .
•
• I f necessary, change the path to sendma i l in $MAILBIN . •
• @MAI LOPTS contains opt ions to sendma i l . Make changes i f • necessary . The de fault opt ions should work i n mos t
#
•
s i tuations .
t The c a l l s to syslog require that your Perl instal lation • conve rted the necessary header f i l e s . See h2ph in your
• perl distribut ion . •
require 5 . 0 0 4 ;
• for setlogsock in Sys : : Syslog module
use strict; use Sys : : Syslog qw ( : DEFAULT setlogsock ) ; •
• Config options . Set these according to your needs .
•
my $UID = 5 0 0 ; m y $ENV_FROM = " " ; my $ INFOFI LE = " /home/autoresp/inforeply . txt " ; my $MAILBIN = " /usr/sbin/sendmail " ; my @MAI LOPTS = ( " -oi " , "-trn , " $ENV_FROM" ) ; my $SELF = " in forepl y . pl " ; •
t end of config opt ions my $EX_TEMPFAIL = 7 5 ; m y $EX_UNAVAILABLE = 6 9 ; m y $EX_OK = O ; my $sende r ; m y $euid = $ > ; $ S I G { P I PE ) = \ & PipeHandler ; $ENV { PATH } = " /bin : /usr/bin : / sbin : /usr/sbin" ; setlogsock ( ' unix ' ) ; openlog ( $ SELF, ' ndelay, pid ' , ' user ' ) ; •
• Check our envi ronment . t
if ( $euid ! = $UID ) { syslog ( ' mail l err ' , "error : invalid uid : $> ( expect ing : $UID) " ) ; exit ( $EX_TEMPFAI L ) ; if ( @ARGV ! = 1 ) { syslog ( ' mai1 I err ' , "error : inva1id invocation ( expecting 1 argument ) " ) ; exit ( $EX_TEMPFAIL ) ; } else { $sender = $ARGV [ O ] ; if ( $sender =� / ( [ \w\- . % ] + \ @ [ \w . - ] + ) / )
t scrub address
$sender = $ 1 ; } else ( syslog ( ' mail l err ' , "error : I l legal sender address " ) ; exit ( $EX_UNAVAI LABLE ) ;
i f ( ! -x $MAILBIN ) sys1og ( ' mail l err ' , "error : $MAILBIN not found or not executable " ) ; exit ( $EX_TEMPFAI L ) ; if ( !
-
f S INFOFILE I {
syslog ( ' mai l l err ' , "error : $ INFOFILE not found" ) i exit ( $EX_TEMPFAI L ) i
t t Check sender exceptions . t if ( $sender eq " " I I $ sender =� / A owner- I - ( request l owner) \ @ I A (mai ler-daemon l postmaster ) \ @ / i ) { exit ( $EX_OK ) i
t
t Check message contents for Precedence header .
t
while ( <STDIN> ) { last if ( / A $ / ) i exit ( $EX_OK) if ( / Aprecedence : \st (bulk l l ist l j unk) / i ) i
t
• Open info file .
t
if ( ! open ( INFO, "<$ INFOFI LE " ) ) ( syslog ( ' mai l l err ' , "error : can ' t open $ INFOFI LE : %m" ) i exit ( $EX_TEMPFAIL) i t
• Open pipe to mai le r .
t my $pid
=
open (MAIL, " 1 - " )
I I exec ( " $MAILBIN" , @MAILOPTS ) i
i
t Send reply .
t
print MAIL "To : $sender\ n " i print MA I L while « INFO» i if ( ! close (MAIL) ) { syslog ( ' mail l err ' , "error : failure invoking $MAILBIN : %m" ) i exit ( $EX_UNAVAlLABLE ) i
close ( INFO) i sys log ( ' mail l info ' , " sent reply to $ sender" ) i exit ( $EX_OK) i sub PipeHandler syslog ( ' mail l e rr ' , "error : broken pipe to mai ler" ) i
Nastavení virtuálního programu pro automatickou odpověď Aby automatická odpověď pracovala s virtuálními doménami, musíte vytvořit speciální druh přenosu v souboru masler.cfpro doručování do konkrétního příkazu. Aby byly zprá vy doručovány do vašeho nového komponentu, musíte namapovat adresu na transport, který jste vytvořili pomocí transportních map. Mnoho programů pro automatické odpovědi umí zpracovávat v jeden okamžik pouze jedinou zprávu s jediným příjemcem. Počet příjemců pro nějaký druh transportu můžete omezit nastaverum parametru ve formě t ransport des tinationJecipient_l imi t, kde řetězec transport je název druhu transportu. Pokud by měl být přenos s názvem in fo reply omezen na jediného příjemce v jeden okamžik, nastavte následující parametr: _
inforep l y_dest ination_recipient_l imit
=
1
Vytváření programů pro automatické odpovědi Pokud vytváříte vlastní program pro automatické odpovědi, měli byste vzít v úvahu několik věcí. Prvru, a patrně nejdůležitěj ší věcí je to, že váš program přijímá data ze sítě, což je nedůvěryhodný zdroj . Nečiňte žádné předpoklady o vstupu, který zpracováváte, kromě toho, že je navržen tak, aby nějakým způsobem napadl váš systém. Za žádných okolností byste neměli spouštět shell, kde by mohl být nedů věryhodný vstup schopen získat přístup k vašemu systému. Další problémy mají co dělat spíše se zdvořilostí než s čím jiným. Například ne chcete, aby váš program pro automatickou odpověď posílal odpověď do e-mai lové konference se stovkami nebo tisíci příjemců. Nikdy neodesílejte odpovědi na adresy ve tvaru owne r- l i s t nebo l i s t- reque st. Existuje několik dalších adres, na které pravděpodobně nebudete chtít odpovídat, jako například pos trna s ter, daemon a maj ordomo. Váš program by měl nastavit svou vlastní adresu obálky na prázdný řetězec, aby nedošlo ke smyčce. Mnohé e-mailové konference používají pole záhlaví s názvem Precedence:. Obec ně nastavují hodnotu na něco jako bul k, aby indikovaly svůj účel. Váš program by měl kontrolovat pole Precedence: a pokud je nastaveno na bul k, l i s t nebo j unk, neměl by posílat odpověď. Nakonec se ujistěte, že váš program může zaznamenávat do souboru protokolu události při přijetí každé zprávy. Jakmile Postfix doručí zprávu vašemu programu, program má zodpovědnost za kontrolu chyb a jejich oznamováru správci.
Následující kroky popisují nastavování programu injorep/y.pl pro e-mailovou adresu injo(ijJora.com. Doména ora.com je nastavena jako virtuální doména. Místní doménou hostitele je example.com:
1 . Vytvořte místní účet, s jehož právy by měl být program
inforepty.pl spouštěn.
V tomto přľkladu je použit účet autoresp. Pro tento účel byste měli vytvořit nový pseudoúčet. Pro vytvořenľ účtu použijte normálnť nástroje pro správu.
2. Přidánľm položky do vašeho souboru master.ff vytvořte druh přenosu s názvem infor epl y. Položka by měla vypadat podobně jako: . in foreply
unix
-
n
n
pipe
flags= user=autoresp a rgv= / u s r / loca l / b i n / i nforepl y . pl $ { sender }
Pro doručovánľ zpráv do externľch přt'kazů je použit démon pipe. Pokud váš program vyžaduje nějaké speciálnľ volby, měli byste zadat flags (více informacť o dostupných volbách najdete v manuálové stránce pro pipe(8)). Pro komponenty
pipe v souboru master.ff je vyžadován atribut user. Atribut argv musľ být zadán jako poslednľ a měl by začínat cestou k přt'kazu pro automatickou odpověď. Existuje několik hodnot, které můžete předat do vašeho přt'kazu, když jej Postftx provádľ. Hodnoty jsou předávány prostřednictvľm speciálnťch maker. V tomto přľkladu je předána adresa obálky odesílatele ($ { sender } ) . Pro jednoduchý pro gram pro automatické odpovědi inforepty.plpotřebujete pouze adresu odesílatele, ale často budete chtít také adresu přľjemce ($ { recipient }), pokud bude program pro automatické odpovědi zpracovávat vľce adres přľjemců. Seznam dostupných maker najdete v manuálové stránce pro pipe(8). 3. Pokud ve vašem systému nemáte nastavené transporty, nastavte parametr trans
port_maps v souboru main.if tak, aby ukazoval na tabulku transportů: transport_maps = hash : /etc/postfix/transport
4. Přidejte do tabulky transportů položku, která bude obsahovat adresu pro směro vánľ zpráv na inforeply. V tomto přľpadě použijeme adresu [email protected]: autoresp@ ora . com
in foreply
Nynľ jsou všechny zprávy odeslané na adresu [email protected] předány programu pro generovánľ automatické odpovědi. 5. Spusťte přľkaz postmap s vyhledávacť tabulkou transportů: t postmap letc/postfiz/transport
6. Nastavte vi rtual_alias _map s na vyhledávacť tabulku virtuálnťch aliasů: virtual_a l i a s_maps = hash : / etc/pos t f ix/vi rtual_a l i a s
7. Přidejte položku do vyhledávacť tabulky virtual_alias pro mapovánľ adresy info@],ora.com na novou adresu pro automatickou odpověď a skutečnou adresu přľjemce, který může přijímat zprávy: info@ora . com
autoresp@ ora . com service @ore i l l y . com
8. Spusťte postmap pro vyhledávacť tabulku virtuálnťch aliasů: t postmap letc/postfiz/virtual_alias
Nyní budou zprávy zaslané na e-mailovou adresu i1ifrlE)ora.com doručeny na adresy
a/[email protected] a service@Joreil(y.com. 9. Restartujte PoStflX, aby načetl změny v souborech main.ifa master.ff. • postfix reload
Když je zpráva zaslána na adresu
[email protected],
Postfix nejprve najde cílo
vou adresu ve vyhledávací tabulce virtual_alias. Adresa ukazuje na adresy
a/[email protected]
a
service@Joreil(y.com.
Postfix najde adresu
a/[email protected] ve
vyhledávací tabulce transportů, která ukazuje na transport inforeply v souboru
master.cf. Položka v
souboru
master.if předává zprávu
do programu
inJorep(y.pl,
který odesílá odpověď původnímu odesílateli. Zpráva je nakonec znovu ode slána pro její doručení na adresu
service@Jorei/(y.com.
Konfigurace správce virtuálních e-mailových konferencí V dalším příkladu budete nastavovat e-mailovou konferenci pro virtuální doménu. E-mailové konference j sou popsány v kapitole 1 0. Možná se do této kapitoly budete chtít podívat ještě před nastavováním vašich virtuálních e-mailových konferencí. V tom to příkladu bude vytvářena e-mailová konference pro Majordomo. Nejprve byste měli nainstalovat a nastavit Majordomo podle instrukcí v kapitole 1 0. Virtuální e-mailové konference vytváří paralelní verzi konference pod místní doménou. Místní verze je používána pouze interně ve vašem systému. Externí uživatelé mohou po užívat virtuální adresy a vůbec nemusí vědět o existenci místní verze. Při pojmenovávání místní verze možná budete chtít zadat název virtuální domény, abyste seznamy pro různé domény nějak odlišili. Následující procedura vytváří e-mailovou konferenci na virtuální adrese
astronom�ora.comJ kteráje řízena
místní verzí
astronomy-ora@J,example.com:
1 . Vytvořte místní verzi e-mailové konference jako by to byla normální e-mailová konference, jak je popsáno v kapitole 1 0, přidáním následujících položek do 1 /lsrl locall mqjordomol aliases: • a s t ronomy@ ora . com l i s t
a s t ronomy-ora :
: include : / u s r / local/ma j o rdomo / l i s t s / a s t ronomy
owner-ast ronomy-ora :
kdent @ora . com
ast ronomy-ora-request : " I /usr/ local /ma j ordomo /wrapper request-answer \ ast ronomy-ora" ast ronomy-ora-approva l :
kdent@ ora . com
2. Obnovte tabulku aliasů pro Majordomo: • postaliases /usr/local/majordomo/aliases
3. Vytvořte soubor s e-mailovými adresami pro seznam členů a nastavte jako jeho vlastníka účet majordom: • touch /usr/local/majordomo/lists/astronomy
• chown majordom /usr/local/majordomo/lists/astronomy
4. Pokud je to potřeba, vytvořte pro seznam soubor info v I usrl locall m% rdomol listsl astronomy-ora.info· 5. Vytvořte potřebné adresy pro konferenci ve virtuální doméně. Přidejte následující položky do mapovacího souboru virtuálních aliasů
vir/ua'-alias:
* a6t ronomy@ora . com l i s t a s t ronomy@ora . com
a s t ronomy-ora@localhost
owne r-ast ronomy@ ora . com
owner-ast ronomy-ora@ l ocalhost
a s t ronomy-reque s t @ ora . com
a s t ronomy-ora- reques t @ localhost
ast ronomy-approva l @ora . com
a s tronomy-ora-approva l @ localhost
6. Obnovte soubor pro mapování virtuálních aliasů: • postmap virtual_alias
7. Poté přidejte adresy do souboru konference I usrl /oca/I m% rdomol listsl astronomy. Nyní by mělo být možné odesílat zprávy na adresu astronom�ora.com pro jejich doručení na všechny adresy ve vašem souboru konference.
KAPITOLA 9
Předávání pošty (Mail Relaying)
Až dosud jsme se zabývali převážně Postf1xem v jeho roli koncového uzlu pro e-mailové zprávy. To znamená, že zprávy, které dorazí do Postf1xu, jsou většinou doručovány do místního systému. Ale Postf1x často slouží jako prostřední uzel na cestě, kterou zpráva putuje do konečného cíle. V této kapitole se podíváme na některé možnosti nastavení Postf1xu jako klienta v komunikaci mezi dvěma MTA.
Záložní MX MX záznamy v DNS znamenají mail exchangers (viz kapitola 6) . Záznamy MX obsahují hostitele a prioritu (nebo preferenci) pro odesílání pošty do domény. Záložní server MX je ten, který přijímá poštu pro konkrétní doménu, ale není preferovaným serverem pro příjem pošty. Pokud preferovaný server není dostupný, přijme záložní server MX poštu a zařadí ji do fronty do doby než bude dostupný některý ze serverů s vyšší preferencí. Obrázek 9-1 ukazuje doručování na záložruno hostitele pokud primární hostitel není dostupný. Záložní server umístí zprávy do fronty, dokud nebude primární server opět dostupný, a bude moci na něj zprávy doručit.
1
� . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .�
Obrázek 9- 1. Doruéování na Zálo:&zího hostitele MX
Pokud je váš systém nastaven v DNS jako záložní hostitel MX nemusíte nastavovat žádný speciální přenos z vašeho systému na primární systém. Postf1x používá záznamy DNS pro zjištění směrování pošty na primárruno hostitele MX Jediné nastavení, které je potřeba v Postf1xu provést, je přidání názvu domény do parametru relaLdorna ins, aby mohl přijímat poštu pro tuto doménu. Když odesílající MTA zjistí, že je primární ,
.
poštovní systém domény nedostupný, pokouší se o doručení na další preferované servery dokud nenajde ten, který poštu převezme. Pokud je váš systém záložním hostitelem MX a cílová doména je uvedena v parametru rela y domains, Postf1X poštu přijme a zařadí ji do fronty. Postf1X periodicky zkoumá frontu a kontroluje, zda je preferovanější systém schopen zprávu přijmout. Jakmile je hostitel MX s vyšší prioritou opět dostupný, může mu Postfix zprávu doručit. _
Postfix se pokouší doručit zprávu ve frontě po dobu danou parametrem maximal_queue_ l i fetime, který určuje, jak dlouho odložená zpráva zůstane ve frontě před jejím vrácením odesílateli. Implicitní hodnotou je pět dní. Pokud poskytujete sekundární poštovní službu pro primární servery, o kterých víte, že budou nedostupné déle než tuto implicitní dobu, můžete hodnotu zvýšit.
Příjemci předávané pošty Je doporučeno, abyste udržovali seznam platných příjemců z domén, pro které po skytujete záložní poštovní služby. Měli byste vyvinout proces pro pravidelné načítání aktualizovaného seznamu uživatelů z vašich primárních poštovních serverů. Pokud váš systém nezná všechny dostupné schránky na primárním poštovním serveru, musí při jmout všechny zprávy. Váš záložní server může zjistit, že zprávu není možno doručit, pouze se pokouší o její doručení na primární server. V tento okamžik váš server musí zprávu vrátit původnímu odesílateli. Jelikož odesílatelé nevyžádané pošty často zasílají zprávy na vykonstruované adresy, pokud nebude váš server znát všechny platné e-mailové adresy na primárním serveru, bude zby tečně přijímat mnoho zpráv, které musí být odmítnuty. Problém s odmítáním je ztížen tím, že odesílatelé nevyžádané pošty falšují adresy odesílatelů pomocí skutečných e-mailových adres nevinných nezúčastněných. Tento nevinný člověk pak dostává všechna oznámení o chybách pro zprávy, které nikdy neodeslal (viz kapitola 1 1) . Parametr relaLrecipi ent_maps udává vyhledávací tabulky, které by měly obsahovat všechny adresy pro domény uvedené v parametru relaLdomains: relay_recipient_maps
=
hash : /etc/po s t f i x / relay_recipients
Soubor rel�_recipients by měl obsahovat položky s adresami příjemců na levé straně. Pravá strana není Postfixem používána, ale musíte zadat hodnotu: # # #
relay_recipients
u s e r l @ example . com
anLvalue
user2@ example . com
an y_va lue
user3@ example . com
any_va lue
Pokud je váš systém ve stejné síti jako primární a uživatelské účty jsou uloženy v nějakém druhu databáze, můžete provádět vyhledávání v reálném čase pomocí MySQL nebo LDAP (viz kapitola 1 5) . Potenciální problém je v tom, ž e jakmile nastavíte relay_recipient_maps, musíte zadat e-mailové adresy pro všechny domény, pro které poskytujete záložní službu. Pokud to
neuděláte. bude Postfix odmítat zprávy, které nebudou uvedeny ve vyhledávací tabul ce. Pokud pro některé domény neznáte platné adresy, můžete zadat pro tuto doménu zástupnou položku: # #
relay_rec ipients
user 1 @ example . com
anLvalue
user2@ example . com
anLva1ue
user3@examp1e . com
anLvalue
@ore i l l ynet . com
anLvalue
Poslední je uvedena zástupná položka, která povoluje doručování zpráv na jakoukoliv adresu v této doméně. Samozřejmě je lepší z výše uvedených důvodů získat seznam platných adres.
Rychlé předávání Sítě, které přijímají poštu pro mnoho sídel, jako napřl.1dad sítě ISP, typicky mají nějaké zákazníky, jejichž systémy nejsou vždy připojené do sítě. Když je síť zákazníka nedostup ná, ISP řadí její zprávy do fronty. Když je síť opět připojena, může zažádat o okamžité doručení veškeré pošty z fronty pomocí přl.'kazu ETRN SMTP: 2 2 0 ma i 1 . ora . com ESMTP Pos t f i x
EHLO mail . example . com 2 5 0 -auge r . seaglas s . com 2 5 0 - P I PELINING 2 5 0 - S I ZE 1 0 2 4 0 0 0 0 2 5 0 -VRFY 2 5 0 -ETRN 2 5 0 - STARTTLS 2 5 0 8 B I TMIME
ETRN example . com 2 5 0 Queu ing started
Pokud je frontě mnoho zpráv a doména je připravena přijmout poštu, bylo by vyhle dávání každého souboru ve frontě časově náročné. Postfix poskytuje funkci s názvem fasl .fiush pro urychlení zpracování pošty pro konkrétní doménu. Rychlé předávání je prováděno démonem flush, který spravuje seznamy zpráv, které jsou zařazeny ve frontě pro konkrétní domény, takže Postfix ví, které zprávy mají být doručeny při obdržení přl.'kazu ETRN. Všechny domény uvedené v rela y domains implicitně smějí službu rychlého předávání používat. Domény můžete zadávat kromě parametru pro předávání také do parametru fast flush domains. Název domény zadejte takto: _
_
_
fast_flush_doma ins
=
$relay_doma i n s , example . com
V tomto případě doména example.com není uvedena v parametru relaLdomains.
Ž e je doména pro rychlé odeslání připravena přijmout zprávy, můžete Postfix upozor nit ručně pomocí příkazu postqueue -s (nebo jeho ekvivalentu, sendmail -qR) s názvem domény: $ postqueue -s example . com
Transportní mapy Postfix může být nastaven tak, aby předával poštu na jakéhokoliv jiného hostitele, bez ohle du na nastavení záznamů DNS MX Tato část kapitoly popisuje obecně parametr t rans port_maps. Další části této kapitoly a jiné kapitoly této knihy uvádí konkrétní nastavení. .
Transportní mapy koncepčně podačují výchozí transportní mapy pro doručování zpráv. Parametr t ransport_maps ukazuje na jednu nebo více transportních vyhledávacích ta bulek. Následující položka nastavuje jako transportní vyhledávací mapu letciposifixl transport: transport_maps
=
hash : /etc/po s t f i x / t ransport
Klíči v transportní vyhledávací tabulce jsou bud' kompletní e-mailové zprávy nebo do mény a subdomény (e-mailové adresy jako klíče pro vyhledávání v transportních mapách vyžadují Postfix 2.0 nebo novější). Když cílová adresa nebo doména odpovídá levé straně klíče, bude hodnota na pravé straně použita pro zjištění metody a cíle doručení. PoKlad 9-1 uvádí některé možné položky transportních map. Pfíklad 9- 1. Položkg transportních map example . com
smtp : [ 1 9 2 . 1 6 8 . 2 3 . 5 6 J : 2 0 0 2 5
orei l l y . com
relay : [ gateway . orei l l y . com]
orei l l ynet . com
smtp
ora . com
ma i l drop
kdent @ora . com
error : no mai l accepted for kdent
Formát hodnot na pravé straně se může lišit v závislosti na druhu transportu, ale obec ně má tvar tra nspor t : nex thop , kde nex thop označuje hostitele a port pro doručování. Všechny možné části hodnoty pravé strany jsou popsány zde: t ransport Odkazuje se na položku v master.if. Pokud přidáváte nový druh transportu, nejprve pro něj vytvořte položku v souboru master.if. host Cílový hostitel pro doručení zpráv. Hostitel je použit pouze u transportů inet, jako například SMTP a LMTP. Postfix pracuje s názvem hostitele jako s jakoukoliv jinou cílovou doménou. Provádí vyhledávání MX pro zjištění toho, kam mají být zprávy doručeny. Pokud záznamy MX neexistují, bude Postfix doručovat na adresu IP uve denou v záznamu A. Pokud víte, že by měl Postfix doručovat přímo na adresu IP uvedenou v záznamu A daného hostitele, můžete nechat Postfix přeskočit kontrolu záznamů MX uzavřením názvu do hranatých závorek. Pokud používáte adresu IP, jsou hranaté závorky povinné.
port Cílový port pro doručování zpráv. Port je použit pouze při transportech inet, jako například SMTP a LMTP. Port může být zadán pomocí skutečného čísla nebo jeho symbolického názvu ze souboru letci services. Každá ze vzorových položek v příkladu 9-1 používá na pravé straně jiný formát, který je vysvětlen níže:
examp/e.com smtp:[192. 168.23.56}:20025 Všechny zprávy určené pro examp/e.com jsou předávány pomocí transportu smtp na hostitele s adresou IP 1 92.1 68.23.56. Zprávy jsou doručovány přes port 20025 namísto výchozího portu SMTP 25. Všimněte si, že je adresa IP v hranatých závor kách, jak je vyžadováno pro adresy IP.
orei/fy. com relt!J:[gatewt!J. orei/fy. com} Všechny zprávy určené pro orei/fy.com jsou předávány prostřednictvím transportu relay na hostitele gatewt!J.oreilfy.com. Jelikož není zadán žádný port, Postfix používá implicitní port 25. Název hostitele je v hranatých závorkách, aby Postfix nehledal záznamy MX Místo toho vyhledá záznam A a bude doručovat na IP adresu, na níž bude přeložen název hostitele. .
Transport relay byl zaveden v Postfixu verze 2 pro nápravu potenciálního úzkého místa při plánování fronty. Příchozí zprávy předávané do interních systémů byste měli směrovat přes transport rel ay, aby nekonkurovaly zprávám určeným pro mnoho jiných systémů v internetu.
orei/fynet.com smtp Všechny zprávy určené pro doménu orei/fynet.com jsou předávány prostřednictvím transportu smtp. Jelikož další uzel i port nej sou uvedeny, Postfix použije výchozí port 25 a zjistí další uzel z cílové adresy. Nejčastěji je další uzel určen provedením vyhledávání v DNS, které určí hostitele MX pro doménu. Tento příklad je tak trochu vymyšlený, protože jednoduché uvedení orei/fynet.com s relay hos ts v tomto případě dosáhne téhož. _
ora.com mai/drop Všechny zprávy určené pro ora.com jsou doručeny službě maildrop. mai ldrop musí být položkou v master.if. Jelikož doručování probíhá skrze rouru a ne socket inet, nezadává se žádný název hostitele a port.
[email protected] error:no mail accepted.for kdent Speciální transport error způsobuje, že budou všechny zprávy odmítnuty. Za dvoj tečku zadejte text, která má být předáván, pokud je zpráva odmítnuta. Transportní mapy mohou být použity také pro speciální zacházení s určitými zprávami v místním systému. (Kapitola 1 4 popisuje ftltry obsahu, které jsou dobrým příkladem nastavení speciálních místních transportů) . Jiným místním využitím transportních map je dočasné odložení všech zpráv domény. Následující část uvádí jako příklad jednoduchého použití transportních map postup pro odložení všech zpráv d.omény.
Odložení doručování pošty Za určitých okolností budete chtít, aby Postfix odložil doručení zpráv dokud nedostane explicitní př1'kaz pro jejich doručení. Odložené zprávy jsou doručeny po spuštění pří kazu postq�eue -f doma i n nebo když Postfix obdrží př1'kaz ETRN SMTP pro rychlé
doručení. Běžnou situací pro odložení zpráv je případ, kdy ISP přijme poštu pro síť zákazru'ka, která není vždy připojena. ISP musí zařadit zprávy do fronty dokud nebude síť připo jena a bude je moci přijmout. Podobně by měli uživatelé v síti zákazru'ka odesílat zprávy skrze místní gateway, která je zařadí do fronty dokud je nebude moci doručit. Tato část ukazuje nastavení pro obě situace.
Odložení předání pošty Tento postup nastavuje nový transport s názvem "ondemand" a nastavuje transportní mapu pro odložení všech zpráv pro doménu example.com: 1 . Vytvořte v souboru master.cf nový transport s názvem ondemand. Kromě názvu by měl být identický s vaším transportem smtp: ondemand
unix
-
smtp
n
2. Řekněte Postfixu, že by mělo být doručování všech zpráv prostřednictvím no vého transportu odloženo automaticky. Zadejte do parametru defer transports v souboru main.cf váš transport ondemand: _
de fer_t ransports
=
ondemand
3. Ujistěte se, že parametr transporcmaps ukazuje na vaši transportní vyhledávací tabulku: transport_maps
=
hash : /etc/po s t f i x / t ransport
4. Přidejte do souboru transport položku pro exampk.com, která bude ukazovat na transport ondemand: example . com
ondemand
5. Spusťte pro tento soubor postmap.
I postmap /etc/postfiz/transport
6. Restartujte Postfix, aby zaregistroval změny v konfiguračních souborech: • postfiz reload
Nyní j sou zprávy určené pro
exampk.com
odloženy dokud nebude explicitně spuštěn
př1'kaz pro jejich doručení. Až budete připraveni uvolnit odložené zprávy, spusťte př1'kaz postqueue -f: $ postqueue -f eumple . cOlll
Odložení odeslání Domácí síť nebo malá firemní síť, která chce zapínat odesílání ručně, by měla odlo žit veškeré doručování přes SMTP, aby pokus o odeslání nastával pouze po připojení k internetu:
1 . V souboru main.if přiřaďte transport smtp do parametru de fer_transports: de fer_t ransports
=
smtp
2. Restartujte Postfix, aby zaregistroval změny v konfiguračním souboru: t postfiz reload
Po připojení mohou být všechny zprávy doručeny pomocí příkazu postqueue
f.
Zbytek této kapitoly popisuje různé situace, kdy musí Postfix předávat poštu na jiné systémy. V mnoha případech jsou pro nastavení podrobností o doručování na další uzly nezbytné transportní mapy.
Brána pro příchozí poštu Poštovní brána je poštovní systém, který přijímá zprávy a předává je do jiného systému. Brá ny mohou poskytovat cestu z jedné sítě do druhé nebo z jednoho protokolu na jiný. Běžně se poštovní brány používají na serveru, který přijímá veškerou poštu pro síť z internetu a předává ji do interních poštovních systémů. Poštovní brány jsou obvykle nastavovány na firewallu pro omezení počtu serverů, které potřebují přímý přístup do internetu. Představte si firemní síť jako je ta, která je znázorněna na obrázku 9-2. J sou zde tři sub domény pro různé pracovní skupiny ve společnosti a každá pracovní skupina má svůj
Brána /!}lJ.exampk.com přijímá veškerou poštu pro síť. Oddělení lidských zdrojů dostává poštu adresovanou jako [email protected], a jejich pošta by měla jít na server mail1.exampk.com. Obchodní oddělení používá [email protected] a jejich pošta by měla jít na server mai/2.exampk.com. Klienti v každé podsíti přijímají poštu z odpovídajícího poštovního serveru. Aby brána /!}lJ.examp/e.com předávala zprávy vlastní poštovní server.
na správné poštovní servery, potřebuje transportní mapy. Následující postup ukazuje jak nastavit gw.example.com pro předávání zpráv na správné interní systémy:
1 . Ujistěte se, že byly správně nastaveny záznamy MX systému DNS pro hr.examp k.com a sa/es.examp/e.com ukazující na bránu /!}lJ.examp/e.com. 2. Ve vašem souboru main.cfnastavte parametr relay_domains tak, aby obsahoval obě interní domény: relay_doma ins 3.
hr . example . com, sales . example . com
=
Ujistěte se, že parametr t ransport _maps ukazuje na vaši transportní vyhledávací tabulku: transpor t_maps
=
hash : / etc/pos t f i x / transport
Internl aK
...-----, · ra L·a Obrázek 9-2. Poftovní bránapro interní systémy
4. Přidejte do souboru transport položky pro každou doménu ukazující na správné interní poštovní systémy: •
# t
transport maps
hr . example . com
relay : [mail l . example . com]
sales . example . com
re l ay : [ mai 1 2 . example . com]
Názvy hostitelů poštovních systémů j sou uzavřeny do hranatých závorek, aby bylo pro tyto systémy vypnuto vyhledávání MX. 5.
Restartujte Postfix, aby zaregistroval změny v konfiguračních souborech:
# postfix reload Je důrazně doporučeno, abyste udržovali seznam platných příjemců pro všechny vaše interní uživatele s použitím parametru relaYJecipient_maps .
Předávání odeslané pošty Pokud poštovní systém nemá adekvátní připojení nebo všechny informace, které po třebuje pro předávání zpráv, může je předat na jiný systém, který je v lepší pozici pro předávání. Podívejte se znovu na síť na obrázku 9-2. Pokud interní poštovní systémy nemají přímý přístup do internetu, nemohou doručovat zprávy odeslané uživateli v je jich podsítích. Mohou samozřejmě předávat všechny zprávy na poštovní systém brány, který může provést doručení za ně. Následující postup demonstruje nastavení Postfixu na
mail1. example. com pro předávání všech přijatých zpráv na systém gw. example. com, který
pak může provést jejich doručení. Před nastavováním interních poštovních systémů se ujistěte, že je poštovní brána nastavena tak, aby umožňovala předávání od interních poštovních systémů. Parametr
mynetworks (viz kapitola 4) by měl obsahovat adresy IP interních poštovních systémů a pokud používáte omezení SMTP UBE (viz kapitola 1 1) , ujistěte se, že jste zadali pe rmi t_mynetworks mezi pravidla pro povolení předávání: 1.
Zkontrolujte, zda parametr mynmmrks (nebo mynetworks_ style) obsahuje klientské systémy.
2.
Nastavte u poštovních klientů v pracovní skupině jako server SMTP maill.exam pIe. com.
3. V souboru main.if nastavte parametr rel ayho s t tak, aby ukazoval na systém brány: relayhost
=
[ gw . example . com]
4. Restartujte PostflX, aby zaregistroval změny v konfiguračním souboru: * postfix reload
Nyní jsou všechny zprávy doručované na maill .example.com předávány prostřednictvím !JP. example. com.
UUCP, fax a další doručování Dokumentace PostflXu popisuje nastavování Postfixu pro doručování na faxové systémy a nastavování brány pro UUCP. Jsou dobrým příkladem nastavování Postfixu pro práci se všemi druhy speciálních zařízení. Pokud potřebujete vytvořit bránu mezi různými druhy systémů nebo různými sítěmi, můžete použít transportní mapy, které umožňují směrování pošty na jiné systémy nebo zařízení.
KAPITOLA 1 0
E-mailové konference
POif1ámka překladatele: V originálu se jedná o termín mailing list, který je ale podle kontextu přeložitelný více způsoby. Záleží na účelu použití. Tento termín by bylo vhodnější přeložit jako seznam pro zasílání pošty. Tento termín se ale příliš nevžil a mnohem častěji je používán termín e-mailová konference, i když nevystihuje všechny možné způsoby použití tohoto seznamu. V závislosti na nastavení se totiž nemusí jednat o konferenci jako takovou, ale jen o seznam pro odesílání informací vlastníkem seznamu všem účastníkům, kteří ale nemají právo přispívat. Toto nastavení se používá typicky pro rozesílání ceníků nebo novinek.
E-mailové konference jsou konvenčním způsobem zasílání jedné e-mailové zprávy více příjemcům. Umožňují konverzaci prostřednictvím e-mailu téměř neomezenému počtu adresátů. E-mailová konference, založená na serveru a spravovaná centrálně, má mnoho výhod oproti jiným mechanismům pro zasílání zpráv více příjemcům. Pokud běžným způsobem odesíláte e-mail stejné skupině lidí, je zadávání seznamu příjemců příliš zdlou havé a náchylné k chybám. MUA obvykle mají nástroj, který umožňuje vytvářet osobní aliasy, které asociují snadno zapamatovatelný název se seznamem e-mailových adres. Osobní aliasy jsou dobré pro jednotlivce, ale když začne být seznam sdílený s ostatními, už to není tak praktické řešení. Největší výhodou centrálně spravovaných e-mailových konferencí je to, že změny jsou prováděny na jednom místě a nové informace jsou oka mžitě dostupné komukoliv, kdo odesílá zprávy do konference. Další výhody se stanou zřejmými pokud použijete správce konference (l\1ailing list Managers; MLM) pro správu seznamu, díky nimž nemusí správci serveru aktualizovat adresy ručně. V této kapitole se podíváme na vytváření jednoduchých konferencí v PostHxu jako ta
kovém a pak na nastavení PostHxu pro doručování zpráv do MLM pro soHstikovanější správu seznamu. Při rozhodování zda chcete vytvořit konferenci v PostHxu nebo použít MLM zvažte, jak často se bude seznam měnit, kdo bude provádět změny a zda potřebujete některé další funkce MLM jako například moderované konference a souhrnné odesílání (digest) . MLM umožňují uživatelům se přihlašovat a odhlašovat a v případě potřeby pro vádět změny v jejich adresách. Pokud máte relativně statické seznamy nebo se uživatelé ,
přihlašují a odhlašují zřídka, pravděpodobně nepotřebujete zátěž spojenou s MLM. Pokud to vyhovuje vašemu prostředí, můžete vždy spouštět obě verze seznamu. Správa konferencí má mnoho aspektů a nuancí. Pokud tuto úlohu vezmete, měli byste se podívat do textu, který se zabývá konkrétně správou elektronických konferencí, například do knihy Managing Mailing Lists, kterou napsal Alan Schwartz (O'Reilly).
Jednoduché elektronické konference Postfix poskytuje prostředky pro vytváření jednoduchých konferencí prostřednictvím normálního aliasu (více informací najdete v kapitole 4) . Protože mohou aliasy ukazovat na seznamy adres nebo soubory, které obsahují seznamy adres, je jednoduché vytvořit alias, který bude ukazovat na více jmen. Můžete vytvořit seznam aliasů v systémovém souboru aliases nebo v nějakém jiném souboru, který zadáte v parametru alias_maps. Více informací o parametru alias_maps najdete dále v této kapitole. Výchozím souborem aliasů po instalaci Postfixu je / etc/ aliase!. Předpokládejme, že spravujete poštu pro doménu example.com a chcete vytvořit novou konferenci. Rozhodnete se vytvořit pro konferenci alias [email protected], který bude používán pro online diskuse. Upravte soubor aliasu a přidejte následující řádek s e-mailovými adresami lidí, kteří chtějí být členy konference: needlepo int :
rgrier@ore i l l y . com, grnhoppe r@onlarnp . com,
grayburn@ore i l l y . com
Po provedení změn v souboru znovu vytvořte vyhledávací tabulku aliasu provedením: 4 postllias letclaliases
Nyní budou všechny zprávy zaslané na adresu [email protected] předávány na všechny e-mailové adresy uvedené v příkladu.
Vlastníci konference Pokud nějaké zprávy nemohou být doručeny na některou z uvedených adres, obdrží odesílatel chybovou zprávu informující o problémech s doručováním. U malých nebo interních konferencí to může naprosto stačit. Pokud ale vytváříte velkou konferenci nebo o sobě jednotliví členové nemusí vědět, pak je samozřejmě vhodnější, aby byly chybové zprávy zasílány správci konference. Běžně se pro konferenci vytváří další alias ve formátu owner-@example.com, kde owner- je uvedeno před názvem aliasu konference. Pro předchozí příklad bychom vytvořili alias owner-needl epoi n t . * Tento alias owner- by měl směřovat na správce, který je obecně lepší osobou pro zasílání odmítnutých zpráv než původní odesílatel: owner-needlepoint : kdent@ exarnple . com
. Některé systémy MLM přijaly konvenci umisťování -owner za alias namísto před něj.
Odesílání chybových zpráv na alias o wner- je dosaženo nastavením odesílatele obálky na alias
[email protected]
namísto e-mailové adresy původrubo odesílatele.
Příklad 1 0- 1 ukazuje typické záhlaví zprávy z konference. PfíkW 10- 1. Vzorové Záhlaví !(/>ráty Z konference
Return-Path : De l i vered-To :' rgrier@ore i l l y . com Received : from cowrie . example . com ( cowrie . example . com [ 1 92 . 1 6 8 . 1 0 0 . 7 ] ) by mai l . ore i l l y . com ( Po s t f i x ) with ESMTP id B 7 1 2 1 2 0 DD5B for Mon , 13 May 2 0 0 2 1 1 : 5 5 : 4 0 - 0 4 0 0 (EDT) Date : Mon , 1 3 May 2002 1 2 : 0 0 : 4 3 - 0 4 0 0 (EDT) From : G . M . Hoppe r X-Sender : gmhoppe r@ cowrie To : needlepoint@ example . com Subj ect : Jus t finished 1atest proj ect Mes sage - I D :
Pokud alias o wn e r - existuje, Postfix jej automaticky použije jako adresu odesílatele obálky při odesílání zpráv členům konference. Pokud z nějakého důvodu nechcete, aby Postfix používal místo aliasu o wner- adresu odesílatele, můžete nastavit parametr
owner reques t special na no: _
_
Také můžete nastavit, aby Postfix používal skutečnou e-mailovou adresu správce namísto aliasu owner- a to nastavením expand_ owner_al ias na yes: expand_owner_al i a s
=
yes
Pokud je tento parametr nastaven, je namísto adresy adresa
[email protected] použita
[email protected].
Ačkoliv uživatelé obecně nepotřebují odesílat zprávy přímo vlastru'kovi konference, měli byste vytvářet aliasy vlastru'ků i pro jednoduché konference, aby mohli ostatní správci pošty v případě problémů s vaší konferencí kontaktovat správnou osobu.
request pro konferenci. Aliasy request [email protected]. Alias request pro alias needlepoint by vypadal takto: [email protected]. Aliasy request se používají pro požadavky na
Jinou konvencí konferencí je vytváření aliasu používají formát
přihlášení a odhlášení z konference nebo pro získání jiných než technických informací o konferenci.
Oddělené soubory konference Pokud máte na seznamu víc než jen několik jmen, je lepší vytvořit textový soubor ob sahující všechny e-mailové adresy konference. Položka aliasu, která ukazuje na soubor, vypadá takto: ema i l alias:
:
inc lude : /pa th/to/fi l e .
Vezměme alias needlepo int z předchozí části kapitoly a přesuňme adresy konference do samostatného souboru. Položka aliasu by byla upravena tak, aby se odkazovala na textový soubor obsahující seznam adres: needlepoint :
Soubor
: include : /etc /pos tfix/needlepo int
/ etc/postjix/ needlepoint obsahuje
e-mailové adresy všech členů skupiny. Zadejte
adresy na samostatné řádky. Když budete potřebovat provést změny v seznamu, jedno duše tento soubor upravte: rgrier@ore i l l y . com gmhoppe r@onlamp . com graybu rn@ore i l l y . com bogus @ example . com
Přidávám neplatnou adresu
[email protected]
pro pozdější testování v další části této
kapitoly.
Další soubory aliasu Vzpomeňte si na kapitolu
4 a to, že parametr alias maps umožňuje zadat to libovolný _
počet souborů aliasu. Mohli byste například chtít používat samostatný soubor aliasu pro uložení vašich konferencí. jednoduše použijte název souboru samostatného aliasu společně se systémovým aliasem pro nastavení parametru alias maps. Také byste měli _
nastavit parametr alias database, abyste mohli spouštět příkaz _
newaliases pro aktualizaci
všech vašich souborů s mapováním aliasů: a l i a s_maps
=
hash : /etc /pos t f i x / a l i a s e s , hash : /etc/postf ix/mai l_l i s t s
a l i a s_database
=
hash : /etc /pos t f i x / a l i a s e s , hash : /etc/postfix /mai l_l i s t s
Může být vhodnější přiřadit všechny vaše soubory aliasů do alias database a pak přiřadit _
alias database do alias maps . Pokud používáte pro aliasy jiné druhy map, jednoduše je také přiřaďte do alias maps : _
_
_
a l i a s_database a l i a s_maps
=
=
ha sh : /etc/po s t f i x / a l i a s e s , hash : /etc/postfix/mai l_l i s t s
$ a l i as_database, n i s : ma i l . a l iases
Po provedení změn v souboru
main.ifnezapomeňte restartovat Postfix.
Vytvoření jednoduché konference Zopakujme si všechno, co jsme dosud probírali a podívejme se na položky konference
needlepoint. Soubor aliasu obsahuje následující řádky: needlepoint :
: inc lude : /etc/postfix /needlepoint
owne r-needlepo int :
kdent@exampl e . com
needlepoint- reques t :
kdent @ example . com
[email protected] /etc/postjix/ needlepoint. Tento
První řádek v příkladu způsobuje to, že zprávy odeslané na adresu budou doručeny na všechny adresy uvedené v souboru
soubor by měl obsahovat seznam e-mailových adres všech členů seznamu. Odmítnuté zprávy a požadavky jsou předávány na skutečnou adresu
[email protected].
Pokud je
to nutné, mohou uživatelé nebo jiní správci pošty posílat zprávy vlastníkovi konference a uživatelé mohou odesílat zprávy na alias request pro přihlášení nebo jiné informace. Když je zpráva odeslána do seznamu, obsahuje záhlaví To : adresu aliasu konference a ne všechny adresy ze seznamu (mohlo by se jednat o stovky nebo dokonce tisíce adres). Každý člen konference obdrží kopii zprávy se záhlavím podobným tomu z příkladu 1 0- 1 . V tomto příkladu gmhtPPe1@on�. com poslal zprávu do konference. Pamatujte si, že Return-Path : obsahuje alias vlastru'ka namísto skutečného autora zprávy ([email protected]).
Testování konference Konferenci můžete otestovat odesláním zprávy na alias, který j ste pro ni vytvořili. V tomto příkladu budeme používat jako alias konference [email protected]. Příldad 1 0-2 ukazuje
položky protokolu pro vzorovou testovací zprávu. Představte si, že adresa boguS@exam pie. comje neplatná. Pfíklad 10-2. PoIoZk;y protokolupro tPrávu do konference pos t f i x / local [ 7 4 l 1 ] : 6C2CE 2 0 DD5B : to= , relay=loca l , delay= l , status=sent ( forwarded as ACDC 1 2 0 DD7 0 ) postfix/qmgr [ 8 l 6 3 ] : ACDC 1 2 0DD7 0 : from= , s i ze=1 1 2 1 , nrcpt=8 ( queue act ive ) pos t f i x / local [ 0 8 3 5 ] : ACDC 1 2 0DD7 0 : to= relay= l oca l , de lay= l , status=bounced (unknown user : "bogus " ) postfix/smtp [ 65 5 6 ] : ACDC 1 2 0DD7 0 : to= relay=mai l . ore i l l y . com [ 1 0 . 8 2 . 6 . 1 1 ] , de lay= l , status=sent ( 2 5 0 Ma i l accepted) postfix/ smtp [ 6 5 5 6 ] : ACDC 1 2 0DD7 0 : to= relay=mai l . orei l l y . com [ 1 0 . 8 2 . 6 . 1 1 ] , de lay= l , s tatus=sent ( 2 5 0 Mai l accepted) pos t f i x / smtp [ 5 9 5 4 ] : ACDC 1 2 0DD7 0 : to= relay=ma i l . on l amp . com [ 1 0 . 1 7 1 . 8 . 1 1 1 ] , de lay= l , status=sent ( 2 5 0 Me s s age received : GZCLUCO O . E 8 F )
Některé informace, jako napřHdad časové razítko nebo název hostitele, byly pro zjednodu šení vypuštěny. Všimněte si, že na konci prvrubo řádku je komentář oznamující (forwarded as ACDCl20DD7O) a zbylé položky protokolu používají nový identifikátor fronty. Také si všimněte v prvním řádku příkladu, že zpráva vstupuje do systému adresovaná na needie [email protected]. Druhý řádek ukazuje, že Postf1X používá při doručování zprávy všem členům konference alias vlastru'ka jako adresu odesílatele obálky (from=
Pfíklad 10-3. OiJ1ámení o odmítnutípro neplatnou adresu From MAI LER- DAEMON@ma i l . example . com Tue Jul 1 6 1 2 : 0 3 : 4 9 2 0 0 2 Date : Tue , 1 6 Ju l 2 0 0 2 1 1 : 2 5 : 2 7 - 0 4 0 0 (EDT) From : Ma i l De l ivery Sys tem <MAI LER-DAEMON@ma i l . example . com> To : owner-needlepo int@ example . com
Subj ect : Unde l ivered Ma i l Returned to Sender
: un known user : "bogu s "
Správci konferencí (MLM - Mailing-List Managers) Provozování konferencí v Postfixu je dobré pro statické seznamy. Ale konference, které se často mění, je lepší spravovat pomocí správce konference. Při použití MLM správce konference nemusí ručně upravovat soubory konference pro přidávání, odstraňování nebo změny adres, protože se členové konference mohou přihlašovat a odhlašovat sami. MLM také podporují další funkce jako například archivování zpráv, souhrnné zprávy a možnost moderování konference kontrolou zpráv správcem před jejich odesláním všem členům. MLM fungují tak, že j sou normální aliasy Postfixu nasměrovány do příkazů, které se starají o distribuci zpráv a správu konferencí. MLM používají aliasy pro správu, které ukazují na programy, které provádí funkce konferencí, jako například přihlašování a odhlašování členů, zpracovávají odmítnuté zprávy a třeba filtrují zprávy zasílané do konference. Sa motné konference ve skutečnosti fungují stejně jako jednoduché aliasy z poslední části této kapitoly. Každá konference má svůj vlastní soubor pro ukládání členů konference, ale místo abyste museli soubor upravovat sami, může za vás MLM automaticky přidávat a odstraňovat adresy. Další dvě části se zabývají dvěma populárními MLM: Majordomo a Mailman.
Majordomo Majordomo je jedním z nejpopulárnějších MLM a je k dispozici již od začátku 90. let. Nabízí kompletní sadu funkcí MLM a téměř všechny úkony pro správu se provádí zasí láním e-mailů. Jakmile je konference vytvořena, je potřeba jen velmi málo zásahů správce pošty nebo žádné. Také existují balíčky nástrojů pro správu Majordomo prostřednictvím webu, které umožňují provádět většinu správy konferencí prostřednictvím webu. Majordomo je k dispozici na jeho domovské stránce na adrese http://www.greatcircle.com/ mcgordomo/. Vyžaduje Perl a funguje s balíčky Perl4 verze 4.036 nebo Perl5 verze 5.002 nebo novějšími. Budoucí verze budou pravděpodobně vyžadovat Perl5. Majordomo také používá malý program wrapper napsaný v C. Pokud plánujete sestavovat tento balíček ze zdrojového kódu, musíte mít kompilátor ANSI C. Pokud nastavujete Majordomo pro moderované konference, kde správce konference schvaluje příspěvky pomocí nástroje approve, musíte provést úpravu, aby Postfix a Major domo spolupracovali správně. Postfix přidává na začátek zpráv, které zpracovává, záhlaví De l i vered-To : . Pak toto záhlaví používá pro zjišťování poštovních smyček. Když je zpráva Majordomo pro ověření doručena moderátorovi, který pak předává zprávu pomocí příkazu approve, je odeslána zpět do konference se všemi původními záhlavími
nedotčenými. Když Postfix přijme zprávu znovu, zjistí, že ji již zpracovával a nahlásí smyčku v doručování pošty. Nejjednodušším způsobem pro ošetření tohoto problému je provedení malé změny ve skriptu approtJe (který je vytvořen v jazyce Perl) . Budete muset upravit soubor, který je obvykle umístěn v podadresáři 1 bin v hlavním adresáři instalace Majordomo. Po kud provede;e kroky v níže uvedeném postupu, bude váš soubor umístěn v adresáři 1 Nsrl loeall mtflordomol binl approtJe. Upravte tento soubor. Najděte podprogram s názvem processJX)unce. V tomto podprogramu je cyklus while, který je znázorněn níže. Vložte zvýrazněný řádek, uložte soubor a to je vše: whi l e « $ F I LE»
{
i f ( / A > ? From / && ! de fined ( $ from_skipped ) )
• S kip any initial " From " or " > From " line
$ from_s kipped
=
1;
nex t ;
next if ( /Adelivered-to : /i ) ;
' Added for Postfix
s/'-/--/ ; print MAIL $_;
Vytváření konference s využitím Majordomo Následující kroky vás provedou nastavením aliasu konference astronomy s použitím programu Majordomo a Postfixu. Tyto instrukce předpokládají, že vytváříte uživatele se jménem majordom a instalujete balíček do 1 Nsrl loea/I mtflordomo. Pokud použijete jiné uživatelské jméno nebo budete instalovat do jiného adresáře, mějte to na paměti, až budete číst tento příklad.
1 . Ujistěte se, že máte ve vašem systému nainstalovaný Perl a že je to alespoň verze 5.002 nebo lepší. Verzi instalace Perlu můžete zjistit provedením příkazu per/ -/) na př1'kazovém řádku. To zobrazí licenci a další informace o vaší instalaci Perlu, včetně čísla verze: $ perl
-v
This is perl , ve rsion 5 . 0 0 5_0 3 bui l t for i 3 8 6 - freebsd Copyright 1 9 8 7 - 1 9 9 9 , Larry Wa l l
2 . Získejte kopii programu Majordomo - buď zdrojové soubory z domovské stránky Majordomo nebo nainstalujte již připravený balíček z vašeho obvyklého zdroje. Řiďte se instrukcemi, které jsou obsaženy ve vašem balíčku pro instalaci Majordomo do vašeho systému. Pokud instalujete ze zdrojových souborů, budete potřebovat pro sestavení kompilátor ANSI C. Pokud sestavíte program Majordomo sami, upravíte soubory Makefile a mqjordomo.if, měli byste být schopni postupovat podle instrukcí jako kdybyste instalovali Majordo mo pro práci se serverem Sendmail jako MTA. Pokud je umístění $sendmai l_command
souboru mtflordomo.ifsprávné, bude zbytek proměnných ve výchozích hodnotách správný.
3. Vytvořte a upravte soubor s názvem IlIsrl loeall majordomol aliase! pro uložení aliasů pro Majordomo. Přidejte aliasy pro příkazy Majordomo podle instrukcí uvedených u programu Majordomo. Pak přidejte aliasy pro vaši konferenci. Tento soubor by měl vypadat takto: ma j ordomo :
" I /usr/ local/ma j o rdomo/wrappe r maj ordomo "
owner-ma j o rdomo :
kdent@ example . com
maj ordomo-owner :
kdent@ example . com
#
ast ronomy l i s t
ast ronomy :
: include : /usr/ local/ma j o rdomo / l i s t s / a s t ronomy
owner-ast ronomy :
csagan@ example . com
ast ronomy-reque s t :
" I /usr/ local /ma j ordomo /wrappe r reques t -answer a s tronomy"
ast ronomy-approval :
csagan@example . com
4. Přidejte soubor aliasu pro Majordomo do parametru alias maps v souboru letci postftxl main.cf. _
a l i a s_maps
=
hash : /etc/al iases , hash : /u s r / l ocal /maj ordomo / a l iases
5. Také můžete přidat nový soubor aliasu do parametru alias da tabase pro automa tické opětovné sestavení datového souboru při spuštění příkazu newaliases: _
a l i as_database
=
hash : /etc/al iases , hash : /u s r / l ocal/ma j o rdomo / a l iases
6. Restartujte Postfix, aby zaregistroval změny v konfiguračním souboru main.cf. # postfiz reload 7. Vytvořte soubor pro ukládání e-mailových adres konference astronomy. Jako jeho vlastníka nastavte účet majoniom: # touch /usr/local/majordomo/lists/astronomy
• chown majordom /usr/local/majordomo/lists/astronomy
8. Vytvořte soubor info, který bude obsahovat zprávu odesílanou novým členům konference a komukoliv dalšímu, kdo odešle příkaz i1!fo. Vytvořte soubor jako I IIsrl loeall majordomol listsl astronomy.info a zadejte odpovídající text pro vaši kon ferenci: Wel come to the a s tronomy discussion l i s t at example . com . The pu rpose of this l i s t is to discuss new ast ronomi cal phenomena . To send a me ssage to a l l the members of the l i s t , address your ema i l to . The basic rules and e t iquette for the l i s t are as follows : 1. . . .
9. Ujistěte se, že je soubor s informacemi přístupný pro účet majordom: # chown majordom /usr/local/majordomo/lists/astronomy . info 1 0. Vytvořte databázi aliasu: # postalias /usr/local/majordomo/aliases nebo pokud j ste přidali soubor aliasu Majordomo do alias database, jednoduše _
zadejte newaliases.
Instalaci Majordomo můžete otestovat spuštěním následujícího přikazu: $ echo
' lista ' I uil majordaDo
Tento pOkaz odešle e-mailovou zprávu do Majordomo obsahujíci phltaz "lists", který hltá Majordomo, aby poslal informace o všech konferencich, které spravuje. V našem phKladu VYPlldá odpověď od Majordomo takto: Date : Tue ,
16
Jul
2002 1 8 : 1 4 : 5 9 -0400
(EDT)
From : Ma j ordomo@ example . com To : kdent@ example . com Subj ect : Ma j ordomo resu l t s
»» l i s t s Ma j o rdomo @ example . com serves t h e fol lowing l i s t s : a s t ronomy Use the ' in f o < l i s t> ' command to get mo re in formation about a spec ific l i s t . »» »»
Vy nebo vaši uživatelé nyní můžete pro získávání nápovědy a přidávání do konferencí odesílat phltazy Majordomo na adresu majordomo @example.com. Pokud se chcete přihlásit do nové konference, pošlete zprávu do ma j ordomo s ph'kazem subscribe v těle zprávy: To : maj ordomo@ example . com From : tbrahe@porcupine . org Subj ect : subscribe ast ronomy
Pokud odešlete požadavek na přihlášení, měli byste obdržet potvrzující zprávu od Ma jordomo. Pro dokončení přihlášení do konference musíte poslat odpověď na tuto zprávu obsahující ověřovací kód (více informaci najdete v dokumentaci k Majordomo).
Potenciální problémy Pokud j ste neměli při instalaci Majordomo žádné problémy, mělo by vše fungovat podle očekávání. Hlavní problém, se kterým se můžete setkat, má co do činění s právy k sou borům. Pokud odešlete zprávu do konference a obdržíte oznámení o odmítnutí zprávy jako je uvedeno níže, pak vězte, že máte problém s právy: The Pos tfix program : cannot open include f i l e /usr/ local /ma j ordomo / l i s t s /ast ronomy : Perrni s s ion denied
Když jej Postfix spouští pro doručování do konference, potřebuje Majordomo přístup pro
(/ usrl Ioea/I majordomol astron01l!J) a ze souboru s konfigurací (I usrl Ioea/I majordomol astron01l!J.cotifig) . Postfix doručuje zprávu do Majordomo běžícího s právy uživatele, který vlastní soubor map aliasu I usrl Ioea/I majordomol aliases.db čtení ze souboru konference konference
obsahující alias majordomo. Obvyklým mechanismem pro zajištění přístupu Majordomo k nezbytným souborům je nastavení programu wrapper na SUID (set user ID) s uživate lem
rool jako
vlastníkem. To znamená, že bez ohledu na to, který uživatel příkaz spouští,
tento proces poběží s právy uživatele root. Instalace Majordomo se stará o správné na stavení práv, ale pokud z nějakého důvodu nejsou správná, obdržíte chybovou zprávu jako je uvedena výše. Pro vyřešení problému můžete nastavit práva sami: t chIIIod 4755 /usr/local/.. jordcao/wrapper
Lepším řešením, než nastavením SUID, je nastavení vlastníka souboru aliasu a všech souborů konference na uživatele majordomo
Mailman Mailman je dalším plnohodnotným MLM. Je k dispozici n a jeho domovské stránce na adrese
http://www.gnu.org/software/ mailmanl.
Obsahuje nástroje pro správu přes web
a vytváří domovskou stránku pro každou konferenci, kde mohou správci a členové spouštět funkce pro správu. Také přijímá příkazy pro správu e-mailem podobně jako Majordomo. Mailman vyžaduje Python alespoň ve verzi 1 .5.2. Obsahuje některé bezpečnostní pro
C, takže pokud plánujete sestavení ze zdrojových kódů, musíte C.
gramy napsané v jazyce mít kompilátor ANSI
V nastavování spolupráce Postfixu a Mailmanu je jeden mírně záludný aspekt. Mailman očekává, že bude spuštěn procesem běžícím s konkrétním identifikátorem skupiny (GID). GID, který očekává, je zadán v době sestavení balíčku Mailman. Pokud sestavuje te balíček sami, ujistěte se, že jste nejprve vytvořili účet a skupinu mailman. Pro vytvoření účtu a skupiny byste měli použít běžné nástroje pro správu systému. Až skončíte, měli byste mít položku v souboru
lelcipasswd vypadající podobně
jako:
mai lman : * : 2 6 4 1 3 : 6 0 0 0 3 : Ma i lman List Manager : / home /mai lman : /bin/sh
a položku v souboru
lelcigroup podobnou této:
mai lman : * : 6 0 0 0 3 :
Ujistěte se, že má účet ma ilman nastavenu primární skupinu mai lman. Ve výše uvedených příkladech
60003
udává skupinu mai lman, kterou má účet mai lman nastavenu jako svou
primární skupinu. Když spouštíte
eotifigure pro Mailman, ujistěte
se jste zadali volbu --wi th-ma i l-gid=xxx,
kde xxx je skutečný identifikátor GID skupiny mai lman, kterou jste vytvořili. Podle výše uvedených příkladů byste měli spustit $ . /configure --with-mlil-qid=60003
eonjigure s
hodnotou 60003 pro volbu GID:
V závislosti na vašem prostředí možná budete potřebovat další volby pro con.ftgure. Před sestavováním balíčku si přečtěte dokumentaci pro Mailman. Pokud jste sestavili balíček Mailman bez zadání skupiny, sestavte jej znovu. Pokud jste Mailman nesestavovali, podívejte se do níže uvedené poznámky.
WANlED gid 1 2 GOl gid 991 Pokud jste nesestavovali balíček Mailman sami (a nemáte možnost jej znovu sestavit), neexistuje žádný lepší způsob, jak zjistit, který GID je očekáván, než podívat se do chybové zprávy. Pokud nesouhlasí skupina procesu PostfIxu a sku pina, kterou Mailman očekává, obdržíte zamítavou chybovou zprávu po odeslání e-mailové zprávy do konference Mailman. Mailman také chybu protokoluje, což vypadá podobně jako: Fa i l ure to exec script . WANTED gid 12 GOT gid 99 ( Reconfigure to take 9 9 ? )
Aby PostflX doručil zprávu d o Mailmanu pomocí správného GID, musíte správ ně nastavit práva souboru aliasu Mailman. Když PostfIx provádí běžné místní doručování, přejímá identitu příjemce zprávy. V případě aliasu PostflX přejímá identitu vlastníka souboru aliasu, pokud jím není root v tom případě PostflX použije identitu zadanou v parametru de faul t_pri v s . Ujistěte se, že je vlastníkem souboru aliasu uživatel mai lman a že má uživatel ma i lman jako primární skupinu ma i lman. PostfIx pak použije skupinu mai lman při doručování zprávy do systému Mailman. -
Pokud jste balíček Mailman nesestavovali a proto nemůžete nastavit identifIkátor GID, který je očekáván, budete muset zařídit, aby PostfIx používal GID, který Mailman očekává. Vygenerujte chybovou zprávu jako je uvedena výše vytvoře ním konference (viz kroky v této kapitole) a odesláním zprávy do ní. Měli byste obdržet zamítavý e-mail (nebo se můžete na chybu podívat do souboru protokolu pro Mailman). Všimněte si, že Mailman hlásí GID, který chce (WANTED gid 12). Změňte primární skupinu účtu mai lman na tuto skupinu. Ujistěte se, že je vlast níkem souboru aliasu systému Mailman účet mai lman.
Vytváření konference v systému Mailman Následující kroky vás provedou vytvořením aliasu konference astronomy používající Mailman a PostflX. Předpokladem je to, že jste vytvořili účet a skupinu s názvem mailman a nainstalovali balíček do / home/ mai/man.
1 . Ujistěte se, že máte nainstalovaný Python alespoň verze 1 .5.2. Zjistěte to spuště ním příkazu python, který zobrazí informaci o verzi Pythonu a výzvu k zadávání příkazu. Tuto výzvu můžete opustit stiskem Ctrl-D:
$ python
Python 1 . 5 . 2 ( # 1 , Jul
5 2001, 03 : 02 : 1 9 )
[ GCC . . .
Copyright 1 9 9 1 - 1 9 9 5 S t i chting Mathematisch Cent rum, Amsterdam »> AD
$
Pokud číslo verze za "Python" na prvním řádku výstupu není alespoň 1 .5.2, budete muset inovovat Python na vyšší verzi. 2. Stáhněte si Mailman buď ve formátu zdrojového kódu z domovské stránky systé mu Mailman, nebo si opatřete balíček se zkompilovanou verzí z vašeho běžného zdroje software. Při instalaci se řiďte instrukcemi, které jste obdrželi s balíčkem Mailman. Pokud instalujete ze zdrojového kódu, budete pro jeho sestavení po třebovat kompilátor ANSI C. Při sestavování balíčku Mailman zadejte správný identifikátor GID (viz informace uvedené dříve v této kapitole) . 3. Měli byste vytvořit samostatný soubor alíasu pro uložení všech vašich alíasů systému Mailman a správně nastavit vlastníka a skupinu. Jako uživatel mailman proveďte následující příkazy. Tento přHdad předpokládá, že chcete soubor alíasu v domovském adresáři uživatele mailman Ihomelmai/man: $ cd Ihome/mailman $ touch· aliases $ postalias aliases
Tyto příkazy vytváří soubor aliasu i potřebné soubory map, které Postfix používá pro vyhledávání. Jelikož provádíte tyto kroky jako uživatel mailman, budou sku pina a vlastník souborů automaticky správné, za předpokladu, že je účet nastaven tak, jak by měl. 4. Přidejte do souboru letcipostftxl main.cfnový soubor aliasu pro ukládání konfe rencí systému Mailman. Jednoduše přidejte soubor aliasu systému Mailman do stávajícího seznamu souborů v parametru alias_maps: a l i a s_maps
=
hash : / e t c / a l i a s e s , hash : / home/ma i lman/aliases
5. Nový soubor aliasu můžete přidat také do parametru alias_database pro auto matické opětovné sestavení datového souboru při spuštění příkazu newa/iases: a l i a s_database
=
hash : /etc / a l i a se s , hash : /home /mai lman / a l iases
6. Restartujte Postfix, aby zaregistroval změny v konfiguračním souboru main . cf: # postfix reload
7. Spusťte příkaz newlist pro inicializaci vaší nové konference. výstup příkazu new/ist obsahuje řádky textu, který musí být vložen do souboru I homel mai/manl aliasu. Zkopírujte řádky z výstupu příkazu newlist do I homel mai/manl aliasu. Soubor ulož te a zavřete. Zvýrazněné řádky v příkladu 1 0-4 jsou ty, které musí být přidány do I homel mai/manl aliasu. 8. Sestavte datový soubor pro nový alias: • postalias Ihome/mailman/aliases
Nebo pokud jste přidali soubor aliasu do alias database, jednoduše spusťte příkaz newaliases. _
Pfí/eJad 104. Spllfténípfíleo� newlist • bin/newlist Enter the name o f the l i s t : astronomy
Enter the ema i l o f the person running the l i s t : kdent@ezample . com I n i t i a l ast ronomy password : Entry for a l i ases file :
II astronomy mail ing list II created : OB-Mar-2002 root astronomy : astronomy-aclmin : astronomy-request : astronomy-owner :
" I /home/mailman/mail/wrapper post astronomy" " I /home/mailman/mail/wrapper mailowner astronomy" " I /home/mailman/mail/wrapper mails astronomy" astronomy-aclmin
Hit enter to continue with ast ronomy owner noti fication . . .
Vy nebo vaši uživatelé nyIÚ můžete posílat požadavky na adresu [email protected] pro získání nápovědy a pro přidám do konference. NyIÚ můžete používat webové nebo e-mailové rozhraIÚ Mailmanu pro zadáváIÚ voleb pro vaší novou konferenci. Volby pro Mailman a další způsoby práce s balíčkem najdete v jeho dokumentaci.
KAPITOLA 1 1
Blokování nevyžádaných zpráv
Nevyžádané zprávy UBE (Unsolicited Bulk Email), také označované jako UCE (Unso licited Commercial Email), jsou obvykle označovány za spam. Spamming je rozesílání pošty velkému počtu lidí, kteří nemají žádný vztah k odesílateli a nežádali jej o zasílání takové pošty. Spam je šířen z toho důvodu, že je jeho rozesílání velmi levné. Zvýšení ceny za přidání stovek nebo tisíců příjemců do rozesílání je relativně malé, proto odesí latelé spamu posílají na tolik adres, na kolik mohou. Tato kapitola se zabývá problémem spamu a nástroji Postftxu pro omezení následků.
Povaha spamu Společným prvkem spamu je rozhodně nepoctivost. Odesílatelé spamu se nesnaží po sílat příjemcům zprávy odpovídající jejich zájmu a jejich zprávy jsou často lživé a tvrdí, že má příjemce vztah k jejich společnosti nebo jejím partnerům nebo si tyto informace nějakým způsobem vyžádali. Zprávy jsou někdy navržené tak, aby vypadaly jako sku tečná korespondence mezi dvěma lidmi omylem doručená jinam, aby upoutala zájem o nějaký produkt nebo službu. Spam často obsahuje pokyny pro odmítnutí zasílání dalších zpráv. V mnoha případech je to samozřejmě jen úskok ze strany odesílatele pro potvrzení toho, že je daná e-mailová adresa správná. Odpovědí na takové zprávy potvrdíte, že je vaše adresa používána. Ří zení se danými instrukcemi s vysokou pravděpodobností povede k tomu, že bude vaše adresa přidána do více adresářů využívaných odesílateli spamu. Spameři se často pokouší skrýt cestu zpráv, aby jejich odesílatel nemohl být vysledován. Záměrně používají falešné návratové adresy a vymyšlené informace v záhlaví. Hledají špatně nastavené systémy, které jim umožňují odesílat zprávy anonymně. Odesílatelé spa mu se dostávají do těchto systémů a instalují své vlastní tajné servery pro odesílání. Své zprávy běžně kódují nebo vkládají do textu náhodné znaky, aby obešli mtry spamu. Některé techniky používané spamery mají vedlejší účinky, které činí problém ještě horším než samotné rozesílání spamu. Odesílají zprávy na e-mailové adresy, o kterých si myslí, že pravděpodobně existují, i když existovat nemusí. Někteří spouští slovníkové útoky na
poštovní servery, kdy prochází připravené seznamy jmen s nadějí, že najdou takového uživatele na poštovním serveru.
Problém spamu I když spam může v malém měřítku vypadat jako malý problém, na internetu je to znač ný problém. Systém obsluhující stovky nebo tisíce uživatelů přijímajících každodenně desítky nebo stovky nevyžádaných zpráv může mít při útoku značné problémy. Spam pro oběti představuje skutečné náklady. Využívá šířku pásma a prostor na disku příjemců a jejich poskytovatelů internetu. Další náklady na spam zahrnují čas pracovníků technické podpory, kteří musí pomáhat uživatelům čistit přeplněné schránky. Někdy může objem spamu dokonce učinit systém nepoužitelným k jeho účelu (omezením šířky pásma nebo zaplněním prostoru na disku) . V takovém případě se dopad spamu neliší od útoku DoS (denial-of-service) . Dokonce i za méně dramatických okolností má spam vliv na legitimní použití systému. Důležité zprávy mohou být v záplavě spamu snadno přehlédnuty nebo omylem odstraněny při čištění schránek. Důležitým problémem spamu je práce se zprávami adresovanými pro neexistující uži vatele. Některé poštovní systémy poznají, že je cílová adresa neplatná a umí zprávu odmítnout před jejím přijetím. Jiné systémy musí poštu nejprve přijmout a pak ji ode sílat zpět jako nedoručitelnou. Objem vrácených zpráv může jednoduše přetížit frontu a mít dopad na doručování legitimních zpráv. Jelikož návratové adresy často neexistují, nemohou být vrácené zprávy doručeny a čekají ve frontě při mnoha pokusech dokud nevyprší jejich platnost. Jiným trikem pro odesílání spamu je použití legitimních návratových adres, které patří nevinným třetím osobám. Cílové nebo předávající systémy, které spam přijmou, jej pak vrátí předpokládanému odesílateli. V tomto případě budou tisíce nebo miliony vráce ných zpráv poslány "zpět" nešťastné oběti při fenoménu označovaném jako backscalter. Tato oběť nemá nic společného s původním spamem. Ve většině případů je jediným řešením těchto zcela nevinným nezúčastněných přestat používat danou adresu a založit si jinou.
Otevřené systémy (Open Relays) Pokud máte poštovní server na internetu, máte zodpovědnost za to, že nevytvoříte server otevřený pro odesílání, který budou moci odesílatelé spamu použít jako výchozí bod pro jejich aktivity. Otevřený systém je poštovní server, který umožňuje vnějším systémům předávat poštu pro jiné vnější systémy, aby původní systém nemusel doručovat přímo na cílové servery. Odesílatelé spamu neustále hledají špatně nainstalované systémy, které to umožňují. Než se spam stal takovým problémem internetu, provozovali správci poš tovních serverů otevřené systémy, protože to vyhovovalo jejich uživatelům. Nyní jsou skoro všechny softwarové systémy SMTP implicitně nastaveny tak, aby nebyly otevřené. Postfix není výjimkou.
Pokud je váš systém zneužíván jako otevřený systém, bude s největší pravděpodobností tak zatížený odesíláním spamu, že bude snížen jeho výkon pro vaše legitimní uživatele. Pokud se rozhodnete přijímat spam na vašem systému, pak je to samozřejmě na vás, ale budete muset provést určité kroky pro zajištění toho, že váš systém nebude používán pro zneužívání jiných systémů. Pokud odesílatelé spamu používají pro odesílání pošty váš systém, vaše síť pravděpodobně skončí na černé listině (blacklist). Jakmile bude vaše síť na černé listině, bude mnoho serverů odmítat všechny zprávy z vaší sítě - spam i legitimní zprávy od vašich uživatelů. Kapitola 4 popisuje bezpečné nastavení Postftxu pro ochranu před jeho zneužitím.
Detekce spamu Pokud nefungujete jako otevřený systém, můžete předpokládat, že vaše systémy nejsou používány k poškozování jiných systémů. Dalším krokem je ochrana vás samotných a vašich uživatelů omezením spamu, který pro vaši síť přijmete. V ideálním případě by měl váš poštovní server jednoduše odmítat zprávy, které vypadají jako spam. I když se může člověk podívat na zprávu a okamžitě říci, zda to je nebo není spam, počítače mají to mají s bezchybným zjišťováním těžší. Bohužel je pravda, že jakmile začnete odmítat spam, existuje vždy riziko, že zablokujete legitimní korespondenci. Špatné označení legitimní zprávy za spam se označuje jako chybná identiftkace. Ú silí vašeho boje proti spamu je pokusem zjistit tolik spamu, kolik můžete, s co nejmenším počtem chybných identiftkací. Při implementaci nástroje proti spamu musíte zvážit ve likost problému se spamem a možnost odmítnutí skutečného e-mailu a rozhodnout se pro stupeň kontroly. Extrémy se pohybují od přijímání veškerého spamu po přijímání pošty pouze od předem schválených jednotlivců. Předběžné schválení se může zdát být moc silným prostředkem, ale problém se stává pro některé lidi opravdu důležitým. Existují dva primární způsoby detekce spamu: zjišťováním známých odesílatelů spamu a hledáním frází nebo jiných informací, které odhalují pravou povahu spamu, v obsahu zprávy. Navzdory obtížnosti úkolu mohou správci pošty dosáhnout určitého úspěchu s minimálním počtem chybně identiftkovaných zpráv implementací různých opatření.
Detekce spamu podle klienta Techniky blokování klientů používají adresy IP, názvy hostitelů nebo e-mailové adresy zadané klienty, když se připojují pro doručení zprávy. Každá část zadaných informací může být porovnána se seznamem známých systémů pro rozesílání spamu. Systémy rozesílající spam mohou vlastnit skuteční odesílatelé, ale může se jednat také o nechtěně otevřené servery SMTP spravované nešťastnými a většinou nevinnými správci pošty. V každém případě, pokud vám systém pravidelně posílá spam, pravděpodobně se tyto zprávy rozhodnete blokovat. Jedním z problémů při identiftkaci spamu podle adresy IP, názvu hostitele nebo e-mailové adresy je to, že jsou tyto informace snadno zfalšovatel né. I když změna adresy IP připojujícího se systému vyžaduje určité vyšší schopnosti, obálkovou adresu je snadné zfalšovat.
Černé listiny (Blacklist) založené na DNS Při snaze o odstranění spamu z internetu byly vyvinuty různé služby proti spamu, obec ně nazývané DNSBL (DNS-based Blacklists) nebo černé listiny. Tyto služby spravují rozsáhlé databáze systémů, o kterých je známo, že mají otevřené servery SMTP (open relays) nebo že byly používány pro rozesílání spamu. V poslední době jsou častěj ším problémem systémy, které byly napadeny odesílateli spamu, kteří na ně nainstalovali svůj vlastní software proxy umožňujíci jim posílat zprávy. Tyto napadené systémy mohou být také použity při útocich DDoS (distributed denial-of-service). Existují seznamy DNSBL, které jsou určeny pro evidenci těchto nesmyslně otevřených systémů. Základ ní myšlenkou je shromažďování informaci od stovek nebo tisíců správců pošty, aby se mohly legitimní servery pokusit bránit před odesílateli spamu. Obvykle tyto systémy přidávají do své databáze položku DNS a adresu IP pro každý systém, který byl označen jako otevřený. Pokud by byl například hostitel s adresou IP
1 92. 1 68.254.3 1 identifikován jako otevřený, (fiktivru) služba DNSBL No Spam Unli rnited s názvem domény nospam.example.com by vytvořila položku DNS, například
3 1 . 254 . 1 68 . 1 92 . nospam . example . com. Když se klient připojuje k vašemu systému, může
PostflX zkontrolovat, zda server No Spam DNS obsahuje položku pro adresu IP klienta. Pokud byla tato adresa IP identifikována jako otevřený systém, může PostflX zprávu odmítnout. Než se rozhodnete použít nějakou službu DNSBL, velmi pečlivě to zvažte. Mnoho ote vřených systémů používaných pro posílání spamu také často provozuje poštovní služby pro uživatele, kteří neposílají spam. Kromě spamu budete s velkou pravděpodobností blokovat legitimní poštu. Také mějte na paměti, že necháváte třetí osoby rozhodovat o tom, kdo může nebo nemůže posílat poštu vašim uživatelům. Pokud jste na druhou stranu zaplaveni spamem, mohou vám služby DNSBL rozhodně pomoci. Pokud se rozhodnete nějakou použít, podívejte se velmi pečlivě na volby a zásady jejích služeb. Musíte volit mezi agresivitou označování spamu a pravděpodobností ztráty legitimní pošty a závažností vašeho problému se spamem.
Detekce spamu založená na obsahu Kromě identifikování klientů můžete spam často poznat podle obsahu zprávy. Určité řetězce v e-mailových zprávách je označují za pravděpodobný spam ("Our Rates Have Never Been Lower! !'') . Ale pokoušet se odlišit spam podle obsahu zprávy může být problematické. Představte si, že přijímáte velké množství spamu nabízejícího hypotéky na nové domy. Rozhodnete se, že můžete eliminovat většinu z těchto zpráv bloko váním zpráv, které obsahují slova jako "really low interest rate on a new mortgage". To může samozřejmě blokovat mnoho zpráv spamu, ale také byste mohli blokovat zprávy od vašeho přítele (nebo někoho z přátel vašich uživatelů) , který právě koupil nový dům a napsal o tom.
Obtíže detekce Problémem technik identifikace spamu založených na odesílateli a obsahu je to, že odesílatelé spamu stále hledají cesty, jak je obejít. Je to druh souboje mezi legitimními uživateli pošty a odesílateli spamu. Můžete vytvořit seznamy otevřených systémů, ale odesílatelé spamu se stále snaží vyhledávat nové otevřené systémy nebo servery proxy, které by mohli zneužít (a asi jich bude stále více) . Můžete zjistit, že přijímáte hodně spamu se stejnou návratovou adresou. Můžete blokovat zprávy s touto návratovou adresou, ale odesílatelé spamu používají taktiku "zasáhnout a utéct". Získají e-mailovou adresu z jednoho z veřejných e-mailových serverů a použijí tuto adresu pro odeslání tisíců nebo milionů zpráv a pak ji zamění za jinou. Během několika dní uvedenou adresu už neuvidíte. Dokonce i flItry obsahu musí být přizpůsobeny pro nové taktiky odesílatelů spamu. Někteří odesílatelé spamu vkládají do slov ve zprávách kód HTML pro přerušení frází, které byste mohli jinak najít pomocí flItru. Nebo mohou kódovat celou zprávu, aby v ní nebyly rozpoznatelné fráze, když ji Postfix kontroluje. Většina poštovních klientů nutí uživatele automaticky zobrazovat takové zprávy a dekóduje nebo ignoruje nepatřičné prvky HTML. Příjemci často ani nezaznamenají, že byla zpráva původně kódována.
Akce proti spamu Obecně řečeno, máte několik možností, když objevíte spam: •
Odmítnete spam už při spojení prostřednictvím SMTP. Přímé odmítnutí spamu je atraktivní, protože nemusíte uchovávat kopii zprávy a starat se o to, co s ní uděláte. Odesílatel zprávy je zodpovědný za vyřizování chyb. Pokud nechcete odmítat i legitimní zprávy, možná se rozhodnete pro přijímání podezřelých zpráv a vyvinutí procesu pro odlišení legitimních zpráv od spamu.
•
Uložíte spam do úložiště podezřelých zpráv. Pokud budete ukládat podezřelé zprávy a budete je periodicky kontrolovat, můžete zajistit, že nepřijdete o legitimní zprávy. Ú kol je těžký a obvykle vyžaduje časté kontroly a nemusí být moc úspěšný.
•
Zjistit spam a předat jej s nějakým druhem příznaku spamu. Tato volba umožňuje uživatelům rozhodování se mezi tolerancí vůči spamu a možnou ztrátou skuteč ných zpráv. Postfix momentálně nemá vestavěný mechanismus pro označování spamu. Může ale snadno při označování spolupracovat s externím flItrem obsa hu (viz kapitola 1 4) . Pokud filtr obsahu doručuje označené zprávy jednotlivým uživatelům, mohou nastavit své poštovní programy pro práci s těmito zprávami, aby s nimi zacházely podle jejich vlastního nastavení.
Při používání MTA pro detekci spamu, je volba pro odmítnutí obvykle nejlepší. Pokud chcete mít větší flexibilitu, zvažte použití voleb pro filtrování spamu na úrovni MDA nebo MUA. Kombinace filtrování spamu je také dobrou alternativou. Můžete Postfix nastavit tak, aby odmítal jasný spam a povoloval projití podezřelých zpráv do další úrovně, kde může jiný agent provádět vhodnější akci.
PostflX skutečně exceluje ve svých nástrojích pro identifikaci klientů odesílajících spam a jejich odmítání. Odmítání zpráv v Postfixu vyžaduje méně systémových prostředků než spouštění externích filtrů po přijetí zprávy. Pokud se obáváte o ztrátu legitimní pošty, máte stále k dispozici několik bezpečnostních nastavení, na které se podíváme při nastavování PostflXu.
Nastavení Postfixu Zbytek této kapitoly pojednává o různých druzích kontrol UBE, které PostflX poskytuje. Bere v úvahu čtyři různé kategorie detekce spamu, které jsou uvedeny níže.
Pravidlapro detekci klienta. Č tyři pravidla parametrů, která pracují s částmi identity klienta. Každému pravidlu je přiřazen seznam jednoho nebo více omezení, která mohou explicitně odmítnout nebo přijmout zprávu nebo se nemusí rozhodnout vůbec (obecně označováno jako DUN NO). Můžete naphThd nastavit pravidlo odmítající adresu IP konkrétního klienta. Parametry pro kontrolu !}ntaxe. Parametry, které kontrolují striktní dodržování standardů. Jelikož odesílatelé spamu často nedodržují standardy, můžete odmítat zprávy, které přicházejí od špatně na stavených nebo nesprávně implementovaných systémů. Některá z omezení klientů také spadají do této kategorie.
KontrolY obsahu. Pomocí regulárních výrazů můžete kontrolovat záhlaví a tělo každé zprávy a zjiš ťovat pravděpodobný spam.
Tfícfy omezení Můžete nadefmovat složitá pravidla pro detekci klientů pomocí tříd omezení. Umož ňují vám pro vytváření nových omezení rozdělovat omezení do skupin. Při nastavování Postfixu pro detekci spamu také zadáváte, co se má dělat se zprávami označenými za spam. Postfix je může rovnou odmítat, rozdělovat je do různých front nebo je předávat do exterruno filtru.
Pravidla pro detekci klienta Postfix poskytuje následující pravidla, kterým jsou přiřazena omezení založená na in formacích o klientovi: •
smtpd_cl ient_restrict ions
•
smtpd_helo_restrict ions
•
smtpd_sender_restrictions
•
smtpd_recipient_restrict ions
•
smtpd_data_restrictions
Každé odpovídá kroku transakce SMTP. Klient v každém kroku poskytuje část informací. PostflX bere v úvahu jedno nebo více omezení pro informace poslané klientem, která můžete přiřadit každému pravidlu. Obrázek 1 1 -1 ukazuje komunikaci SMTP a klientské pravidlo použité v každém kroku. header_ checks a body checks jsou popsány dále v této _
kapitole. Podívejme se na komunikaci SMTP, abychom zjistili, kdy se který parametr používá.
I
� smtpd3lient....restrlctlons
Server: 220 smlp.example.com ESMTO Postllx
�================� Klient: HelO mall.ora.com Server: 250 smlp.example.com
Klient: MAIL FROM:
smtpd_helo_restrlctions >
Klient: RCPT TO:
smtpd_sender_restrlctlons >
smtpd_recipient.... restrlctions
Klient: DATA Server: 354 End data wlth . Klient: To: Kyle Dent SUbject:SMTP Example
smtpd_da�restrlctions >
Thls Is a message body. II conllnues unlll a dol Is typed on a line by Itself.
header3hecks
- bodY3hecks
Obrázek 1 1-1. Komlmileace SMTP a lelimtská pravidla
Krátký popis komunikace SMTP Komunikaci SMTP uvedenou na obrázku 1 1 -1 byste měli znát z kapitoly 2. Příklad 1 1 - 1 ukazuje položky protokolu pro transakci. Klient SMTP s e nejprve připojí k Postfixu přes socket. Z důvodu toho, jak sockety fungují, PostflX získá adresu IP klienta při sestavení spojení. Na obrázku nevidíte adresu IP klienta, ale je Postfixem zaprotokolována. V zá vislosti na názvu hostitele nebo adrese IP klienta můžete zprávu přijmout nebo odmít nout, takže můžete blokovat konkrétní názvy hostitelů nebo adresy IP a adresy sítí.
Příklad 1 1 -1. Protokolování SMTP 1 . pos t f i x / smtpd [ 8 6 6 0 62 ] : eonneet from mai l . ora . eom [ 1 0 . 1 4 3 . 2 3 . 4 5 ] 2 . pos t f i x / smtpd [ 8 6 6 0 62 ] : 0 6 9 4 B 2 0 005B : e l ient= [ 1 0 . 1 4 3 . 2 3 . 4 5 ] 3 . pos t f i x / eleanup [ 8 6 4 8 6 8 ] : 0 6 9 4 B 2 0 005B : \ mes sage-id=<2 0 0 3 0 1 0 6 1 8 5 4 0 3 . 0 6 9 4B2 0 005B@ smtp . example . eom> 4 . postfix/qmgr [ 8 6 1 3 9 6 ] : 0 6 9 4 B 2 0 005B : from=< info@ora . eom> , \ s i ze=4 8 6 , nrept=1 ( queue aetive ) 5 . pos t f i x / l oeal [ 8 6 4 8 5 7 ] : 0 6 9 4 B 2 0 005B : to= , relay=loea l , °de lay= 9 8 , status=sent (mai 1box ) 6 . pos t f i x / smtpd [ 8 6 6 0 62 ] : diseonneet from mai l . ora . eom [ 1 0 . 1 4 3 . 2 3 . 4 5 ]
Jakmile j e klient připojen, odesílá příkaz HELO s názvem hostitele. Zadaný název hostitele může být použit pro přijetí nebo odmítnutí zprávy pomocí smtpd _heloJestrictions.
V další kroku klient pošle příkaz MAIL FROM s adresou odesílatele následovaný příkazem RCPT TO udávajícím e-mailovou adresu příjemce.
Pokud je vše až do příkazu DATA přijatelné, je klientovi povoleno odeslat obsah zprávy, který se skládá ze záhlaví zprávy následovaných tělem zprávy. PostflX poskytuje jinou možnost odmítnutí zprávy v závislosti a jejím obsahu (viz část Kontrola obsahu dále v této kapitole� . Pokud jsou kontroly záhlaví a těla v pořádku, je zpráva doručena. Postfix oznamuje klientovi odmítnutí zprávy odesláním kódu odpovědi. Standardní kódy odpovědí j sou popsány v kapitole 2. V této kapitole nás zajímají kódy v rozsazích 4xx a 5xx. Více informací se dozvíte z rámečku dále v této kapitole.
Výpis omezení Když přiřadíte omezení d o pravidel UBE Postfixu, není nutné použít všechna pravidla. Můžete nadefinovat omezení pro pravidla, která potřebujete, a ostatní ponechat beze změny. Výchozí nastavení, pokud v souboru main.cfnejsou nadefinována žádná pravidla, vypadá takto: smtpd_cl ient_restrict ions smtpd_helo_re s t rict ions
=
=
smtpd_sender_restrict ions
=
smtpd_recipient_restrict ions
=
permi t_mynetworks , reject_unauth_destination
To brání tomu, aby se z vašeho systému stal otevřený systém, protože umožňuje odesílat všem počítačům z vaší sítě a odmítat všechny ostatní, pokud neodesílají zprávy určené pro jednoho z vašich uživatelů. Existují mnohá omezení. Všechna jsou uvedena v tabulce 1 1 - 1 společně s informací o klientovi, se kterou pracuje. Jedním důležitým konceptem, který zprvu mate hodně lidí, je to, že kterékoliv z těchto omezení může být použito v kterémkoliv pravidlu.
I když může vypadat logicky, že check helo_acce s s by mělo být přiřazeno do srnt pd helo restrict ions, mohlo by být zrovna tak přiřazeno srnptd_sender restrict ions _
_
_
_
nebo něj akému jinému omezení. To poskytuje vysokou flexibilitu v řazení omezení při rozhodování o přijetí nebo blokování. Tablllka 1 1 -1. Pravidlo a omezení SMTP Omezení
Klientem předané informace
check_client_access druh_mapy:název_mapy
Adresa IP nebo název hostitele klienta
rejecUbl_client rejecUhsbLclient rejecCunknown_client check_helo_access druh_mapy:název_mapy permiCnakedjp_address rejecUnvalid_hostname reject_non_fqdn_hostname rejecCunknown_hostname
HELO název_hostitele
checlcsender_access druh_mapy:název_mapy
MAIL FROM adresa
rejectnon_fqdn_sender rejecUhsbLsender rejectunknown_sender_domain check_recipientaccess druh_mapy:název_mapy
RCPT TO adresa
permitauth_destination permiUrucbackup rejectnon_fqdn_recipient rejectunauth_destination rejectunknown_recipientdomain rejecl_unauth-pipelining
DATA command
V tabulce 1 1 -1 vidíte, že některá pravidla mají parametr ve tvaru druh_mapy : název_mapy . Název_mapy udává normální vyhledávací tabulku Postfixu, jejíž klíč na levé straně je porovnáván s informací od klienta a hodnota na pravé straně je akce, která má být pro vedena. Přístupové mapy jsou popsány dále v části Definice omezení.
Jak omezení fungují Všechna omezení bez mapy přístupu vrací jednu z možných hodnot, které určují, co Postfix povede se zprávou: OK, REJECT a DUNNO (přístupové mapy mohou také vracet stejné hodnoty, ale umožňují také další akce). Omezení j sou vyhodnocována v pořadí, ve kterém jsou uvedena. Pokud pravidlo v průběhu zpracování vrátí implicitní REJECT, je zpráva okamžitě odmítnuta. Pokud pravidlo vrací explicitní OK, zastaví se zpracování tohoto parametru, ale pokračuje se dalším dokud nebudou vyhodnocena všechna přiřazená pravidla nebo dokud nedojde k odmítnutí. Je důležité si pamatovat, že pravidlo může zprávu explicitně přijmout, ale stále může být odmítnuta omezením jiného pravidla. Pokud sada pravidel nedojde k definitivnímu rozhodnutí (všechna DUNNO), je výchozí akcí zprávu přijmout. Jakýkoliv jediný parametr může zprávu odmítnout, ale aby nebyla odmítnuta, musí ji všechny přijmout. Existují obecná omezení, jako například permit a reject, která vrací explicitně hodnoty OK nebo REJECT bez hodnocení informací klienta. Když je pravidlo vyhodnoceno jako REJ ECT, Postfix zprávu ve skutečnosti implicitně neodmítne dokud klient nepošle příkaz RCPT TO. Přestože může vědět už při příkazu HELO, že bude zpráva tohoto klienta odmítnuta, čeká s odesláním kódu odmítnutí dokud neobdrží pOKaz RCPT TO. Důvodem tohoto chování je to, že někteří klienti SMTP nekontrolují, zda byli odmítnuti v průběhu transakce a dále se pokouší zprávu doručit. V takovém případě ukončíte spojení, které trvá déle než by mělo a do souboru protokolu bude zaznamenáno několik varování. Jinou výhodou tohoto jednání je to, že budete mít v souboru protokolu více informací. Pokud chcete změnit implicitní cho vání a odmítat zprávu hned jak to bude možné, nastavte parametr smtpd_delaL rej ect v souboru main.if. smtpd_de lay_re j ect
=
no
Možná to budete chtít provést v řízeném prostředí, kde víte, že se všichni připojující se klienti SMTP chovají správně. Jinak je ve většině případů lepší implicitní nastavení.
Testování nových omezení Pro testování pových omezení je užitečný parametr soft_bounce: soft_bounce
=
yes
Pokud je nastaven, jsou odpovědi 5xx převedeny na odpovědi 4xx. Když přidáte nové omezení, kterým si nejste jisti, můžete zapnout soft bounce a pak hledat v souborech protokolů, co bylo odmítnuto, abyste mohli doladit nastavení než bude proveden další pokus o doručení. _
Jinou užitečnou volbou pro testování omezení je kvaliftkátor warn_ if _rej ect. Jednoduše jej zadejte před omezení, pro které pak bude namísto odmítnutí zprávy protokolováno varování. Pokud si nejste jisti, jaký dopad bude mít nové omezení na nové prostředí, můžete je vyzkoušet s warn_ i f_rej ect a pak je, pouze pokud funguje jak jste očekávali, implementovat: smtpd_recipient_restrictions
=
permi t_mynetworks reject_unauth_destination
wa rn_i f_re j e ct re j e c t_ i nva l i d hostname rej ect_unknown_recipient_doma in rej ect_non_fqdn_recipient
Pokud klient v tomto příkladu použije při doručování zprávy neplatný název hostitele v pří kazu HELO, PostflX zaprotokoluje varování, ale zprávu doručí (za předpokladu, že není blokována z jiného důvodu).
Jednoduchý příklad Před přechodem k deftnicím omezení se podívejme na jednoduchý příklad: smtpd_recipient_re stri ctions
=
permi t_mynetworks reject_unauth_destina t i on rej ect_inva l i d_hostname rej ect_unknown_sende r_doma in
Tento příklad rozšiřuje výchozí nastavení o dvě další omezení. Když se klient připojuje z va ší vlastní sítě, permi t mynetworks vrátí OK, takže je povoleno odeslat e-mail. Jiná omezení nejsou kontrolována. Pokud je klient z jiné sítě, permi t_mynetworks nevrátí OK a nevrátí REJECT, takže vrátí DUNNo. PostflX pak zkontroluje rej ect_unauth_dest ination. _
Pokud zpráva není adresována někomu z vašich cílových domén, vrátí REJECT. Jinak vrátí DUNNo. Za předpokladu, že vrátí DUNNO, Postftx zkontroluje re j ect_in va l id_hos tname, které říká, že má být vráceno REJ ECT, pokud není název hostitele zadaný v příkazu HELO platný. Jinak vrátí DUNNo. Postftx nakonec zkontroluje rej ect un known sender doma in, které vrací REJ ECT pokud název domény adresy _
_
_
zadané v příkazu MAIL FROM nemá platný záznam v DNS. Pokud žádné z omezení zprávu neodmítlo, Postfix ji přijme pro doručení.
Definice omezení Existuje šest druhů omezení. Všechna tato omezení j sou definována v částech, které následují.
Přístupové mapypro kontrolu klientů Omezení ve tvaru check _* _access ukazují na vyhledávací tabulky, které mohou obsa hovat adresy IP, názvy hostitelů nebo e-mailové adresy (v závislosti na parametru), které by měly být Postfixem přijaty nebo odmítnuty.
Jiné kontrolY klientů Jiná omezení klientů porovnávají informace od klienta s obecnými konfiguračními informacemi namísto přístupových tabulek. Příkladem může být perrni t_rnynetwor ks, které jste již viděli.
Kontrola dodržování !)ntaxe . Některá omezení říkají Postfixu, aby prosazoval standardy SMTP velmi striktně. Jelikož odesílatelé spamu používají často špatně nastavený nebo implementovaný software, můžete zastavit velké množstvi spamu zajištěním toho, že budou připo jující se klienti dodržovat pravidla.
Kontrola DNS Pravidla pro kontrolu DNS zjišťují správnost informací z DNS. Odesílatelé spamu často pracují v sítích, které nemají správně nastavené DNS. Pravidla tohoto druhu jsou bohužel vhodná pouze pro velmi agresivní proti spamu, protože mnoho legi timních serverů také nemá správně nastavené DNS.
Kontrola černých listin v reálném čase Č erné listiny j sou služby uvádějící klienty podezřelé z odesílání spamu. Postfix může kontrolovat tyto služby s černými listinami v reálném čase a odmítat klienty na nich uvedené. Všeobecná pravidla Všeobecná pravidla explicitně odmítají nebo přijímají zprávy. Obvykle udávají vý chozí postoj pokud není zpráva explicitně přijata nebo odmítnuta. Jelikož budou tato pravidla zprávu vždy přijímat nebo odmítat, měla by být uvedena až na konci seznamu pravidel.
Přístupové mapy Všechna omezení v kategorii kontroly klientů ukazují na soubory s přístupovými mapami. Přístupové mapy jsou jednoduše druhem vyhledávacích tabulek Postfixu (více informací o vyhledávacích tabulkách najdete v kapitole 4) . Do vyhledávací tabulky zadáváte infor mace o klientovi jako klíč a prováděnou akci (přijetí nebo odmítnutí) jako hodnotu:
check_c l ient_access
druh_mapy : název_mapy
Omezení check_cl ient access ukazuje na přístupovou tabulku obsahující položky s adresami IP, adresami sítí, názvy hostitelů a nadřazených domén pro jejich po rovnávání s adresou IP klienta (postfix provádí reverzní vyhledávání adresy IP pro získání názvu hostitele pro porovnání hostitele a názvu nadřazené domény) . Každá položka obsahuje akci, která má být provedena, pokud adresa IP odpovídá klíči. _
check_helo_access
druh_mapy : název_mapy
Omezení check_hele_access ukazuje na přístupovou tabulku obsahující názvy hos titelů a nadřazené domény pro jejich porovnání s informacemi o hostiteli zadanými v příkazu HELO. Každá položka obsahuje akci, která má být provedena pokud zadané informace o hostiteli odpovídají klíči. check_recipient_acces s
druh_mapy : název_mapy
Omezení check_recipient access ukazuje na přístupovou tabulku obsahující polož ky s e-mailovými adresami, doménami a místními částmi, které mají být porovnávány s adresou zadanou v příkazu RCPT TO. Každá položka obsahuje akci, která má být provedena pokud zadaná adresa odpovídá klíči. _
check_sender_acce s s
druh_mapy : název_mapy
Omezení check_ sender_access ukazuje na přístupovou tabulku obsahující položky s e-mailovými adresami, doménami a místními částmi, které mají být porovnávány s adresou zadanou v příkazu MAIL FROM. Každá položka obsahuje akci, která má být provedena pokud zadaná adresa odpovídá klíči. Omezení check sender_access a check_recipient_acces s kontrolují zadané e-mailové adresy. Pro ně může být klíčem v tabulce e-mailová adresa ([email protected]) pro po rovnávání s konkrétní adresou, název domény (example.com) pro porovnávání domény nebo subdomény adresy nebo místní část e-mailové adresy (user@) pro porovnávání všech adres se zadanou místní částí. _
Pravidla check_cl ient_access a check_hele_acce s s porovnávají klíč se zadaným ná zvem hostitele nebo adresou IP. Položkou tabulky může být název hostitele, adresa IP (1 92 . 1 68 . 1 4 3 . 2 3) nebo adresa sítě zadaná počátečními oktety adresy (1 0 nebo 1 0 . 12 nebo 1 0 . 12 . 1 5 4). Akce mohou být zadány takto:
OK Přijmutí položky. Zpracování aktuálního pravidla skončí. Postfix přejde na další pravidlo omezení. REJECf Odmítnutí položky. Volitelně můžete zadat krátký řetězec, který má být použit v od povědi a zaprotokolován u této zprávy. Postfix jinak použije obecný kód odpovědi a text nastavený pro omezení. Parametr access_map_rej ect _ code obsahuje výchozí kód odpovědi pro check_* _access rules a maps _rbl_rej ect_ code obsahuje výchozí kód odpovědi pro rej ect_map s _rbl. Pokud nezadáte hodnotu, bude jí implicitně 554.
DUNNO Konec kontroly položek ve vyhledávací tabulce. Postfix přejde na další omezení pro aktuální pravidlo.
FIL1ER Přesměruje zprávu na ftltr obsahu. Musíte zadat transport a další uzel, jako byste to učinili v transportní tabulce.
HOW Umístí zprávu do fronty. Volitelně můžete zadat krátký řetězec pro zaprotokolování. Postfix jinak zaznamená do protokolu obecnou zprávu.
DISCARD Nahlásí klientovi úspěšné doručení, ale zprávu zahodí. Volitelně můžete zadat krátký řetězec, který má být zaprotokolován. Postfix jinak zaznamená do protokolu obec nou zprávu. Tuto akci nepoužívejte pokud jste pečlivě nezvážili důsledky. Tiché zahození zpráv hovoří proti očekávanému chování poštovních systémů. Pokud se jedná o spam, může být zahození zpráv nejlepší akcí, ale zahození legitimní pošty může ovlivnit celkovou spolehlivost elektronické pošty.
4xx text tfJráty Odmítnutí zprávy. Klientovi je odeslána odpověď se zadaným kódem. Odpověď v rozsahu 4xx říká klientovi, že se jedná o dočasný problém a že má zařadit zprávu do fronty a pokusit se o její doručení později (viz informace v rámečku).
5xx text tfJráty Odmítnutí zprávy. Klientovi je odeslána odpověď se zadaným kódem. Odpověď v rozsahu 5xx říká klientovi, že se jedná o trvalý problém a že má být odesláno oznámení původnímu odesílateli (viz informace v rámečku) . Pro přístupové mapy můžete také nastavit tabulky s regulárními výrazy. Ve většině pří padů pravděpodobně nemá smysl používat tabulku s regulárními výrazy pro přístupové seznamy. Postfix pro porovnávání již dělí e-mailové adresy, domény a adresy IP na jed notlivé části, takže použitím regulárních výrazů ve skutečnosti moc nezískáte. Tabulky s regulárními výrazy jsou na druhou stranu dobré pro kontroly záhlaví a těla zpráv, což je popsáno dále v této kapitole. Rozšiřme příklad konfigurace o nějaké přístupové mapy: srntpd_cl ient_restri ctions
=
check_c l i ent_acce s s hash : /etc/po s t f i x / c l ient_acce s s srntpd_sender_re s t r i c t i ons
=
check_sender_acce s s hash : /etc/po s t f i x / sender_acce s s srntpd_recipient_re s t r l ctions =
perrni t_rnynetworks reject_unauth_des tination re j ect_i nva l i d_hos tnarne rej ect_unknown_sender
Nyní jsme přidali omezení pro použití vyhledávacích tabulek clien'-access a sender_access.
Soubor clien'-access může obsahovat položky jako například: 10 . 157
REJECT
1 92 . 1 6 8 . 7 6 . 2 3
REJECT
currentma i l . com
REJECT
a soubor sender_access může obsahovat položky jako například: .
hards e l l @ example . com
REJECT
market ing@
REJECT
specia l s . digital-letter . com
REJECT
Jiná omezení klientů Následující omezení klientů porovnávají klientem odeslané informace s místním nasta vením Postfixu. Do této kategorie spadají výchozí pravidla. permit_auth_destination Povoluje požadavek pokud přeložená cílová adresa odpovídá názvu hostitele nebo subdoméně pokud je Postfix cílovým místem pro zprávu nebo předávajícím ser verem pro cílové místo. Cílová místa jsou uvedena v parametrech mydestination , inet _ interfaces, vi rtual_a l i a s _maps nebo virtual_ma i lbox_maps a předávající servery jsou uvedeny v parametru relay_domains. Kromě toho adresa nesmí ob sahovat odesílatelem zadané směrování (například [email protected]@example.ne�. Pokud pe rmi t auth_des t i nation nenajde shodu, vrací DUNNO a ne REJECT. PostflX pokračuje v kontrole všech dalších pravidel omezení. _
permi t_mynetworks Povoluje požadavek pokud adresa IP klienta odpovídá některé z adres uvede ných v parametru mynetworks. Normálně se toto omezení používá pro vyloučení místních klientů z ostatních omezení UBE a k tomu, aby mohli odesílat skrze váš server SMTP. reject_unauth_de s tination Odmítá požadavek pokud PostflX není cílovým místem nebo předávajícím serverem pro cílové místo. Cílová místa jsou uvedena v parametrech mydest ination, inet_ in terface s , virtual_alias _maps nebo virtual_ma i lbox_maps a předávající servery jsou uvedeny v relay_domains. Adresy nesmí obsahovat odesílatelem zadané směro vání (například [email protected]@example.ne�. Parametr relay_domains_rej ect code udává kód odpovědi pro odmítnuté požadavky. Implicitní hodnotou je 554. _
Kontrola dodržování syntaxe Omezení v kategorii dodržování syntaxe zjišťují špatně nastavené klienty a odmítají poštu pokud nedodržují standardy. Tato pravidla mohou odhalit mnoho spamu, ale také mohou odmítat legitimní klienty. Měli byste studovat povahu vašeho spamu a skutečných zpráv a tím zjistit, která pravidla vám pomohou nejvíce bez odmítání skutečných zpráv. Pomocí přístupových map můžete umístit odesílatele, kteří by jinak byli odmítnuti, s akcemi OK na bílou listinu (whitelist).
rej ect invalid hostname _
_
Odmítne požadavek pokud název hostitele zadaný v přľkazu HELO nenľ platným názvem hostitele. Parametr inva l i d_hostname rej ect code udává kód odpovědi pro odmítnuté požadavky. Výchozí hodnotou je 501 . Většina legitimnľch odesílatelů používá platné názvy hostitelů. _
_
rej ect_non_fqdn_hostname Odmítne požadavek pokud název hostitele zadaný v po'kazu HELO nenľ v plně kva lifikované podobě jak vyžaduje RFC Parametr non fqdn_re j ect code udává kód odpovědi pro odmítnuté požadavky. Implicitnf hodnotou je 504. _
_
rej ect_non_fqdn_recipient Odmítne požadavek pokud adresa zadaná v po'kazu RCPT TO nenľ v plně kvalifi kovaném tvaru jak vyžaduje RFC Parametr non fqdn rej ect code udává kód od povědi pro odmítnuté požadavky. Implicitnf hodnotou je 504. Většina legitimnľch odesílatelů používá plně kvalifikované názvy domén. _
_
_
rej ect_non_fqdn_sender Odmítne požadavek pokud adresa zadaná v přt'kazu MAIL FROM nenľ v plně kvalifikova ném tvaru jak vyžaduje RFC Parametr non fqdn _rej ect code udává kód odpovědi pro odmítnuté požadavky. Implicitnf hodnotou je 504. _
_
rej ect_unauth_pipel ining Pipelining je technika podporovaná Postfixem pro urychlenľ doručovánľ hromadné pošty odeslánľm více přt'kazů SMTP najednou. Protokol vyžaduje, aby klienti nejprve zkontrolovali, zda server pipelining podporuje. Někten klienti nesprávně začínají pipelining před zjištěnľm, zda je Postfix skutečně podporuje. Pravidlo rej ect unau th_pipel ining takové požadavky okamžitě odmítá. Nenľ prováděno žádné další zpracovánľ a zpráva je odmítnuta. _
Kontrola DNS Pravidla pro kontrolu DNS zjišťují, zda klienti a adresy obálek pošty jsou odeslány z domén, které mají platné informace DNS. Bylo by skvělé, kdyby mohli správci pošty vždy vyžadovat platné informace DNS, protože by bylo pro odesílatele spamu těžší se skrýt. Bohužel existuje mnoho legitimnľch domén, které nemají DNS nastavené správně, aby mohlo být toto omezenľ praktické. Měli byste se podívat na povahu vašeho spamu a skutečných zpráv a tím zjistit, která pravidla vám pomohou nejvíce bez odmítánľ skutečných zpráv. Pomocí pnstupových map můžete umístit odesílatele, kten by jinak byli odmítnuti, s akcemi OK na bílou listinu (whitelist). rej ect_unknown_cl ient Odmítne požadavek pokud adresa IP klienta nemá záznam PTR v DNS nebo po kud název hostitele v záznamu PTR neodpovídá připojující se adrese IP. Parametr unknown_cl ientJej ect_ code udává kód odpovědi pro odmítnuté požadavky. Impli-
citní hodnotou je 450. Pokud změníte implicitní hodnotu, je vrácen kód odpovědi, který jste zadali, s výjimkou dočasného problému DNS. V takovém případě je vaše změna potlačena a Postftx vrací 450. Toto pravidlo vede k mnoha chybným urče ním spamu, protože je velmi běžné, že jsou záznamy PTR špatně nastaveny nebo nejsou nastaveny vůbec. rej ect_unknown_hostname Odmítne požadavek pokud název hostitele zadaný v příkazu HELO nema zaznam DNS A nebo MX Parametr unknown_hostname_rej ect _ code udává kód odpovědi pro odmítnuté požadavky. Implicitní hodnotou je 450. Pokud změníte implicitní hodnotu, je vrácen kód odpovědi, který jste zadali, s výjimkou dočasného problé mu DNS. V takovém případě je vaše změna potlačena a Postftx vrací 450. Mnozí klienti nepoužívají plně kvaliftkovaný název hostitele a byli by tímto omezením odmítnuti. .
rej ect_unknown_recipient_domain Odmítne požadavek pokud název domény adresy zadané v příkazu RCPT TO nemá záznam DNS A nebo MX. Parametr unknown_address Jej ect _ code udává kód odpovědi pro odmítnuté požadavky. Implicitní hodnotou je 450. Pokud změníte implicitní hodnotu, je vrácen kód odpovědi, který jste zadali, s výjimkou dočasného problému DNS. V takovém případě je vaše změna potlačena a Postftx vrací 450. rej ect_unknown_sender_domain Odmítne požadavek pokud název domény adresy zadané v příkazu MAI L FROM nemá záznam A nebo MX v DNS. Parametr unknown_addressJe j ect_code udává kód odpovědi pro odmítnuté požadavky. Implicitní hodnotou je 450. Pokud změníte implicitní hodnotu, je vrácen kód odpovědi, který jste zadali, s výjimkou dočasného problému DNS. V takovém případě je vaše změna potlačena a Postftx vrací 450. Jelikož je adresa zadaná v příkazu MAIL FROM je adresou, na kterou musí být odesílány oznámení o nedoručitelnosti, má smysl požadovat známý název domény. Uvedení tohoto pravidla ve vašich omezeních je důrazně doporučeno.
Kontrola černých listin v reálném čase Omezení pro černé listiny v reálném čase způsobí, že bude Postftx provádět vyhledávání v DNS pomocí informací od klienta a z domén, které zadáte pro zjišťování, zda je klient uveden v jedné ze služeb DNSBL: rej ect_rbl_cl ient název domény Odmítne požadavek, když vyhledávání adresy klienta pod danou doménou vrací záznam A (například 31 .254. 1 68.1 92.nospam.example.com) . rej ect_rhsbl_cl ient název domény Odmítne požadavek pokud má název hostitele klienta záznam A pod danou do ménou.
reject_rhsbl_sender název domény Odmítne požadavek, pokud má doména adresy odesílatele záznam A pod danou doménou.
Všeobecná pravidla Existují dva druhy všeobecných pravidel, která explicitně přijímají nebo odesílají zprávu: permi t Okamžitě požadavek povolí. Zpracování aktuálruno omezení skončí, ale Postfix pokračuje v kontrole dalších omezení. reject Okamžitě požadavek odmítne. Neprobíhá další zpracování a zpráva je odmítnuta.
Odmítání spamu pomocí kódů 4xx a 5xx? Existují dvě třídy návratových kódů, které můžete použít pro odmítání spamu. Návratové kódy v rozmezí 4xx normálně indikují dočasný problém Při odpovědi 4xx zařadí klient zprávu do fronty a pokusí se o doručení později. Kód 5xx indi kuje trvalý problém a říká klientovi, aby se již nepokoušel zprávu odeslat. Kódy 5xx na první pohled vypadají jako obvyklá volba pro odmítání spamu, protože je odesílateli spamu řečeno, aby se zprávu již nepokoušel doručit. Od povídání kódy 4xx může mít své výhody. V případě, že odmítnete legitimní poštu, měl by se klient znovu pokusit o doručení zprávy. Za předpokladu, že kontrolujete tyto věci ve vašich protokolech, byste měli upravit vaše nastavení proti spamu tak, aby umožňovala další pokus o doručení. Pokud na druhou stranu odmítnete skutečný spam kódem 4xx a máte nějaké sekundární poštovní servery pro vaši doménu, které také zprávu neodmítnou, můžete dočasným odmítnutím zaplňovat jejich fronty. Při naplňování vašich přístupových tabu lek můžete doladit odpovědi výběrem kódu založeného na tom, koho blokujete a z j akého důvodu jej blokujete. Samozřejmě měj te na paměti, že odesílatelé spamu nemusí respektovat odpověď, kterou pošlete, takže nemusíte být příliš úspěšní při kontrolování toho, co se děje. Můžete zadat kód odpovědi s krátkou textovou zprávou na straně akce v přístupo vé tabulce. Postfix poskytuje parametry pro řízení implicitního kódu odpovědi pro většinu pravidel omezení. Pokud je k dispozici, uvádí defuůce omezení parametr pro relevantní kód odmítnutí.
Sledování seznamu omezení S tím, co už známe, sledujme, co se stane při některých omezeních příkazu HELO. Před pokládejme, že smtpd_hele_ restrictions jsou přiřazena následující pravidla: smtpd_he lo_Lestrict i ons check_he lo_access hash : /etc/postfix/helo_access =
rej ect_inva l id_hos tname
and helo_access contains the following entries: greatdea l s . example . com
REJECT
ore i l l ynet . com
OK
Projděme si čtyři případy, kdy se klienti připojují s různými příkazy HELO: HELO example
PostflX nejprve narazí na pravidlo check_hele_access ukazující na vyhledávací tabulku helo_access. Při kontrole vyhledávací tabulky nenajde zadaný název hostitele example, takže přejde k pravidlu rej ect_ invalid_hostname. Jelikož example není kompletním názvem hostitele, jak je vyžadováno standardem, Postfix zprávu odmítne. HELO greatdeals.example.com
Postfix nejprve narazí na pravidlo check_he l o_a cce s s ukazující na vyhledávací tabulku hele_access. Při kontrole vyhledávací tabulky najde položku pro greatde als.example.com s akcí REJECT. Postfix proto zprávu odmítne. HELO oreilfynet.com
Postfix nejprve narazí na pravidlo check_hele_access ukazující na vyhledávací tabulku helo_access. Při kontrole vyhledávací tabulky najde položku pro oreilfynet.com s akcí OK. Postfix zastaví zpracování parametru smtpd_heleJestrictions, aniž by se staral o ostat ní omezení a pokud je zadáno, přejde k pravidlu smtpd_ senderJestrictions. HELO mail.ora.com
Postfix nejprve narazí na pravidlo check_hele_access ukazující na vyhledávací tabul ku helo_access. Při kontrole vyhledávací tabulky nenajde daného hostitele mail.ora.com. takže přejde k pravidlu rej ect_inval i d_hostname. Jelikož má mail.ora.com formát vyžadovaný standardem, Postfix pokračuje pravidlem smtpd_ sender_ restrict ions, pokud je zadáno. Parametry pro kontrolu dodržování syntaxe
V souboru main.q jsou dva parametry, které vyžadují striktní dodržování standardů pro elektronickou poštu. Parametr smtpd_hele_ requi red zapněte pro vyžadování, aby klienti SMTP začali konverzaci slovem HELO/EHLO, jak je popsáno v dokumentu RFC pro SMTP. Postfix je implicitně shovívavý vůči klientům, kteří nedodržují standard přesně. Pokud zadáte smtpd _hele_ required yes a klient tento krok přeskočí, Postfix zprávu odmítne. RFC také přesně specifikuje formát adresy obálky. Postfix normálně akceptuje téměř =
jakoukoliv adresu obálky, která dává smysl, ale pokud zadáte strict_rfc 8 2 1_envelopes yes, Postfix odmitne zprávy od klientů, kteří neodesílají správně formátované adresy.
=
Ve skutečné praxi je pravděpodobně dobré vyžadovat příkaz HELO, protože většina klientů dodržuje alespoň základní kroky protokolu. Na druhou stranu existuje mnoho klientů, kteří neformátují adresu správně. Budete-li příliš striktní, můžete přicházet o legitimní zprávy.
Kontrola obsahu Poslední šancí, kdy máte možnost přímo odmítnout zprávu, j e kontrola obsahu samotné zprávy. Postfix nabízí jednoduchou kontrolu obsahu prostřednictvím parametrů: •
header_checks pro záhlaví zpráv
•
mime_header_checks pro záhlaví MIME
•
nested_header_checks pro záhlaví připojené zprávy
•
body_checks pro tělo zprávy
Tyto kontroly jsou fungují stylem "všechno nebo nic". Neexistuje možnost vypnout kontroly pro určité odesílatele nebo příjemce. Pro sofistikovaněj ší analýzy byste měli používat samostatný ftltr obsahu speciálně navržený pro zjišťování spamu. Více infor mací o používání ftltrů v Postfixu najdete v kapitole 1 4. Každý parametr ukazuje na vyhledávací tabulku obsahující vzorky regulárních výrazů a akce. Tyto vzorky jsou porovnávány s řetězci v e-mailových zprávách. Pokud Postfix najde shodu, je provedena daná akce. Kontrola pomocí regulárních výrazů implicitně nerozlišuje malá a velká písmena. Více informací o používání regulárních výrazů ve vyhledávacích tabulkách Postfixu najdete v kapitole 4.
Nastavení kontroly obsahu Parametry mime header_checks a nested_header_checks implicitně používají stejné vyhle dávací tabulky jako header_checks. Pokud chcete tyto kontroly odlišit, můžete je nastavit odděleně. Jinak nastavení header_checks způsobí, že budou mime_header_checks a nes ted_header_checks používat stejné vzorky jako header_checks. Když provedete přiřazení parametrů pro kontrolu, uveďte druh i název tabulky, kterou používáte (viz kapitola 4): _
heade r_checks
=
body_checks
regexp : / etc/postfix /body_checks
=
regexp : / etc/pos tfix /heade r_checks
Ve vyhledávací tabulce pro vyhledávání vzorků je regulární výraz jako klíč levé strany uzavřen mezi dva oddělovače (obvykle lomítka): /match str ing/
REJECT
Typický soubor header_checks obsahuje řádky jako: / free mortgage quote/
REJECT
/ repa i r your credi t /
REJECT
/ take advantage now/
REJECT
Pokud se nějaký z uvedených řetězců objeví v nějakém záhlaví zprávy (s největší pravdě podobností by byly uvedeny v záhlaví Subject:), je zpráva odmítnuta. Postfix zaznamená odmítnutí do protokolu společně se závadným řádkem a pokud jste zadali chybovou zprávu, je také zaprotokolována a odeslána klientovi.
Akce kontroly obsahu Akcí n a pravé straně může být jedna z následujících hodnot. ] sou označeny hodnoty, které umožňují volitelné zadání textu zprávy. Daná zpráva he odeslána klientovi a pro tokolována s odmítnutím. Pokud zprávu nezadáte, PostflX použije implicitní.
REJECT ifJráva Odmítne zprávu pokud řádek zprávy odpovídá regulárnímu výrazu.
WARN ifJráva Protokoluje odmítnutí bez skutečného odmítnutí zprávy. Tato akce je užitečná pro testování regulárního výrazu, abyste viděli, co se děje v protokolu při použití RE ]ECT ještě před skutečným odmítnutím zprávy.
IGNORE Umožňuje odstranit záhlaví nebo řádky z těla zprávy. Pokud regulární výraz odpo vídá, je řádek ze zprávy odstraněn. To může být užitečné pro odstranění informací o interní síti před odesláním zprávy mimo vaši síť. Buďte opatrní co odstraňujete, jelikož je většina záhlaví vyžadována standardy a mohou být velmi užitečné pro pátrání po problémech s poštou.
HOW ifJráva Zpráva bude umístěna do fronty HOLD. Více informací o frontě HOLD najdete v kapitole 5.
DISCARD ifJráva Způsobí, že bude PostflX tvrdit, že doručení bylo úspěšné a tiše zprávu zahodí. Někdy se software odesílatelů spamu nestará o odpověď. Dokonce i když odmítnete zprávu s chy bou 5xx, klient se neustále pokouší o její doručení. DISCARD se tváří jako by zpráva byla doručena. I když byla jednoduše zahozena. Akce DISCARD může být také užitečná pro minimalizaci problému s vysokým rozptylem uvedeného dříve v této kapitole. Pokud je jako adresa odesílatele použita adresa nevinného uživatele, můžete potvrdit, že pošta byla doručena, aby se odmítnuté zprávy nevracely nevinným uživatelům.
FILIER transport:nexthop Po zařazení zprávy do fronty ji Postfix odešle skrze oddělený mtr obsahu. Více informací o oddělených mtrech obsahu najdete v kapitole 1 4. Akce nemohou obsahovat konkrétní kód chyby nebo upravená omezení jako u přístu pových map.
Porovnávání vzorků Kontroly záhlaví porovnávají každé záhlaví s každým vzorkem v uvedených vyhledáva cích souborech. Víceřádková záhlaví jsou před porovnáváním zkombinována do jedi ného řádku. Každý vzorek je kontrolován v pořadí, ve kterém je uveden a porovnávání se zastaví, když Postfix najde shodu a v ten okamžik je zpráva zpracována podle akce, kterou jste zadali. Vzorky zadané parametrem body checks jsou porovnávány s každým řádkem těla zprávy. Řádky jsou porovnávány po jednom a každý je porovnáván s každým vzorkem v pořa dí, ve kterém je vzorek uveden. Porovnávání skončí, když Postfix najde shodu a v ten okamžik je zpráva zpracována podle akce, kterou j ste zadali. _
Velmi dlouhé řádky těla jsou porovnávány po částech, jejichž největší délka je dána pa rametrem l i ne_length_l imi t Implicitní hodnotou je 2048. Postfix také implicitně kon troluje obsah zprávy pouze do hodnoty body checks s i z e_l imi t Implicitní hodnotou je 50 KB. Záhlaví zprávy jsou porovnávána po částech, které jsou omezeny parametrem header s i ze l imit Tato omezení jsou užitečná v tom, že PostflX nezkoumá celý obsah souboru, když zprávy obsahují velké přílohy. .
_
_
.
_
.
_
Někteří správci používají kontroly záhlaví pro jednoduché vyhledávání virů. Můžete odmítnout všechny zprávy, které obsahují přílohy s příponami, které by mohly být nebezpečné pro vaše uživatele: I name ? = " ? * \ . (bat l com l dl l l exe l hta l pi f l vbs ) " ? 1
REJECT
Měli byste zadat další přípony, o kterých víte, že by mohly představovat problém pro vaše uživatele. Samozřejmě mějte na paměti, že tento vzorek skutečně nestačí pro opravdové vyhledávání virů, jelikož můžete zapomenout na nějakou příponu a mnoho klientů PC může spouštět soubory bez ohledu na jejich příponu. Typický soubor ba4Jjhecks obsahuje řádky jako: l increase your sales byl
REJECT
I l owe s t rates . * \ ! 1
REJECT
l i n comp l i ance (with l o f ) strictl
REJECT
1 [ : a lpha : ] < ! - - . * - - > [ : a lpha : ] 1
REJECT Suspicious embedded HTML comments
Druhý řádek odpovídá všem řetězcům začínajícím "lowest rates" následovaným nějakým textem až po vykřičník ("We have our lowest rates in 40 years!"). Č tvrtý řádek hledá komentáře HTML, které jsou obsažené uprostřed slov. Pamatujte si, že je to běžný trik odesílatelů spamu pro překonání vašich ftltrů obsahu, ale také odhaluje, že zpráva obsahuje spam. Regulární výrazy můžete otestovat pomocí příkazu pas/map. Umístěte obsah zprávy do souboru a pak jej zadejte do příkazu pas/map: $ postmap
-
q
-
regaxp : /etc/postfix/body_checks < msg . txt
opportuni t y . increase your sales by 5 0 0 % . Consider
REJECT
pas/map vypisuje všechny řádky, které odpovídají nějakému regulárnímu výrazu společně se zadanou akcí.
Studujte spam, který přijímáte, pro vylepšování a přidávání vašich vzorků. Samozřejmě mějte na paměti potenciální problémy s výkonem při špatně napsaných regulárních výrazech. Jiným potenciálním problémem kontroly obsahu je to, že neexistuje způsob jak umístit na bílou listinu (whitelist) jednotlivé zprávy, které byste chtěli přijímat i když obsahují fráze, které vedou k odmítnutí. Konkrétně pokud je zpráva umístěna na bílou listinu (whitelist) v průběhu kontroly parametru omezení (popsáno dříve v této kapitole), mohla by být stále odmítnuta na základě kontroly záhlaví a těla. Když vytváříte pravidla pro detekci spamu, mějte na paměti, že uživatelé mohou chtít jiný přístup a mohou chtít mít možnost nějaký spam přijmout a nějaké zprávy blokovat. Pokud musíte vytvořit pro různé uživatele různá pravidla, je pravděpodobně nejlepší toho nezkoušet dosáhnout na MTA. Místo toho zvažte možnost nastavení specializovaného agenta pro doručování, jako například procmail, mai/drop nebo sieve pro nastavení pravidel UBE pro jednotlivé uživatele. V Postfixu můžete nastavit třídy omezení pro jednotlivé uživatele, jak uvidíte v další části.
Upravené třídy omezení Třídy omezení poskytují poslední parametry Postfixu proti spamu. Umožňují definovat sadu omezení, které můžete přiřadit na pravou stranu přístupové tabulky. Nemohou být použity při kontrolách záhlaví a těla - pouze v přístupových tabulkách. Třídy omezení umožňují nastavovat různá omezení pro různé klienty, odesílatele a příjemce. Třídy ome zení jsou výkonným nástrojem, který může poskytovat značnou flexibilitu v omezeních UBE Postfixu. Pokud potřebujete nějaký druh komplikovaných pravidel pro blokování spamu, je dobré investovat čas do pochopení tříd omezení. Třídy omezení jsou užitečné zejména pokud potřebujete vytvářet výjimky v normálních omezeních. Například vytvořme dvě třídy uživatelů. Jedna skupina chce přijímat všech ny jim adresované zprávy, ať už se jedná nebo nejedná o spam. Jiná skupina preferuje zejména přísné kontroly spamu, dokonce i za cenu rizika ztráty nějaké legitimní pošty.
Vzorové třídy omezení Pojmenujeme s i tyto třídy jako "spamlover" a "spamhater". Musíte uvést všechny třídy omezení, které chcete definovat, v parametru smtpdJestrict ion_classes: smtpd_re striction_classes
=
spaml ove r , spamhater
Vymysleli jsme si názvy tříd, ale jakmile jsou uvedeny v smtpd_re striction_classes, můžete s nimi pracovat jako s jakýmkoliv jiným pravidlem omezení. Pro třídu můžete přiřazovat seznam omezení. Jakmile je třída definována, může být třída omezení po užita jako akce v přístupové tabulce. Když Postfix narazí na třídu, prochází přiřazená omezení. Nadefinujeme "spamhater" s několika omezeními: spamhater
=
reject_inva l i d_hostname
rej ect_non_fqdn_hostname reject_unknown_sende r_doma in rej ect_rbl_cl ient nospam . example . com
a "spamlover" s jednoduchým "permit": spamlover
=
permit
Samozřejmě můžete tato omezení upravit tak, aby měla smysl pro vaše nastavení. Nyní, když již byly třídy deklarovány a nadefinovány, je můžete začít používat přiřaze ním příslušné třídy každému z příjemců ve vyhledávací tabulce. Tabulku pojmenujeme per_user-'Ibe. •
• per_use r_ube •
abe lard@ example . com
spamhater
heloise@ example . com
spamlover
Nyní řekněte Postfix, že by měl kontrolovat vyhledávací tabulku pro vaše příjemce při kontrole omezení: smtpd_recipient_restrictions
=
permi t_mynetworks re j ect_unauth_destination check_recipient_access hash : /etc/po s t f i x /per_user_ube
Když přijde zpráva adresovaná na [email protected], Postfix prochází normální vý chozí omezení a pak najde checkJecipient_acce s s ukazující na vyhledávací tabulku příjemců. Postfix najde adresu příjemce v tomto souboru, načte akci spamhater a pak spustí omezení definovaná pro spamhater. Pokud některé z omezení "spamhater" vrátí REJECT, Postfix zprávu vrátí. Jinak bude doručena. Zprávy pro [email protected] prochází stejným procesem, ale když Postfix kontroluje omezení "spamlover", najde perrnit a zprávu hned přijme.
Příklad nastavení Postfixu proti spamu Nyní, když jsme si ukázali mnoho aspektů arzenálu Postfixu proti spamu, kapitolu zakončíme příkladem nastavení. Požadavky se server od serveru značně liší, takže je nemožné uvádět skutečná doporučení stranou od toho, co jsme probírali v této kapi tole. Příklad 1 1 -2 může poskytovat výchozí bod, ale sami se musíte rozhodnout, která omezení odpovídají vaší situaci. Příklad 1 1 ·2. Vzorová omezenípro blokování UBE smtpd_restrict ion_classes
=
spamlover spamhater spamhater
=
re j ect_i nva l i d_hos tname reject_non_fqdn_hostname
reject_unknown_sender_doma in rej ect_rbl_c l ient nospam . example . com spamlover
=
permit
smtpd_helo_requ i red
=
yes
smtpd-c l ient res t r i ctions - h c eck_c l ient_access hash : /etc/postfix/cl ient_access =
smtpd_helo_restrictions
=
rej ect_inval i d_hos tname check_helo_access hash : /etc/postfix /helo_access smtpd_sender_res t r i ctions
=
re j ec t_non_fqdn_sender rej ect_unknown_sende r_doma in check_sender_access has h : /etc /pos t f i x / sender_access smtpd_recipient_res t r i ctions
=
permi t_mynetworks reject_unauth_destination re j ect_non_fqdn_recipient rej ect_unknown_recipient_domain smtpd_data_re s t r i ct ions
=
rej ect_unauth_pipe l i n ing header_checks /etc/postfix /header_checks =
body_checks
=
/etc/postfix /body_checks
Do přístupových tabulek byste měli zadat adresy IP a e-mailové adresy ze zpráv, které jste přijali a identifikovali jako spam. Je velnů obtížné blokovat velké množství spamu pomocí omezení check_helo_access a check_sender_access, protože je pro odesílatele spamu velnů snadné tyto informace zfalšovat. Odesílatelé spamu mohou používat neo mezený počet adres a názvů hostitelů. To činí téměř nemožným se jich držet. Protože je tak jednoduché tyto informace zfalšovat, mohli byste blokovat legitimní hostitele a adresy, které měly tu smůlu, že odesílatelé spamu použili jejich údaje. Ale tyto kontroly mohou být užitečné proti zprávám, které opakovaně používají stejné informace, a odesílatelům spamu, kteří se nesnaží zakrývat své stopy. Některé online marketingové služby používají při odesílání spamu jejich skutečné údaje. Tyto servery mohou dokonce respektovat požadavky na odstranění, ale pokud se jedná o požadavky o odstranění pro firmy, o kterých jste nikdy neslyšeli, můžete je blokovat podle informací z příkazu HELO nebo MAIL FROM. Také můžete blokovat servery, ze kterých nechcete dostávat poštu, ať už jsou skutečné nebo falešné. Pošta z nějakého serveru, kterou považujete za nežádoucí, je jedním pří kladem. Také pokud věříte, že je nemožné, abyste dostávali zprávy z Malediv, můžete blokovat adresy a názvy hostitelů s doménou nejvyšší úrovně pro Maledivy. Samozřejmě mějte na paměti, že pokud provozujete poštovní systém pro mnoho uživatelů, pravděpo dobně byste neměli prosazovat svůj morální postoj vůči komukoliv nebo předpokládat, že vaši uživatelé nemají na Maledivách přtbuzné nebo speciální zájem o jejich kuchyni.
KAPITOLA 1 2
Ověřování SASL
Základní protokol SMTP neposkytuje mechanismus ověřování uživatelů. Jelikož jsou obálkové adresy pošty velmi snadno zfalšovatelné, nemůžete vědět, kdo odesílá poštu na váš server, dokud nebudete mít spolehlivý prostředek pro ověřování klientů. Při povolování předávání pošty na váš server musíte mít jistotu, že jsou odesílatelé tím, za koho se vydávají a nemůžete se při identifikaci spoléhat na e-mailovou adresu odesílatele. V této kapitole se podíváme na používání SASL (Simple Authentication and Securi!J Layer) jako prostředek pro řízení předávání pošty a obecně pro identifikaci toho, kdo používá váš poštovní server. Možná budete chtít poskytnout přístup jednotlivcům pro používání vašeho poštovního serveru jako serveru SMTP nebo jiným MTA, které budou předávat poštu skrze váš systém. Také se podíváme na nastavení Postfixu pro poskytování vlastních přihlašova cích údajů jiným MTA, které mohou vyžadovat ověřování před doručením pošty nebo jejím předáváním. Kapitola 4 obecně popisuje problém předávání pošty a některá další řešení, která je třeba zvážit. Protože zamknete váš poštovní server pro ochranu před neautorizovaným předáváním, někteří z vašich uživatelů mohou mít problémy při odesílání pošty pokud nejsou ve vaší síti. Pokud máte například uživatele, kteří cestují se svými přenosnými počítači, pravdě podobně se budou připojovat prostřednictvím blízkého ISP a obdrží adresu IP z jeho sady pro vytáčená připojení. Nebo třeba máte uživatele, kteří pracují doma. V každém případě, pokud nevíte, jaká bude adresa IP uživatele, vám může SASL poskytnout pro středky pro jejich spolehlivou identifikaci. RFC 2554, "SMTP Service Extension for Authentication", poskytuje rozšíření pro základní protokol SMTP, které umožňuje klientům se ověřit serveru SMTP pomocí protokolu SASL. Ukážeme si, jak použít knihovny Cyrus SASL od Carnegie Mellon pro přidání SASL do Postfixu. Také možná budete chtít přidat podporu pro TLS (viz kapitola 1 3) . TLS (dříve SSL) je nejčastěji používáno pro šifrování komunikace mezi webovými prohlížeči a servery, ale stejně dobře funguje pro poštovní servery a klienty. Jelikož některé z mechanismů hesel SASL posílají heslo v nezašifrované podobě, můžete použít TLS pro zajištění toho, aby hesla nebyla posílána v textové podobě.
Přidání SASL do Postfixu vyžaduje, abyste měli ve vašem systému nainstalované knihov ny Cyrus a aby byl PostflX s nimi zkompilován. Vzdálení uživatelé musí nastavit jejich e-mailové klienty pro odesílání přihlašovacího jména a hesla pokud chtějí předávat poštu skrze váš systém. Ve většině moderních poštovních klientů je to celkem snadné.
Seznáméní se SASL SASL je obecná metoda pro přidávání nebo zlepšování ověřování v protokolech klienti server. Jeho hlavním účelem je ověřování klientů na serverech. Když nastavu jete SASL, musíte se rozhodnout pro ověřovací mechanismus, pro výměnu ověřovacích informací (obvykle označovaných jako přihlafovací údcge) a ověřovací [Jstém pro uložení informací o uživatelích. Ověřovací mechanismus SASL řídí výzvy a odpovědi mezi klientem a serverem a to, jak by měly být kódovány při přenosu. Ověřovací systém označuje to, jak server ukládá a ověřuje hesla. Obrázek 1 2- 1 ukazuje tyto dva procesy. Jakmile je ověření úspěšné, server zná identitu uživatele a může určit, jaká práva by měl daný uživatel mít. V případě Postfixu je to právo předávání pošty. Také můžete dané uživatele při předávání pošty volitelně omezit použitím konkrétní adresy odesílatele. Systém SASL Unixová hesla SASLDB Kerberos atd .
�........
Mechanismy SASL Plain OTP Digest
Obrázek 12- 1. Systénry a mechanismy pro ovéfrJvání SASL
Volba ověřovacího mechanismu Klient i server se musí dohodnout na mechanismu ověřování, který budou používat (podívejte se do dokumentace knihoven Cyrus na aktuálně podporované mechanismy) . Některé z běžněj ších mechanismů jsou uvedeny níže:
PLAIN Mechanismus PLAIN je nejjednodušší pro používání, ale neobsahuje žádné šifro vání přihlašovacích údajů. Současně s mechanismem PLAIN možná budete chtít používat TLS (viz informace o TLS v kapitole 1 3). Přihlašovací jméno a heslo jsou předávány poštovnímu serveru jako řetězec kódovaný v base64.
WGIN Mechanismus LOGIN není oficiálně zaregistrovaným nebo podporovaným me chanismem. Někteří starší poštovní klienti byli vyvinuti s použitím ověřovacího mechanismu LOGIN. Knihovny SASL jej podporují pro případ, že byste museli takové klienty podporovat. Pokud jej potřebujete, musíte pro něj zadat podporu při kompilaci knihoven a Postfixu. Pokud sestavujete svůj vlastní Postfix ze zdrojových souborů, podívejte se do přílohy C. Pokud používáte distribuci s balíčky a potře-
bujete podporu pro LOGIN, podívejte se do dokumentace vaší distribuce, zda jí podporuje. Pokud ano, funguje ověřování stejně jako mechanismus PLAIN.
OTP OTP je mechanismus ověřování používající jednorázová hesla (dříve S/Key) . Tento mechanismus neposkytuje žádné ověřování, ale nemusí to být nutné, protože je každé heslo dobré jen pro jednu relaci. Klienti SMTP musí být schopni generovat přihlašovací údaje OTP.
DIGEST-MD5 Při použití mechanismu DIGEST-MDS klient i server sdílí tajné heslo, které ale není nikdy posíláno přes síť. Výměna ověření začíná výzvou serveru. Klient po užije výzvu a tajné heslo pro vygenerování unikátní odpovědi, která by mohla být vytvořena pouze někým, kdo má tajné heslo. Server používá stejné dvě věci, výzvu i tajné heslo, pro vygenerování své vlastní kopie a porovná je. Jelikož skutečné tajné heslo není nikdy odesíláno po síti, není citlivé na odposlouchávání sítě.
KERBEROS Kerberos je síťový ověřovací protokol. Pokud Kerberos ještě nepoužíváte, prav děpodobně nebudete potřebovat podporu mechanismu KERBEROS. Pokud po užíváte Kerberos, je použití SASL dobrou cestou jak doplnit ověřování SMTP do vaší stávající infrastruktury.
ANONYMOUS SASL obsahuje mechanismus ANONYMOUS, který má smysl pro některé pro tokoly, ale pro SMTP žádnou výhodu nemá. Tento mechanismus je v podstatě používán otevřeným systémem (open relay) a účelem ověřování SMTP je eliminace otevřeného předávání zpráv. Když se klient připojuje k poštovnímu serveru, server typicky vypisuje všechny me chanismy hesla, které podporuje, v pořadí jejich upřednostňování. Klient zkouší první, který podporuje. Pokud se připojení nepodaří, může být nastaven tak, aby se pokusil použít další mechanismus, dokud se ověření nepodaří. Pokud se klient a server nemohou úspěšně shodnout na společném mechanismu, ověřování selže. Jakmile se server a klient dohodnou na mechanismu, začne ověřovací proces skládající se z jedné nebo více výzev a odpovědí, které jsou určovány dohodnutým mechanismem. Protokol také udává, jak mají být tyto výměny kódovány:
Volba ověřovacího systému Ověřovací systém SASL může používat stávající hesla d o systému Unix (napříldad passwd, shadow nebo PAM) nebo oddělený soubor s hesly jen pro ověřování uživatelů SMTP. Jiné volby zahrnují Kerberos nebo dokonce nějaké nové schéma .
. Poznámka: jde o kódování, ne šifrování. Konkrémí mechanismus může a nemusí vyžadovat šifrování přihlašo vacích údajů klienta.
Konec konců, vaše volba určuje, kde a jak chcete uchovávat svoje ověřovací informace. Vezměte v úvahu vaši síť a to, jak se vaši uživatelé aktuálně ověřují, při rozhodování o tom, který systém je pro vás nejlepší. Pokud se například vaši uživatelé již ověřují pomocí PAM, pak budete pravděpodobně chtít nastavit SASL pro používání stávajícího systému. Na druhou stranu, pokud má většina vašich uživatelů SMTP virtuální účty (bez přihlašování do systému), měli byste zvolit pro uživatele SMTP oddělenou databázi hesel. Č asto může tuto databázi sdílet i váš server POP /IMAP, což je konvenční volba pro virtuální poštovní účty.
Postfix a SASL Před nasazením SASL byste se měli rozhodnout, který systém a mechanismus budete používat, protože to ovlivňuje vaši instalaci a nastavení. Pro zapnutí ověřování SASL v Postfixu musíte mít knihovnu Cyrus SASL a kopii Postfixu s podporou SASL. Pro některé platformy jsou k dispozici zkompilované balíčky s podporou SASL. Pokud chcete použít zkompilovaný balíček Postfixu, ujistěte se, že podporuje SASL a obsahuje potřebné knihovny SASL. Kromě toho se ujistěte, že jsou knihovny SASL zkompilovány s volbami, které potřebujete pro vaši situaci. Relevantní volby jsou popsány ve zbytku této části. Vývoj knihovny Cyrus SASL jde aktuálně dvěma cestami: SASL a SASLv2. SASL ustupuje SASLv2. V budoucnu můžete očekávat, že bude Postfix obsahovat podporu pouze pro SASLv2. Tato kapitola se zabývá SASLv2. Musíte mít správnou kombinaci verzí Postfixu a knihoven SASL. Měli byte být schopni použít poslední verzi SASLv2 knihoven Cyrus. Podpora PostflXu pro SASLv2 se objevila nejprve v experimentálním vydání verze 1 . 1 .7-20020331 a byla zahrnuta do oficiálního vydání 2.0. Pro potřeby této kapitoly je velmi důležité, abyste používali verzi Postfixu, která podporuje SASLv2. Když je v textu uvedeno SASL, označuje verzi 2 této knihovny.
Nastavení Postfixu pro SASL Než začnete, vyberte ověřovací mechanismy, které chcete podporovat a systém ověřo vání, který chcete používat v SASL.
Zadání ověřovacího systému Knihovna SASL používá pro každou aplikaci, s e kterou spolupracuje, samostatný kon figurační soubor. Postfix používá pro účely SASL soubor s názvem smtpdeonj Tento soubor je obvykle umístěn v /lIsr/ loeal/ lib/ sasl2/ smtpdeotif. Soubor smtpdeonf obsahuje minimálně řádek označující systém, který má být používán. Podíváme se na zadání hesel systému Unix nebo samostatného souboru s hesly pro SASL. Podívejte se do dokumen tace k SASL na další volby, které byste mohli zadat do souboru smtpdeotif.
Hesla systému Unix Pro ověřování uživatelů v SASL je nejběžněj ší použití stávající databáze systému. Histo ricky to znamenalo použití souboru / etc/passwd. Dnes je pravděpodobnější, že používáte pro ověřování / etc/ shadow, PAM nebo nějakou jinou databázi. Jelikož tato hesla nejsou dostupná neprivilegovaným procesům a PostflX záměrně běží s omezenými právy, ne může normálně ověřovat uživatele. Knihovny Cyrus řeší tento problém poskytováním speciálrubo ověřovacího serveru s názvem saslallthd. Zpracovává požadavky namísto Postfixu. Démon saslallthd vyžaduje práva superuživatele. Jelikož běží jako proces oddělený od Postfixu a nemusí komuniko vat se sítí, je jeho dopad na zabezpečení samozřejmě minimální. Pokud budete používat ve spojení se SASL hesla systému Unix, musíte spustit démon saslallthd, který je obsažen v distribuci Cyrus. Pamatujte si, že používání hesel systému Unix omezuje na používání pouze čistě textových hesel, protože démon potřebuje pro ověřování skutečná hesla. Podívejte se do kapitoly 1 3 na použití šifrování mezi PostflXem a e-mailovými klienty. Pro zadání toho, že chcete, aby Postfix používal pro ověřování démon saslallthd, vytvořte soubor smtpd.conf s tímto řádkem: pwchec k_method : saslauthd
saslallthd je obsažen v distribuci Cyrus SASL a měl by být nainstalován na konvenčním místě. Démon musí běžet na pozadí, aby jej mohl Postfix používat pro ověřování klientů. Když spustíte saslallthd, řeknete mu pomocí volby -a, jaký druh systému hesel používáte. Nejběžnější jsou pam, shadow nebo getpwent (pro konvenční / etc/passwd) . NapříKlad pro spuštění démonu v systému, který používá pro ověřování PAM zadejte příkaz: • slslluthd -I pam
Pro další volby pro saslallthd se podívejte do dokumentace balíčku Cyrus. Pravděpodobně také chcete, aby se tento démon spouštěl automaticky při spuštění systému, aby byl vždy k dispozici pro váš server Postfix. saslallthd můžete přidat do spouštěcích procesů vašeho systému stejným způsobem j ako přidáváte jiné démony, jako například PostflX.
Hesla SASL Pokud nechcete, aby váš poštovní server používal stávající účty systému, můžete vy tvořit samostatnou databázi uživatelů a hesel nezávislou na mechanismu hesel systému. Můžete vytvořit účty pro uživatele, kteří mají přístup pouze k poště a nebudou se moci přihlašovat do systému hostitele. Do souboru smtpd.cotifzadejte následující řádek: pwchec k_method : auxprop
Termín auxprop pochází z použití doplňků Cyrus. Doplňky umožňují vkládat externí programy pro ověřování. Distribuce Cyrus SASL je dodávána s sasldb jako výchozím doplňkem a to by mělo být vše, co potřebujete k práci s PostflXem. Klíčové slovo auxprop jednoduše říká, že by měl být použit externí soubor s hesly SASL. Při používání hesel SASL nemusíte spouštět démon saslallthd, ale musíte vytvořit externí soubor s hesly obsahující přihlašovací údaje pro všechny vaše poštovní účty. Soubor
se jmény a hesly pro SASL je implicitně uložen v letci sas/db2. Server SMTP Postfi xu potřebuje mít přístup alespoň ke čtení tohoto souboru a pokud používáte funkci
auto_transition Cyrus SASL (viz dokumentace pro Cyrus), bude Postfix vyžadovat také právo zápisu do tohoto souboru. Pokud nepotřebujete funkci auto_transi tion, je nejlepší nedávat Postf1Xu právo zápisu do souboru s hesly. Pokud máte jiné procesy, které také potřebují přístup k souboru Gako například server POP lIMAP) , možná budete muset upravit vlastnictví a práva, aby měly všechny proce sy, které jej potřebují, přístup k souboru. NapřHdad můžete ve vašem systému vytvořit skupinu sas!. Ujistěte se, že j sou uživatel postf1X a ostatní účty, které potřebují přístup k souboru, v této skupině. Pokud některý z procesů potřebuje soubor aktualizovat, pak se přístup pouze pro čtení příliš restriktivní a budete muset procesům přidělit právo zápisu. Pro nastavení práv na
4 4 0, aby byl pouze pro čtení a nebyl obecně čitelný kým
koliv, spusťte následující příkazy: t chown poltfix : aasl /etc/lalldb2
• chmod 440 /etc/lalldb2
Pro vytvoření účtů pro váš server SMTP použijte příkaz saslpasswd2 z distribuce Cyrus SASL. Ukládá účty do souboru letci sasldb2. Musíte zadat uživatelské jméno i doménu SASL. Pro Postf1X by měla být doménou hodnota uvedená v parametru myhostname. Pokud používáte pro určení názvu hostitele příkaz postcotif -h myhostname, můžete si být jisti, že máte správnou hodnotu. Následující příkaz vytváří účet pro uživatele kdent: • aaslpallwd2 -c
-
u 'poltconf -h myholtname ' kdent
Pas sword : Aga in ( for ve r i f ication) :
Heslo zadejte dvakrát. Volba -c říká příkazu saslpasswd2, aby vytvořil uživatelský účet a -u se používá pro zadání domény pro tento účet, kterou můžete převzít přímo z konfigurace Postfixu.
Nastavení Postfixu Všechny relevantní parametry Postf1XU pro ověřování hesel SASL začínají smtpd_ sasl' pro server SMTP nebo smtp sasl' pro klienta SMTP, Pro nastavení serveru potřebujete _
alespoň parametr smtpd_ sasl_auth_enable a omezení permit_ sas l_authenticated, které musí být přiřazeno do jednoho z parametrů pro omezení smtpd. Podívejte se do kapitoly
1 1 na další informace o omezeních UBE.
Zapnutí SASL Pro zapnutí ověřování na serveru SMTP v Postfixu přidejte parametr pro povolení do souboru main.if. smtpd_s as l_auth_enable
•
=
yes
Poznámka: jde o kódování, ne šifrování. Konkrétní mechanismus může a nemusí vyžadovat šifrování přihlašo
vacích údajů klienta.
Kromě toho se někteří starší poštovní klienti" nedrží správně ověřovacího protokolu SMfP. Podle specifikace server uvádí seznam podporovaných mechanismů za klíčovým slovem AUTH následovaným mezerou. Tito klienti očekávají, že obdrží AUTH následovaný znamén kem rovnítka. Postfix jim umožňuje vyhovět nastavením následujícího parametru: broken_sa s l_auth_c l ients
=
yes
Nastavením tohoto parametru říkáte Postfixu, aby oznamoval podporu ověřování SMTP standardním i nestandardním způsobem. Tato volba je zcela bezpečná, jelikož nevadí ostatním poštovním klientům a ti nestandardní budou nyní také fungovat.
Prevence před falšováním odesílatele Abyste se ujistili, že klienti používají správnou adresu odesílatele při odesílání pošty, Po stfix umožňuje mapovat adresy odesílatelů na přihlášení pomocí SASL. Pokud máte na příklad adresu [email protected], která by měla být použita pouze uživatelem SASL se jménem kdent, můžete vytvořit soubor vyžadující správného uživatele pro tuto adresu: kdent
kdent@example . com
Tento soubor je normální vyhledávací tabulkou Postfixu a umožňuje použití regulárních výrazů stejně jako místních částí a domén (více informací o vyhledávacích tabulkách Postfixu najdete v kapitole 4) . Pomocí parametru smtpd_ sender_login_maps v souboru main4 zadejte tabulku, kterou jste vytvořili: smtpd_sender_login_maps
=
hash : /etc/po s t f i x / s a s l_senders
Do této tabulky můžete zadat tolik adres, kolik budete potřebovat. Pro odmítnutí zpráv od uživatelů pokoušejících se o použití nesprávných adres odesílatele nebo uživatelů, kteří nejsou k odesílání oprávněni vůbec a pokouší se použít danou adresu, zadejte omezení re j ect_ sender_login_mi smatch do vašich omezujících parametrů (více infor mací o omezeních UBE najdete v kapitole 1 1) .
Povolení ověřených uživatelů Pokud již používáte parametr smtpdJecipientJestrict ions jako součást blokování UBE, musíte říci Postfixu, aby umožnil odesílání ověřeným uživatelům přidáním per mit_sas l_authent i cated do seznamu omezení. Pokud jste předtím používali výchozí nastavení a nepotřebovali jste parametr smtpd_ recipient Je s t r i ct i ons, jednoduše přidejte následující řádek: smtpd_recipient_restrict ions
=
permi t_mynetworks ,
permit_sas l_authenti cated, re j ect_unauth_de s t i nation
Pokud již používáte parametr smtpd_recipientJestrict i ons, pouze přidejte permit_ sasl_authenticated do seznamu omezení. Ujistěte se, že j ste do vašeho seznamu zadali nějaký druh omezení odmítání (viz kapitola 1 1).
* Ú dajně Microsoft Outlook a Outlook Express před verzí
experimentovat.
5 , ale můžete při zjišťování podpory u vašich klientů
Zadání mechanismů Parametr smtpd_ sas 1_ secu r i t y_options umožňuje nastavit, které mechanismy hesla budou uvedeny při přihlašování klientů na váš server SMTP. Kompletní seznam do stupných mechanismů závisí na vašem systému a mechanismech, které byly k dispozici při sestavování vašich knihoven SASL. Implicitním nastavením je, pokud nic nezadáte, přijímat všechny dostupné mechanismy včetně hesel ve formátu čistého textu, ale ne anonymní přihlášení. Pokud používáte démon saslauthd, musíte akceptovat hesla ve formátu čistého textu, takže je asi nejlepší implicitní nastavení. Pokud zadáte nějaké jiné volby, změníte výchozí hodnoty, takže se ujistěte, že j ste zadali do vašich voleb noanony mous. Pokud nastavíte tento parametr, můžete zadat libovolnou kombinaci následujících hodnot. Například: smtpd_sa s l_security_options
=
noanonymous , nopla intext
Běžnými mechanismy jsou: nop1aintext Pokud vaše zásady zabezpečení nepovolují odesílání hesel v čistě textové podobě, za dejte nop1aintext. To způsobí, že SASL použije některou z technik výzva/odpověď, která ověřuje bez přenášení skutečných hesel. noactive Při aktivních útocích se útočníci postaví mezi klienta a server. Některé druhy aktiv ních útoků j sou běžně označovány jako útoky man-in-the-rniddle (volně přeloženo: někdo mezi) . Ú točníci mohou být schopni číst nebo měnit odesílaná data nebo si hrát na klienta nebo server. Pro omezení podporovaných mechanismů hesel na ty, které nejsou citlivé na tento druh útoku, zadejte noactive. nodi ct ionary Při slovníkových útocích útočníci prochází databázi možných hesel a zkouší jedno po druhém, aby získali přístup. Databáze jsou typicky tvořeny seznamy měst, spor tovních týmů, vlastních jmen a všech slov slovníku plus obvyklých variací slov. Pro omezení podporovaných mechanismů hesel na ty, které nej sou citlivé na tento druh útoku, zadejte nodict ionary. noanonymous Anonymní přihlášení nemá pro servery SMTP žádný smysluplný účel. Postfix im plicitně neumožňuje anonymní přihlášení. Pokud zadáte další volby, ujistěte se, že jste zadali i noanonymous, jelikož přepíšete implicitní hodnoty. mutua1 auth Můžete vyžadovat mechanismy, které poskytují vzájemné ověřování, kde klient i ser ver pro ověření jejich identity poskytují přihlašovací údaje. Pro omezení mechanismů na ty, které poskytují vzájemné ověřování, zadejte mutua1_auth.
Shrnutí nastavení Zde jsou krok z a krokem uvedeny pokyny shrnující nastavování popisované v této ka pitole. Toto je hrubý přehled toho, co je potřeba nastavit v Postfixu pro použití SASL: 1 . Určení ověřovacích mechanismů a systému, který chcete podporovat. 2. Nainstalujte knihovny SASL a znovu zkompilujte Postfix s podporou SASL. Nebo získejte distribuci Postfixu s SASL, obsahující podporu pro ověřovací mechanismy a volby SASL, které potřebujete. 3. Znovu nainstalujte PostflX. 4. Vytvořte soubor I usrl loeall libl sasl21 smtpd.eorif. V pwcheck_method zadejte sas lauthd nebo auxprop. 5. Pokud používáte pro ověřování hesla systému Unix, spusťte démon saslauthd a zadejte druh ověřování, který používáte ve vašem systému. Jinak použijte příkaz saslpasswd2 pro vytvoření účtů pro poštu ve vašem systému. 6. Zapněte ověřování v souboru main.cf. To vyžaduje, abyste povolili SASL a abyste zadali, že by mělo být ověřeným uživatelům povoleno odesílání pošty. Základní nastavení vyžaduje alespoň následující parametry: smtpd_sas l_auth_enable
=
yes
smtpd_recipient_res t r ictions
=
permi t_mynetworks ,
permit_sas l_authenticated, rej ect_unauth_dest ination
7. Restartujte Postfix, aby zaregistroval změny v konfiguračním souboru main.if. # postfix reload
Testování nastavení ověřování Pravděpodobně bude nejlepší, pokud se pokusíte ověřit na serveru SMTP ručně ještě než se o to pokusí uživatelé se svými poštovními klienty. Připojením se na váš server SMTP a ručním ověřením můžete vidět, jakou přesnou odpověď dostanete a můžete okamžitě zkontrolovat, zda nejsou v souboru protokolu nějaké další důležité informace. Nejjednodušším způsobem připojení k serveru SMTP je použití klienta Telnet a započetí komunikace se serverem SMTP (vzorová relace SMTP je uvedena v kapitole 2). Nejjed nodušší je testovat mechanismus PLAIN, takže pokud jej máte vypnutý, možná jej budete chtít zapnout pro ověření správné funkce ověřování. Po testování jej můžete vypnout. Pro ověření pomocí mechanismu PLAIN musíte odeslat příkaz AUTH následovaný vašimi přihlašovacími údaji kódovanými pomocí base64. Vaše přihlašovací údaje j sou kombi nací autorizační identity (identity pro přihlášeru) následované znakem null, který je dále následován ověřovací identitou (identitou, jejíž heslo bude použito), opět následovanou znakem null, která je nakonec následována heslem. Obvykle je autorizační identita stejná jako ověřovací identita a budeme to nyní předpokládat. Při použití přihlašovacích údajů pro uživatele kdent musíte zakódovat řetězec "kden t \ O kdent\ORumpe l s t i l t s kin".
Důležité je, že je potřeba zakódovat přihlašovací údaje do base64 bez znaku konce řádku. Pokud váš systém obsahuje přľkazy mmencode a printJ, mělo by to být snadné. Přľkaz prinif vypisuje formátované řetězce a neobsahuje automaticky konec řádku jako běžnější přľkaz echo. Příkaz mmencode jednoduše převede řetězce do různých formátů MIME a používá implicitně base64, což je přesně to, co potřebujeme. Zakódovaný řetězec, který potřebujete, můžete získat provedením: S printf ' kdent\Okdent\ORumpelstiltskin ' I mmencode a2RlbnQAa2 RlbnQAcnVtcGxlc3RpbHRza21u
Na některých platformách nemusí prinif pracovat se znaky null vloženými do řetězce správně. Tento problém zjistíte tak, že je kódovaný řetězec kratší než původní řetězec. Pokud je to ve vašem systému možné, můžete zkusit použít namísto prinif příkaz echo s přepínačem -no Přepínač -n říká programu echo, aby na konec nevkládal znak konce řádku. Pokud nemůžete přinutit echo nebo prinif spolupracovat, nebo pokud nemáte přľkaz mmencode, můžete pro získání požadovaného řetězce použít jednoduché řešení napsané v jazyce Perl.
encode_sasLplain.pl Pokud nemáte přľkaz mmencode (nebo mimeencode), můžete použít pro vytvoření kódovaného řetězce pro testování tento jednoduchý skript vytvořený v jazyce Perl. Tento skript vyžaduje modul MIME::Base64, který nemusí být ve vašem systému nainstalován. Můžete jej jednoduše získat z vašeho obhbeného zrcadla CPAN : . ! / u s r /bin /pe rl use s t r i c t ; use MlME : : Base 6 4 ; i f ( S #ARGV ! = 1 l die "Usage : encode_sa s l_pl a i n . pl <use rname> <password> \ n " ; print encode_bas e 6 4 ( " SARGV [ O l \ O SARGV [ O l \ O SARGV [ l l " l ; exit O ;
Pro získání potřebného ověřovacľho řetězce kódovaného v base64 pro uživatele kdent s heslem Rumpe l s t i l t s kin spusťte: S encode_sasl�lain . pl kdent Rumpelstiltskin a2RlbnQAa2RlbnQAcnVtcGxlc3RpbHRz a 2 1 u
Tento přľkaz vytvoří potřebný řetězec, který pak můžete zkopírovat a vložit do vaší relace Telnetu.
Jakmile budete mít potřebný řetězec, zkopírujte jej a vložte do vaší relace Telnetu. V níže uvedeném př:ľkladu napíšete pro spuštění pOKaz te/ne! a pak všechny tučné řádky. Zde testujete ověřování na hostiteli mail.examp/e.com. Měli byste zadat název vašeho vlastního systému:
$ telnet mail . uuple . CCIII 25 Trying 1 92 . 1 6 8 . 1 0 0 . 5 . . . Connected to ma i l . example . com . Es cape character is
' A
J
' .
Server : 2 2 0 ma i l . example . com ESMTP Postfix
EBLO telt . ora . cCIII 2 5 0 -mai l . example . com 2 5 0 - P I PELINING 250-SIZE 10240000 2 5 0 -VRFY 2 5 0 -ETRN 2 5 0 -AUTH LOG IN PLAIN DIGEST-MD5 CRAM-MD5 2 5 0 -XVERP 2 5 0 8 B I TMIME AOTH PWH a2Rl.bnQAs2RlbnQAcnVtcGxlc3RpbBRza21u
Server : 2 3 5 Authent i cation succe s s ful
quit Server : 2 2 1 Bye Connection c losed by foreign hos t .
Pokud nespatříte zprávu, že by ověřování úspěšné, podívejte se do souboru protokolu, co hlásil Postfix. Problémy může být obtížně najít, protože se na přihlašování podílí mnoho věcí. Když testujete ověřování pomocí Telnet a nevidíte řádek: 2 5 0 -AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
mezi rozšířeními serveru, ujistěte se, že j ste nezapomněli zadat do souboru main.cf parametr smtpd_sas l_auth_enable. Pokud je zde parametr uveden, bude lepší, když se podíváte na to, jak jste zkompilovali Postfix, a ujistíte se, že byl sestaven s podporou pro SASL. Pokud soubor protokolu říká, že nemůže otevřít soubor db, ujistěte se, že je v adresáři / etc soubor s hesly a že má účet postflX právo jej číst. Distribuce Cyrus obsahuje některé nástroje, které mohou pomoci problémy diagnostikovat. Podívejte se do dokumentace příkazů sasldblistusers2 a saslpasswd2.
Ověřování klienta SMTP Možná budete chtít, aby váš Postfix odesílal poštu skrze jiné servery, které vyžadují ověřování SMTP. Kromě vyžadování hesel na vašem vlastním serveru můžete Postfix nastavit tak, aby používal přihlašovací jméno a heslo při odesílání pošty skrze jiné ser very SMTP. Musíte Postfixu předat soubor s hesly obsahující přihlašovací údaje, které by měl použí vat při ověřování na ostatních serverech. Položky v souboru s hesly by měly obsahovat doménu nebo názve hostitele, uživatelské jméno a heslo ve formátu: doména už ivatel ské_j méno : heslo. Pro doménu nebo název hostitele Postfix nejprve kontroluje cílovou doménu z adresy příjemce. Pokud doménu nenajde, hledá název hostitele, ke kterému
se připojuje. To PostfIxu umožňuje jednoduše spolupracovat se sídly, které mají více hostitelů MX sdílejících stejnou databázi uživatelů. Pro zadání souboru s hesly použijte parametr smtp_ sas 1_pas sword_maps. Parametr smtp_ sas1_securi ty_options klienta funguje stejně jako parametr smtpd_sasl_ security_opt i Oll s serveru (popsaný dříve v této kapitole) pro servery SMTP. Pokud nezadáte žádné volby, umožní implicitní hodnoty všechny dostupné mechanismy včetně hesel ve formátu čistého textu, ale ne anonymní přihlášení.
Postup pro zapnutí ověřování klienta SMTP Pomocí následujících kroků můžete nastavit PostfIx tak, aby předával přihlašovací jméno a heslo při odesílání pošty. V tomto příkladu budete pro Postf1X vytvářet až dvě odlišná hesla pro ověřování při odesílání přes jakýkoliv server v doméně ora.com a přes hostitele s názvem mail.postfIx.org:
/ etc/postftx/ sasl-fJasswd s položkami pro všechny potřebné kombinace hostitele, přihlašovacího jména a hesla. Váš soubor by měl vypadat takto:
1 . Vytvořte soubor s názvem
ora . com
kdent : Rumpe l s t i l tskin
mai l . postfix . org
kyle : qu ixote
2. Spusťte postmap pro tento soubor: # poltmap /atc/poltfix/lall-PIllwd
3. V souboru main.cf zapněte ověřování klienta. Všimněte si, že nyní nastavujete smtp_s a s 1_auth_enab1e namísto smtpd_s a s 1_au th_enab1e jako jste to dělali pro zapnutí ověřování na serveru. Také musíte nastavit parametr smtp _ sas 1_ pas sword_maps tak, aby ukazoval na soubor s hesly, který jste vytvořili: smtp_s as l_auth_enable
=
smtp_s as l_pas swo rd_maps
yes =
hash : /etc /pos t f i x / s a s l_passwd
4. Restartujte PostfIx, aby zaregistroval změny v konfIguračním souboru main.if. # poltfix raload
Když se nyní bude klient SMTP PostfIxu pokoušet o odesílání pošty skrze domény nebo hostitele uvedené v souboru / etc/postjix/sasl-fJasswd, bude nabízet odpovídající přihla šovací údaje. Pokud se například klient smtp PostfIxu připojuje k serveru mail.ora.com, ověřuje se pomocí uživatelského jména kdent a hesla Rumpe 1 s t i l ts kin.
KAPITOLA 1 3
TLS (Transport Layer Security)
TLS (fransport Layer Security) , dříve známé jako SSL, rozšiřuje komunikace TCP o šifrování pro zajištění soukromí a integrity zpráv. RFC 3207 definuje rozšíření SMTP známé jako STARITLS. Jeho hlavním účelem je zajištění soukromí v komunikacích P2P (peer-to-peer) . Také dává záruku, že vaše pošta nebude doručena do škůdcovského systému, který se tváří jako server, o kterém si myslíte, že na něj odesíláte poštu. Jinou užitečnou aplikací je kombinace s SASL pro ochranu čistě textových hesel, která by byla jinak odesílána v jejich nezašifrované podobě. Výhodou TLS je to, že můžete dosáhnout zachování soukromí a zajištění spolehlivé identifikace serveru bez předchozího nastavení obou systémů. Pokud je vaši klienti podporují, je možné také silné ověřování. Při použití klientských certifikátů, což jsou kryptograficky podepsané identifikátory (viz rámeček), si může být váš poštovní server jistý, že jsou připojující se klienti tím, za koho se vydávají. Klientské certifikáty můžete používat namísto nebo ve spojení s ověřováním SASL, které bylo popsáno v kapitole 1 2. Správa klientských certifikátů vyžaduje určitou režii a asistenci uživatelům při nastavo vání jejich e-mailových klientů pro jejich použití, zatímco použití TLS jen pro šifrování přihlašovacích údajů je možno nastavit velmi jednoduše. Samozřejmě je důležité si zapamatovat, že TLS není určeno k ochraně obsahu e-mai lových zpráv. Když zašifrujete přenos mezi klientem a serverem, je vše (včetně zprávy) šifrováno. TLS samozřejmě chrání pouze přenos mezi těmito dvěma systémy. Po přijetí zprávy serverem je zpráva pravděpodobně uložena nezašifrovaná. Nemůžete si být jisti, zda zpráva bude či nebude šifrována při jejím předávání na další cíl nebo pokud při sta hování zprávy příjemcem pro její přečtení. Pokud nemůžete řídit a šifrovat celou cestu od původrubo odesílatele ke konečnému příjemci, bude zpráva s největší pravděpodobností v některém bodě předávána v nezašifrované podobě. Pro zajištění zachování důvěrnosti zprávy potřebujete řešení pro klienty, jako napřľklad PGP nebo S/MIME.
Postfix a TLS Podpora TLS v Postfixu je zajišt'ována sadou úprav, které provedl Lutz Jiinicke. Úpravy si můžete stáhnout po klepnutí na odkaz pro další software (Add-on Software) na webu
Postfixu (informace o sestavování Postfixu s úpravami TLS najdete v příloze C) . Pokud používáte balíček Postfixu již připravený pro vaši platformu, ujistěte se, že obsahuje úpravy pro TLS .
Kromě kompilace PostflXu pro podporu TLS musíte také vytvořit a nastavit certifikáty TLS Potřebujete privátní i veřejný klíč. Veřejný klíč je podepsaným certifikátem iden tifikujícím váš server. Je ověřen a digitálně podepsán certifikační autoritou (CA), která potvrzuje, že váš certifikát ve skutečnosti identifikuje váš systém (viz rámeček) . Kromě vlastních certifikátů musíte mít také veřejný klíč CA, která podepsala váš certifikát. .
Pro získání podepsaného certifikátu se můžete buď zaregistrovat u některé z mnoha CA nebo můžete vystupovat jako vlastní CA. Klienti připojující se k vašemu serveru s podporou TLS musí znát a uznávat CA, kterou jste použili pro potvrzení vaší identity. Obecně je velmi jednoduché v e-mailových klientech přijmout certifikát a přidat veřejný klíč CA do seznamu důvěryhodných autorit, pokud mezi nimi tato CA není.
Krátké seznámení s certifikáty TLS TLS používá pro zabezpečení důvěrnosti komunikace mezi klientem a serverem kryptografii veřejného klíče. Také zajišťuje, že odeslané informace nikdo nezfalšoval, protože tento protokol umožňuje vzájemné ověření klienta a serveru. Samozřejmě mějte vždy na paměti, že jsou výhody TLS omezeny jen na koncové body daného spojení TLS To, co se děje s daty před nebo po předání mezi klientem a serverem, není chráněno TLS .
.
Kryptografie veřejného klíče používá dvojici komplementárních klíčů. Jeden může být veřejně distribuován a druhý je tajný. Data zašifrovaná jedním klíčem mohou být dešifrována druhým klíčem a naopak. Někdo jiný vám může poslat data zašifrovaná vaším veřejným klíčem, která můžete dešifrovat pouze vy pomocí privátrubo klíče. Ve většině implementací může být privátní klíč použit pro vytvoření digitálrubo podpisu bloku dat. Veřejný klíč pak může být použit pro ověření, že daný podpis vytvořil příslušný privátní klíč. Kromě toho je váš privátní klíč asociován s identi fi kátorem označovaným jako ve řejný název (common name) (často se jedná o název hostitele vašeho serveru). Ostatní se mohou ujistit, že je váš server tím, za koho se vydává, porovnáním veřejného názvu (common name) asociovaného s veřejným klíčem a jeho názvu DNS nebo názvu předaného v průběhu navazování spojení. Obecně budete chtít, aby měli všichni váš veřejný klíč, kdežto váš privátní klíč musí být za každou cenu chráněn. Veřejné klíče jsou pro vytvoření certifikátů digitálně podepsané CA. CA jsou obvykle třetí strany, které jsou důvěryhodné pro obě strany. Digitální podpis CA teoreticky označuje, že ověřila identitu držitele veřejného klíče a potvrzuje, že tento veřejný klíč patří tomuto serveru*. Veřejný klíč ověřený CA je často označován za podepsaný certifikát. Certifikátu byste měli důvěřovat pouze pokud důvěřujete CA, která jej vydala. Jediná záruka pochází od CA, která potvrzuje identitu držitele certifikátu.
Veřejné a privátní klíče j sou ve skutečnosti používány pouze na začátku spojení pro určení identit a pro zašifrování náhodně vybraného klíče relace. Tento klíč je pak používán oběma stranami pro šifrování a podepisování zbytku přenosu. Klíč relace může být použit pouze pro jedinou relaci a pak je zrušen. Podívejme se na výměnu dat mezi klíentem a serverem. Klient kontaktuje server a požádá o šifrované spojení. U webu klíent používá https. U pošty klient pošle příkaz STARTTLS, který oznamuje, že si přeje vytvořit ši frované spojení. Server se prokáže tím, že zašle zpět svůj podepsaný certi fikát, který udává jeho veřejný název (common name) a CA, která jej ověřila. Klient ověřuje identitu serveru. Kontroluje, zda je podepisující CA uvedena mezi jeho důvěryhodnými CA a zda je v certi fikátu veřejný název (common name), které očekává. Po kontrole certi fikátu klient a server provedou potvrzení klíče pro vygenerování klíče relace, který má být použit pro tuto výměnu dat a pak zrušen. Způsob potvrzení klíče se liší v závislosti na druhu použité šifry. Komunikace mezi oběma stranami pokračuje s použitím privátního klíče relace pro šifrování a ověřování všech přenosů . • V praxi to bylo jako velmi těžko zvládnutelný aspekt kryptografických systémů s veřejným klíčem
vy
puštěno. Docházelo k mnoha selháním, která odhalila, že by důvěra v důvěryhodnou certifikační autoritu mohla být mylná.
Certifikáty TLS Ú pravy TLS pro Postfix byly napsány s použitím knihoven OpenSSL. Knihovny o b sahují nástroje pro přík azový řádek pro správu certi fikátů, které bu d ete potřeb ovat pro vygenerování certi fikátů. Pro účely Postfixu musí být všechny vaše certi fikáty ve formátu PEM, tj . ve kódovány v b ase64 s nějakými dalšími řádky záhlaví. Výchozím výstupem nástrojů OpenSSL je PEM, takže nebu dete muset vygenerované certi fi káty pro použití v Pos tfixu konvertovat. Nástroje OpenSSL j sou implicitně nainstalovány v adresáři I !lsrl locall ssL Příkaz openssl je nástrojem, který bu dete při správě svých certi fikátů používat nejčastěji.
Vlastní CA Certi fikáty vašeho serveru musí být podepsány nějakou CA . Pro podepsání vašich vlast ních certi fi kátů si můžete jed noduše nastavit vlastní certi fikační autoritu. Distribuce OpenSSL o b sahuje skript, pomocí kterého si můžete nastavit vlastní CA . V domovském adresáři SSL zadejte: • mse/CA . pl -ne.ca
Odpovězte na všechny dotazy. Tím budou nastaveny všechny potřebné soubory pro CA v adresáři .1 demoCA. Poz ději, když spustíte příkaz pro podepsání certi fi kátu, se bu de p říkaz openssl o d kazovat na tyto kořenové certi fikáty.
Generování certifikátů serveru Pro vygenerování veřejného a privátrubo klíče pro váš server můžete použít příkaz openssL Z veřejného klíče vytvoříte požadavek na podepsání certifikátu (CSR, certificate signing request) pro odeslání na CA k ověření. Jakmile je podepsán, může být váš ve řejný certifikát' distribuován, ale vaše privátní klíče musí být pečlivě chráněny. Mnoho aplikací ve skutečnosti ukládá privátní klíče šifrované a vyžadují pro přístup k nim heslo. V Postfixu samozřejmě nemůžete používat šifrované klíče, protože různé komponenty potřebují přístup ke klíčům, když jsou spuštěny démonem masler. Distribuce OpenSSL obsahuje skripty, které vám pomohou vygenerovat klíče a poža davky na podepsání certifikátů, ale tyto skripty klíče implicitně šifrují. Jelikož chcete klíče ponechat nešifrované, použijete příkaz openssl přímo. Pro vytvoření veřejného a privátního klíče pro Postfix spusťte následující příkaz: $ opanlII req -ne. -nedal -keyout mailkey . pem \
-out mailreq . pem -daYI 365
Příkaz openssl s volbou -new vytvoří privátní klíč i CSR. Volba -nodes říká příkazu openssl, aby klíč nešifroval. -keyout a -out udávají názvy souborů pro privátní klíč a CSR. -days 365 nakonec říká, že má být certifikát platný jeden rok. Pokud používáte CA třetí strany, řiďte se jejich pokyny pro podepsání vašeho požadav ku na podepsání certifikátu. Budete odesílat výše vytvořený soubor mailreq.pem. Pokud budete vystupovat jako vaše vlastní CA, můžete soubor podepsat pomocí následujícího příkazu: # openlII ca -out mail_ligned_cert . pem -infilel mailreq . pem
Tím bude vytvořen soubor
mai'-signed_cert.pem, který bude sloužit jako váš podepsaný
certifikát. Pravděpodobně budete chtít zkopírovat všechny soubory certifikátů týkající se Postfixu a TLS do jejich konvenčního umístění. Pokud jste použili všechny výchozí volby, přesuňte soubory certifikátů pomocí následujících příkazů do adresáře s konfigurací Postfixu: # cp /ulr/local/111/mailkey . pem /etc/poltfix
# cp /ulr/local/111/mail_ligned_cert . pem /etc/poltfix
Tyto soubory představují privátní klíč a veřejný certifikát vašeho serveru. Protože jste vytvořili privátní klíč bez jeho zašifrování, musíte jej chránit pomocí práv, která by měla být co nejvíce omezující. Pomocí následujících příkazů zajistěte, že bude jeho vlastru'kem uživatel root a bude jej smět číst pouze on. i chown root /etc/poltfix/mailkey . pem * chmod 4 0 0 /etc/poltfix/mailkey . pem
Instalace certifikátů CA Váš server s Postfixem a TLS musí mít přístup k veřejnému certifikátu CA, která pode psala certifikát vašeho serveru, a všem CA, které podepsaly certifikáty pro vaše uživatele.
Pokud je všechny podepsala jedna CA, potřebujete certifikát pouze jedné CA. Pokud vystupujete jako vaše vlastní CA, zkopírujte soubor cacerl.pem, který byl vytvořen po spuštění skriptu CA.pl: • cp /usr/local/ssl/damoCA/cacart . pem /etc/postfix
Pokud jste použili pro podepsání vašeho veřejného certifikátu CA třetí strany, umístěte veřejný certifikát této organizace ve formátu PEM do souboru I etclpostftxlcacerl.pem. Také budete potřebovat veřejné certifikáty od všech CA, které podepsaly certifikáty klientů, kterým budete důvěřovat. Certifikáty CA mohou být do Postfixu s 1LS přidány dvěma různými způsoby. Prvním je uložení všech certifikátů sp olečně do jednoho souboru definovaného parametrem smt
pd_U s _CAfile. Jednoduše připojíte nové certifikáty ke stávajícímu souboru. Pokud jsou certifikáty vaší CA uloženy například v souboru I etclpostftxl cacerl.pem a máte nový cer tifikát uložený v souboru s názvem newCA.pem, použijte následující příkazy pro přidání nového certifikátu CA: • cp /etc/postfix/cacart . pem /etc/postfix/cacert . pem . old /etc/postfix/cacert . pem
t cat newCA . pem »
(Musíte zadat dvě lomené závorky, abyste s i soubor nepřepsali.)
Jinou možností je ukládání všech certifikátů CA v samostatných souborech. Tato volba trochu zjednodušuje správu certifikátů CA, ale certifikáty nehudou automaticky do stupné pro Postfix v prostředí se změněným kořenovým adresářem. Tuto možnost si pravděpodobně vyberete pokud máte mnoho certifikátů CA. Parametr smtpd_Us_CApath ukazuje na adresář, kde jsou certifikáty CA uložené. Pro přidání dalších certifikátů jed noduše zkopírujte nový soubor certifikátu do tohoto adresáře a spusťte nástroj crehash, který je součástí OpenSSL. Pokud máte například nový certifikát uložený v souboru s názvem newCA.pem a ukládáte všechny certifikáty do adresáře letcipostftxl cerls, použijte pro jejich přidání do Postfixu následující příkazy: # cp newCA . pem /etc/postfix/certs • c_rehash /etc/postfix/certs
Nastavení Postfixu a TLS Ú pravy TLS pro Postf1X přidávají další parametry pro práci s TLS na serveru SMTP. Zde jsou některé důležité parametry TLS, které budete potřebovat pro základní nastavení. Na další parametry se podívejte do vzorového konfiguračrubo souboru, který je obsažen v balíčku úpravy pro TLS .
smtpd_use_U s Zapíná podporu serveru pro 1LS Jinak Postfix pracuje jako bez úpravy 1LS Příklad: .
smtp_use_t I s
=
.
yes
smtpd_t l s_key_fiIe Ukazuje n a soubor obsahující privátní klí č vašeho serveru. Příklad: smtpd_Us_ key_ file =
/etc/postfix/ma i l key . pem
smtpd_t l s_cert_file Ukazuje na soubor obsahující podepsaný certifikát vašeho serveru. Příklad: smtpd_tl s_
cert_file
=
/etc/postfix /mail_s igned_cert . pem
smtpd_t l s_CAfile Ukazuje na,soubor obsahující veřejné certifikáty identifikující certifikační autority, kterým důvěřujete. Přl1clad: smtpd_tl s_CAfile
=
/etc/postfix/cacert . pem
smtpd_tl s_CApath Ukazuje na adresář se soubory s veřejnými certifikáty certifikačních autorit, kterým důvěřujete. Příklad: smtpd_t l s_CApath
=
/etc/postfix/certs
Jakmile nastavíte tyto parametry v souboru main.cfa restartujete Postfix, bude váš server připraven na šifrovaná připojení.
Shrnutí nastavování Postfixu s TLS Zde je souhrn kroků, které je potřeba provést pro nastavení Postfixu pro použití 1LS:
1 . Pokud ještě není nainstalována ve vašem systému, nainstalujte distribuci OpenS SL, kterou budete potřebovat pro vygenerování certifikátů 1LS.
2. Znovu zkompilujte a nainstalujte a PostflX s úpravou pro 1LS (viz příloha C) nebo získejte distribuci PoStflXu, která obsahuje podporu pro 1LS.
3. Vygenerujte certifikáty serveru včetně požadavku na podepsání certifikátu. Pokud vystupujete jako vaše vlastní certifikační autorita, můžete potvrdit požadavek pa podepsání sami, nebo je pro ověření odešlete CA třetí strany. 4. Nainstaluj te své certifikáty (privátní klíč serveru, podepsaný veřejný certifikát
a veřejný certifikát vaší CA) do adresáře Postfixu.
5. V souboru main.if nastavte následující parametry pro 1LS: smtpd_use_t l s
=
yes
smtpd_t l s_key_file smtpd_t l s_cert_file smtpd_tl s_CAfile
=
/etc /pos t fix/ma i l key . pem
= =
/etc /pos t f i x /ma i l_s igned_cert . pem
/etc /pos t f i x / cacert . pem
Pokud chcete nastavit další parametry 1LS, proveďte to zde (viz dokumentace k úpravě pro 1LS) . 6. Restartujte Postfix, aby zaregistroval změny v konfiguračním souboru
main.cf.
• postfix reload
Nyní by měl být váš server schopen odpovídat odpovídajícím způsobem na požadavky klientů na šifrovanou relaci.
Požadavek na certifikáty klientů Namísto jiných technik ověřování SMTP nebo pro jejich doplnění můžete vyžadovat certifikáty na straně klienta. Certifikáty klientů poskytují špičkovou metodu ověřování, kterou může být velmi obtížné obejít. Certifikáty na straně klienta musí být podepsány CA. Pokud plánujete, že budou muset být certifikáty vašich uživatelů podepsané CA třetí strany, měli byste se řídit instrukcemi vaší CA pro vytváření certifikátů pro klienty. Certifikáty klientů můžete také vytvořit a podepsat sami pomocí nástrojů obsažených v balíčku OpenSSL.
Vytváření certifikátů klientů Vytváření klientských certifikátů je stejné jako vytváření certifikátu serveru popsané dříve v této kapitole s přidáním kroku pro převedení podepsaného certifikátu do for mátu, který mohou klienti elektronické pošty importovat. Nejpopulárnější poštovní klienti očekávají certifikáty ve formátu PKCS 1 2, který spojuje dohromady podepsaný certifikát a privátní klíč a chrání je pomocí hesla. Pokud používáte CA třetí strany,po skytne vám tato společnost s největší pravděpodobností pro vaše uživatele správný formát potřebný pro konkrétrubo poštovrubo klienta. Pokud podepisujete certifikáty sami, musíte vytvořit pro uživatele soubor ve formátu PKCS 1 2. Tento soubor j e vytvořen pomocí podepsaného certifikátu uživatele, privátního klíče odpovídajícího tomuto certifikátu a veřejného certifikátu vaší vlastní CA. Pro každého uživatele, který by se měl ověřovat pomocí certifikátu musíte vytvořit samostatnou dvojici certifikát/klíč. Měli byste se dohodnout na zásadách pro volbu jména. Obecně byste použili při generování certifikátů e-mailovou adresu jednotlivce nebo název počítače klienta. Níže uvedené kroky vás provedou vytvářením certifikátu pro uživatele s e-mailovou adresou [email protected]: 1 . Pomocí příkazu opensslvygenerujte privátní a veřejný klíč pro uživatele. Pamatujte si, že váš veřejný klíč musí být také podepsán CA (třeba vámi) : $ openaal req -ne. -nodaa -keyout kdentkey . pem \
-out kdentreq . pem -daya 365
Tento příkaz vytváří privátní klíč i CSR, jak je zadáno volbou -new. Volba -nodes říká openssl, aby klíč nebyl šifrován. -keyout a -out udávají názvy souborů, do kterých by měly být privátní klíč a CSR vytvořeny. Konečně, volba -days 3 6 5 říká, že má být certifikát platný po dobu jednoho roku. 2. Pokud používáte CA třetí strany, řiďte se jejich pokyny pro požadavky na pode psání certifikátu. Budete jim posílat soubor kdentreq.pem, který jste vytvořili výše. Pokud vystupujete jako svá vlastní CA, můžete soubor podepsat sami pomocí příkazu: # openaal ca -out kdent_aigned_cert . pem -infilea kdentreq . pem
3. Jakmile budete mít podepsaný certifikát, převeďte jej d o formátu, který je možno použít v poštovních klientech uživatelů:
t openI81 pkc812 -in kdent 8igned cert . pem -inkey \ Itdentkey . pIII -certfile /e �/po8tťiz/cacert . pIII -out kdent . p12 \ -uport -1lIII8 "kdent@ora . cCIII "
Budete požádáni o zadání hesla pro soubor, který pOKaz vytváří. Budete muset uživa teli poskytnout heslo, které vyberete. Volba -certfile ukazuje na soubor certifikátu vaší vla�tní CA. V tomto příkladu používáte soubor, který byl vytvořen skriptem CA.pl Po skončení můžete předat uživateli soubor kdent.p 12 a heslo, které jste použili při jeho vytváření. Uživatel by měl být nyní schopen importovat soubor do poštovruno klienta, který podporuje formát PKCS1 2.
Nastavení ověřování certifikátem na straně klienta Postfix/TLS používá pro identifikaci přijatelných certifikátů fingerprint certifikátu. Fingerprint je kryptografický údaj vypočtený z podepsaného certifikátu. Fingerprinty všech certifikátů jsou uloženy ve standardní vyhledávací tabulce Postfixu (viz kapitola 4). Když klient předkládá certifikát, Postfix s TLS vypočítává fingerprint z certifikátu a porovnává jej s těmi, které jsou uvedeny v jeho vyhledávací tabulce. Pokud najde odpovídající, umožní klientovi předávat zprávy. Musíte vytvořit fingerprint pro certifikát každého klienta. Mnozí klienti elektronické pošty mohou vytvořit fingerprint za vás nebo, pokud jste certifikát vytvořili, můžete fingerprint jednoduše vypočítat pomocí po'kazu openssl x509: $ open881 z509 -fingerprint -noout -in kdent_8iqnad_cert . pem \
I cut -d= -f2 5 7 : 8E : 9 5 : 6 3 : 6 7 : CD : 2 B : 9 6 : 7C : OA : 3A : 6 1 : 4 6 : A5 : 9 5 : EA
Pro pokračování: 1 . Získejte seznam fingerprintů pro certifikát každého klienta. Můžete je vygene rovat jak bylo popsáno výše nebo je získat od vašich uživatelů, pokud je mohou získat od svých poštovních klientů. 2. Vytvořte soubor pro uložení fingerprintů certifikátů všech klientů. Pro tento poKlad vytvoříte soubor letcipostftxl clientcerls 3. Přidejte do souboru clientcerls všechny fingerprinty. Jelikož je to standardní vyhle dávací tabulka Postfixu, musíte také zadat u každého fingerprintu hodnotu pravé strany, i když se tato hodnota nepoužije. Použijte hodnotu, která vám pomůže fingerprint v budoucnu identifikovat. Váš výsledný soubor by měl obsahovat pro každého uživatele položku jako je tato: 5 7 : 8E : 9 5 : 6 3 : 6 7 : CD : 2B : 9 6 : 7 C : OA : 3A : 6 1 : 4 6 : A5 : 9 5 : EA
4. Spusťte pro soubor clientcerls pOKaz pos/map: * po8tmap /etc/po8tfiz/cliantcert8
5. Přidejte do souboru main.if následující parametry: relay_cl ientcerts
=
hash : / etc/po s t f i x / c l ientcerts
kdent@ ora . com
smtpd_t l s_as k_ccert
=
yes
smtpd_recipient_restrict ions
=
permi t_mynetworks permi t_t l s_c l i entcerts re j ect_unauth_destination
Všimněte si, že smtpd_U s_as k_ccert má dvě "c" pro "client certificate". Pokud máte již nadefinován parametr smtpdJecipientJe s t r i ctions, přidejte per mit_U s_clientcerts do seznamu pravidel omezení. 6. Restartujte Postfix, aby zaregistroval změny v konfiguračním souboru
main.cf.
t postfiz reload
Nastavení klienta TLS/SMTP Jelikož může nastat situace, kdy budou jiné poštovní servery vyžadovat, aby se váš server ověřoval při předávání pošty, může Postfix/TLS také předkládat certifikát, když vystupuje jako klient SMTP. Pamatujte si, že dokud nenastavíte další transporty SMTP v souboru master.1a nenastavíte je, aby používali jiné klientské klíče a certifikáty, jste při nastavování vašeho klienta SMTP omezeni na pouze jeden certifikát. Pokud používáte sebou podepsaný certifikát serveru, můžete použít stejný certifikát a odpovídající privátní klíč jako svůj klientský certifikát. Pokud certifikát vašeho ser veru podepsala CA třetí strany, je možné, že jej bude možno použít pouze pro server SMTP. V takovém případě můžete vygenerovat samostatný klientský certifikát a mít jej také podepsaný. Veřejný název (common name) vašeho klientského certifikátu by měl odpovídat názvu vašeho hostitele jak je zadán v parametru myhostname. Použijte stejný postup jaký jste použili pro vytvoření certifikátů serveru. Pokud používáte stejné certi fikáty, nemusíte dělat nic. Jednoduše nastavte parametry klienta TLS tak, aby ukazovaly na stejné soubory jako parametry serveru. Úpravy Postfixu pro TLS zahrnují následující parametry pro používání TLS v klientu SMTP. Další parametry TLS najdete ve vzorovém konfiguračním souboru, který je obsažen v distribuci TLS: smtp_use_U s Zapíná podporu klienta pro TLS. Jinak Postfix pracuje jako bez úpravy pro TLS. Přľklad:
smtp_use_tl s
=
yes
smtp_t l s_key_fiIe Ukazuje n a soubor obsahující privátní klíč používaný ve spojení s certifikátem klienta. Ph1clad: smtp_t l s_key_fi Ie
=
/etc/postfix/ma i l key . pem
smtp_t l s_cert_fiIe Ukazuje n a soubor obsahující certifikát klienta. Ph1clad: smtp_U s _cert_ file
pos tfix/mai l_s igned_cert . pem smtp_U s _CAfile
=
/ etc/
Ukazuje na soubor obsahující veřejné certifikáty identifikující CA, která podepsala certifikát vašeho klienta. Přl1dad: smtp _t l s _CAfile
=
/etc/postfix/CAcert . pem
Za předpokladu, že používáte stejné certifikáty, jaké jste použili pro váš server, je postup pro zapnutí TLS v klientovi SMTP docela jednoduchý:
1 . V souboru main.ifnastavte následující parametry: smtp_use_t l s
=
yes
smtp_t l s_key_fi l e smtp_t l s_cert_fi l e smtp_t l s_CAfile
=
/etc/postfix/ma i l key . pem
= =
/etc/postfix/ma i l_signed_cert . pem
/etc/pos t f i x / cacert . pem
Pokud chcete nastavit ještě nějaké další parametry TLS, proveďte to zde (viz dokumentace k TLS) .
2. Restartujte PostflX, aby zaregistroval změny v konfiguračním souboru main.cf. t
poltfix reload
Nyní bude PostflX při připojování se k serveru SMTP, který vyžaduje klientské certifikáty, předávat potřebné informace.
KAPITOLA 1 4
Filtrování obsahu
Filtr obsahu je nástroj , který prohlíží záhlaví a tělo e-mailové zprávy a v závislosti na tom, co najde, obvykle provádí nějakou akci. Nejběžnějším přtKladem jsou antivirové programy a programy proti nevyžádané poště. Viry jsou běžně šířeny v obsahu e-mai lových zpráv a pokud nemůžete detekovat nevyžádanou poštu podle připojujícího se klienta nebo informací z obálky, můžete mít větší štěstí při kontrole skutečného obsahu zprávy. Filtry mohou měnit zprávy, přesměrovat je, odpovídat na ně nebo je označit pro pozdější zpracování jiným nástrojem. V této kapitole se budeme zabývat ftltrováním obsahu na poštovním serveru, i když to nemusí být vždy nejlepší volbou pro ftltrování. Filtrování na MTA je vhodné pro ftltrování, kterým by měly projít všechny nebo téměř všechny zprávy. Pokud potřebujete ftltrování, které může nastavovat uživatel, není MTA tou nejlepší volbou. Můžete zvážit jiné druhy ftltrování:
MDA (Mail delivery agent) Konftgurovatelné programy MDA, jako napřtKlad procmail nebo sieve, umožňují uži vatelům spravovat vlastní soubory s nastavením doručování. MDA obecně očekávají, že si uživatelé upraví své konftgurační soubory v systému poštovního serveru. Pokud nemají účty v systému, musíte jim poskytnout jiné prostředky pro nastavení jejich ftltrování, napřtKlad webovou aplikaci.
MUA (Mail user agent) Také můžete zvážit možnost využití výhod ftltrování v e-mailových klientech. Pokud klienti podporují ftltrování, je to skvělý způsob ftltrování podle jednotlivých virtu álních uživatelů, kteří nemají účty v systému vašeho poštovního serveru. Poskytuje výhodu přenesení prohlížení pošty náročného na procesor a paměť ze serveru na více klientů.
Kontrola těla a Záhlaví v Postftxu Kontrola těla a záhlaví v Postftxu poskytuje jen omezené ftltrování. Nemůže být nastavena uživatel, ale její implementace je pravděpodobně nejjednodušší. Informace o jejím nastavení najdete v kapitole 1 1 .
Dobrým kompromisem může být kombinace mtrů MTA a MUA. Filtr MTA může označovat zprávy hodnotou, která je čtena mtry uživatelů v MUA. Uživatelé pak mo hou nastavovat své vlastní mtry pro příjem, odmítání nebo kategorizaci zpráv podle hodnoty příznaku. Nejlepší volbou pro mtrování na MTA je antivirový software. Můžete jej spravovat centrálně a blo kovat viry dříve než se dostanou do sítě. Akce, které by měly proběhnout pro každou zprávu vstupující do systému, je nejlepší provádět na MTA. Kontroly těla a záhlaví Postfixu, i když jsou výkonné, mohou kontrolovat najednou pouze jeden řádek zprávy a j sou vždy aplikovány na všechny zprávy. Neposkytují konvenční způsob nastavení složitých voleb pro odmítání nebo přesměrování zpráv. Cokoliv složitějšího než jednoduché mtrování by pravděpodobně nemělo být prováděno v obecném MTA jako je Postfix. Postfix poskytuje dva přístupy pro nastavování externích mtrů: příkazy, které přijímají obsah e-mailových zpráv na svém standardním vstupu nebo démoni, kteří přijímají ob sah zpráv prostřednictvím SMTP nebo LMTP. Při použití příkazů je pro každou zprávu spuštěn nový proces, který může být náročný na prostředky, zejména pokud má příkaz vysoké nároky na spuštění. Filtry realizované přes démony zůstávají rezidentní a mají potenciál pro vyšší výkon díky použití méně systémových prostředků. Použití démonu je o něco složitější nastavit, ale poskytuje robustněj ší řešení.
Filtrování založené na příkazech Nejjednodušším způsobem nastavení mtrování obsahu je použití programu, který běží jako příkaz a přijímá obsah zprávy na svém standardním vstupu. Postfix doručuje zprávy do vašeho mtrovacího příkazu přes rouru. Váš mtrovací pOKaz provede kontrolu a předá mtrovanou zprávu zpět Postfixu pomocí příkazu sendmaiL Pro tuto chvíli budeme předpokládat, že mtrovací příkaz pracuje s poštou, která přichází přes démon SMTP, ale s poštou, která je doručována místně (pomocí příkazu sendmai�, aby váš mtr mohl používat sendmail pro vrácení zprávy do Postfixu bez vytvoření smyčky. Obrázek 1 4- 1 ukazuje cestu, kterou zprávy prochází jakmile váš mtr zapnete. Správce fronty namísto předávání zprávy doručovacímu agentu spouští mtr. Váš mtrovací program musí být schopen přijmout zprávu na svém standardním vstupu a pak ji doručit do příkazu sendmail serveru Postfix. Pokud máte mtrovací program, který nepracuje se vstupem a výstupem tímto způsobem, mělo by být snadné vytvořit obalující skript shellu pro vyřešení těchto detailů. V distribuci Postfixu je poKlad takového skriptu obsažen v souboru FIL7ER_README.
Nastavení Když nastavujete Postfix pro používání mtrovacího programu, musíte zadat uživatele, pod kterým program poběží. Měli byste vytvořit pseudoúčet, jehož jediným účelem bude spouštět mtr.
..........•
�..
:
E) mtPd d _ _
PosHlx ..........• Správce fronty
... . .......... . ..
........................ , ...•
. . . . . .... . . . . . .. .
I Rt..� I.�·TI.
Obrázek 14- 1. Pnkozprofiltrovánípofly
Vytvořme příklad nastavení a předpokládejme, že máte ftltrovací program s názvem sim ple-filt uložený v adresáři / usr/local/ bin a že jste pro jeho spouštění vytvořili pseudoúčet s názvem ftltr. Přidejte do souboru master. ifpoložku pro váš ftltr: filter
unix
-
n
n
p ipe
f l ags=Rq user=f i l ter argv=/u s r / loca l /b i n / s imple_f i l t - f $ { sende r ) -- $ { recipient )
První řádek obsahuje všechna standardní nastavení pro položku komponentu Postftxu a poslední sloupec řľká, že má být zpráva zpracována démonem pipe systému Postftx. Další řádky jsou pokračováním prvruno, protože mají na začátku prázdné znaky. Ob sahují volby, které služba pipe použije při provádění příkazu. Volby R a q, zadané jako flags, říkají službě pipe, aby na začátek přidala záhlaví Return- Path: a dala do uvozovek prázdné a speciální znaky v adresách $ { sender ) a $ { recipient ) , které jsou předávány příkazu. Další možné volby najdete v manuálové stránce pro pipe ( 8 ) . Volba u s e r= je pseudouživatelem ftltru, kterého nastavujete pro spouštění vašeho flitrovacľho příkazu. Volba argv udává skutečný příkaz společně s jeho parametry pro spouštění. Zde uvedený seznam parametrů (- f $ { sender ) -- $ { recipient ) může být použit skriptem tak jak je pro spouštění příkazu sendmail pro doručení pošty zpět do Postftxu. Váš vlastní flitr může vyžadovat odlišné parametry, ale ujistěte se, že jste zadali položky, které potřebujete pro odeslání zprávy zpět do Postftxu pomocí příkazu sendmail. Proměnná $ { recipient ) je expandována démonem pzpe do více příjemců až do omezení zadaného v parametru fi l ter_destinationJecipient_l imit, pokud má zpráva více než jednoho příjemce. Kromě položky nového komponentu musíte také provést změnu v položce smtpdv sou boru master. ifpro zapnutí ftltrování všech zpráv, které jsou doručeny démonu SMTP: smtp
inet n -o content f i l ter= f i l ter :
n
smtpd
V předchozím příkladu jednoduše přidejte druhý řádek ke stávajícímu řádku smtpd. nezapomeňte uvést na začátku prázdné znaky, abyste označili, že je pokračováním předchozího řádku. Parametr content_filter je nastaven na položku, kterou jste právě vytvořili pro váš ftltrovací program v souboru master.if. Nastavte tuto volbu zde a ne v souboru main.if, protože by měla být použita pouze pro démon smtpd a ne pro všechny zprávy, které vstupují do systému Postfix. Po restartování Postfixu budou všechny zprávy přicházející přes SMTP zpracovávány vaším ftltrovacím programem. Filtr tohoto druhu, ačkoliv je snadné jej nastavit, není nejefektivnější metodou filtrová ní. Vyžaduje, aby Postfix spouštěl shell nebo interpret, a aby filtr spouštěl sendmai/ pro opětovné odeslání ftltrované zprávy. Pokud se váš program dostane do problémů - na přľklad s místem na disku nebo v paměti - neexistuje žádný spolehlivý způsob, jak by mohl nahlásit přesný problém zpět Postfixu. Filtrování založené na démonu popisované v další části nabízí robustnější řešení s vyšším výkonem:
Filtrování založené na démonu Filtrování založené na démonu nabízí vyspělejší architekturu než metoda založená na přľkazech s menšími nároky na vstupy a výstupy a využiti procesoru. Může poskytovat lepší zpracování chyb než ftltrování pomocí příkazu. Pokud je implementováno jako rezidentní proces, je eliminována zátěž spojená se spouštěním pro každou zprávu. Filtrování obsahu založené na démonu si může předávat zprávy s Postfixem pomocí standardrubo protokolu SMTP nebo LMTP. Takový ftltr může běžet jako samostatný démon nebo může být spouštěn PostflXem, pokud je to příslušným způsobem nastaveno v souboru master.if.
. . . . . . . ., . . .
: 25
Postflx
............................. •
. ...
.. .. .. . .. .
.----.
.
1 smt�d 21 ....1
10Q26
Obrázek 14-2. Démon profiltrovánípofty
. Všechno ostatIÚ je stejné. Výkon závisí do značné míry na samotném fIltrovacím programu.
V této konfiguraci chceme, aby filtr obsahu zpracovával všechny zprávy, ať už jsou doručeny fiÚstně (pomocí příkazu sendrnail) nebo do démonu smtpd. Musíte nastavit Postfix v souboru master.if tak, aby používal speciální klientský komponent smtp pro doručování zpráv do vašeho fUtru a další démon smtpd pro příjem zpráv zpět z vašeho fUtru. Obrázek 1 4-2 ukazuje, jak fUtrovaná zpráva prochází Postfixem do vašeho fUtru obsahu a zpět do Postfixu pro doručení. V tomto diagramu fUtr přijímá poštu prostřed níctvím portu 1 0025 na localhost od dalšího klienta smtp a odesílá ji zpět do Postfixu prostřednictvím portu 1 0026 na localhost na další komponent serveru smtpd. Pokud chce filtr zprávu odmítnout, měl by odpovědět kódem SMTP 550 společně s důvodem odmítnutí. Jinak by měl zprávu přijmout a provést své operace před jejím předáním zpět do Postfixu. Pokud váš fUtr zprávu odmítne, Postfix ji pošle zpět na adresu odesílatele se zprávou, kterou poskytl váš fUtr.
Nastavení Pro účely této kapitoly budeme předpokládat, ž e provozujte samostatný démon pro fUtrování obsahu, který čeká na příjem zpráv pomocí SMTP. Po jejím zpracování ji pošle zpět do Postfixu pomocí SMTP. Základní kroky pro nastavení jsou:
1 . Vytvoření pseudoúčtu pro váš ftltr. 2. Instalace a nastavení vašeho ftltru obsahu. 3. Přidání dvou komponent Postfixu do souboru master.if.
4. Přidání parametru contencftlter do souboru main.if. 5. Restartování Postfix, aby zaregistroval změny ve svých konfiguračních souborech. Při nastavování fUtru obsahu založeného na démonu se ujistěte, že nepoužívá stejný název hostitele, jaký je nastaven v Postfixu v parametru myhostname nebo to bude klient SMTP Postfixu považovat za chybu a nedoručí zprávu do fUtru. Zbytek této části vás provede podrobnostmi nastavování fUtrování obsahu založeného na démonu.
Vytvoření pseudúčtu Jako u jednoduchého fUtrovacího řešení popsaného výše, i zde byste měli vytvořit pseu doúčet pro váš fUtr. Ú čet by neměl mít přístup k jiným prostředkům vašeho systému. Pokud váš fUtr potřebuje provádět zápis do souborů, měli byste pro tento účel vytvořit adresář. Váš ftltr by měl být spuštěn jako daný uživatel nebo by měl být nastaven tak, aby se po spuštění stal tímto uživatelem. Podívejte se na konfigurační volby vašeho filtru. Pro tento příklad budeme předpokládat, že jste vytvořili uživatele fUtr.
Instalace filtru obsahu Balíček vašeho fUtru by měl obsahovat instrukce pro instalaci a nastavení. V tomto pří kladu budeme předpokládat, že fUtr naslouchá na portu 1 0025 rozhraní loopback. Po zpracování zpráv by je měl fUtr předávat zpět do Postfixu na portu 1 0026. Měli byste
být schopni ftltr odpovídajícím způsobem nastavit nebo, pokud váš ftltr naslouchá na jiném portu nebo odesílá na jiný port, to mít na paměti při procházení tímto přľkladem. Pokud je to možné, nejprve svůj ftltr otestujte, abyste se ujistili, že pracuje správně dříve než se jej pokusíte připojit k PostflXU.
Nastavováni dalších komponentů Postfixu Při vytváření dalších komponentů SMTP se můžete setkat s problémy "mail loops back to myself" . Jedním z řešení je přidělení jiné hodnoty myhostname pro další komponenty. Přidejte potřebné nové komponenty do souboru master.if. Druhý komponent smtp bude použit pro odesílání zpráv do vašeho ftltru (více informací o úpravách souboru master.cf najdete v kapitole 4) . Tuto další položku smtp nazveme chkmsg: chkmsg
smtp
10
n
unix -o myhos tname=localhost
Později, až zapnete ftltrování obsahu v souboru main.cj, řeknete Postfixu, aby posílal zprávy do vašeho ftltru na port 1 0025 pomocí tohoto komponentu. Kromě dalšľho klienta smtp také potřebujete další službu smtpd pro příjem zpráv od vašeho ftltru. Druhá instance smtpd je nastavena trochu jinak než ta normální, protože chcete, aby PostflX zpracovával provoz od vašeho ftltru jinak než zprávy přicházející zvenčí. Nastavte volby pro položku takto: 10calhost : 1 0 0 2 6
inet n -o content f i l ter=
n
10
smtpd
-o local_recipient_maps= -o mynetworks= 1 2 7 . 0 . 0 . 0 / 8 -o smtpd_helo_re s t r i ctions= -o smtpd_c l i ent_restrictions= -o smtpd_sende r_re strictions= -o smtpd_recipient_re strictions=permi t_mynetworks , rej ect
Tato instance smtpd je nastavena tak, aby naslouchala na portu 1 0026 rozhraní loopback. Nastavíte váš ftltr tak, aby odesílal zpracované zprávy na tuto službu. V tomto poldadu je několik voleb, které potlačují nastavení ze souboru main.cf a jsou vysvětleny níže: content filter
Implicitní instance smtpd má zapnuté ftltrování obsahu v souboru main.if. Pro tuto instanci smtpd by nemělo být nastaveno ftltrování obsahu. local_recipient_maps
Některé vyhledávací mapy konvertují adresu, pokud je zpráva přijata externím smtpd. Když se váš filtr pokusí o její opětovné vložení, Postfix nemusí poznat příjemce a může zprávu odmítnout. Nastavte tuto volbu na prázdný řetězec, aby byly filtrované zprávy vždy přijaty. mynetworks
Jelikož váš ftltr běží na stejném systému jako Postfix, mohou ftltr s Postfixem komu nikovat přes místní rozhraní loopback, což je pseudozařízení, které není asociováno
s žádným skutečným hardwarovým rozhraním. Rozhraní loopback vždy používá adresu 1 27.0.0. 1 . Jelikož je první bajt adresy 1 27, jde o síť třídy A, kterou můžete zadat prefixem sítě /8. Díky nastavení mynetworks na síť loopback a nastavení smtpd_recipient_restrictions pro povolení pouze této sítě tato instance smtpd přijímá připojení pouze od vašeho filtru a není vystavena žádnému (potenciálně nebezpečnému) provozu ze sítě. smtpd_helo_re strictions , smtpd_cl ient_restriction s , smtpd_sender_restrictions
Omezení, která jsou kontrolována již původní instancí smtpd, můžete vypnout. Pokud tato omezení v souboru main.ifnepoužíváte, nemusíte je zde vypínat. smtpd_recipient_restrictions
Nakonec řeknete smtpd, aby přijímal připojení na rozhraní loopback a odmítal všechna ostatní.
Zapnutí filtrování Po provedení potřebných změn v souboru master.ifmusíte nastavit PostflX pro předávání všech zpráv, které přijme, do vašeho ftltru. Přidejte do souboru main.iftento řádek: content_f i l t e r
=
chkmsg : [ 1 2 7 . 0 . 0 . 1 ] : 1 0 0 2 5
Tento parametr říká Postfixu, aby předával zprávy do ftltru prostřednictvím služby chkmsg, kterou jste vytvořili v souboru master.if. Také mu řeknete, aby odesílal zprávy na port 1 0025, který by měl odpovídat nastavení vašeho futru. Nezapomeňte restartovat Postfix, aby zaregistroval změny v konfiguračních souborech. Postfix po restartu začne předávat všechny zprávy vašemu ftltru pro jejich zpracování.
Příklad filtru založeného na démonu Pro předvedení nastavování ftltru obsahu založeného na démonu vás tato část pro vede instalací programu Vexira AntiVirus od Central Command. Vexira je komerční antivirový produkt, který je k dispozici na webu Central Command na adrese http:/ / www.centralcommand.com/. Jejich produkt Vexira AntiVirus for Mail servers je napsán tak, aby fungoval kromě jiných MTA i s PostflXem. Je k dispozici pro platformy Linux, FreeBSD a OpenBSD. Pokud používáte jiné antivirové řešení založené na démonu, mělo by být nastavování podobné zde uvedenému postupu: 1 . Nainstalujte Vexira podle dokumentace od Command Central. Zbytek tohoto postupu předpokládá, že jsou vaše konfigurační soubory podle pokynů k instalaci v adresáři / etc. 2. Nastavte program Vexira tak, aby naslouchal na portu 1 0024 rozhraní loopback. V souboru / etc/ vamailarmor.confnastavte parametr ListenAddre s s takto: L i s tenAddre s s localhost port 1 0 0 2 4
3. Také nastavte parametr ForwardTo pro předávání zpráv zpět do Postft.xu přes port 1 0025 rozhraní loopback: ForwardTo SMT P : localhost port 1 0 0 2 5
4 . Restartujte program Vexira pomocí metod nebo skriptů nainstalovaných ve vašem
systérpu. Podívejte se do dokumentace programu Vexira.
main.cf odesílání všech zpráv do démonu Vexira pro vyhle dávání virů. Nastavte parametr content_ filter takto:
5. Nastavte v souboru
content_fi l ter = smtp : [ 1 2 7 . 0 . 0 . 1 ) : 1 0 0 2 4
6. Přidejte d o souboru Postftxu masler.cf další démon SMTP pro příjem zpráv od programu Vexira po vyhledávání virů: localhost : 1 0 0 2 5
inet
n
n
10
smtpd
-o content f i l ter= -o local_recipient_maps= -o mynetworks= 1 2 7 . 0 . 0 . 0 / 8 - o smtpd_helo_restrictions= -o smtpd_c l ient_restrict ions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permi t_mynetwor k s , rej ect
7. Restartujte Postft.x, aby zaregistroval změny v konft.guračních souborech: f postfiz reload
Další informace Více flitrů obsahu můžete provozovat jejich zřetězením. Pokud máte například antivirový program i flItr nevyžádané pošty, jednoduše nastavte první program tak, aby předával zprávy druhému programu a ne zpět do Postftxu. Konft.gurace Postft.xu se nemusí měnit. Postft.xu bude vracet zprávy poslední mtr. Pamatujte na případné přepisování adres před předáním zprávy mtru. Když mtr zprávu odešle a přepsaná adresa není v mapách příjemce, Postft.x ji odmítne. Možná budete muset vypnout přepisování adres na vašem normálním serveru SMTP a místo toho ho zapnout na serveru SMTP, který přijímá zprávy vrácené mtrem. Pro některé flitry je doporučeno, abyste je nastavili pro příjem pošty před vaším normál ním MTA a předávali zprávy na váš MTA až po zpracování. To není nejlepší řešení. Po stft.x je navržen speciálně pro příjem zpráv z nepřátelské sítě a mtr je navržen speciálně pro zpracování obsahu zpráv a pravděpodobně není optimalizován pro vysokou zátěž a potenciální rizika spojená s akceptováním připojení zvenku. Podobně chtějí některé mtry provádět konečné doručování zpráv bez jejich opětovného vložení do Postft.xu. Opět, Postft.x poskytuje značnou flexibilitu a bezpečnost při práci s konečným rozdě lováním zpráv, které byste mohli ztratit delegováním doručování na jiný balíček.
KAPITOLA 1 5
Externí databáze
Soubory map Postftxu jsou jednoduchým a efektivním mechanismem pro mnohé operace vyhledávání potřebné při zpracování pošty. V mnoha situacích může být samozřejmě mno hem vhodnější mít informace uložené v databázi oddělené od Postftxu. Databáze může sloužit jako centrální úložiště pro mnoho systémových nebo síťových služeb, které potře bují podobné informace, jako např.íklad názvy účtů a hesla. Databáze může být užitečná pokud další systémy s Postftxem potřebují sdílet stejné informace o nastavení. Centrální databáze může být také vhodnější pokud musí upravovat informace mnoho lidí. Databáze mohou také v porovnání s běžnými soubory snížit výkon Postfixu. Pokud nemáte potřebu databáze, bude obecně lepší, když vystačíte se standardními mapami Postfixu. V mnoha případech můžete využít výhod obou možností uložením informa cí do databáze a pravidelným spouštěním skriptů, které budou aktualizovat soubory Postfixu z centrálruno úložiště dat. Ale pokud vaše prostředí vyžaduje neustálý přístup k upraveným datům, může být externí databáze jedinou možností. V této kapitole se podíváme na nastavení Postfixu pro spolupráci s databázemi MySQL a LDAP (postfix má od verze 2.1 podporu i pro PostgreSQL) . V každém případě musí být Postfix zkompilován s dalšími knihovnami pro podporu map uložených v mysql a ldap. Pokud používáte zkompilované balíčky, ujistěte se, že obsahují podporu pro typ databáze, který chcete použít. Pokud Postfix kompilujete, podívej te se do přílohy C na informace o kompilování s dalšími knihovnami. To, zda vaše instalace Postfixu obsahuje podporu pro LDAP a MySQL, můžete jedno duše zjistit pomocí příkazu postconf -m: $ postconf statie pere regexp
mysql environ proxy
ldap btree unix hash
-m
Mezi druhy map byste měli najít ldap nebo mysql. I když může databáze, kterou používáte společně s Postfixem, obsahovat různé in formace, funguje stejně jako mapy Postfixu. Máte klíč, například e-mailovou adresu příjemce, a očekáváte, že obdržíte nějakou hodnotu spojenou s tímto klíčem, jako na příklad adre �u pro další předávání pošty. Jak toho docílit pomocí obou druhů databází, MySQL i LDAP, je vysvědeno v dalších částech této kapitoly. Je dobré se ujistit, že vaše vyhledávání pracuje správně s běžnými vyhledávacími tabulka mi Postfixu. Pak nastavte vyhledávání na MySQL nebo LDAP a ujistěte se, že obdržíte stejné výsledky. Postfix ve většině případů očekává, že vyhledávání vrátí pouze jedinou hodnotu. Ujistěte se, že vaše dotazy na databázi nevrací více hodnot.
MySQL MySQL je open-source relační databáze, která používá jazyk SQL (Structured Query Lan guage) pro dotazy na data a pro správu dat. Abyste mohli používat Postfix v kombinaci s MySQL, nemusíte umět SQL, ale pomůže vám to pochopit jejich spolupráci. Normálně byste použili MySQL, protože již máte databázi informací o každém uživateli, jako napří klad celé jméno, název účtu, telefonní čísla atd. Musíte se ujistit, že vaše databáze obsahuje informace, které potřebujete pro dosažení konkrétní úlohy s Postfixem. Běžným způsobem použití je mapování e-mailových aliasů na název místruno účtu. Aby to fungovalo, musíte mít jeden sloupec databáze obsahující e-mailové aliasy a další s názvy místních účtů. Postfix může provádět dotaz na databázi s adresou příjemce jako klíčem pro vyhledání místruno účtu pro doručení. Všechny parametry vyhledávacích tabulek Postfixu umí pracovat s do tazy MySQL. Musíte jen zadat, které sloupce obsahují potřebné informace.
Konfigurace MySQL Mapy MySQL j sou zadávány jako všechny ostatní mapy v Postfixu. Zadáte druh mapy a soubor obsahující mapování. V případě MySQL není soubor, který zadáváte, samozřejmě samotnou vyhledávací tabulkou, ale místo toho tento soubor obsahuje informace o nastavení, které určuje, jak získat požadovanou hodnotu z databáze: a l i a s_maps
=
mysql : / etc /pos tfix/mysql - a l iases . c f
Soubor mysql-aliases.cj obsahuje konfigurační informace o tom, jak získat informace z MySQL. Parametry pro tento soubor jsou vysvědeny níže.
Parametry MySQL Parametry MySQL poskytují informace, které Postfix potřebuje pro připojení k vašemu databázovému serveru a vytvoření příkazu SQL pro vyhledání potřebných informací. Tyto parametry jsou umístěny v konfiguračním souboru mapy MySQL, který funguje jako konfigurační soubor Postfixu s ignorovanými prázdnými řádky a komentáři. Ko mentáře jsou označeny # jako prvním znakem řádku. Můžete mít stejný počet konfi-
guračních souborů MySQL jako normálních vyhledávacích souborů PostfIxu. Všechny parametry MySQL zde uvedené jsou povinné, s výjimkou addi t ional_condi tions. Na obrázku 1 5- 1 je znázorněn příkaz SQL, který Postfix vytváří pomocí popisovaných parametrů.
Tabulka
L-��_�
WHERE
L...--T--...J
FROM L
_ _ _
,
' kdt'
��...J
" ' -AN-O-ty-p-e-=-'f-orw-ar-d'
Pole_ where
I
Da/�fpodmfnky
Obrázek 15· 1. Vzorotj pf/koZ SQL
hosts Seznam názvů hostitelů nebo adres IP, kde běží server MySQL. Také můžete zadat socket unixové domény uvedením unix : před cestou k socketu. Název více než jednoho hostitele nebo socketu byste měli uvádět pouze pokud máte více redun dantních databázových serverů. Dokud není dotaz proveden úspěšně, je v uvedeném pořadí zkoušen každý z hostitelů. Například: hosts
=
unix : / tmp/mysql . sock, db . example . com, 1 92 . 1 6 8 . 1 5 0 . 1 5
user Název účtu, který má být použit pro přihlášení do databáze MySQL.
password Heslo, které má být použito pro přihlášení do databáze MySQL.
dbname Název databáze, která má být použita pro dotaz.
table Název tabulky, která má být použita pro dotaz.
select field Název sloupce, který obsahuje hledanou hodnotu.
where field Název sloupce, který obsahuje hodnotu klíče.
addit ional condi tions Další porovnání pro klauzuli WHERE příkazu SQL vytvářeného PostfIxem. Abyste mohli použít tento parametr, musíte znát SQL. Nastavte tento parametr jako kdy byste pokračovali v příkazu SQL. Například: addi t i onal_condi tions
=
and mai l_type
=
' local '
Příklad pro MySQL Projděme si př11dad ilustrující konfiguraci MySQL a Postfixu. Server example.com pou žívá server MySQL pro správu všech uživatelů v jeho síti. Je v něm databáze obsahující různé informace o uživatelích v síti, včetně jmen, telefonních čísel, atd. Mezi ostatními tabulkami v'databázi je jedna s názvem emai l_address, která obsahuje potřebné infor mace pro nastavení Postfixu. Struktura tabulky vypadá takto: Fie1d
Nu I I
Type
Key
Defau 1 t
Extra
PRr
loca1part
varchar ( 1 5 )
type
varchar ( 1 5 )
YES
NULL
to addres s
varchar ( 6 5 )
YES
NULL
password
varchar ( 6 5 )
YES
NU LL
1ast changed by
varchar ( 1 5 )
YES
NULL
Tato tabulka obsahuje všechny e-mailové adresy, pro které by měl Postfix přijímat poštu, se sloupcem localpart obsahujícím místní část adresy. Někteří z uživatelů používají své primární e-mailové účty na jiných systémech, takže jsou jejich adresy example.com aliasy, které předávají zprávy jinam na jejich primární e-mailové adresy. Sloupec type ř1'ká, zda je adresa doručována místně nebo předávána na jinou adresu. Hodnota for ward informuje, že jde o alias. Pokud je pošta pro nějakou adresu přávána dál, obsahuje sloupec to_addres s cílovou adresu. Tabulka 1 5-1 obsahuje přístupové údaje potřebné pro nastavení Postfixu v tomto pří padě. Před nastavováním Postfixu byste měli shromáždit stejné informace o vaší vlastní databázi. Tablllka 15·1. Informace o databázi MySQLpro nastavení Postftxu Přístupové údaje:
Hodnoty
Hostitel
mysql.example.com
Název databáze
user_acoounls
Tabulka databáze
emaiLaddress
Uživatel databáze
kdent
Heslo uživatele
Rumpelstillskin
Kromě obecných informací o databázi uvedených v tabulce 1 5-1 budete muset zadat sloupce, které potřebujete pro konkrétní mapy Postfixu, které nahrazujete vaší tabulkou MySQL. Př11dad 1 5-1 ukazuje vzorový záznam z databáze se sloupci relevantními pro tuto konfiguraci. V tomto příkladu budete nastavovat parametry Postfixu local_ reci pient_maps a alias_maps . Pfíklad 15· 1. VzorO/ý záif1am Z tablllk;y emaiLaddress to addres s ky1e . dent@ora . com
Konfigurace locaUecipienCmaps Parametr local_ recipient_map s ukazuje na seznamy místních uživatelů, kteří by měli přijímat poštu na tomto systému. Implicitně ukazuje na uživatelské účty a aliasy v sys tému, aby byla pošta poslaná na neexistujícího uživatele serverem SMTP odmítnuta. Tato vyhledávací mapa je trochu odlišná od jiných v tom, že pro mapování nevyžaduje návratovou hodnotu. Záleží pouze na tom, zda příjemce ve vyhledávací tabulce je nebo není. V tomto příkladu databáze MySQL obsahuje seznam všech poštovních účtů, které by měly přijímat poštu na tomto systému. Parametr local_ recipient_map s můžete na stavit na konfiguraci MySQL, která načítá seznam uživatelů pošty. Pro nastavení dotazu použijete soubor mysql-locaLcf. Nejprve nastavte parametr local_recipient_maps tak, aby ukazoval na konfigurační soubor dotazu a byl nastaven druh dotazu na mysql : loeal_reeipient_maps
=
mysql : /ete/po s t f i x /mysql -Ioea l . e f
Soubor mysql-locaLcf obsahuje parametry pro všechny položky uvedené v tabulce 1 5- 1 plus select_f i e l d a where_f i e l d pro tento konkrétní dotaz: jl • mysql -Ioea l . e f - loeal reeipients for ma i l server . • hosts user
mysql . exampl e . eom
=
kdent
=
pas sword dbname table
= =
=
Rumpe l s t i l t skin
user aeeounts ema i l addre s s
seleet_field where_f ield
= =
l oealpart loea lpart
Parametry select_ field a where_ field se oba odkazují sloupec localpart. Parametr select_ field v tomto případě není nijak zvlášť důležitý, jelikož nepotřebujete vracet hodnotu z mapy. Parametr addi tional_condi tions nepotřebujete, protože chcete každý záznam v tabulce. Po restartování bude Postfix používat nastavení MySQL pro určo vání místních uživatelů a odmítání pošty pro příjemce, kteří nejsou uvedeni v tabulce MySQL. Konfigurační soubor MySQL můžete zkontrolovat jednoduše příkazem pos/map: $ postmap -q ' kdent ' mysql : /etc/postfix/mysql-local . cf kdent
Volba -q říká příkazu pos/map, aby provedl dotaz na mapu pro daný klíč. Pokud má váš dotaz problémy, pos/map je nahlásí na terminál.
Nastavení alias_maps Někteří uživatelé nepřijímají poštu na tomto systému, ale je předávána na jiný účet. Nastavením alias _maps na jinou konfiguraci MySQL můžete získat seznam uživatelů, kteří mají aliasy a zjistit, kam se má pošta předávat. Pro tuto konfiguraci dotazu použi-
jete soubor mysql-alias.cf. Nejprve nastavte parametr alias_maps tak, aby se odkazoval na soubor s konfigurací dotazu: a l i as_maps
=
mysql : / etc/po s t f i x /mysql-a l i a s . c f
Soubor mysql -a l i a s . cf obsahu j e následuj ící parametry :
• • mysql-al i a s . cf - forwarding a l i a s e s t hosts
user
mysql . example . com
=
kdent
=
pas sword dbname table
= =
=
Rumpe l s t i l t s k i n
user accounts ema i l addre s s
select f i e l d -
where_field
=
=
to addre s s -
l ocalpart
addi tional_condi tions
=
and t ype
=
' forward '
V tomto případě nastavujete select_ field na to _address, jelikož toto je hodnota, kte rou alias_maps potřebuje pro předávání zpráv. Také jste zadali addi tional_condi tions, protože chcete pouze adresy, které mají aliasy. Po restartu bude Postfix používat tuto konfiguraci MySQL pro zjišťování adres s aliasy a adres pro předávání pošty.
Nastavování virtuálních domén Databáze MySQL jsou často používány servery, na kterých je umístěno mnoho virtu álních domén. Tento poslední přľklad MySQL vás provede nastavováním virtuálních domén. Přečtěte si v kapitole 8 obecné informace o virtuálním hostingu, jelikož se tato část zabývá pouze nastavením MySQL. V tomto poKladu budete používat tabulku s názvem emai l_address z databáze customer. Tato tabulka obsahuje záznamy pro všechny virtuální adresy ze všech domén, pro které systém přijímá poštu. Obsahuje následující pole, která nás zajímají: domain
Název virtuální domény pro tento záznam. mai l addres s
Veřejná e-mailová adresa, n a kterou mohou být zprávy odesílány. Zprávy jsou do ručovány do místního virtuálrubo úložiště pošty. mai lbox
Obsahuje název souboru pro doručování do místrubo úložiště pošty. Název by měl být uveden relativně k cestě nastavené v vi rtual_mai lbox_base. Za názvem můžete uvést lomítko pro použití formátu maildir. PoKlad 1 5-2 ukazuje vzorový záznam z databáze s relevantními sloupci.
Pfíklad 15-2. Vzororý zá�am pro alias virtuální schrán-9 doma in
ma i l addre s s
ora . com
kdent @ora . com
mai lbox ora . com/ kdent
V tomto příkladu všechno virtuální doručování probíhá pod stejným uživatelem a sku pinou: vma i l : vmai l . Pokud potřebujete jiného uživatele nebo jinou skupinu pro různé uživatele nebo domény, měli byste mít v tabulce další sloupce pro uid a gid a pak pro ně také vytvořit mapy mysql. Pro doručování používáte statický identifikátor uid a gid a vaše úložiště pošty je jedno duše adresářem v místním systému souborů: virtual mai lbox base -
-
=
/usr/ local/vma i l
virtual_u id_maps
=
static : l 0 0 3
virtual_gid_maps
=
static : l 0 0 3
Seznam virtuálních domén a mapy schránek pochází z e dvou konfiguračních souborů MySQL: virtua l_ma i l box_doma ins virtua l_ma i lbox_maps
=
=
mysql : / etc/postfix /virtua l_domains . c f
mysql : /etc/pos t f i x /vi rtua l_ma i lboxes . c f
Konfigurace virtuaLmailboxes.cjmapuje e-mailové adresy na úložiště pošty, kam by měly být zprávy doručeny: hosts user
mysql . example . com
=
kdent
=
pas sword dbname table
= =
=
Rumpe l s t i l t s kin
customer ema i l addre s s
select f i e l d where field -
=
=
mai l box ma i l address -
LDAP LDAP je protokol, který poskytuje přístup do adresářů s informacemi. Adresáře LDAP se skládají z položek, které jsou organizovány hierarchicky. Abyste mohli LDAP používat v Postfixu, musíte vědět, jak LDAP pracuje a jak je váš adresář organizován. Mnoho sítí začíná používat LDAP pro informace o uživatelích, což zjednodušuje PostflXU určování, pro které uživatele a adresy by měl přijímat poštu. Pokud vaše organizace používá adresář LDAP, můžete se dotazovat na stávající informace z Postfixu.
Konfigurace LDAP Mapy LDAP jsou zadávány druhem mapy ldap a mohou být uvedeny společně s jiný mi mapami pro daný parametr. Na rozdíl. od MySQL jsou parametry LDAP všechny uvedeny v souboru main.if. Musíte si vymyslet název pro konkrétní konfiguraci LDAP,
kterou vytváříte a zadat ji s druhem mapy ldap. Pokud nazvete vaši konfiguraci LDAP napřHclad ldapal iases, nastavte vaše mapy aliasů jako: a l i a s_maps
=
l dap : ldapal iases
Parametry LDAP pro tuto konfiguraci začínají všechny názvem, který jste si vymysleli, následovanÝJ11 názvem parametru. Server LDAP je zadán parametrem název_server_ host, takže pro výše uvedený přľklad je parametr s názvem l dapal iases _ server_host: l dapa l iases_server_hos t
=
l dap . example . com
Důležité parametry LDAP j sou definovány níže. Kompletní seznam je k dispozici v souboru LDAP_README obsaženém v distribuci Postfixu: název seareh base -
-
Základní DN, od kterého se má začít hledat. Musíte znát kontext pojmenovávání vašeho adresáře, abyste mohli zadat společný kontejner pro vaše položky. Č asto je jím kořenový adresář. Př.fklad: ldapaliases _seareh_base = de=example, de=eom název_ seope Rozsah hledání. Pro rozsah jsou možné tři volby: sub, base a one. Hierarchie vašeho adresáře určuje, kterou hodnotu potřebujete. Volba base je málokdy užitečná. Při sub je prohledáván celý strom pod základním adresářem a při one jsou prohledávány pouze podřízené uzly. Výchozí hodnotou parametru _ s eope je sub, pokud nezadáte jinou. Příklad: ldapaliases _ seope = one název_query_filter Atributy a hodnoty, které by měly tvořit váš mtr pro vyhledávání. Jako zástupný symbol pro e-mailovou adresu aktuálruno příjemce můžete použít proměnnou % s . Pb1clad: ldapal iases_query_fi l ter = (ma i IType=forward) název result attribute -
-
Atribut obsahujfcí hodnotu, kterou chcete vrátit pro toto vyhledávání. Můžete uvést vfce atributů v pořadí jejich preference. Pb1clad: ldapal iases_result_attribute email , rfe82 2Mai lbox.
Příklad pro LDAP Běžným použitim LDAP v Postfixu je ochrana interruno poštovruno serveru v síti, která používá adresář LDAP s účty uživatelů. Postfix je umístěn na systému brány, přijímá zprávy z internetu a předává je internímu poštovnímu serveru. Chcete, aby Postfix odmítal zprávy pro neexistující uživatele sítě, aby nebyly nikdy přijaty do vaší sítě. Nastavením parametru loeal Jeeipient_maps na dotaz na adresář LDAP můžete nastavit Postfix tak, aby věděl o všech uživatelských účtech a mohl odmítat zprávy pro neexistující účty. Ve velké síti může být vfce poštovních systémů sloužících pro různé skupiny uživatelů. Také můžete nastavit Postfix tak, aby předával zprávy pro konkrétruno uživatele na správný poštovní server nastavením transport_maps směrujícím e-mailové adresy na správné interní poštovní servery.
Adresář LDAP obsahuje atributy pro ma i l a ma i lHost, kde ma i l obsahuje veřejnou e-mailovou adresu uživatele a mai lHost je interní server, na který by měly být zprávy předávány. Vzorová položka v adresáři vypadá takto: dn : uid=kden t , ou=peop l e , dc=examp l e , dc=com uid : kdent cn :
Kyle D. Dent
ma i l : kyle . dent @example . com uidNumber : 1 0 0 1 gidNumbe r : 1 0 0 1 ma i l Ho st : ma i l 1 . example . com homeDi rector y : /home / kdent mai l Type : forward obj ectC l a s s : people userPas sword : ( c r ypt } hidden accountStatus : act ive
Tabulka 1 5-1 obsahuje informace o adresáři LDAP, které potřebujete pro nastavení Po stfixu v tomto případě. Před nastavováním Postfixu byste si měli opatřit název hostitele a základní DN vašeho vlastrubo adresáře. Tabulka 15-2. Informace o adresáti WAPpro nastavování Posifixu Informace o adresáři
Hodnoty
Host
Idap.example.com
Base ON
dc=example,dc=com
Pro vyhledávání local_ recipient _maps musíte pouze vědět, že daná adresa existuje v atributu mai l . Pro předávání zpráv na správný interní poštovní server potřebujete hodnoty z atributu mai lHost.
Nastavování locaUecipienCmaps Parametr localJecipient_maps se odkazuje na seznamy místních uživatelů, kteří by měli přijímat poštu na tomto systému. Implicitně se odkazuje na uživatelské účty a aliasy, které existují v systému, aby byla pošta pro neexistující uživatele Postfixem odmítnuta. V tomto přľkladu adresář LDAP obsahuje seznam všech e-mailových účtů, které by měly přijímat poštu na tomto systému. Můžete vytvořit vyhledávací mapu Idap pro local_re cipient_maps. V případě local_recipient_maps není vrácená hodnota použita k ničemu, protože jen potřebujete vědět, zda e-mailová adresa existuje či nikoliv. Použijte konfi guraci LDAP s názvem "ldaplocal". Nejprve nastavte parametr local Jecipient_maps tak, aby používal tuto konfiguraci: loca l_recipient_maps = ldap : ldaplocal Zbytek parametrů LDAP pro tuto konfiguraci je nas taven takto : ldaplocal_se rver_ho st = ldap . example . com l daplocal_sea rch_base = dc=examp l e , dc=com ldaploca l_query_f i l ter = ( & (mai l =% s ) ( accountStatus=active ) ) l dapl ocal_re sul t_att ribute = uid
Parametr ldaplocal_query_ f i lter porovnává e-mailovou adresu příjemce s atributem
mai l
v
adresáři. Také kontroluje, zda je atribut accountStatus nastaven jako aktivní.
Výsledný atribut je nastaven na uid. Pro toto vyhledávání potřebujete vědět pouze to, že položka existuje, ale Postfix vyžaduje neprázdný výsledek vyhledávání. Postfix po rc; startu používá konfiguraci LDAP pro zjišťování místních uživatelů a od mítání pošty pro příjemce, kteří nej sou uvedeni v adresáři LDAP. Konfigurační soubor LDAP můžete snadno zkontrolovat pomocí příkazu postmap: $ postup -q
I
kdenť
ldap : lclaplocal
kdent
Volba -q říká příkazu postmap, aby se dotazoval mapy na daný klíč. Pokud má váš dotaz nějaké problémy, bude je postmap hlásit na terminálu.
Nastavení transport_maps Pokud zprávy přijaté Postfixem musí být předávány na spráný interní poštovní server, použijte transport_maps. Nastavte parametr transport_map s tak, aby používal novou konfiguraci LDAP s názvem "ldaptransport": transport_maps = ldap : ldapt ransport
Protože adresář LDAP vrací pouze název hostitele a vy potřebujete hodnotu transpor tu (transport : nexthop), můžete použít parametr _result_f i l ter pro zadání šablony výsledků: l daptransport_result_f i l t e r = relay : % s Také nastavte následuj ící parametry : ldaptransport_server_hos t = ldap . example . com ldapt ransport_search_base = dc =examp l e , dc = com ldapt ransport_query_filter = ( & (ma i l = % s ) ( accountStatus=active ) ) ldaptransport_result_attribute = ma ilHost
Parametr ldaplocal_query_ f i l ter znovu porovnává e-mailovou adresu příjemce s atri butem ma i l v adresáři a kontroluje, zda je atribut accountStatus nastaven jako aktivní. Výsledným atributem je hodnota atributu ma i lHost, kterou je poštovní server, který by měl přijímat zprávy pro daného uživatele. Výsledek je expandován v šabloně dané v ldaptransportJesult_ f i l ter. Aby byla použita nová transportní mapa ldap, restartujte Postfix.
PŘíLOHA A
Konfigurační parametry
Tato příloha obsahuje abecední seznam parametrů obvykle nastavovaných v souboru main.if serveru Postfix. Krátké popisy jsou uvedeny pouze proto, abyste se seznámili s účelem parametru. Všechny tyto parametry jsou plně zdokumentovány ve vzorových konfiguračních souborech a manuálových stránkách obsažených v distribuci Postfixu. Tato krátká referenční příručka vás může navést správným směrem, ale abyste pochopili to, jak tyto parametry fungují, se budete muset podívat do textu této knihy nebo online dokumentace. U všech těchto parametrů je uvedeny typ hodnoty, která by mu měla být přiřazena. Většina z těchto typů hodnot je samozřejmá. Ty, které vyžadují nějaké vysvětlení, jsou popsány zde:
Explicitní seif1am Tento parametr vyžaduje jednu nebo více položek ze specifického seznamu mož ných hodnot. Použitelné hodnoty konkrétních parametrů najdete v online doku mentaci.
Výhledávaci tabulk:; Když se parametr odkazuje na vyhledávací tabulky, jsou tyto tabulky uvedeny včetně druhu mapy a názvu tabulky odděleného dvojtečkou: transport_map
=
hash : /etc /pos t f i x / t ransport
Cesta Kompletní cesta k souboru.
Šablona Některé hodnoty parametrů jsou uvedeny jako řetězce, které obsahují makra: smtpd_banner
=
$myhostname ESMTP $mai l_name
Tato makra jsou expandována na jejich hodnoty v čase použití tohoto parametru. Informace o tom, která makra jsou povolena pro konkrétní parametry, najdete v online dokumentaci.
ČasovéjednotAg Mnoho parametrů je zadáno jako množství času: queue_run_de lay
=
1000s
Je jim přiřazena hodnota a zkratka časové jednotky. Zkratky časových jednotek jsou uveden)l v tabulce A- I . Pokud neuvedete časovou jednotku, má každý parametr svou výchozí jednotku, kterou v tomto případě použije. Výchozí jednotky pro konkrétní parametr najdete v online dokumentaci. Tablllko A-I. éasovéjednotk;y Jednotka
Zkratka
Příklad
Sekundy
s
1s
Minuty
m
1 5m
Hodiny
h
4h
Dny
d
5d
Týdny
w
2w
Všechny parametry mají výchozí hodnotu (ačkoliv je u některých výchozí hodnotou null). V souboru main.ifmusí být uvedeny pouze ty parametry, které se liší od jejich výchozích hodnot. Tyto parametry jsou zde uvedeny s jejich výchozí hodnotami, ale ta se někdy mění podle verze Postfixu. Výchozí hodnotu parametru můžete zjistit pomocí příkazu postcon! spuštěného s volbou -d: $ postconf -d alias_mapa a l i as_maps
=
hash : /etc /al iases , n i s : ma i l . a l iases
Referenční příručka parametrů Postfixu 2baunce natice recipient Impllcltni hodnota: postmaster
Možné hodnoty: e-mailová adresa
,,2bounce" je jednou z několika možných tříd chyb. Každá třída chyby může volitelně generovat chybovou zprávu. 2bounce _notice_ recipient udává adresu příjemce pro chybové zprávy ,,2bounce". Přiklad : 2bounce_noti ce_recipient
=
postmaster
access map reject cade Možné hodnoty: kód odpovědi
Implicitní hodnota: 554
Kód odpovědi SMTP odeslaný při odmítnutí požadavku z důvodu omezení mapy přístupu. Přiklad : acces s_map_re j ect_code
=
554
Možné hodnoty: mapy aliasů
Implicitní hodnota: hash:/etc/aliases, nis:mail.aliases
Seznam databází aliasů používaný agentem pro místní doručování. Příklad : a l i a s_maps
=
hash : /etc / a l iases , n i s : mai l . a l iases
allow_mail to files Možné hodnoty: explicitní seznam
Implicitní hodnota: alias,forward
Omezuje nebo umožňuje místní doručování pošty do externích souborů, když jsou expandovány ze souboru aliasů. Příklad : a l l ow_ma i l_to_f i l e s
=
a l i a s , forward
allow percent hack Možné hodnoty: yes/no
ImpllcHní hodnota: yes
Percent hack je staré řešení, které umožňovalo odesílatelem řízené směrování e-mailo vých zpráv. Nyní je mnohem spolehlivější použití DNS a směrování pošty, ale PostfIx tuto funkci podporuje i nadále. Pro vypnutí této volby nastavte parametr allow_per cent had na no. Příklad : a l l ow_pe rcent_hack
yes
=
alternate config directories Možné hodnoty: adresář
Implicitní hodnota: (null)
Příkazy postqueue a postdrop mají možnost používat odlišné adresáře pro načítání konfIgu račruno souboru Postftxu. Pokud chcete používat nějaké nestandardní adresáře, musíte je uvést v tomto parametru. Příklad : a l ternate_con fig_di rectories
=
/usr/ loca l /po s t f i x / conf
append at myorigin Možné hodnoty: yes/no
Implicitní hodnota: yes
Připojí k nekompletním e-mailovým zprávám hodnotu z myorigin do adres, které obsa hují pouze místní část adresy. Mění adresu user na user@host , example , com. Příklad : append_at_myorigin
=
yes
authorized verp clients Implicitní hodnota: $mynetworks
Možné hodnoty: hostitelé/domény
VERP je technika používaná v e-elektronických konferencích pro práci s vrácenými zprávami. Kombinuje adresu majitele konference s adresou původruno příjemce po mocí speciálruno znaku oddělovače. authori zed_verp_clients obsahuje seznam názvů hostitelů a domén a adres IP klientů, kteří smějí tuto funkci používat. Příklad : autho ri zed_verp_c l ients
=
$mynetworks
berkeley db read buffer size Implicitní hodnota: 131072
Možné hodnoty: počet bajtů
Velikost bufferu používaného při čtení hashe Berkeley DB nebo tabulek btree. Příklad : ber �eley_db_read_bu ffer_s i z e
=
131072
biff Implicitní hodnota: yes
Možné hodnoty: yes/no
biff j e malý proces, který může upozorňovat místní uživatele na to, že jim přišla nová zpráva. Pokud nemáte místní uživatele, měli byste upozorňování procesem biffvypnout, jelikož může ovlivnit výkon poštovrubo serveru. Příklad : b i f f
=
yes
body checks size limit Implicitní hodnota: 51 200
Mo!né hodnoty: počet bajtů
Omezuje velikost předmětu zprávy pro ftltrování body_checks. Příklad : body_checks_s i ze_l imit
=
51200
bounce service name Mo!né hodnoty: služba
Implicitní hodnota: bounce
Služba používaná hlavním démonem pro správu souborů protokolů se stavovou infor mací o zprávách, které nemohly být doručeny. Tento parametr za normálních okolností nemusíte měnit. Příklad : bounce servi ce name -
-
=
bounce
canonical maps Mo!né hodnoty: druhy vyhledávacích tabulek
Implicitní hodnota: (null)
Seznam vyhledávacích tabulek používaných pro mapování e-mailových adres na jejich přepsaný tvar. Příklad : canon ical_maps
=
hash : /etc/po s t f i x / canon ica l_maps
command directory Momé hodnoty: adresář
Implicitní hodnota: lusrlsbin
Umístění nástroj ů pro správu Postfixu pro příkazový řádek, jako například postcat a postqueue. Příklad : command_directory
=
/ u s r / sbin
command time limit MoIné hodnoty: čas
Impllcltnl hodnota: 1 000s
Když agent pro místní doručování předává zprávy příkazu, Postfix omezuje čas, po který může příkaz běžet. command_t ime_limit stanovuje časový limit. Příklad : comrnand t ime l imit
=
10005
content filter Impllcltnl hodnota: (null)
Možné hodnoty: transport
Transport, který má být použit jako ftltr zpráv. Postfix předává zprávy do uvedeného transportu. Příklad : content_f i l ter
myfilter
=
daemon timeout Impllcltnl hodnota: 1 8000s
Možné hodnoty: čas
Č as po který mohou démoni Postfixu vyřizovat požadavek. Po dosažení daného času skončí. Příklad : daemon t imeout
180005
=
debug peer list Implicltnl hodnota: (null)
MoIné hodnoty: hostitelé/domény
Postfix může pro odstraňování problémů rozšířit protokolování pro konkrétní hostitele, se kterými jsou problémy. debug_pee r_l i s t udává seznam hostitelů, domén nebo vzor ků regulárních výrazů, pro něž by mělo být protokolování rozšířeno na úroveň danou parametrem debug_peer_level. Příklad : debug_peer_l i s t
=
example . com, ma i l . ora . com
default destination concurrency limit Impllcltnl hodnota: 20
Možné hodnoty: počet
Postfix umožňuje nastavit maximální počet souběžných doručování pro transporty v souboru masler.cf. Pokud pro transport nenastavíte explicitní limit, je použita hod nota z parametru defaul t_destination_concurrency_l imit . Pamatujte si, že omezení souběžného zpracování se provádí na počet cílů naproti omezení procesu, která jsou zadávána pro transport. Příklad : de faul t_de s t i nation_concurrency_l imit
=
20
default extra recipient limit Impllcitnl hodnota: 1 000
Možné hodnoty: počet
Omezuje počet příjemců pro transport, když správce fronty přerušuje normální doru čování kvůli transportu s vyšší prioritou. Příklad : de faul t_ext ra_recipient_l imit
=
1000
defaulCprocess limit Implicitnl hodnota: 1 00
Molné hodnoty: počet
Pro každý transport mohou být nastavena omezení procesu. Pokud pro transport nenastavíte explicitní omezení procesu, je použita hodnota z parametru defaul t_pro cess _l imi t. Pamatujte si, že omezení procesu jsou pro jednotlivé transporty a omezení souběžného zpracování se uvádí pro cíle. pfiklad : de faul t_proces s_limit
100
=
default recipient limit Implicitní hodnota: 1 0000
Molné hodnoty: počet
Omezuj e počet příjemců, které správce pošty uchovává v paměti pro konkrétní transport. pfiklad : de fault_recipient_1 imit
10000
=
default verp delimiters Implicitní hodnota: +=
Molné hodnoty: znaky
VERP je technika používaná v e-mailových konferencích pro zpracování vrácených zpráv. Kombinuje adresu vlastníka konference a adresu původruno příjemce pomocí speciálruno oddělovače. Parametr de faul t_verp de l imi ters udává, které znaky mají být použity při vytváření návratových adres VERP. _
pfiklad : de faul t_verp_de l imiters = +=
defer service name Implicitní hodnota: defer
Molné hodnoty: služba
Služba, kterou hlavní démon používá pro správu souborů protokolů se stavovými informacemi pro zprávy, které nemohly být doručeny. Tento parametr obvykle není potřeba měnit. pfiklad : de fer service name = de fer -
-
delay notice recipient Implicitní hodnota: postmaster
Molné hodnoty: e-mailová adresa
"delay" je jednou z několika možných tříd chyb. Každá třída chyb může volitelně ge nerovat chybovou zprávu. delaLnoticeJecipient udává adresu příjemce chybových zpráv pro "delay". pfiklad : de lay_not i ce_recipient
=
postmaster
deliverJock attempts Možné hodnoty: počet
Implicitní hodnota: 20
Omezuje počet pokusů Postfixu o získání exkluzivruno zámku souboru schránky. pfiklad : de l i ver_lock_a ttempts = 2 0
disable dns lookups Možné hodnoty: yes/no
Implicitní hodnota: no
Když Postfix zjišťuje, kam má být zpráva doručena, obvykle nejprve hledá záznamy MX pro cílovou doménu. Pokud je nastaven parametr disable_ dns _lookups, Postfix nehledá záznamy MX a doručuje přímo na záznam A cílové domény. Příklad : disable_dn s_l ookups
no
=
disable mime output conversion Možné hodnoty: yes/no
Implicitní hodnota: no
Pokud vzdálený systém neuvádí podporu 8bitového formátu MIME, Postfix obvykle převádí 8bitový formát MIME na 7bitový formát. Pro vypnutí normálního chování nastavte disable_mime_output _convers ion na ye s . Příklad : disabl e_mime_output_conve rs ion
=
no . .,-.'
disable Vrty command
Implicitní hodnota: no
Možné hodnoty: yes/no
Postfix normálně umožňuje používání příkazu SMTP VRFY. Pro jeho zákaz nastavte di sable_vrfy_command na yes . Příklad : disable_vrfy_command
=
no
double bounce sender Implicitní hodnota: double-bounce
Možné hodnoty: e-mailová adresa
double bounce je použito, když původní odesílatel nemůže být upozorněn na to, že zpráva nebyla doručena. Parametr double_bounce_sender udává adresu odesílatele, kterou Postfix používá pro poštu, která by měla být zahozena, pokud nemůže být doručena. Daná adresa by neměla být používána pro cokoliv jiného, jelikož jsou všechny zprávy na ní adresované bez upozornění zahozeny. Příklad : doub le-bounce- sender
=
double -bounce
empty address recipient Implicitní hodnota: MAILER-DAEMON
Možné hodnoty: e-mailová adresa
Cílová adresa pro upozornění, když nemůže být pošta s odesílatelem s hodnotou null « » doručena. Například pokud upozornění o vrácení, které používá odesílatele s hodnotou, nemůže být doručeno, je odesláno na adresu zadanou v parametru emp ty_addres s_recipient. Příklad : empty_addres s_recipient
=
MAI LER- DAEMON
error service name Implicitní hodnota: error
Možné hodnoty: služba
Služba, kterou hlavní démon používá pro generování chybových zpráv pokud zpráva nemůže být doručena. Tento parametr normálně není potřeba měnit . .
Příklad : error service name -
-
=
error
export environment Implicitní hodnota: TZ MAIL_CONFIG
Možné hodnoty: proměnné prostředí
Seznam proměnných prostředí, které jsou exportovány do externích procesů, jako napřľklad doručování do služby pipe nebo externích příkazů. Příklad : export_envi ronment
=
T Z , MAIL CONFIG
fallback relay Implicitní hodnota: (null)
Možné hodnoty: hostitelé/domény
Seznam adres IP, hostitelů nebo domén pro příjem zpráv pokud normální dl nelze nalézt nebo je nedostupný. Příklad : fal lback_relay
example . com
=
fast flush domains Implicitní hodnota: $relay-domains
Možné hodnoty: hostitelé/domény
Služba pro rychlé odeslání umožňuje správci fronty zkusit v případě požadavku ihned odeslat zprávy pro konkrétní doménu. Parametr fast_ flush domains udává seznam adres IP, hostitele a domény, které smějí používat službu pro rychlé odeslání. _
Příklad : fast_flush_domains
=
$relay_doma ins
fast flush refresh time Implicitní hodnota: 1 2h
Možné hodnoty: čas
Služba pro rychlé odeslání umožňuje správci pošty zkoušet v případě požadavku doruče ní zpráv pro konkrétní doménu. Parametr fast flushJefresh time udává časový inter val pro automatické odeslání zpráv, pro které nebylo požadováno opětovné doručení. _
Příklad : fast flush refresh time -
-
-
=
_
12h
fork attempts Implicitní hodnota: 5
Možné hodnoty: počet
Omezuje počet pokusů Postfixu o spuštění procesu. Příklad : fork_attempts
=
5
forward expansion filter Implicitní hodnota: (viz při klad)
Možné hodnoty: znaky
Při přiřazování názvů cest parametru forward_path můžete používat makra jako napří klad $user, která jsou expandována Postfixem pro zjištění cesty pro aktuální zprávu. Parametr forward expans ion_ fil ter udává seznam znaků, které by měly být při expan dování maket povoleny. Znaky, které nejsou povoleny, jsou nahrazeny podtržítky. _
Příklad : forward_expans ion_f i l ter = 1 2 3 4 5 6 7 8 9 0 ! @ % -_=+ : ' . / abcde fgh i j klmnopqrstuvwxyz \ ABCDEFGHI JKLMNOPQRSTUVWXYZ
hash queue depth Možné hodnoty: počet
;-! -
Implicítní hodnota: 1
Postfix vytváří pro soubory každé z front strukturu podadresářů. Parametr hash_queue_ depth udává počet úrovní podadresářů v adresářích front. Příklad : hash_queue_depth = 1
header address token limit Implicitní hodnota: 1 0240
Možné hodnoty: počet
Omezuje počet tokenů (každé slovo a každý znak @ nebo . je token, jak je definováno v RFC 2822) v adresách záhlaví, které mají být přepsány Postfixem. Přebytečné tokeny jsou bez upozornění zahozeny. Příklad : header addre s s token l imit = 1 0 2 4 0 -
-
-
header size limit Možné hodnoty: počet bajtů
Implicitní hodnota: 1 02400
Omezuje povolený počet znaků v záhlaví zprávy. Přesahující text je bez upozornění zahozen. Příklad : header s i ze l imit = 1 0 2 4 0 0
home mail box Možné hodnoty: cesta
Implicitní hodnota: (null)
Postfix normálně doručuje zprávy do souborů schránek v úložišti pošty. Zadáním cesty do parametru home _mai lbox můžete změnit doručování na soubory schránek relativně vůči domovským adresářům uživatelů. Pro zadání schránek ve formátu maildir zadejte na konci lomítko. Příklad : home mai lbox = Ma i l /mbox
ignore mx lookup error Implicitní hodnota: no
Možné hodnoty: yes/no
Postfix se normálně, pokud nedostane žádnou odezvu od názvového serveru při vy hledávání záznamů MX, znovu pokouší o vyhledání po nějaké době. Zapnutím volby ignore mx lo o kup error můžete zapnout okamžité vyhledávání záznamů A. _
_
_
Přiklad : ignore_mx_1oo kup_e rror
=
no
in flow delay Implicitní hodnota: 1 s
Možné hodnoty: čas
Udává čas, po který má Postfix čekat před přijetím nové zprávy. Tento parametr byste měli měnit pouze při experimentování s výkonem. Přiklad : i n_f 1 ow_de 1ay
=
ls
initial destination concurrency Možné hodnoty: počet
Implicitní hodnota: 5
Počáteční počet doručovacích procesů pro konkrétní cíl. Přiklad : i n i t i a 1_destinati on_concurrency
=
5
ipc idle Možné hodnoty: čas
Implicítní hodnota: 1 00s
Maximální čas nečinnosti pro interní komunikační kanály. Jakmile je dosaženo maxima času, komponenty Postfixu se záměrně odpojí. Přiklad : ipc_id1e
=
100s
line length limit Možné hodnoty: počet
Implicitní hodnota: 2048
Nastavuje maximální délku řádku ve zprávě. Řádky, které tento limit přesahují, j sou při doručování rozděleny a rekonstruovány. Přiklad : 1 i ne_1 ength_1 imit
=
2048
Imtp connect timeout Možné hodnoty: čas
Implicitní hodnota: Os
Nastavuje maximální čas, po který klient LMTP čeká na dokončení připojení TCP. Pro vypnutí časového limitu nastavte tento parametr na O. Přiklad : 1mtp_connect_timeout
=
O
Imtp data init timeout Možné hodnoty: čas
Implicitní hodnota: 1 20s
Nastavuje maximálrú čas, po který klient LMTP čeká na odpověď od serveru po odeslání příkazu LMTP DATA. Příklad : lmtp_data_i n i t_timeout
=
120s ;'-:' . '
Imtp Ihlo timeout Možné hodnoty: čas
Implicitní hodnota: 300s
Nastavuje maximální čas, po který klient LMTP čeká na odpověď serveru po odeslání příkazu LMTP LHLO. Příklad : lmtp_lhlo_timeout
=
300s
Imtp quit timeout Možné hodnoty: čas
Implicitni hodnota: 300s
Nastavuje maximální čas, po který klient LMTP čeká na odpověď serveru po odeslání příkazu LMTP QUIT. Příklad : lmtp_qu i t_timeout
=
300s
Imtp rset timeout Možné hodnoty: čas
Implicitní hodnota: 300s
Nastavuje maximální čas, p o který klient LMTP čeká na od p ověď serveru p o odeslání p řľkazu
LMTP RSET.
Příklad : lmtp_rset_timeout
=
300s
Imtp tcp-port Implicitní hodnota: 24
Možné hodnoty: číslo portu
Port TCP, který má být použit pro připojení LMTP, pokud služba lmtp není nalezena v databázi services.
local destination concurrency limit Implicitní hodnota: 2
Možné hodnoty: počet
Nastavuje maximální počet doručovadch procesů pro stejného mľstrubo příjemce. Přiklad : local_destination_concurrency_limit
=
2
local recipient maps Implicitní hodnota: uníx:passwd.byname $alias_maps
Možné hodnoty: vyhledávací tabulky
Seznam vyhledávadch tabulek obsahujľdch všechny e-mailové adresy, které jsou mľstní. Parametr je používán serverem SMTP pro odmítnutí zpráv pro neexistujíd uživatele. Přiklad : loca l_rec ipient_maps
=
unix : pas swd . byname $ a l i a s_maps
luser relay Implicitní hodnota: (null)
Možné hodnoty: e-mailová adresa
Cílová adresa, na kterou by měly být doručovány všechny zprávy pro neznámé příjemce. Příklad : luseL_re l a y
=
info
mail owner Implicitní hodnota: postfix
Možné hodnoty: uživatelské jméno
Uživatel, který je vlast!Úkem souborů front Postfixu. Také je používán pro spouštění procesů démonů Postfixu. Příklad : mai l_owner
=
postfix
mail spool direetory Implicitní hodnota: (závislá na systému)
Možné hodnoty: adresář
Adresář, ve kterém j sou uloženy soubory schránek. Příklad : mai l_spoo l_di reetory
/var/ma i l
=
mail box eommand Možné hodnoty: cesta
Implicitní hodnota: (null)
Externí příkaz, který má být použit pro konečné doručení do schránky. Tento parametr je obvykle používán pro nastavení externího agenta pro místní doručování, jako je například procmail. Příklad : ma i lbox_eommand
=
/ u s r / loeal/bin /proema i l
mailbox delivery loek Možné hodnoty: explicitní seznam
Implicitní hodnota: (závislá na systému)
Metody zamykání, které by měl Postfix používat při doručování pošty do souborů. Příklad : mai lbox_de l ivery_l oek
=
fent l ' dot loek
mail box transport Možné hodnoty: transport
Implicitní hodnota: (null)
Transport, který má být používán pro konečné doručení do schránky. Příklad : mai lbox_t ransport
=
eyrus
manpage_direetory Možné hodnoty: adresář
Implicitní hodnota: (závislá na systému)
Adresář pro manuálové stránky Postfixu. Příklad : manpage_direetory
=
/ u s r / l oeal /man
masquerade domains Možné hodnoty: domény
Implicitní hodnota: (null)
Maskování (maškaráda) adres skrývá názvy interních hostitelů odebráním názvů inter ních hostitelů před odesláním zpráv ze systému brány. Parametr masquerade_domains udává seznam domén, kterých by se maskování mělo týkat. Příklad : masquerade_domains
=
exampl e . com
maxjdle Možné hodnoty: čas
Implicitní hodnota: 1 005
Maximální doba nečinnosti, po kterou démon Postfixu (s výjimkou správce fronty) čeká na nový požadavek. Příklad : max idle
=
100s
maximal_backofUime Možné hodnoty: čas
Implicitní hodnota: 40005
Maximální doba pro opětovný pokus o doručení odložených zpráv. Pokaždé, když je zpráva odložena, správce fronty prodlouží čas do dalšího pokusu o doručení této zprávy. Prodloužená doba nesmí překročit maximal_backoff_t ime. Příklad : maxima 1 backo f f time -
-
=
4000s
message size limit Implicitní hodnota: 1 0240000
Možné hodnoty: počet bajtů
Nastavuje maximální akceptovatelnou velikost zprávy. Příklad : me ssage_s i z e_l imit
=
10240000
mime header checks Implicitní hodnota: $headecchecks
Možné hodnoty: vyhledávací tabulky
Seznam vyhledávacích tabulek obsahující vzorky pro porovnávání s každým záhlavím MIME u příchozích zpráv. Každý vzorek je uveden společně s akcí, která má být pro vedena v případě shody. Příklad : mime_header_checks
=
regexp : / etc/pos t f ix/mime_header_checks
minimal backoff time Implicitní hodnota: 1 0005
Možné hodnoty: čas
Minimální doba, po které se Postfix opět pokusí o doručení odložených zpráv. Pokaždé, když je zpráva odložena, správce fronty prodlouží dobu do dalšího pokusu o doručení. Vypočtený čas nesmí být menší než min imal_backoff_t ime. Příklad : minimal backo f f t ime -
-
=
1000s
mydomain Implicitni hodnota: (závislá na systému)
Možné hodnoty: doména
Název domény systému. Příklad : mydoma in
=
example . com
mynetworks Implicitní hodnota: (závislá na systému)
Možné hodnoty: net addresses
Seznam adres IP nebo adres sítě, kterým je povoleno odesílat zprávy skrze váš poštovní server. Pro povolení odesílání zpráv může být použit parametr rnynetworks nebo rnyne tworks s tyle. rnynetworks má přednost před rnynetworks _style. _
Příklad : mynetworks
=
1 92 . 1 6 8 . 1 5 . 3 2 / 2 6
myorigin Implicitní hodnota: $myhostname
Možné hodnoty: doména
Doména, která má být připojena k e-mailovým adresám, které obsahují pouze místní část. Příklad : myorigin
=
$myhos tname
newaliases_path Možné hodnoty: cesta
Implicitní hodnota: (závislá na systému)
Plná cesta k příkazu newa/iases, který je používán pro kompatibilitu se Sendmailem. Pa rametr newa/iases se používá pro opětovné sestavení databází aliasů. Příklad : newa l i a s e s_path
=
/usr/bin/newa l i a s e s
notity classes Možné hodnoty: explicitní seznam
Implicitní hodnota: resource,software
Seznam tříd chyb, které způsobí odeslání oznámení. E-mailové adresy pro oznámení jsou nastaveny v parametrech pojmenovaných podle třídy, třída notice_recipient. _
Příklad : noti fy_classes
=
resource ' software
parent domain matches subdomains Možné hodnoty: yes/no
Implicitní hodnota: (viz příklad)
Seznam vyhledávacích map, kde by vyhledávání mělo porovnávat samotnou doménu a všechny její subdomény. Příklad : parent_domain_matche s_s ubdoma ins
=
debug_peer_l i s t , fast_flush_domains ,
mynetworks , permi t_mx_bac kup_networ ks , qmqpd_authorized_c l ient s , relay_domains , smtpd_ acces s_maps
pickup_service name Implicitní hodnota: pickup
Možné hodnoty: služba
Služba, kterou hlavní démon používá pro příjem místně předaných zpráv. Tento parametr normálně nemusíte měnit. Příklad : pickup_service_narne
pickup
=
process id directory Implicitní hodnota: pid
Možné hodnoty: adresář
Adresář pro soubory zámků používaný hlavním démonem. Zadaná cesta je relativní vůči adresáři úložiště PostflXU. Příklad : proces s_id_directory
=
pid
proxy interfaces Implicitní hodnota: (null)
Možné hodnoty: adresa IP
Když server Postfix běží v interní síti za zařízením proxy nebo NAT a slouží jako zá ložní hostitel MX pro doménu a primární hostitel MX není dostupný, může vzniknout smyčka doručování pošty. proxL interfaces udává seznam adres síťového rozhraní, které přijímá poštu skrze zařízení proxy. Uvedení rozhraní brání vytvoření smyčky. Příklad : proxy_i nterfaces
=
1 92 . 1 68 . 1 5 . 2 3
qmgr clog warn time Implicitní hodnota: 300s
Možné hodnoty: čas
Minimální doba mezi varováními, že konkrétní cíl ucpává aktivní frontu. Hodnota O varování vypne. Příklad : qrngr_c l og_warn_t irne
=
300s
qmgr message active limit Implicitní hodnota: 20000
Možné hodnoty: oounl
Maximální počet zpráv povolených pro aktivní frontu. Příklad : qrngr_rne s s age_act ive_l irnit
=
20000
qmgr message recipient minimum Implicitní hodnota: 1 0
Možné hodnoty: počel
Minimální počet příjemců uložených v paměti pro každou zprávu. Příklad : qrngr_rne s s age_recipient_rnin irnurn
=
10
qmqpd error delay Implicitní hodnota: 1 s
Možné hodnoty: čas
Služba QMQP poskytuje centrální poštovní frontu pro cluster poštovních serverů. Parametr qmqp d_error_deIay udává dobu, kterou by měl server QMQP čekat před ode sláním negativní odpovědi klientovi. Zpoždění je určeno pro zdržení . špatně fungujících klientů. Příklad : qmqpd_e rror_de lay
=
ls
queue directory Implicitní hodnota: Ivarlspool/postfix
Možné hodnoty: adresář
Adresář pro frontu Postftxu. Příklad : queue_directory
=
/var/ spoo l /postfix
queue run delay Implicítní hodnota: 1 000s
Možné hodnoty: čas
Doba mezi vyhledáváním odložených zpráv ve frontách, které je potřeba znovu zkusit doručit. Příklad : queue_run_de lay
=
1000s
rbl reply_maps Implicitní hodnota: (null)
Možné hodnoty: vyhledávací tabulky
Seznam vyhledávacích tabulek používaný pro mapování názvů domén RBL na odpovědi při odmítání zpráv z důvodu rej ect Jbl nebo rej ectJhsbl. Pokud doména RBL není uvedena, poskytne odpověď defaul tJbl JepIy. Příklad : rbl_repl y_maps
=
hash : /etc /pos t f i x / rbl_rep l y
recipient canonical maps Možné hodnoty: vyhledávací tabulky
Implicitní hodnota: (null)
Seznam vyhledávacích tabulek používaných pro mapování e-mailových adres příjemců na jejich očekávaný přepsaný tvar. Funguje stejně jako canon ical_maps, ale pouze pro adresy příjemců. recipient_canonical_maps má přednost před canonical_maps. Příklad : recipient_canon ica l_maps
=
hash : / etc/po s t f i x / canon ical
reject code Možné hodnoty: kód odpovědi
Implicitní hodnota: 554
Kód odpovědi SMTP, který má být odeslán pokud je požadavek odmítnut z důvodu omezení klientů. Příklad : rej ect_code
=
554
relay domains reject code Možné hodnoty: kód odpovědi
Implicitní hodnota: 554
Kód odpovědi SMTP, který má být odeslán pokud je požadavek odnútnut z důvodu nepovoleného pokusu o odeslání. Příklad : relay_dornains_re j ect_code
=
554
relay transport Možné hodnoty: transport
Implicitní hodnota: relay
Transport, který má být použit pro doručování předávaných zpráv. Příklad : relay_transport
relay
=
relocated maps Možné hodnoty: vyhledávací tabulky
Implicitní hodnota: (null)
Seznam vyhledávacích tabulek, který mapuje přesunuté adresy nebo domény na jejich nové umístění. Příklad : relocated_rnaps
=
hash : /etc /pos t f i x / relocated
resolve_dequoted_address Možné hodnoty: yeslno
Implicitní hodnota: yes
Udává, zda má Postfix rozkládat adresy, jejichž nústní část obsahuje uživatelem zadané směrování. Při nastavení yes dá Postfix místní části obsahující speciální symboly jako například @ do uvozovek pro striktní dodržování RFC 822. Příklad : resolve_dequoted_addre s s
=
yes
sample directory Implicitní hodnota: letcJpostfix
Možné hodnoty: adresář
Adresář se vzorovými konfiguračními soubory Postfixu. Vzorové soubory obsahují příklady a dokumentují konfigurační parametry Postfixu. Příklad : sarnpl e_directory
=
/etc /pos t f i x
sendmail path Implicitní hodnota: (závislá na systému)
Možné hodnoty: cesta
Plná cesta k příkazu sendmailpro kompatibilitu se Sendmailem. Příkaz sendmail se používá hlavně pro odesílání zpráv z příkazového řádku nebo ze skriptů. Příklad : sendrnai l_path
=
/ u s r / sbin/ sendrna i l
setgid group Implicitní hodnota: postdrop
Možné hodnoty: skupina
Identifikátor skupiny používaný Postfixem pro poštu a správu fronty. Používaná skupina by měla být určena pouze pro Postfix. Přiklad : setgid_group
=
pos tdrop
showq service name Implicitní hodnota: showq
Možné hodnoty: služba
Služba používaná pro hlášení stavu fronty Postfixu. Tento parametr normálně není potřeba měnit. Přiklad : showq_servi ce_name
=
showq
smtp bind address Implicitní hodnota: (null)
Možné hodnoty: adresa IP
Adresa IP rozhraní, ke kterému by se měl klient SMTP připojovat při připojování k poš tovním serverům. Nastavení tohoto parametru je nezbytné pouze v systémech s více sítěmi, kde musíte explicitně použít pouze jedno rozhraní. Přiklad : smtp_bind_addre s s
=
1 92 . 1 68 . 1 5 . 2 3
smtp data done timeout Implicitní hodnota: 600s
Možné hodnoty: čas
Maximální doba, po kterou klient SMTP čeká na odezvu ze serveru po odeslání SMTP . Gediná tečka) označující konec obsahu zprávy. Přiklad : smtp_data_done_t imeout
=
600s
smtp data xfer timeout Implicitní hodnota: 1 BOs
Možné hodnoty: čas
Maximální doba, po kterou klient SMTP čeká při odesílání obsahu zprávy. Pokud je spojení nefunkční déle než po zadanou dobu, ukončí klient SMTP spojení. Přiklad : smtp_data_x fe r_t imeout
=
180s
smtp destination recipient limit Implicitní hodnota: (viz příklad)
Možné hodnoty: počet
Omezuje počet příjemců pro vněj ší doručení zprávy prostřednictvím klienta SMTP. Přiklad : smtp_de s t inati on_recipient_l imit
=
Sdefau l t_dest inati on_rec ipient_l imit
smtp_helo timeout Možné hodnoty: čas
Implicitni hodnota: 300s
Maximální doba, po kterou klient SMTP čeká na odpověď od serveru po odeslání příkazu SMTP HELO. Příklad : smtp_he lo_timeout
=
300s
smtp mail timeout Možné hodnoty: čas
Implicitní hodnota: 300s
Maximální doba, po kterou klient SMTP čeká na odpověď od serveru po odeslání příkazu SMTP MAI L FROM. Příklad : smtp_ma i l_timeout
=
300s
smtp pix workaround delay time Možné hodnoty: čas
Implicitní hodnota: 1 0s
Některé starší firewally Cisco PIX obsahují chybu, která způsobuje kolizi při doručování SMTP, když zakončující tečka a CR/LF označující konec obsahu zprávy přijdou v od dělených paketech. Postfix umí tento problém automaticky detekovat a odstranit tím, že počká před odesláním zakončující tečky a CR/LF, aby se buffer socketu pro odesílání měl šanci vyprázdnit. Parametr smtp _pix_workaround_de lay_t ime udává, jak dlouho má Postfix čekat, než bude buffer prázdný. Příklad : smtp_pix_wo rkaround_de l a y_t ime
=
lOs
smtp quit timeout Implicitní hodnota: 300s
Možné hodnoty: čas
Maximální doba, po kterou klient SMTP čeká na odpověď od serveru po odeslání příkazu SMTP QUIT. Příklad : smtp_qu i t_timeout
=
300s
smtp rcpt timeout Implicitní hodnota: 300s
Možné hodnoty: čas
Maximální doba, p o kterou klient SMTP čeká na odpověď od serveru po odeslání p říkazu
SMTP RCPT TO. Příklad : smtp_rcpt_t imeout
=
300s
smtp skip S xx greeting Možné hodnoty: yes/no
Implicitní hodnota: yes
Když server SMTP odpovídá kódem 5xx, může Postfix zprávu vrátit nebo zkoušet další poštovní servery cílové domény, aby zjistil, zda j sou schopné zprávu přijmout. Parametr smtp_ s kip_ 5xx _greeting udává, zda by Postfix měl nebo neměl reagovat na
kód odpovědi a pokračovat. Pokud bude nastavena hodnota no, bude PostflX zkoušet další poštovní servery. Příklad : smtp_skip_5xx_gree ting = yes
smtpd banner Implicitní hodnota: (viz příklad)
Možné hodnoty: Aablona
Text, který následuje za stavovým kódem 220 v uvítací zprávě SMTP. Pokud tento parametr změníte, ujistěte se, zda jste zadali $rnyhostnarne na začátek textu, protože to vyžadují RFC. Příklad : smtpd_banner
=
$myhostname ESMTP $mai l_name
smtpd data restrictions Implicitní hodnota: (null)
Možné hodnoty: Omezení UBE
Seznam omezení UBE, která mají být použita když klient odešle příkaz SMTP DATA. Příklad : smtpd_data_restrictions = rej ect_unauth_pipel ining
smtpd error sleep time Implicitní hodnota: 1 s
Možné hodnoty: čas
Doba, po kterou Postfix zpočátku čeká, pokud klient způsobí chybu. Po dosažení počtu chyb uvedených v parametru srntpd_soft_error_lirní t PostflX při každé chybě prodlouží čekací dobu o jednu sekundu. Příklad : smtpd_e rror_s leep_time = l s
smtpd expansion filter Možné hodnoty: znaky
Implicitní hodnota: (viz příklad)
Seznam znaků, které jsou povoleny při expandování maker serverem SMTP. Příklad : smtpd_expan s i on_f i l ter = \ t \ 4 0 ! " # $ % & ' (
) * + ' - . / 0 1 2 3 4 5 6 7 8 9 : ; <=> ? @
ABCDEFGHI JKLMNOPQRSTUVWXYZ [ \ \ J A_ ' abcde fgh i j klmnopqrs tuvwxyz { I ) �
smtpd helo required Možné hodnoty: yes/no
Implicitni hodnota: no
Udává, zda má Postfix požadovat, aby klient zahájil komunikaci SMTP příkazem HELO/ EHLO. Příklad : smtpd_he lo_requ i red = no
smtpd history flush threshold Možné hodnoty: počet
Maximální počet řádků v historii př1'kazů serveru SMTP. Příklad : smtpd_h i s tory_f lush_threshold = 1 0 0
Implicitní hodnota: 1 00
smtpd noop commands Implicitní hodnota: (nu II)
Možné hodnoty: explicilní seznam
Seznam příkazů SMTP, které by měl Postfix přijmout, ale neměl by nic dělat. Postfix vždy odpovídá na tyto příkazy stavem ,,250 Ok". Příklad : smtpd_noop_commands
=
vrfy, expn
smtpd recipient limit Možné hodnoty: počel
Implicitní hodnota: 1 000
Maximální počet příjemců povolených v příkazu RCPT TO pro každou zprávu. Jakmile je dosažen tento limit, Postf1X odmítá příkazy RCPT TO. Příklad : smtpd_recipient_l imit
1000
=
smtpd restriction classes Implicitní hodnota: (null)
Možné hodnoty: seznam
Seznam názvů správcem definovaných tříd omezení. Každá nadefinovaná třída může být přiřazena parametrům UBE. Příklad : smtpd_re strict ion_c l a s s e s
=
myre s t r i c t i on_a , myrestricti on_b
smtpd soft error limit Implicitní hodnota: 1 0
Možné hodnoty: počel
Počet chyb, po kterém by měl Postfix prodloužit prodlevu o jednu sekundu při každé chybě. Příklad : smtpd_soft_e rror_l imit
=
10
soft bounce Implicitní hodnota: no
Možné hodnoty: yes/no
Udává, zda má být pošta, která by jinak byla vrácena, zařazena do fronty pro opětovné pokusy o doručení. Také konvertuje kódy odpovědí trvalého odmítnutí na dočasné chybové kódy. Tento parametr je užitečný pro testování změn konfigurace a zajištění toho, že pošta nebude trvale odmítnuta. Příklad : soft bounce
=
no
strict 7bit headers Implicitní hodnota: no
Možné hodnoty: yes/no
Udává, zda by měl Postfix akceptovat pouze 7bitový text v záhlavích zpráv, jak je vy žadováno dokumenty RFC. Pošta s 8bitovým kódováním záhlaví zpráv je implicitně odmítnuta. Příklad : strict 7bit headers
=
no
strict 8bitmime body Implicitní hodnota: no
Možné hodnoty: yes/no
Udává, zda by měl Postfix odmítat zprávy, které obsahují 8bitový text, který nemá správné kódování MIME. Příklad : s t r i c t_8bi trnirne_body
=
no
strict rfc821 envelopes Implicitní hodnota: no
Možné hodnoty: yes/no
Udává, zda by měl Postfix vyžadovat, aby byly adresy obálek v lomených závorkách « » a bez nepatřičných informací, jak je vyžadováno dokumenty RFC. Příklad : s t r i ct_rfc82 1_enve lopes
=
no
swap bangpath Implicitní hodnota: yes
Možné hodnoty: yes/no
UUCP používá vykřičník (1) pro směrování poštovních zpráv. Parametr swap_bangpath udává, zda má Postfix pro směrování pošty změnit vykřičník na zavináč (@) . Příklad : swap_bangpath
=
yes
syslog name Implicitní hodnota: postfix
Možné hodnoty: řetězec
Název procesu, který by měl být zaznamenáván v !ys1ogu. Příklad : syslog_narne
=
postfix
transport retry time Možné hodnoty: čas
Implicitní hodnota: 60s
Doba čekání před pokusem o použití dříve nedostupného transportu. Příklad : transport_retry_tirne
=
60s
undisclosed3ecipients header Možné hodnoty: řetězec
Implicitní hodnota: (viz přiklad)
Řádek záhlaví, který má být vložen pokud nej sou zadáno žádní příjemci v záhlaví To: (například To:, Re sent-To:, Ce:) . Příklad : undi s c l o sed_re cipients_header
=
To : undi s c l o sed-recipient s : ;
unknown client reject code Možné hodnoty: kód odpovědi
Implicitní hodnota: 450
Kód odpovědi SMTP, který má být odeslán pokud je požadavek odmítnut z důvodu omezení rej eet_unknown_el ient. Příklad : unknown_c l ient_rej ect_code
=
450
unknown local recipient reject code Možné hodnoty: kód odpovědi
Implicitní hodnota: 550
Kód odpovědi SMTP, který má být odeslán při odmítnutí požadavku z důvodu adreso vání na neexistujícího místruno uživatele. Příklad : un known_l ocal_recipient_re j ect_code
=
550
unknown virtual alias reject code Možné hodnoty: kód odpovědi
Implicitní hodnota: 550
Kód odpovědi SMTP, který má být odeslán pokud je požadavek odmítnut z důvodu adresování na neexistujícího uživatele v jedné z domén virtuálních aliasů. Příklad : un known_virtual_a l ias_re j ect_code
=
550
verp delimiter filter Možné hodnoty: znaky
Implicitní hodnota: -=+
VERP je technika používaná v e-mailových konferencích pro práci s vrácenými zpráva mi. Kombinuje adresu vlastníka konference a adresu původruno příjemce se speciálním oddělovacím znakem. Parametr verp_de l imiter_f i l ter udává, které znaky má Postfix akceptovat jako oddělující znaky VERP. Příklad : verp_de l imiter_f i l ter
=
-=
+
virtual alias maps Možné hodnoty: vyhledávací tabulky
Implicitní hodnota: (null)
Seznam vyhledávacích tabulek používaných pro mapování virtuálních aliasů na jejich cílové e-mailové adresy. Příklad : vi rtual_a l i as_maps
=
hash : / etc/postfix/vi rtual_a l i a s
virtual mailbox base Možné hodnoty: adresář
Implicitní hodnota: (null)
Základní adresář pro soubory virtuálních schránek. Všechny soubory schránek jsou umístěny relativně vůči základnímu adresáři. Příklad : vi rtual -ma i lbox- base
/ u s r / local /virtual -ma i l
=
virtual mailbox limit Implicitní hodnota: 51 200000
Možné hodnoty: počet bajtů
Maximální velikost souborů virtuálních schránek. U schránek ve formátu maildir omezuj e p ouze velikosti jednotlivých souborů, ne celé schránky. Tato hodnota nesmí být menší než
message_s i z e_limit. Příklad : virtual-mai lbox-l imit
=
51200000
virtual mailbox maps Implicitni hodnota: (nu II)
Možné hodnoty: vyhledávací tabulky
Seznam vyhledávacích tabulek používaný pro mapování adres virtuálních schránek na odpovídající soubory schránek. Cesty k souborům schránek jsou relativní vůči virtu al mai lbox base. -
-
Přiklad : virtual_ma i lbox_maps
=
hash : /etc/postfix/vi rtua l_ma i lbox
virtual transport Možné hodnoty: transport
Implicitní hodnota: virtual
Implicitní transport, který má být používán pro doručování zpráv na adresy virtuálních schránek. Přiklad : vi rtual_transport
=
virtual
PŘílOHA B
Příkazy Postfixu
Zde j sou uvedeny nástroje Postfixu pro přľkazový řádek. Každý z nich je plně zdoku mentován v manuálové stránce, která je obsažena v distribuci Postfixu. Tato příloha má sloužit jako stručný přehled přľkazů a jejich účelů. Kompletnľ informace o těchto příkazech najdete v odpovľdajícľch manuálových stránkách: pos talias
Vytvářľ databáze aliasů nebo provádí dotazy na ně. postcat
Tiskne obsah souborů fronty, což umožňuje správcům zobrazenľ textu zpráv ve frontě. postconf
Zobrazuje nebo měnľ parametry Postfixu. Může zobrazit najednou jeden parametr nebo kompletnľ seznam parametrů. postdrop
Vkládá zprávu do adresáře maildrop pro její doručenľ Postfixem. postfix
Spouští a zastavuje Postfix. Také je možno jej použít pro další údržbu Postfixu, jako například kontrolu konfigurace a vyprázdněnľ fronty. postkick
Odesílá požadavek na konkrétnľ službu Postfixu. Umožňuje skriptům shellu komu nikovat se službami Postfixu. postlock
Zamyká daný soubor pro exkluzivnľ přľstup. Poskytuje skriptům shellu prostředky pro využívánľ zamykánľ kompatibilrubo s Postfixem. pos t log
Protokoluje danou informaci do systému syslog. Poskytuje prostředky pro skripty shellu pro snadné protokolovánľ informacľ ve stylu podobném Postfixu.
postmap
Vytváří vyhledávací mapy nebo na ně provádí dotazy. Většina konfiguračních in formací Postfixu je uchovávána ve vyhledávacích tabulkách, které jsou vytvářeny příkazem postmap. pos tqueue
Umožňuje přístup k frontě Postfixu na uživatelské úrovru. Změny ve frontě, které vyžadují práva superuživatele jsou spravována příkazem postsuper. postsuper
Poskytuje superuživatelský přístup k frontě Postfixu. Umožňuje správci odstraňo vat zprávy, nechat je čekat nebo je opět uvolňovat a v případě potřeby opravovat strukturu fronty.
PŘílOHA C
Kompi lace a instalace Postfixu
Obecnými kroky k překladu Postfixu z e zdrojových souborů j sou získání softwarového balíčku, jeho rozbalení, kompilace a instalace. Nástroje, které budete potřebovat, j sou běžně dostupné v téměř všech distribucích systémů Unix: gzip, tar, make a kompilátor C. Postfix obecně předpokládá GNU kompilátor gcc, ale můžete jej sestavit také pomocí nativnľho kompilátoru vašľ platformy, pokud podporuje ANSI C.
Získání Postfixu Na oficiálním webu Postfixu (http://www.posifix.org/) je odkaz na stažení, který vede na seznam zrcadel, ze kterých můžete software zľskat. Měli byste si vybrat zrcadlo, které je vám nejblíže. Balíček, který chcete stáhnout, vyberte klepnutim na odkaz "Source code" uvedený pod verzľ Official nebo Experimental (viz kapitola 1). Zde uvedené přľklady předpokládajľ, že j ste si stáhli soubor posifix-2.0. 1 O.tar.gz. Pokud se soubor, který j ste si stáhli, jmenuje jinak, název souboru v přľkladech odpovľdajľcím způsobem změňte.
Slabikář kompilování Postfixu Než přejdeme ke specifikám sestavování Postfixu, podľvejme se na základy kompilování kódu jazyka C. Volby pro konkrétní sestavování jsou obvykle obsažené v popisném souboru, který se jmenuje Make.ftle. Nástroj make poUžľvá soubor Make.ftle pro určení nezbytných podmľnek, závislosti a voleb použľvaných při sestavování balíčku. Pomocí těchto informací make volá kompilátor pro vytvoření objektových souborů a pak linker (obvykle Id) pro jejich spojení do spustitelných souborů. Jelikož distribuce Postfixu vytvářľ svůj vlastní soubor Make.ftle, nemusľte se starat o jeho úpravy (spľše byste jej neměli upravovat, protože změny, které provedete budou prav děpodobně později přepsány) . Volby, které Postfix potřebuje ve svém souboru Make.ftle jsou definovány v proměnných prostředľ, jako napřľklad CCARGS. Soubor INSTALL, který je obsažen v distribuci Postfixu, popisuje všechny dostupné volby. Zde se podľ váme na ty běžnějšľ.
Následující proměnné prostředí jsou k dispozici pro nastavení voleb pro kompilaci. Pro ponechání mezer a metaznaků shellu byste měli použít uvozovky okolo hodnot: AUXLIBS Řľká linkeru, kde má hledat další knihovny, které nej sou na standardních místech. Pokud n�říklad sestavujete podporu pro rozšiřující balíček, možná budete muset zadat, kde jsou knihovny potřebné pro překlad tohoto balíčku. CC
Udává konkrétní kompilátor, který má být použit. Pokud chcete použít jiný kompi látor než ten, který si vybral Postfix, nastavte tuto proměnnou na váš kompilátor. Postfix obvykle používá gcc, s výjimkou platforem, kde je známo, že nativní kom pilátor funguje lépe. Můžete se podívat do souboru makedefs, kde najdete informaci o kompilátoru, který Postfix implicitně používá ve vašem systému. CCARGS
Předává kompilátoru další parametry. Pokud váš kompilátor umožňuje použití speciálních voleb nebo nejsou vaše podpůrné soubory umístěny v implicitních adresářích, zadejte příslušné volby do této proměnné. DEBUG
Parametr DEBUG udává úrovně ladění, které má kompilátor použít při sestavování binárních souborů Postfixu. Při zapnutém ladění jsou vytvářeny další informace, které může použít ladící program. Funkce pro ladění můžete také pro překlad Po stfixu pro produkční systém zcela vypnout. OPT
Parametr OPT udává úrovně optimalizace pro kompilátor, které mají být použity při sestavování binárních souborů Postfixu. Další optimalizace může zvýšit výkon, ale za cenu delší kompilace a většího množství paměti. Pravděpodobně můžete akceptovat implicitní hodnoty, které Postfix vybľrá pro vaši platformu.
Volby kompilátoru Volby kompilátoru jsou nastaveny v proměnné CCARGS. Soubory se zdrojovým kódem C vyžadují hlavičkové soubory, které definují funkce a proměnné. Hlavičkové soubory jsou standardně umístěny v adresáři / tur/ inc/ude. Pokud jsou vaše hlavičkové soubory umístěny někde jinde, musíte říci kompilátoru, kde je má hledat. Volba kompilátoru I se používá pro zadání dalších adresářů, kde by mohl kompilátor najít hlavičkové soubory. Pokud připojujete knihovny z externích balíčků, mohou být hlavičkové soubory umís těny v místě instalace balíčku a ne na standardním místě. Běžnou konvencí pro externí balíčky je instalace hlavičkových souborů do adresáře / usr/local/ inc/ude. Pokud chcete kompilátoru říci, aby při sestavování Postfixu hledal kromě standardního adresáře také v jiném adresáři, zadejte volby a adresář pomocí CCARGS: -
CCARGS= ' - I /us r / l oc a l / include / '
Pro každý další adresář, který by měl kompilátor prohledávat, použijte další volbu - 1 . Postftx používá při sestavování podmíněnou kompilaci podle toho, které knihovny nebo jiné prostředky jsou k dispozici ve vašem systému. Definuje určitá makra založená na tom, co zjistí o vašem systému, nebo na volbách, které j ste nastavili. Volba -D umožňuje definovat makra v čase kompilace Postfixu. Přídavné balíčky Postfixu vyžadují, abyste nadefinovali konkrétní makro a sdělili Postfixu, že je má použít při sestavování. Pokud například chcete zahrnout podporu pro MySQL, nadefinujete makro HAS_MYSQL: CCARGS= ' - DHAS_MYSQL '
Volby linkeru Volby linkeru jsou nastaveny v proměnné AUXLIBS. Po zkompilování objektových sou borů je Postfix spojí dohromady s požadovanými knihovnami do spustitelných souborů. Systémové knihovny j sou standardně umístěny v adresáři I IIsrl lib. Aby linker hledal knihovny v dalších adresářích, použijte volbu -L: AUXL IBS= ' - L / u s r / l o ca l / l ib '
Také musíte linkeru říci, které konkrétní knihovny má připojit. Volba - 1 se používá pro vyjmenování konkrétních knihoven. Soubory knihoven musí být na standardním místě nebo v adresáři uvedeném volbou -L. Názvy souborů archívů knihoven začínají l ib, pokračují názvem a dále příponou, která je normálně . a pro statické knihovny a . s o nebo . sl pro sdílené objekty nebo sdílené knihovny. Když použijete volbu - 1 , vynecháte po čáteční lib a příponu souboru knihovny. Například pro spojení s klientskou knihovnou MySQL, kde se soubor knihovny jmenuje libmysqlclient.a, bude volba - 1 zadána takto: AUXLIBS= ' -L/usr/ local / l ib - lmysql c l ient '
Většina linkerů vybírá dynamické a ne statické knihovny. Dynamické knihovny j sou připojovány při spuštění programu a ne při jeho kompilaci. Linker při kompilaci zadá informace, které umožňují programu najít knihovny při jeho spuštění. Pokud instalu jete všechny dynamické knihovny do standardrubo umístění, jako například I IIsrl lib, nebude mít váš systém problém s nalezením knihoven při spuštění. Některé externí balíčky samozřejmě instalují knihovny do nestandardních adresářů a pak nemohou být nalezeny při spuštění. Různé systémy používají odlišné konvence pro umisťování dynamických knihoven pomocí pevné cesty a proměnných prostředí. Ujistěte se, že je váš systém nastaven tak, aby byl schopen najít vaše dynamické knihovny nebo se ujis těte, že j sou tyto dynamické knihovny instalovány ve standardních adresářích vašeho systému. Jinou možností je zadání skutečné cesty k daným knihovnám při sestavování vašich programů. Linker používá parametr pro zahrnutí adresářů do cesty vyhledávání dynamických knihoven. Tento parametr se liší v závislosti na linkeru a platformě. GNU linker (Linux, FreeBSD) používá - rpath, stejně jako IRIX. Solaris zase používá -R a HP-UX používá tb. Parametr, který byste měli použít pro zadání cesty ke knihovnám, zjistíte v manuálové stránce vašeho linkeru, /d(lJ.
Například v případě knihovny SSL, pokud je váš soubor libssLso umístěn v adresáři / usr/local/lib a sestavujete PostflX v systému FreeBSD nebo jiném systému, který používá rpath, nadefinujte AUXLIBS takto: AUXLIBS= ' -L/usr/ 1oca1 / 1 ib -rpath/u s r / 1oca1 / 1 ib - l s s l '
Když propojujete Postfix s externími knihovnami, pokud máte nainstalováno více verzí knihoven, je velmi důležité se ujistit, že propojujete Postfix s verzí, kterou potřebujete. Také se ujistěte, že verze knihovny, se kterou Postfix propojujete, odpovídá správné verzi hlavičkových souborů. Problémy s nesprávnou verzí jsou častým zdrojem chyb kompilace. Někdy si kompilátor nestěžuje a v tom případě váš překlad může proběhnout úspěšně, ale pravděpodobně zjistíte neobvyklé chyby při provozu Postfixu, které mohou být obtížně vypátratelné.
gcc a neznámé volby linkeru Některé verze gcc neznají všechny volby linkeru, které byste mohli použít a generují chyby při kompilaci. Běžně je to volba -rpath. Kompilátor generuje chybu jako gcc: unrecogni zed option I -rpath'. Jelikož je tato volba skutečně určena pro linker agcc ji opravdu nemusí znát, existuje snadné řešení. Kompilátor gcc používá parametr -Wl k vyznačení toho, že mají být konkrétní volby předány linkeru a jinak ignoro vány. V tomto případě, když zadáváte volbu -rpath, proveďte to pomocí -Wl: AUXL I BS= ' -L/usr/ 1oca1 / 1 ib -W1 , - rpath , / u s r / 1oca 1 / 1ib - l s s l '
Více informací najdete v manuálové stránce k gcc(1).
Překlad Postfixu Zdrojový soubor, který jste si stáhli, je komprimovaným archívem tar a musí být dekom primován pomocí příkazu gzij:>. V adresáři, kam j ste si stáhli balíček, zadejte následující příkaz: $ gzip -d postfix-2 . 0 . 10 . tar . gz
Tento příkaz dekomprimuje soubor a vytvoří soubor tar bez přípony .gZ' Dále soubor rozbalte: $ tar -xf postfix-2 . 0 . 10 . tar
Tento příkaz vytvoří adresář s názvem postftx-2.0. 10 umístěný v aktuálním adresáři. Nastavte tento adresář jako aktuální adresář pro zbytek kompilace: $ cd postfix-2 . 0 . 10
Pokud akceptujete všechny implicitní parametry pro překlad Postfixu, je kompilace provedena jednoduše spuštěním příkazu make v nejvyšším adresáři distribuce: $ malte
Provedení make vytváří soubor Make.file pro vaši konkrétní platformu, který je pak použit při kompilaci PostfIxu pro váš systém. Pokud nepotřebujete měnit implicitní nastavení, můžete přejít do části "Instalace".
Úpravy vašeho překladu Soubor makedifs obsahuje informace specifIcké pro platformu, které PostfIx používá při nastavování baličku pro váš systém. Pokud jste zvědaví, můžete se do tohoto souboru podívat, abyste zjistili, které parametry PostflX používá pro vaši platformu. IdentifIkuje vaše prostředí a vytváří makra a defInice, které jsou používány v souboru Make.file pro překlad PostfIxu ve vašem systému. Výsledný soubor Make.file je zpracován příkazem make, který pak volá váš kompilátor a linker pro překlad PostflXU. Když napíšete příkaz make jak byl uveden výše, všechno proběhne automaticky, takže se nemusíte o tento soubor starat. Pokud chcete změnit některý z parametrů pro vaše prostředí, můžete spustit překlad ve dvou krocích. Příkaz make makeftles vytváří nový soubor Makeftle v závislosti na parametrech, které zadáte na příkazové řádce. Pro nastavení konkrétních parametrů jednoduše nadefInujte proměnné na příkazovém řádku. Například můžete použít jiný kompilátor. Následující příklad funguje v systému HP-UX a zajišťuje, že make najde správný kompilátor: $ malte makefiles CC="/opt/ansic/bin/cc -Ae "
Zadali byste samozřejmě cestu ke svému vlastnímu kompilátoru plus další potřebné volby. Pokud potřebujete zadat další adresář pro hlavičkové soubory vašeho systému, nadefInujte CCARGS: $ malte maltefiles CCARGS=" -I /usr/local/include/ "
Volby samozřejmě můžete kombinovat: $ malte maltefiles CC="/opt/ansic/bin/cc -Ae" CCARGS=" - I /usr/local/include"
Změny implicitních hodnot Postfixu PostfIx poskytuje prostřednictvím svých konfIguračních souborů značnou flexibilitu. Skoro všechny parametry PostfIxu, včetně používaných adresářů, mohou být nastaveny v konfIguračním souboru. Samozřejmě s výjimkou umístění samotného konfIgurač rubo souboru. Umístění můžete změnit nadefInováním DEF_CONFIG_DIR v proměnné CCARGS: $ malte maltefiles CCARGS= ' -DDEF_CONFIG_DIR=\ " /usr/local/etc/postfix\ '"
Jednoduché a dvojité uvozovky a zpětná lomítka jsou důležitá, jelikož by hodnota pro DEF _CONFIG_ DIR měla být sama uvedena v uvozovkách. PostfIx po zkompilování hledá svůj konfIgurační soubor main.cf v adresáři I Nsrl loeall etelpost.fix namísto implicitrubo adresáře I etcIpost.fix.
Pro potřebná nastavení prostředí můžete používat kombinace všech výše uvedených přľkladů. Pokud váš příkazový řádek začíná být komplikovaný, možná budete chtít pro jeho spouštění vytvořit jednoduchý skript shellu. Viz část "Skript pro spouštění" dále v této příloze. Jakmile jste po.užili make make.ft/es s vašimi volbami pro vytvoření vašeho vlastního sou boru Make.ft/e, spusťte make pro překlad Postfixu: $ malte
Instalace Po úspěšném zkompilování Postfixu jste připravení jej nainstalovat. Instalaci budete muset provést jako uživatel root. Musíte vytvořit vyhrazený účet, který bude vlastníkem fronty Postfixu a většiny jeho procesů. Ú čet by neměl umožňovat přihlášení a nepotřebuje shell a domovský adresář. Pro vytvoření účtu použijte vaše nástroje pro správu systému. Můžete nastavit heslo na * a jeho domovský adresář a shell na neplatné cesty (něco jako I binlfalse nebo I devl nu/�. Název účtu by měl být podle konvencí postfix. Položka v souboru letcipasswd by měla vypadat podobně jako: pos t f ix : * : 1 0 0 1 : 1 0 0 1 : postfix : /no /where : /bin/false
Také musíte vytvořit vyhrazenou skupinu, která není používána žádným uživatelským účtem, včetně účtu postfix, který jste právě vytvořili. Podle konvence je název skupiny postdrop. Ve většině systémů se vytváří skupiny úpravami souboru letcigroup. Přidejte do něj řádek podobný tomuto: postdrop : * : 1 0 0 7 :
Pamatujte si, že Postfix je náhradou serveru Sendmail a pro zachování kompatibility instaluje svůj vlastní binární soubor sendmai/ namísto stávajícího. Možná budete chtít původní soubor přejmenovat, abyste si jej zazálohovali. V závislosti na vaší platformě je váš stávající soubor sendmai/ obvykle v I usrl sbinl sendmai/ nebo I usrl libl sendmail. Umístění souboru sendmai/ můžete zjistit spuštěním: t whereis sendmail
Tento příkaz může vypsat mnoho souborů, protože hledáte binární soubor, který nemá příponu. Jakmile jej najdete, přejmenujte jej: #
MV
lusrlsbin/sendmail lusrlsbin/sendmail . orig
Patrně budete chtít přejmenovat také další dva soubory, které budou Postfixem nahra zeny: mai/q a newa/iases. Ty jsou běžně umístěny v adresáři I usrl bin, ale můžete pro jejich nalezení použít opět příkaz whereis. Tyto příkazy mohou být symbolickými odkazy: #
MV
t
MV
lusr/bin/mailq lusr/bin/mailq . orig lusr/bin/newaliases lusr/bin/newaliases . orig
Nyní jste připraveni spustit instalační skript.
Ujistěte se, že jste přihlášení jako uživatel root a že jste stále v adresáři distribuce Post fixu. Spusťte instalační skript: • malte install
Po zkontrolování, že je vše sestaveno, se instalační skript zeptá na několik informací pro nastavení Postfixu ve vašem systému: instal l_root : [ l l
Adresář instalLroot j e kořenovým adresářem vašeho systému. Ten byste měnili pouze pokud byste vytvářeli instalovatelný balíček. Autoři balíčků často chtějí uchovávat všech ny soubory pohromadě v samostatném podadresáři, aby je mohli zabalit při vytváření distribučrubo balíčku: tempdi r : [ /home / kdent /pos t f ix-2 . 0 . 1 0 ]
Adresář tempdirje místem, kam může instalační skript zapisovat dočasné soubory. Impli citně je ukládá do aktuálrubo adresáře a pak je po sobě uklízí. Pokud z nějakého důvodu chcete, aby instalační skript používal jiný adresář, zadejte jej zde: config_di rectory : [ / etc/postfix ] daemon_directory : [ / u s r / l ibexec/postfix ] command_directory : [ / u s r / s b i n ] queue_directory : [ /var/ spool /po s t f i x ] sendmai l_path : [ /u s r / l ib/sendma i l ] newa l i a s e s_path : [ /u s r /bin/newa l iases ] mai l q_path : [ /u s r /bin/ma i l q ]
Pravděpodobně byste měli přijmout nabízené implicitní hodnoty. Jen se ujistěte, že implicitní hodnoty navrhované instalačním skriptem odpovídají adresářům, které jste našli pomocí příkazu whereis pro původní kopie příkazů sendmail, newaliases a mai/q. Pokud ne, měli byste zadat správnou cestu. ma i l_owner : [pos t f i x ]
Výchozí hodnotou mai l_owner je postfix a pokud jste se drželi výše uvedených instrukcí, můžete ji akceptovat. Pokud jste vytvořili účet s jiným uživatelským jménem, zadejte je. setgid_group : [ pos tdrop ]
Výchozí hodnotou setgid je postdrop a pokud jste se drželi výše uvedených instrukcí, mů žete ji akceptovat. Pokud jste vytvořili skupinu s nějakým jiným názvem, zadejte jej zde. manpage_director y : [ / usr/ local /man ]
Pro instalaci manuálových stránek Postfixu můžete tuto cestu akceptovat nebo zadat vhodnější místo ve vašem systému. s ample_di rectory : [ / etc/po s t f i x ]
Vzorové konfigurační soubory obsahují vysvětlivky k parametrům Postfixu a měly by být obsaženy ve vaší instalaci. Pokud je nechcete mít ve svém adresáři s konfigurací, můžete zadat jiné místo. readme_di rectory : [ n o ]
Distribuce PostflXu obsahuje několik souborů README s dalšími informacemi o kon krétních funkcích a rozšiřujících balíčcích. Jsou méně důležité pro běžnou údržbu Post fixu než vzorové konfigurační soubory, ale pokud je budete chtít mít obsažené ve vašem systému, zadejte cestu, kam by měly být nainstalovány. I když je nenainstalujete, budou stále k dispozici v adresáři distribuce. Instalační skript pak nainstaluje všechny nezbytné soubory.
Inovace Pokud je Postfix již nainstalován ve vašem systému, můžete jej inovovat na novou ver zi. Obvykle je nejlepší před provedením inovace PostflX zastavit. Proces inovace není interaktivní a vyžaduje, aby ve vašem systému již existoval soubor main.if. • postfix stop # malta upqrade
# postfix start
Postfix kontroluje změněné soubory a nahrazuje je novějšími verzemi z vaší nové kom pilace. Po opětovném spuštění Postfixu se podívejte do souboru protokolu.
Kompilace rozšiřujících balíčků Tato část popisuje sestavování Postfixu s různými rozšiřujícími balíčky, které j sou uve deny v této knize. Před opětovným zkompilováním Postfixu s dalšími balíčky je důležité nejprve odstranit případné předchozí překlad. Proveďte následující příkaz: $ malta tidy
Nyní můžete začít s čistým zdrojovým stromem nové sestavování. Každý z níže uvede ných příkladů vás provede vytvořením nového souboru Make.ft/c. Jakmile bude vytvořen, jednoduše spusťte: $ malta
pro opětovný překlad Postfixu. Pokud bude nové sestavování úspěšné, můžete násle dujícím příkazem inovovat aktuálně nainstalovaný PostflX: • malta upqrade
Pokud j ste předtím PostflX neinstalovali, použijte příkaz make insta/1.
Cyrus SASL Informace o Cyrus SASL a Postfixu najdete v kapitole 1 2. Zdrojové soubory pro knihovny Cyrus SASL si můžete stáhnout z webové stránky Carnegie Mellon na adrese http://asg.wcb.cmu.cdu/sasl/sas/-/ibrary.html. Pamatujte si, že tato kniha předpokládá, že pracujete s knihovnami SASL verze 2.x. Řiďte se instrukcemi pro sestavování knihoven Cyrus SASL2. V distribuci Postfixu je také obsažen soubor SASL_README.
Jedním problémem při kompilaci s rozšířením Cyrus SASL, který ovlivňuje Postf1x, je to, zda chcete nebo nechcete zahrnout podporu pro některé klienty od společnosti Micro soft, kteří provádí ověřování pomocí nestandardního mechanismu. Standardní čistě textový mechanismus ověřování je označen jako PLAIN, ale tito klienti používají LOGIN. Pokud potřebujete podporu i pro tyto klienty, ujistěte se, že j sou knihovny sestavovány se zapnutou volbou enable login při spouštění con.ftgure. --
-
Když instalujete tyto knihovny, zapamatujte si jejich umístění. Tento příklad předpo kládá, že byly nainstalovány do adresáře I usrl loeall lib a že j sou hlavičkové soubory umístěny v adresáři I usrl loeall inc/ude. Pokud používáte jiné umístění, příklady přísluš ným způsobem upravte. Pro překlad Postf1xu s podporou SASL musíte nadef1novat makro USE _ SASL AUTH a zadat adresáře s knihovnami a hlavičkovými soubory. Musíte také provést propojení s knihovnou IibsasI2.so. Pokud je to potřeba, spusťte make ticfy. Vytvořte soubor Make.ftle s následujícími volbami: _
$ make makefiles CCARGS= ' -DUSE_SASL_AUTH - I/usr/local/include/sasl ' \
AUXLIBS= ' -L/usr/local/lib -lsas12 '
Pokud musíte zadat linkeru cestu k vašim knihovnám, zadejte správnou cestu pro vy hledávání: $ make makefiles CCARGS= ' -DUSE_SASL_AUTH - I/usr/local/include/sasl ' \
AUXLIBS= ' -L/usr/local/lib -lsas12 -rpath /usr/local/lib '
Pokud váš linker používá jiný parametr než rpath, zadejte správný parametr.
TLS Informace o TLS a PostflXu najdete v kapitole 1 3. Úpravy pro TLS najdete na stránce "Add-on Software" na webu Postf1xu. Jelikož toto rozšíření upravuje zdrojové kódy Postf1xu, ujistěte se, že j ste si stáhli správný balíček pro vaši verzi PostflXU. V tomto příkladu předpokládejme, že se stažený soubor jmenuje p.ftxtls-0.8. 13-2.0. 1 O-O. 9. 7b. lar.gz. Pokud jste stáhli jiný soubor, příklady odpovídajícím způsobem upravte. Toto rozšíření je závislé na knihovně OpenSSL, kterou musíte nejdříve nainstalovat, pokud ve vašem systému není. Podívejte se do dokumentace dodávané s distribucí TLS, abyste se ujistili, že máte správnou verzi OpenSSL. V tomto příkladu předpokládejme, že jsou vaše knihovny OpenSSL nainstalovány v adresáři I usrl loeall ssll lib a hlavičkové soubory v adresáři I usrl loeall ssll inc/ude. Pokud se vaše instalace liší, příklad odpovída jícím způsobem upravte. Ú pravy zdrojového kódu PostflXu pro použití TLS j sou všechny obsaženy v souboru p.ftxlls.difJa pro aplikování rozdílů do zdrojových souborů PostflXu použijete příkaz paleh. Ú pravu TLS byste měli rozbalit do podadresáře, který je na stejné úrovni jako adresář Postf1xu, takže pokud j ste v adresáři nadřazeném tomu se zdrojovými soubory PostflXu, můžete vidět adresář Postf1xu i adresář s úpravou pro TLS:
$ pwd /horne / kdent $ ls - ld pfixtls-O . 8 . 13-2 . 0 . 10-0 . 9 . 7b postfix-2 . 0 . 10 drwxr-xr-x 5 kdent kdent 5 1 2 May 1 4 2 0 0 2 pfixt l s - 0 . 8 . 1 3 - 2 . 0 . 1 0 - 0 . 9 . 7b drwxr-xr-x
1 5 kdent
kdent
1 0 2 4 May 3 1 1 7 : 3 1 po st fix-2 . 0 . 1 0
Z tohoto adresftře aplikujte úpravu tímto způsobem: $ patch -pO < pfixtls-O . 8 . 13-2 . 0 . 10-0 . 9 . 7b/pfixtls . diff
patch hlásí prováděné změny dokud neskončí a nezobrazí "done" na terminálu. Vraťte se do adresáře s distribucí Postfixu pro překlad Postfixu s podporou TLS. Musíte nadefinovat makro HAS SSL a zadat adresáře knihoven SSL a hlavičkových souborů. Také musíte provést propojení s knihovnami IibssLso (nebo libssLa) a libcrypto.so (nebo libcrypto.a). V případě potřeby spusťte make ticfy. Vytvořte soubor Makeftle s následujícími volbami: _
$ make makefiles CCARGS= ' -DHAS_SSL - I/usr/local/ssl/include ' \
AUXLIBS= ' -L/usr/local/ssl/lib -lcrypto -lssl '
Pokud potřebujete linkeru sdělit cestu ke knihovnám, zadejte správnou cestu pro vy hledávání: $ make makefiles CCARGS= ' -DUSE_SASL_AUTH - I/usr/local/ssl/include ' \
AUXLIBS= ' -L/usr/local/ssl/lib -lcrypto -lssl -rpath /usr/local/ssl/lib '
Pokud váš linker používá jiný parametr než rpath, zadejte správný parametr.
MySQL Informace o MySQL a Postfixu najdete v kapitole 1 5. Toto rozšíření je závislé na kli entské knihovně MySQL a na kompresní knihovně zlib, které musíte nejprve nainsta lovat. Tento příklad předpokládá, že je vaše knihovna MySQL nainstalována v adresáři I usrl loeall libl mysql, hlavičkové soubory v adresáři I usrl loeall inc/udel mysql a knihovna zlib v adresáři I usrl lib. Pokud se vaše instalace liší, příklad odpovídajícím způsobem upravte. V distribuci Postfixu je obsažen soubor MYSQL_README, který obsahuje o sestavování Postfixu s podporou MySQL. Pro překlad Postfixu s podporou MySQL musíte nadefinovat makro HAS _MYSQL a zadat adresáře knihovny MySQL a hlavičkových souborů. Musíte provést propojení s knihov nami libmysqlc/ient.so a lib:\;S0. Musíte také provést propojení s matematickou knihovnou libm.so, která je v unixových systémech standardně. V případě potřeby spusťte make ticfy. Vytvořte soubor Makeftle s následujícími volbami: $ make makefiles , CCARGS=-DHAS_MYSQL - I/usr/local/include/mysql ' \
, AUXLIBS=-L/usr/local/lib/mysql -lmysqlclient -lz - lm '
Pokud musíte linkeru sdělit cestu ke knihovnám, zadejte správnou vyhledávací cestu: $ make makefiles , CCARGS=-DHAS_MYSQL - I/usr/local/include/mysql ' \
, AUXLIBS=-L/usr/local/lib/mysql -lmysqlclient -lz -lm \ -rpath /usr/local/lib/mysql '
Pokud váš linker používá jiný parametr než rpath, zadejte správný parametr.
LDAP Informace o LDAP a Postfixu najdete v kapitole 1 5. Toto rozšíření je závislé na knihov nách LDAP, které musí být nejprve nainstalovány. Existují komerční knihovny i open-sou rce balíček dostupný na adrese http://www. openldap.org/. Tento příklad předpokládá, že máte knihovny LDAP nainstalované v adresáři I usrl localllibl a hlavičkové soubory LDAP v adresáři I usrlIocallinc/ude. Pokud se vaše instalace liší, příklad odpovídajícím způsobem upravte. V distribuci Postfixu je obsažen soubor LDAP_README s informacemi o sestavování Postfixu s podporou pro LDAP. Pro překlad Postfixu s podporou pro LDAP musíte nadefinovat makro HAS _LDAP a zadat adresáře pro knihovny a hlavičkové soubory LDAP. Musíte provést propojení s knihov nou libldap.so a také s knihovnou liblber.so, která definuje kódovací rutiny pro protokol LDAP. V případě potřeby spusťte make ticfy. Vytvořte soubor Make.ftle s následujícími volbami: $ make makefiles CCARGS= ' -I/usr/local/include -OHAS_LDAP ' \
AUXLIBS= ' -L/usr/local/lib -lldap -L/usr/local/lib -lIber '
Pokud musíte linkeru sdělit cestu ke knihovnám, zadejte správnou cestu pro vyhle dávání: $ make makefiles CCARGS= ' -I /usr/local/include -OHAS_LDAP ' \
AUXLIBS= ' -L/usr/local/lib -lldap -L/usr/local/lib -lIber \ -rpath /usr/local/lib '
Pokud váš linker používá jiný parametr než rpath, zadejte správný parametr.
Časté problémy Pokud se dostanete do problémů, podívejte se do souborů README na informace týkající se vašeho sestavování. Č asto obsahují informace o problémech, se kterými se můžete setkat. Pokud existuje soubor README specifický pro vaši platformu, samo zřejmě si jej přečtěte. Některé možné problémy j sou uvedeny níže. Přesné zprávy se mohou v závislosti na vaší platformě a kompilátoru lišit, takže j sou zde popsány jen obecné problémy, se kterými byste se mohli setkat při sestavování Postfixu.
Problémy při kompilaci No such.ftle or directory Ujistěte se, že je cesta k vašemu kompilátoru správná. Pokud jste zadali kompilátor nastavením CC při vytváření vašeho souboru Makeftle (například make make f i l e s CC=" /path ) , zkontrolujte zadanou cestu. Pokud cesta k vašemu kompilátoru pochází ze souboru Postfixu makedifs, možná ji budete muset změnit: "
$ make makefiles CC="/cesta/ke/kompilátoru"
Další možností je volání kompilátoru bez cesty, pokud je jeho adresář v cestě vašeho prostředí: $ malte maltefiles CC="cc"
Could not open soureefile Ujistěte se, že je cesta k vašim hlavičkovým souborům správná. Hlavičkové soubory jsou obvykle umístěny v adresáři / usr/ inc/ude. Pokud váš systém používá z nějakého důvodu jinou cestu, budete ji muset zadat pomocí volby - I nastavené v CCARGS: $ malte maltefiles CCARGS= " - I/path/to/include"
Pokud jste cestu zadali s volbou I, znovu zkontrolujte správnost zápisu. -
Unresolved (or undeftned) rymbol Ujistěte se, že jsou cesty ke knihovnám, které jste zadali pomocí volby - L, správné a že j ste správně zadali knihovny pomocí volby - 1 .
Warningsfrom headerfiles Pokud se setkáte s chybami spojenými s hlavičkovým souborem jako maiLeotif.h, možná nepoužíváte kompilátor ANSI C. Téměř všechny platformy obsahují kom pilátor, který se používá pro úpravy jádra, ale ne všechny obsahují kompilátor ANSI C, který byste mohli použít pro kompilaci. Možná budete muset kontaktovat pro získání kompilátoru ANSI C dodavatele. Také kompilátor GNU gee funguje skoro na všech platformách a je k dispozici jako open source software. Pokud používáte kompilátor pro HP-UX, musíte použít volbu -Ae pro kompilaci v režimu ANSI. Zadejte ji do vaší proměnné CCARGS: $ malte maltefiles CCARGS= " -Ae"
Don 't know how to Pravděpodobně se vám ztratil soubor Makefile nebo jej ještě nemáte. Soubor Makefi/e můžete vytvořit jednoduše spuštěním příkazu: $ malte -f Mlkefile . init maltefiles
Po dokončení zkuste sestavování znovu.
Problémy za běhu Error in loading shared /ibraries Ujistěte se, že jste zadali volbu - rp a th nebo -R při sestavování Postftxu a že jsou zadané cesty správné. Ujistěte se, že používáte správnou volbu pro vaši platformu. Možná se budete muset pro jistotu podívat do manuálové stránky pro /d(l).
Skript pro spouštění Pro překlad Postfixu pro vaše prostředí můžete kombinovat různé volby nebo přidávat knihovny popisované v této příloze. Pokud se váš příkazový řádek pro vytváření sou-
boru Make.ftle stane Postfix poněkud komplikovaným, měli byste vytvořit jednoduchý skript shellu, který bude spouštět příkazy s volbami a knihovnami, které potřebujete. Vytváření skriptu pro sestavování poskytuje výhodu dokumentování voleb, které byly použity při posledním sestavování Postfixu. Klidně si pro sebe zadávejte spoustu ko mentářů s vysvětlením důvodů pro použití nebo nepoužití nějaké volby a jak jste k tomu došli. Následující výpis je příkladem skriptu shellu, který byste mohli použít, ačkoliv jej pravděpodobně budete muset upravit, aby odpovídal vašemu prostředí. Tento příklad obsahuje všechny rozšiřující knihovny, které zde byly popsány. Nepotřebné byste měli vypustit: # * S imple script to create a Make f i l e to build Postfix .
# *
# Remember to start by cleaning up or uncomment t h i s l ine # t o have this script do it every time .
• #ma ke t idy
• # Spec i fy a l l of our opt i ons and supporting l ibraries # ma ke make f i l e s \ CCARGS= ' - DUSE_SASL_AUTH - DHAS_SSL -DHAS_MYSQL - DHAS_LDAP \ - I /usr/ local / include / s a s l - I /usr/ loca l / s s l / include \ - I / u s r / loca l / include/mysql - I /usr/loca l / include ' \ AUXLIBS= ' -L / u s r / l ocal / l i b -L/usr/ local / s s l / l ib \ -L/usr/ loca l / l ib/mysql -L/usr/loca l / l ib \ - l s a s 1 2 -lcrypto - l s s l - lmysql c l ient - l z -lm - l l dap - l Iber \ - rpath / u s r / local / l ib/mysql - rpath /usr/ local / l ib \ - rpath / u s r / local / s s l / l ib '
Pro překlad Postfixu zadejte: $ sh build . sh $ malta
První příkaz vytváří soubor Makifile s volbami, které potřebujete. Druhý provádí překlad.
PŘíLOHA D
Často kladené dotazy
Nemohu př!Jimat ifJráry. Co znamená cf?yba ,, : mailfor example.com loops back to myse!!,,? Postfix hlásí tuto chybu, když odpověď DNS ukazuje na váš poštovní server, ale Postfix nebyl nastaven tak, aby přijímal poštu pro tuto doménu. Postfix přijímá poštu pro domény uvedené v parametrech mydestination, relay_domains, virtual_mai l box_domains, vi rtual_alias _domains a domény, které jsou přeloženy n a adresy IP uvedené v inet _ interfaces a proxL interface s . Vaše doména musí být uvedena v jednom z těchto parametrů.
K4Yžprovedu změtry v konjiguračních souborech nebo ryhledávadch tabulkách, musím restartovat Postftx? To záleží na druhu souboru, který měníte. Změny v souborech, které Postfix načítá do paměti při spuštění, vyžadují restart. Příkladem takových souborů j sou main.cj, master.if a jakákoliv vyhledávací tabulka používající regulární výrazy. Soubory DB nebo DBM nejsou načítány do paměti a nevyžadují po změně restart Postfixu.
Exist,,!/e nijalrj druh direktiry "inc/ude "pro main.if? Ne. Většina správců se složitými konfiguracemi vytváří soubor Makejile, který spojuje potřebné soubory. Pokud máte jiné úlohy správy, přidejte je také do souboru Makejile. Váš Makifile by měl obsahovat položku, která vypadá podobně jako: ma in . c f : f i l e l f i le2 f i l e 3 cat f i l e l f i l e 2 f i l e 3 > ma in . c f . new mv ma in . c f . new ma in . c f
Pak zadejte make main.ifpro opětovné sestavení vašeho konfiguračrubo souboru.
Kde mohu :ifskat informace o doručovánípošty? To v Postfixu momentálně není možné.
Jak mohu přidat nebo připqjit nijalrj text na konec každé '{jJráry, která f:yla odeslána Z mého serveru? To v Postfixu není implementováno přímo. Není to úloha MTA a z důvodu pou žívání MIME a digitálních podpisů to není tak jednoduché, jak by se mohlo zdát. Zprávy MIME mají strukturu, která může být velmi složitá. Digitální podpisy slouží
k ověření, že podepsaná zpráva nebyla upravena. Přidání zápatí na konec zprávy oboje porušuje. Někteři lidé přidávají krátký text do záhlaví a zápatí e-mailů, ale tento text pravděpodobně není většinou uživatelů spatřen. Správným řešením je nastavení poštovních klientů pro přidávání požadovaného textu. Jak již bylo řečeno, je možné nastavit ftltr obsahu, který požadovaný text připojí. Řiďte se instrukcemi pro nastavování PostflXU pro práci s ftltrem obsahu. Váš filtr by měl znát MIME a měli byste vědět, že digitální podpisy pak nebudou fungovat.
Jak mohu ulo:ijt koPii každé tPráry? Zadejte adresu do parametru always _bcc. Na tuto adresu budou chodit kopie všech zpráv.
Jak mohu zapnout kvótu nebo omezení velikosti schránek u:ijvatelů? Toto skutečně není funkce Postfixu, ačkoliv toho můžete dosáhnout pomocí para metru mai lbox_ s i ze _limit. Pamatujte si, že pokud použijete schránky ve formátu maildir, omezuje tento parametr pouze velikost jednotlivých souborů pošty a ne velikost celé schránky. Kvóty schránek jsou nejlépe prosazovány samotným úložiš těm pošty, čehož je možno dosáhnout pomocí nástrojů operačrubo systému nebo pomocí konfigurace vašeho serveru POP /IMAP' Když Postfix odesilá zprávu zpět, sděluje odesilateli "For further assistance, please send mail to <postmaster>". Chtěl bych, aby byl v adrese i název domény, např. <[email protected]>. Jak je to možné udělat? Tato zpráva znamená, že by měli uživatelé kontaktovat svého vlastrubo správce pošty, jelikož je s největší pravděpodobností místní správce pošty tím, kdo musí vyřešit problém. Pokud byste chtěli i přesto tuto změnu provést, musíte upravit zdrojový kód.
Mám alia.ry a pouze první adresa v seiJ1amu přijímá tPráry. Ostatní mohou přijímat tPráry ktfyžje pošlupřímo na ně, ale pokudjsou součásti aliasu,jqich tPráry nedoraif. Pokud používáte pro doručování externí program, možná neumí zpracovat více než jednu zprávu najednou. Napřľklad jako v případě maildrop. Pro zajištění toho, aby Po stflX předával zprávy pro doručení po jedné, nastavte parametr transport_des tina t ion_recipient_l imi t v souboru main.ifna 1. transport je název metody transportu provádějící doručování. Pokud používáte maildrop, parametr vypadá takto: ma i l drop_de s t inat ion_recipient_l imit
=
1
Mám v rystému několik rozhraní. Jak mám nastavit, al?Y se Posifixpřipqjovalpomodpouzejednoho Z nich? Zadejte do parametru inet_ interfaces adresu IP rozhraní, které má Postfix po užívat. u Sendmailujsem powffval varován� pokud nemohla Idt tPráva čtyři hodif!Y doručena. Mohu tak
nastavit i Posifix? Toto se nastavuje pomocí parametru delay_warning_t ime. Implicitně je nastaven na O pro "nikdy".
Pokoulím se testovat seif1am aliasů, al!Jch vidl4 které adre.ryjsou expandová'!} Z konkrétních seif1amů. UJi'!Ýchpoftovních servemjsempouť/valpříkaZ EXPNpro i/skání kompletního seif1amupříjemců, ale Zdá se, že s Postfixem nefunguje. PostflX nepodporuje EXPN. Z důvodu architektury PostflXu a z důvodu zabezpeče ní neprivilegovaný server SMfP neví nic o místních aliasech. Skutečné expandování aliasů při doručování provádí privilegovaný místní agent pro doručování. Pokud používáte správce elektronické konference, je velice pravděpodobné, že poskytuje příkaz, který vám sdělí, kdo je v seznamu nebo možná budete muset zkontrolovat soubor s aliasy v systému poštovního serveru.
Jakjje rozdíl mezi mailbox_transport a mailboxjommand? Parametr mai lbox_t ransport je nastaven na službu v souboru master.rf, zatímco ma i lbox_command se odkazuje na skutečný příkaz v systému souborů poštovrubo serveru. Existuje několik parametrů, které mohou ovlivnit doručování do schránky. Parametry jsou zpracovávány v pořadí podle preference mai lbox_transport, mai l box command maps, mai lbox_command a home_mai lbox. _
_
Přenos do vfech mých interních .rystémůje prováděn skrze mou poftovní bránu. Existuje ilJůsobjak odstranit nebo skryt nái!!Y hostitelů a adre.ry IP mých interních .rystémů v záhlaví ilJráv předjo/ich odesláním? Přidejte kontrolu záhlaví, která bude porovnávat řádky záhlaví obsahující informace o interních systémech a zadejte pro ně akci IGNORE.
Jak mohu říci Postftxu, al!Jpředával dál vfech'!Y ilJráty, kteréjsou odeslá'!} na neexistující schrán/tg konkrétnímu uijvateli? Můžete zadat adresu do parametru luserJelay a vypnout local_ recipient maps: _
luser_re lay info local_recipient_maps =
=
Buďte opatrní. S nárůstem množství nevyžádané pošty bude adresa, kterou zadáte, dostávat velké množství nevyžádané pošty.
Podle mého nastave'!Y I?J mll Postftx odpovídat neustále cf?ybotjm kódem (554), ale stále posílá dočasnou cf?ybu (454). Proč to dělá? Pravděpodobně máte zapnutou volbu soft_bounce.
Mám ve.frontě spoustu pošty, o které vím, žeji nepombu;i. Je mo:f!ré nějak odstranit vfech'!} ilJráty ve.fronte? t postsuper -d ALL
Pamatujte si, že slovo ALL musí být napsáno velkými písmeny, a že provedení tohoto přľkazu odstraní všechnu poštu ve frontě.
Kam Postftxprotokoluje informace? PostflX protokoluje zprávy do démonu .ryslogd vašeho systému. Pro nalezení souboru protokolu se podívejte do dokumentace vašeho systému.
Výpadá to, že Postftx ignoruje záif1am MX a pokoulí se doručovat přímo na záif1am A. Je to normální? Je to normální, pokud máte nastaveno: disable_dn s_loo kups
=
yes
v souboru main.if. Také můžete mít transportní mapu zadanou v závorkách a v tom případě Postfix doručuje přímo do systému: example . com
smtp : [ ma i l . example . com]
Dostávám mnoho ne1!Yžádaných �ráv bez obálkové adre.ry odesílatele. Jakje mohu blokovat? Nechcete blokovat zprávy podle toho, zda mají prázdnou návratovou cestu. Pří jem prázdných adres obálky je vyžadován standardy. Tato technika se používá pro zabránění vytvoření smyčky chybových zpráv. Budete muset nevyžádanou poštu identifikovat jinými prostředky.
Pou�vám pro blokování ne1!Yžádané pofty headerjhecks a bo4Jjhecks, ale mé kontrolY blokují některé legitimní �rá1!Y. Existuje mo�ost, jak nastavit, al?J na některé �rá1!Y nel?JIY apliková'!)' kontrolY Záhlaví a těla �ráv? Ne. Kontroly záhlaví a těla jsou aplikovány na každou zprávu a měly by být použí vány pro jednoduché kontroly, které mohou být jednoduše aplikovány na veškerou poštu. Pokud potřebujete něco sofistikovanějšího, měli byste nastavit ftltr obsahu, který má potřebnou inteligenci.
Rejstřík
A access_map_rejecccode 1 34, 1 88 additionaLconditions 1 79, 1 81 , 1 82 adresy obálky 1 3 aktivní fronta 21 , 25, 58, 61 zprávy označené hvězdičkou (*) 61 aktivní útoky 1 54 alias_database 37, 38, 1 1 3, 1 1 7, 1 21 alias_map s 37 aliasy 22, 37 allow_mai1_to_commands 39 allow_mai1_toJtles 39, 1 89 allow_percenchack 1 89 alternate_confi�directories 1 89 anonymní přihlášení 1 54 append_acmyorigin 52, 1 89 append_dot-':'mydomain 52 architektura Postfixu 1 8 authorized_verp_clients 1 89 autoritativní názvové servery 67 auxprop 1 5 1 B
backscatter 1 24 backup MX 1 0 1 berkeley_db_read_buffer-size 1 90 biff 1 90 BIND (server DNS) 68 body_checks 1 41 body_checks_sizclimit 1 90
bounce_service_name 1 90 bounce_size_limit 58 brány 53, 75, 1 07 broken_sasl_auth_clients 1 53 btree (databáze pro vyhledávací tabulky) 33, 1 77 c
certifikační autority (CA) 1 60 certifikáty 43, 1 59, 1 60, 1 6 1 class_notice_recipient 60 cliencaccess 1 36 clientcerts 1 66 command_directory 1 90 command_time_limit 1 9 1 CSR (Certificate Signing Request) 1 62
Č černé listiny 1 26 D
démon defer 20 pickup 1 9 pipe 23 qmgr 57 smtpd 20 syslog 44 trivial-rewrite 1 9, 20, 21 daemon_directory 49
databáze externí 1 77 LDAP 1 83 MySQL 1 78 dbm 33, 36 dbname 1 79 debug...p eedist 1 9 1 defaulcdatabase_type 33, 3 8 defaulcdestination_concurrency_limit 59, 1 9 1 defaulcdestination_recipienclimit 204 defaulcextra_recipienclimit 1 91 defaulcprivs 39, 80, 1 20 defaulcprocess_limit 49, 59, 1 92 defaulcrecipienclimit 1 92 defaulcverp_delimiters 1 92 defecservice_name 1 92 defer_transports 1 06, 1 07 delay_notice_recipient 1 92 deliver_Iock_attempts 1 92 Delivered-To: 1 1 5 denial-of-service (DOS) 1 24 dig 7 1 DIGEST-MD5 1 49 digitální podpisy 1 60, 226, 227 disable_dns_lookups 1 93 disable_mime_outpucconversion 1 93 disable_vrfy_command 1 93 DNS (Domain Name System) blacklist 1 26 konfigurace virtuálních domén 72 směrování pošty 67 záznamy MX 67, 68 DNSBL (DNS-based Blacklists) 1 26 domény autoritativní názvové servery 67 fascflush_domains 65, 1 03 hosting více domén 87 doručení pošty 21 dotlock 77 double_bounce_sender 1 93 DRAC (Dynamic Relay Authorization Control) 42, 43
E e-mail správce (postmaster) 1 2 e-mailové konference 1 1 ° empty_address_recipient 1 93 encode_sasl_plain (skript jazyka Perl) 1 56 error_service_name 1 94 ESMTP (Enhanced SMTP) 1 7, 1 03 expand_owner_alias 1 1 2 exporcenvironment 1 94
F fallback_relay 1 94 fallback_transport 83, 84 fascflush_domains 65, 1 03, 1 94 fascflush_refresh_time 1 94 fcnt 77 fifo 47, 48 ftltecdestination_recipienclimit 1 7 1 ftltrování obsahu 1 69 založené na démonech 1 72 založené na příkazech 1 70 flock 77 fork_attempts 1 94 forward_expansion_ftlter 1 95 forward_path 79, 80 G
gethostname 40
H hash_queue_depth 1 95 header checks 1 30, 1 35, 1 43, 1 44, 229 headecaddress_token_limit 1 95 header_checks 36, 1 29, 1 4 1 , 1 99 headecsize_limit 1 43, 1 95 home_mailbox 80, 1 95 hosting více domén 87 hosts, nastavení pro MySQL 1 79 https 1 6 1
CH check_cliencaccess 1 30, 1 34, 1 35 check_helo_access 1 30, 1 34 check_recipiencaccess 1 30, 1 34
check_sender_access 1 3 1 , 1 34 chroot 7, 47, 48, 49, 55
IETF (Internet Engineering Task Force) 4, 1 2 ignore_mx_lookup_error 1 96 lMAP 75 in_flow_delay 1 96 initial_destination_concurrency 59, 1 96 ipcidle 1 96 J
jednorázová hesla (OTP; One-Time Passwords) 1 49
K kanonické adresy 5 1 Kerberos 1 49 klientské certifikáty 1 59, 1 68 knihovna OpenSSL 1 6 1 kódování base64 1 48, 1 55 kódy odpovědí 1 6 komponenty Postfixu 1 8 konfigurační soubor main.cf 29, 30 majordomo.cf 1 1 6 master.cf 46 mysql-Iocal.cf 1 81 konfigurační soubory 29 konfigurační soubory databázové formáty 33 ostatní formáty 36 vyhledávací tabulky 32
L LDAP 1 83 line_Iength_limit 1 43, 1 96 LMrP (Local Mail Transfer Protocol) 82 lmtp_connecctimeout 1 96 lmtp_data_inictimeout 1 97 lmtp_lhlo_timeout 1 97 lmtp_quictimeout 1 97 lmtp_tcp_port 1 97 local_destination_concurrency_limit 1 97
local_recipiencmaps 1 97 local_transport 83, 84 LOGIN 1 48 lusecrelay 54, 1 98
M mail_owner 1 98 mail_spooLdirectory 1 98 mailbox_command 1 98 mailbox_delivery_lock 1 98 mailbox_ttansport 1 98 maildir 76 maildrop 1 9 Mai1man 1 1 9 main.cf 1 8, 29, 30 Majordomo 1 1 5 majordomo.cf 1 1 6, manpage_directory 1 98 MANPATH 56 masquerade_classes 53 masquerade_domains 1 99 masquerade_exceptions 53 master.cf 46 max_idle 1 99 maximal_backofCtime 1 99 maximal_queue_lifetime 58, 1 02 maxproc (master.cf) 49 mbox 76 MDA (Mail Delivery Agent) 3, 1 2 message_size_limit 1 99 MIME 1 4 mime_headecchecks 1 41 , 1 99 minimal_backofCtime 59, 1 99 místní domény 72, 75 místní doručování 21, 75 .forward 22 formáty úložiště zpráv 76 LMTP (Local Mail Transfer Proto col) 82 MLM (Mailing List Managers) 1 1 0 MTA (Mail Transfer Agent) 3, 1 2 MUA (Mail User Agent) 3 , 1 2 mutual_auth 1 54 mydestination 22, 3 1 mydomain 28, 40
myhostname 40 mynetworks 32, 41 mynetworks_style 41 , 42 myorigin 40 MySQL 1 78 mysql-Iocal.cf· 1 81
N nástroje pro příkazový řádek 7 1 , 21 1 názvy domén maskování názvů hostitelů 53 myorigin 3 1 , 40, 5 1 plně kvalifikované 1 37 nested_headecchecks 1 41 newaliases_path 200 NIS 37 noactive 1 54 noanonymous 1 54 nodictionary 1 54 non_fqdn_rejecccode 1 37 noplaintext 1 54 notify_classes 200 nslookup 7 1 nsswitch.conf 74 o
odložená pošta 58 okamžité odeslání zpráv 65 ověřovací mechanismus ANONYMOUS 1 49 ověřování 42, 43, 1 47 ověřování SMTP 1 57 ownecrequescspecial 1 1 2
P PAM 1 49 parencdomain_matches_subdomains 200 pcre (perl-compatible regular expressions) 33, 35, 1 77 PEM 1 6 1 Perl 35 permicauth_destination 1 36 permicmynetworks 1 36 permicsasl_authenticated 1 52 permictls_clientcerts 1 67
PGP 1 59 pickup_service_name 201 PKCS 1 2 1 65 PLAIN 1 48 plně kvalifikovaný název hostitele 28, 30, 40, 53 POP 75 POP/lMAP 75 pop-before-smtp 42 pořadí hledání 34 posítě 35, 41 POSIX (portable Operating System Interface) 35 process_id_directory 201 program pro automatickou odpověď 97 protokolování 43 proxy_interfaces 69, 73, 201 předávání pošty 1 0 1 příkaz AUTH 1 53, 1 55 egrep 44 EHLO (SMTP) 1 7, 1 40 echo s přepínačem ?n 1 56 ETRN 65, 1 03, 1 06 HELO (SMTP) 1 6, 1 7 MAIL FROM (SMTP) 1 6, 1 30, 1 33 mailq 61 mmencode 1 56 newaliases 28, 29, 37, 38 newlist (Mailman) 1 2 1 , 1 22 openssl 1 6 1 postalias 21 1 postcat 21 1 postconf 21 1 postdrop 21 1 postfix 21 1 postkick 21 1 postlock 21 1 postlog 21 1 postmap 21 2 postqueue 21 2 postsuper 2 1 2 printf 1 56 RCPT TO (SMTP) 1 30, 1 3 1 saslpasswd2 1 52
sendmail 45 SQL vytvářený Postfixem 1 79 STARrrLS 1 6 1 přístupové mapy 1 3 1 , 1 33 příklady 1 35, 1 36 tabulky s regulárními výrazy 1 35 pseudoúčty 1 0
Q qmgcclog...warn_time 201 qmgcmessage_active_limit 201 qmgcmessage_recipiencminimum 201 qmqpd_error_delay 202 queue_directory 57 queue_minfree 57 queue_run_delay 202
R rbl_reply_maps 202 recipienccanonicaLmaps 52, 202 regexp 35 regulární výrazy 35 reject 1 3 1 rejecccode 1 34, 202 rejeccinvalid_hostname 1 37 rejeccnon_fqdn_hostname 1 37 rejeccnon_fqdn_recipient 1 37 rejeccnon_fqdn_sender 1 37 rejeccrbLclient 1 38 rejeccrhsbl_client 1 38 rejeccrhsbl_sender 1 39 rejeccsendeclogin_mismatch 1 53 rejeccunauth_destination 1 36 rejeccunauth_pipelining 1 37 rejeccunknown_client 1 37 rejeccunknown_hostname 1 38 rejeccunknown_recipiencdomain 1 38 rejeccunknown_sender_domain 1 38 rekurzivní hledání 34 relay_domains 22, 32, 75, 1 0 1 relay_domains_rejecccode 203 relay_recipiencmaps 1 02, 1 08 relay_transport 203 relayhost 1 09 relocated_maps 34, 54, 203
resolv.conf 55, 74 resolve_dequoted_address 203 reverzní mapování PTR na název hostitele 67 reverzní vyhledávání adres IP 1 34 RFC 4 RFC 2 1 42 1 2 RFC 2554, "SMTP Service Extension for Authentication" 1 47 RFC 2821 (protokol SMTP) 4 RFC 2822 (záhlaví zpráv, formát zprávy a adresy) 1 2 RFC 3207, STARrrLS 1 59 RFC 822 (formát zprávy) 1 2 RFC 882 (DNS) 66
S S/Key 1 49 S/MIME 1 59 sample_directory 203 SASL 1 47 saslauthd 1 5 1 sasldb 1 51 seleccfield 1 79 sendeccanonical_maps 52 Sendmail 1 sendmail_path 203 sestavování Postftxu 2 1 3 setgid-,group 204 showq_service_name 204 silné ověřování 1 59 skrývání názvů interních hostitelů 53 skupina postdrop 28 slovníkové útoky 54, 1 23 směrování pošty 67 SMTP 4 smtp_bind_address 204 smtp_connecctimeout 50 smtp_data_done_timeout 204 smtp_data_xfectimeout 204 smtp_destination_concurrency_limit 59 smtp_helo_timeout 205 smtp_mail_timeout 205 smtp_pix_workaround_delay_time 205 smtp_quictimeout 205
smtp_randomize_addresses 71 smtp_rcpctimeout 205 smtp_sasCauth_enable 1 58 smtp_sasl_password_maps 1 58 smtp_sasl_security_options 1 58 smtp_skip_5xx�reeting 205 smtp_tls_CAftle 1 67 smtp_tls_cercftle 1 67 smtp_tls_keyJtle 1 67 smtp_use_tls 1 67 smtpd.conf 1 50 smtpd_banner 206 smtpd_cliencrestrictions 1 28 smtpd_data_restrictions 1 28 smtpd_delay_reject 1 3 1 smtpd_error_sleep_time 206 smtpd_expansion_ftlter 206 smtpd_hard_error_limit 50 smtpd_helo_required 1 40 smtpd_helo_restrictions 1 28 smtpd_history_flush_threshold 206 smtpd_noop_commands 207 smtpd_recipienclimit 207 smtpd_recipiencrestrictions 1 28 smtpd_restriction_classes 1 44 smtpd_sasl_auth_enable 1 52 smtpd_sasl_security_options 1 54 smtpd_sendec1ogin_maps 1 53 smtpd_sender_restrictions 1 28 smtpd_sofcerroclimit 50, 207 smtpd_tls_ask_ccert 1 67 smtpd_tls_CAftle 1 63, 1 64 smtpd_tls_CApath 1 64 smtpd_tls_cercftle 1 64 smtpd_tls_keyJtle 1 63 smtpd_use_tls 1 63 sockectype 84 sockety 83 sofcbounce 1 32, 207 soubory aliasů 37 spam 1 23 spouštění při startu systému 45 správa fronty 46 správce fronty 1 9, 20 SSL 1 47
stderr 1 0 stdin 1 0 stdout 1 0 strace 56 stricC7bicheaders 207 stricc8bitmime_body 208 striccrfc8213nvelopes 208 subdomény 53, 1 04 swap_bangpath 208 symbolické odkazy 56 syslog...name 208
š šifrování, TLS 1 59
T telnet 1 5 TLS (Transport Layer Security) 1 59 transport smtp 1 07 transport_destination_recipienclimit 60, 97 transporcmaps 23 transporcretry_time 208 transportní mapy 1 04 trus S 56 trvalé úložiště 4 třídy adres 21 třídy adres 21 třídy chyb 60 tusc 56 U
UBE (Unsolicited Bulk Email) 41 , 1 23 úložiště zpráv 76 undisclosed_recipients_header 208 unixové sockety 83 unknown_address_rejecccode 1 38 unknown_cliencrejecccode 208 unknown_hostname_rejecccode 1 38 unknown_local_recipiencrejecccode 209 unknown_virtual_alias_rejecccode 209 útoky 7, 54, 1 23, 1 54 útoky DDoS (Distributed Denial-of-Service) 1 26
útoky DOS (denial-of-service) 7 útoky man-in-the-rniddle 1 54 UUCP 1 09 uuencode 1 4 uživatelské účty 9 , 1 02, 1 80, 1 85 v
verp_delimitecfJ1ter 209 Vexira AntiVirus pro poštovní servery 1 75 virtual_alias_domains 22, 72, 88, 92 virtual_alias_maps 22, 34, 89, 9 1 , 209 virtual�d_maps 9 1 virtual_mailbox_base 90, 1 82, 209 virtual_mailbox_domains 22, 76, 89, 93 virtual_mailbox_limit 209 virtual_mailbox_maps 2 1 0 virtual_transport 2 1 0 virtual_uid_maps 9 1 virtuální aliasy 72, 7 5 , 9 1 virtuální domény 72, 87, 88 virtuální schránky 22, 75, 90 virtuální účty 87, 1 50
vyhledávací tabulky aliasy 22, 25, 28, 37, 38 canonical_maps 32, 34, 5 1 externí databáze 1 77 kanonické adresy 51 přístupové mapy 131, 1 33, 1 35 vzdálení uživatelé 42 w
wakeup (master.ct) 49 warn_iCreject 1 32 where_field (MySQL) 1 79, 1 81 WHOSON 42, 43
Z záhlaví Received: 1 4 zamykání souborů 77 záznamy A 67 CNAME 67 pro poštovní servery 70 PTR 67 znaky ASCII v těle e-mailové zprávy 1 4
o autorovi Ky1e. D. Dent pracuje v New Yorku jako nezávislý konzultant a vývojář. Navrhl a im plementoval různé bezpečnostní, síťové a webové aplikace pro výrobní a ftnanční spo lečnosti. S Postftxem s různými nastaveními pracoval od jeho vydání společností IBM v roce 1998.
Kyle D. Dent začal pracovat s počítači v IBM, ale původně pracoval v nakladatelství a jako učitel angličtiny pro cizince. Je nadšeným stoupencem veřejných knihoven a pracuje jako člen správní rady místní knihovny. Nedávno se začal učit hrát na klasickou kytaru.
Tiráž Vzhled našich knih je výsledkem komentářů čtenářů, našeho vlastního experimentování a zpětné vazby z distribučních kanálů. Charakteristické obálky doplňují náš zvláštní přístup k technickým tématům a oživují potenciálně suchá témata. Zvířetem na obalu knihy je holub. Holubi patří do třídy ptáků a řádu Columbiformes (holubi), do které patřil také dnes již vymřelý pták Dodo (Raphus cucullatus) . Jejich čeleď Columbidae zahrnuje více než 300 druhů holubů, včetně holuba skalrubo nebo divokého (Columba livia) . V roce 1 679 objevil francouzský astronom Augustin Royer souhvězdí Columba ve tvaru holubice, jehož hvězdy nacházející se poblíž souhvězdí Puppis (Lodní záď) a Caelum (Rydlo) byly původně součástí souhvězdí Canis Major (Velký pes) . Odpovědným redaktorem této knihy byl Reg Aubry a jejím korektorem byl Matt Hut chinson. Kvalitu knihy kontrolovali Colleen Gorman a Claire Cloutier a asistentkou produkce byla Mary Agner. Rejstřík této knihy vytvořila Ellen Troutman-Zaig. Obálku této knihy, na základě graftckého návrhu série, který vytvořil Edie Freedman, navrhla Ellie Volckhausenová. Obrázek na obálce je původní ilustrací, kterou vytvořila Susan Hartová. Vnitřní stranu obálky vytvořila Emma Colbyová v programu QuarkX Press 4. 1 s použitím písma ITC Garamond od společnosti Adobe. Vnitřní rozložení navrhl David Futato. Joe Wizda převedl tuto knihu do formátu aplikace FrameMaker 5.5.6 pomocí konverzrubo nástroje, který vytvořili Erik Ray, Jason McIn tosh, Neil Walls a Mike Sierra s použitím technologií Perl a XML. Použitým písmem je Linotype Birka. Písmem pro nadpisy je Adobe Myriad Condensed a pro výpisy kódu bylo použito písmo TheSans Mono Condensed. Ilustrace objevující se v knize vytvořili Robert Romano a Jessamyn Read v programech Macromedia FreeHand 9 a Adobe Photoshop 6. Ikony pro tipy a varování nakresW Christopher Bing. Tuto tiráž napsali Leanne Soylemez a Reg Aubry.
Předmluva
Všichni programátoři jsou optimisté - tato moudrá slova byla napsána téměř před třiceti lety panem Frederickem P. Brooksem, Jr: Poštovni systém Postftx je toho příkladem. Postftx začínal jako půlroční projekt, když jsem navštívil oddělení sítí a zabezpečení spo lečnosti IBM Research ve státě New York. Ačkoliv půl roku stačilo k nahrazení poštovního systému na mé pracovní stanici, nestačilo na vytvoření kompletního poštovního systému pro obecné použití. V průběhu následujícího roku bylo přidáno mnoho kódu a software byl testován uzavřenou skupinou expertů. A v pěti letech po zveřejnění se velikost a počet funkcí systému Postftx více než zdvojnásobily. Mezitím pokračuje aktivní vývoj . Jedním z hlavních cílů systému Postftx je jeho široké přijetí. Vytvoření systému Postftx bylo pouze prvnim úkolem na cestě k cíli. Druhým úkolem bylo zpřístupnění software. Zatímco si zkušení uživatelé rádi přečtou příručku, která je vydávána s PostflXem, většina lidí potřebuje jemnější přístup. Popravdě bych neočekával široké přijetí Postftxu bez knihy seznamující s koncepty na pozadí systému s příklady toho, jak provádět nejběžnější úlohy. Rád jsem ponechal napsání této knihy na Kyle Dentovi. Stejně jako Postftx se vyvíjí i tato kniha. Od doby, kdy byla napsána první verze této knihy, Postftx prošel několika většími změnami. Některé změny byly výsledkem diskuse s Kylem za účelem zjednodušení pochopení Postftxu, některé změny přidaly funkce, které v předchozích verzích chyběly, a některé změny si vynutily nevyžádané zprávy a počítačové viry. Kromě změn, které představovaly nové nebo rozšířené funkce, bylo jako součást pokračující údržby a vylepšování provedeno mnoho méně viditelných změn. Tato kniha popisuje Postftx verze 2.1 a popisuje některé z rozdílů oproti starším verzím Postftxu, které byly v době vydání rozšířené. Jak se Postftx vyvíjí, bude se pomalu odklá nět od této knihy a tuto knihu bude potřeba aktualizovat. I když je pro mě potěšením uvítat vás u této verze, už se těším na další možnost setkání v blízké budoucnosti. -Wietse Venema Hawthorne, New York 1 9. září 2003 •
Frederick
P.
Brooks,]r.:
The Mythicol Mon·Month: Essays on softwa,. Engineering, Addi.son Wesley, 1 975.
O'REILLY Postfix: kompletní průvodce Postftx je MTA (Mail Transfer Agent) - software používaný poštovními servery pro doručování elektronické pošty. Postftx je experty respektován pro svůj bez pečný návrh a obrovskou stabilitu a noví uživatelé jej mají rádi pro jeho snadné nastavování. Postftx byl také přijat jako výchozí MTA pro systém MacOS. Je kompatibilní s programem Sendmail, takže stávající skripty a programy fungují i po jeho instalaci. Postftx vytvořil známý bezpečnostní expert Wietse Venema, jenž tuto knihu posuzoval již v průběhu jejího vzniku. Autor Kyle D. Dent popisuje mnoho úloh Postftxu od virtuálního hostingu po práci s nevyžádanými komerčními zprávami. I když je základní konftgurace Postftxu snadná, má každý server unikátní potřeby vyžadující
určitou míru studia. Tato kniha pomocí vysvětlování pozadí a mnoha příkladů usnadňuje čte nářům základní nastavení i dosažení maximálního výkonu Postftxu. Popisuje rozhraní Postftxu pro různé nástroje umožňující vytvoření plně škálovatelného a velmi bezpečného poštovního systému. Tyto nástroje zahrnují POP, lMAP, LDAP, MySO!-, SASL (Simple Authentication and Security Layer) a TLS (Transport Layer Security), jež je zdokonalením SSL. Součástí publikace je referenční příručka s parametry Postftxu a průvodce instalací. Kniha obsahuje tato témata: •
Základní instalace a nastavení
•
Nastavení DNS pro elektronickou poštu
•
Práce se servery POP/lMAP
•
Hosting více domén (virtuální hosting)
•
E-mailové konference
•
Blokování nevyžádaných zpráv
•
Zabezpečení pomocí SASL a TLS
Grada Publishing, a.s. U Průhonu 22, 170 00 Praha 7 tel.: +420 220 386 401 fax: +420 220 386 400 e-mail: [email protected] www.grada.cz
Q'REILLY®
