O`REIl.Ly - michonet.sk

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 <kdent@ example . com> ;
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 <info@orei l l y . com>
To : < kdent @ example . com>
Repl y-To : <info@orei l l y . com>
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 : <info@oreilly . com>
2 5 0 Ok
RePT TO : <kdent@example . com>
2 5 0 Ok
DATA
3 5 4 End data with <CR><LF> . <CR><LF>
Date : Mon , 8 Apr 2003 15 : 38 : 21 -0500
From : Customer Service <info@oreilly . com>
To : <kdent@example . com>
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 : <info@ore i l l y . com>
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 <CR><LF> . <CR><LF>
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 <adresa_elektron i c ké_pošty>
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 <adresa_e l e ktroni c kéyošty> \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 = <QUEUE> ;
$1 = "";
# Přeskočit j eden řádek záhlaví .
• Zbytek položek fronty vyt i s knout
• na více řádků .
while ( $entry = <QUEUE> ) {
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=<he l o i se@ora . com> , \
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=<abe l a rd@ example . com> , \
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=<heloi se@ora . com> , \
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=<abe lard@ example . com> ,
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=<he l o i se@ora . com> \
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=<abe l ard@ example . com> \
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=<heloise@ora . com> \
s i ze=30 6 , nrcpt=l ( queue active )
postfix/ smtp [ 3 93 7 ] : CCBEDIE8 : to=<abelard@example . com> \
� 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-<alias_konference>@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 : <owne r-needlepoint@example . com>
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 <needlepoint@ example . com> 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 <gmhoppe r@onlamp . com>
X-Sender : gmhoppe r@ cowrie
To : needlepoint@ example . com
Subj ect : Jus t finished 1atest proj ect
Mes sage - I D : <Pine . GSO . 4 . 1 0 . 1 0 2 0 5 1 3 1 2 0 0 2 3 0 . 6 92 - 1 0 0 0 0 0 @ cowr ie>
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
<lisCalias>[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=<needlepoint@ example . com> ,
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=<owner-needlepoint@example . com> ,
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=<bogus @ example . com> relay= l oca l ,
de lay= l , status=bounced (unknown user : "bogus " )
postfix/smtp [ 65 5 6 ] : ACDC 1 2 0DD7 0 : to=<grayburn@orei l l y . com>
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=<rgrier@ore i l l y . com>
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=<gmhopper@onlamp . com>
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=<owner-needle­
point@example . com» . Neplatná adresa ukazuje stav "bounced". Oznámení o odmítnutí,
které vypadá jako to v přtKladu 1 0-3, je odesláno na alias vlastru'ka, který ukazuje na
adresu [email protected]. Všimněte si, že zpráva oznamující odmítnutí je doručena na
adresu [email protected]. Odesílatel zprávy oznámení neobdrží.
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
<bogus@exampl e . com> : 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 <ast ronomy@example . com> .
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
<ast ronomy@example . com> : 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:<[email protected]
Server: 250 OK
smtpd_helo_restrlctions
>
Klient: RCPT TO:<[email protected]
Server: 250 OK
smtpd_sender_restrlctlons
>
smtpd_recipient.... restrlctions
Klient: DATA
Server: 354 End data wlth <CRxLF>.<CR><LF>
Klient: To: Kyle Dent<[email protected]
From:<[email protected] >
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=<kdent @ smtp . example . eom> ,
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'­
<klfl pfedaný PosfflXBfT7>
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 ,, <[email protected]>: 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®