Cryptoloop

Cryptoloop
O tomto dokumentu
Tento dokument HOWTO popisuje, jak lze použít šifrování zařízení pomocí Cryptoloop v řadě jader 2.6 systému Linux.
Cryptoloop umožňuje vytvořit šifrované systémy souborů v rámci oddílu nebo jiného souboru v systému souborů. Tyto šifrované
soubory lze přesunout na disk CD, DVD, paměťové zařízení USB atd. Cryptoloop používá tzv. loopback zařízení. Jedná se o
pseudozařízení fungující jako „smyčka“, přes kterou musí projít každé volání systému souborů. Díky tomu lze zpracovat data,
která mají být šifrována a dešifrována. Od verze jádra 2.6 bylo rozhraní Crypto API integrováno do hlavního jádra a nastavení
šifrovaného systému souborů se značně usnadnilo. Nejsou požadovány žádné další záplaty jádra. Je však nutné aktualizovat
některé uživatelské nástroje. K práci s nástrojem Cryptoloop zatím bohužel neexistuje kvalitní dokumentace. Tento dokument
HOWTO byl vytvořen proto, aby všem zájemcům usnadnil vytvoření šifrovaného systému souborů pomocí standardních funkcí
nástroje Cryptoloop. Nástroj Cryptoloop je založen na rozhraní Crypto API v jádře 2.6 systému Linux. Neměli byste jej
zaměňovat se zařízením Loop-AES, což je zcela nezávislý projekt. Cryptoloop se podobá rozhraní Crypto API, které bylo k
dispozici jako samostatná záplata pro jádra řady 2.4. Nová verze není se starou verzí kompatibilní.
Zřeknutí se odpovědnosti
Autoři nepřijímají žádnou odpovědnost za obsah tohoto dokumentu. Použití koncepcí, příkladů a informací je na vaše vlastní
riziko. Dokument může obsahovat chyby a nepřesnosti, které mohou způsobit poškození vašeho systému. Postupujte opatrně.
Ačkoli je výskyt problémů velmi nepravděpodobný, autoři za ně nemohou přijmout žádnou odpovědnost.
Reakce
Budu velmi rád, když mi pošlete své názory na tento dokument. Své dodatky, komentáře a kriti-ku směrujte na následující emailovou adresu: <[email protected] >.
Úvod
V současnosti existuje několik alternativ k používání nástroje Cryptoloop. Nejznámější je pravdě-podobně Loop-AES, viz http://
loop-aes.sourceforge.net nebo další howto v této knize, zaměřené na zašifrování kořenového oddílu. Loop-AES poskytuje velmi
podobné funkce jako Cryptoloop. V současnosti je Aes-loop vyspělejší než Cryptoloop a je také rychlejší (podle autora Loop-AES
asi dvakrát), protože používá vysoce optimalizovanou implementaci algoritmu AES v jazyce Assem-bler. To neznamená, že
nástroj Cryptoloop je pomalý. Při každodenní práci s normálním počtem vstupně-výstupních operací jsem nezaregistroval
významný rozdíl v rychlosti mezi oddílem šifro-vaným pomocí nástroje Cryptoloop a nešifrovaným oddílem. Pokud pro vás není
výkon vstupně- -výstupních operací mimořádně důležitý, měl by vám Cryptoloop vyhovovat. Loop-AES nabízí některé dodatečné
funkce, které zatím nejsou dostupné v implementaci nástroje Cryptoloop v jádře. Loop-AES vyžaduje upravené uživatelské
nástroje (mount, losetup) a tyto úpravy nejsou s nástrojem Cryptoloop kompatibilní. Nástroje Cryptoloop a Loop-AES nelze
používat současně.
Nástroj Cryptoloop je poměrně bezpečný. Klíč je obvykle generován z hesla, jehož hodnota hash slouží jako klíč algoritmu AES.
Z toho vyplývá možnost útoku se známým otevřeným textem. Nástroj Loop-AES je z tohoto hlediska dokonalejší, protože
generuje náhodný klíč a šifruje jej samostatně. Útok se známým otevřeným textem je díky tomu obtížnější. Loop-AES také
podporu-je režim více klíčů, kdy jsou sektory šifrovány pomocí 64 odlišných klíčů AES. Obecně platí, že útok hrubou silou na
heslo může být velmi účinný, pokud zvolíte slabé heslo. Chcete-li se proti tomu pojistit, měli byste použít heslo s délkou alespoň
20 znaků. Když to neuděláte, bude útok hrubou silou na heslo mnohem snazší než pokus hrubou silou přímo prolomit šifrování
AES.
Funkce Cryptoloop dostupná ve standardním jádře nabízí stabilní a čistou implementaci bez nutnos-ti instalace dodatečných
záplat. Protože je tato funkce stále poměrně nová, pravděpodobně nebyla z hlediska bezpečnosti dostatečně zkontrolována. Sami
se musíte rozhodnout, co je pro vás vhodné.
Důležité upozornění: Nástroj Cryptoloop byl v nejnovějším jádře 2.6 označen jako nedoporučený (deprecated). To znamená, že
nadále nebude aktivně udržován. Nástupcem nástroje Cryptoloop bude dm-crypt (http://www.saout.de/misc/dm-crypt/). Dm-crypt
je k dispozici v hlavním jádře od verze 2.6.4. Cryptoloop zůstane v hlavním jádře ještě dlouho k dispozici, ale hlavní metodou šifrování disků bude dm-crypt. Nástroj dm-crypt používá jiný přístup k zařízením (vyžaduje device-mapper) zařízení a poskytuje
prakticky stejné funkce jako Cryptoloop. Stále se jedná o naprostou novinku a zatím neexistují žádné snadno použitelné
uživatelské nástroje. Kód nástroje dm-crypt by měl být mnohem čistší než kód nástroje Cryptoloop, ale jsou zde některé důležité
rozdíly. Chcete-li například vytvořit šifrovaný systém souborů uvnitř souboru, musíte nadále použít loop--back zařízení, ale
podpora této funkce se stále vyvíjí.
K dispozici jsou i další nástroje, které umožňují vytvořit šifrovaný systém souborů. BestCrypt je komerč-ní produkt společnosti
Jetico. Umožňuje vytvářet šifrované kontejnery a nabízí velký výběr šifer. Po-skytuje také některé důmyslné funkce, jako jsou
skryté kontejnery. Je k dispozici pro systémy Win-dows a Linux, takže se hodí při výměně šifrovaných kontejnerů mezi těmito
systémy. BestCrypt lze nyní přeložit i pro jádra řady 2.6. Cryptoloop také umožňuje vytvořit kontejnery, které lze přemisťovat.
Stačí vytvořit šifrovaný systém souborů uvnitř souboru, jak je popsáno dále. K souborům, které jsou zašifrovány nástrojem
Cryptoloop, podle mých informací nelze přistupovat z jiných operačních systé-mů (např. Windows). V tomto případě můžete být
odkázáni pouze na nástroj BestCrypt.
Další program jménem TrueCrypt (http://www.truecrypt.org/) umožňuje transparentně šifrovat celé oddíly nebo vytvořit virtuální
šifrované disky uvnitř jiných souborů. Podporuje také tvorbu skry-tých svazků a nabízí výběr z mnoha prověřených šifrovacích
algoritmů. K dispozici jsou jazykové balíčky včetně češtiny. Od verze 4.0 je program dostupný nejen pro systémy Windows, ale i
GNU/Linux. Jedná se o svobodný program typu open-source.
Existují i komerční nástroje na šifrování disků, jako například PGP disk, ale pokud vím, systém Linux je nepodporuje.
Konfigurace jádra
Chcete-li použít nástroj Cryptoloop, musíte aktivovat několik funkcí jádra. Můžete tyto požadova-né funkce buď přeložit jako
moduly nebo je přeložit přímo do jádra. Používáte-li základní distri-buční jádro, pravděpodobně budete mít moduly již
připravené. Vyzkoušíte to například pomocí modinfo cryptoloop – objeví-li se popis modulu, pak je přeložen a připraven k
použití.
Následujícím postupem je zpřístupníte jako moduly. Pokud nemáte zkušenosti s vytvářením jádra řady 2.6, měli byste si přečíst
dokument HOWTO o jádře systému Linux (http://www. linuxdocs.org/HOWTOs/Kernel-HOWTO.html). Následující pokyny
obsahují pouze nejnutnější kroky.
1. Přejděte do adresáře, který obsahuje strom zdrojových souborů jádra (obvykle /usr/src/linux/ – musíte mít nainstalován
balíček, např. kernel-source), a spusťte kon-figuraci:
make menuconfig
2. Zapněte podporu obecného loopback zařízení. Aktivujte možnost „Loopback device support“ pod položkou:
Device Drivers -> Block Devices -> Loopback device support
1
Ve stejné sekci zapněte podporu nástroje Cryptoloop. Tato možnost by se měla zobrazit ihned poté, co zapnete podporu
obecného loopback zařízení.
2
Chcete-li zapnout šifrovací rozhraní API, přejděte z hlavní nabídky na položku „Crypto-graphic options“ (Možnosti
šifrování ). Zde můžete bez rizika zapnout většinu algoritmů. Doporučuji zapnout následující možnosti:
-- Cryptographic API<*> HMAC support< > Null algorithms<*> MD4 digest algorithm<*> MD5 digest algorithm<*> SHA1 digest
algorithm<*> SHA256 digest algorithm<*> SHA384 and SHA512 digest algorithms<*> DES and Triple DES EDE cipher
algorithms <*> Blowfish cipher algorithm<*> Twofish cipher algorithm<*> Serpent cipher algorithm<*> AES cipher
algorithms <*> CAST5 (CAST-128) cipher algorithm<*> CAST6 (CAST-256) cipher algorithm<*> Deflate compression
algorithm< > Testing module
Jestliže se rozhodnete, že z těchto funkcí vytvoříte moduly, nezapomeňte nejdříve při spuš-tění systému načíst příslušné
moduly (jmenují se cryptoloop , aes atd.).
5. Vytvořte jádro a moduly a nainstalujte je. Pokud například používáte zavaděč lilo v počítači x86, lze to provést takto:
make
make modules_install
cp arch/i386/boot/bzImage /boot/kernel-2.6.1
lilo
6. Načtěte požadované moduly při spuštění systému. V různých distribucích se to provádí odlišně. V systému Gentoo lze
například tyto moduly přidat do souboru /etc/modu-les.autoload/kernel-2.6, jinde to může být třeba /etc/modprobe.preload.
Jestliže jste přeložili Cryptoloop jako modul, je nutné jej načíst jako první. Automaticky také načte základní modul
loopback zařízení. Modul můžete načíst ručně příkazem:
modprobe cryptoloop
Získání uživatelských nástrojů
Ovladač Cryptoloop vyžaduje aktualizované uživatelské nástroje, aby mohl v praxi vytvořit a při-pojit šifrovaný systém souborů.
Potřebujete k tomu aktualizovaný balíček util-linux, který získáte na adrese http://ftp.cwi.nl/aeb/util-linux/util-linux-2.12.tar.gz.
Nejaktuálnější verze má číslo 2.12. Brzy budou k dispozici nové verze, které pravděpodobně přinesou zásadní změny. Než tedy
upgradujete na novější verzi, nezapomeňte zkontrolovat tento dokument HOWTO. Bohužel se můžete setkat s mnoha různými
záplatami balíčku util-linux. Liší se způsobem vytváření a připo-jování šifrovaných oddílů. Chcete-li použít balíček util-linux
2.12 s jádrem 2.6, musíte aplikovat alespoň následující dvě záplaty:
1
2
Kombinovaná záplata losetup (http://www.stwing.org/~sluskyb/util-linux/losetup -combined.patch).
Záplata util-linux 2.6 (http://www.ece.cmu.edu/~rholzer/cryptoloop/util-linux-2.12-kernel-
2.6.patch). Stáhněte si balíček util-linux a dvě výše uvedené záplaty. Nejdříve rozbalte balíček util-linux a potom aplikujte
dvě záplaty:
tar xvfz util-linux-2.12.tar.gz cd util-linux-2.12 patch -p1 < /cesta_k_souboru_záplaty/losetup-combined.patch patch -p1 < /
cesta_k_souboru_záplaty/util-linux-2.12-kernel-2.6.patch
Po použití záplat přeložte a nainstalujte balíček util-linux podle pokynů v souboru INSTALL. Doporučuji použít systém Gentoo
Linux, který tyto záplaty aplikuje automaticky, když se záplaty balíčku util-linux objeví. V jiných distribucích mohou být také
dostupné verze balíčku util-linux, které již mají tyto záplaty aplikovány.
Nastavení loopback zařízení
Cryptoloop lze použít na soubor nebo celým systém souborů. Následující popis se týká nastavení tohoto nástroje pro určitý oddíl.
Může se jednat o libovolný vybraný oddíl. V následujícím příkla-du se používá /dev/sda1 . Jako šifrovací algoritmus jsem zvolil
AES, ale můžete jej nahradit za jakoukoli oblíbenou šifru, kterou jste v jádře zapnuli. Seznam algoritmů podporovaných aktuálně
spuštěným jádrem můžete zkontrolovat v souboru /proc/crypto. Vynikajícím zdrojem informací
a
o různých šifrovacích algoritmech jsou knihy Bruceho Schneiera Applied Cryptography a Practical Cryptography.
Rozumnou volbu pravděpodobně představují algoritmy AES i Serpent. Na algorit-mus AES se zaměřilo hodně pokusů o
kryptoanalýzu a zatím nebyla zjištěna žádná vážná slabá místa. Algoritmus Serpent nebyl analyzován tak rozsáhle, ale podle
názoru odborníků je ještě
b
o něco silnější než AES. Serpent je však také pomalejší než AES. Vyhněte se algoritmu DES, který je zároveň pomalý a
slabý. Alternativou může být algoritmus Triple-DES, ale AES je pravděpo-dobně bezpečnější a rychlejší, takže již není důvod
nadále Triple-DES používat.
1. Než na oddílu vytvoříte šifrovaný systém souborů, doporučuje se oddíl naformátovat a zaplnit jej náhodnými daty. Díky
tomu bude pro útočníka obtížnější nalézt na šifrovaném oddílu určité vzory.
Varování! Dávejte pozor, jakou zde pro svůj oddíl zadáte hodnotu (parametr of). Pokud uděláte chybu, můžete snadno
přepsat nesprávný oddíl náhodnými nesmyslnými daty!
Oddíl můžete zaplnit náhodnými daty takto:
dd if=/dev/urandom of=/dev/sda1 bs =1M
Někdy se zobrazí chybová zpráva, že zařízení je plné. Tuto zprávu můžete ignorovat.
1
Vyberte šifru a délku klíče. Seznam šifer podporovaných svým jádrem naleznete v soubo-ru /proc/crypto. Doporučuji
použít algoritmus AES s 256bitovým klíčem.
2
Nastavte loopback zařízení. Slouží k tomu příkaz losetup z balíčku util-linux. Následující příkaz vytvoří šifrovaný
systém souborů pomocí loopback zařízení číslo 0 a pomocí šifry AES s 256bitovým klíčem na zařízení /dev/sda1:
losetup -e aes-256 /dev/loop0 /dev/sda1
Příkaz vyzve k zadání hesla. Vyberte silné heslo a pokuste se jej zapamatovat, aniž byste si jej museli poznamenat na
štítek přilepený k monitoru. Práce s nástrojem Cryptoloop má jednu velkou nevýhodu. Vzhledem k tomu, že hodnota hash
odvozená z hesla slouží jako šifrovací klíč, nelze heslo později snadno změnit. Nejjednodušší způsob změny hesla spočívá ve vytvoření nového šifrovaného oddílu nebo souboru, do kterého přesunete všech-na data. Proto je nutné vybrat
silné heslo hned na začátku. Algoritmus AES je sice nejspíš dostatečně silný, ale pokud si zvolíte slabé heslo, bezpečnost
se vytrácí.
Pokud příkaz losetup není úspěšný a zobrazí chybovou zprávu INVALID ARGUMENT, jedná se o chybu balíčku utillinux. Zkontrolujte, zda jste postupovali podle výše uvede-ných pokynů pro instalaci opravené verze balíčku util-linux.
Starší a nezáplatované verze předávají délku klíče odlišným způsobem a nefungují s rozhraním Crypto API jádra 2.6.
4. Vytvořte systém souborů. Můžete zvolit libovolný systém souborů. Následující příkaz vytvoří systém souborů ext3 file s
použitím loopback zařízení:
mkfs.ext3 /dev/loop0
5. Připojte šifrovaný systém souborů. Nejdříve musíte vytvořit připojovací bod, jako např. /mnt/crypto:
mkdir /mnt/crypto
Potom lze systém souborů připojit. V této fázi musíte příkazu mount explicitně sdělit, které loopback zařízení má použít:
mount -t ext3 /dev/loop0 /mnt/crypto
1
2
Nyní si se svým šifrovaným systémem souborů můžete začít hrát, dokud vás to neomrzí.
Odpojte systém souborů. Když jste systém souborů dostatečně vyzkoušeli, odpojte jej:
umount /mnt/crypto
8. Odpojte loopback zařízení – stále je připojeno k příslušnému oddílu. Odpojení provede příkazem:
losetup -d /dev/loop0
Připojení šifrovaného souborového systému
U všech operací se zařízením Cryptoloop je důležité, aby byly načteny všechny potřebné modu-ly. Musíte načíst alespoň modul
Cryptoloop a moduly pro každou šifru pomocí modprobe. Pokud jsou funkce přeloženy přímo do jádra, není to nutné.
Chcete-li připojit šifrovaný systém souborů vytvořený výše, můžete použít standardní příkaz mount z balíčku util-linux:
mount -t ext3 /dev/sda1 /mnt/crypto/ -oencryption=aes-256
Zobrazí se výzva k zadání hesla a systém souborů bude připojen standardním způsobem. Z funk-ce šifrování vyplývá, že se jedná
o systém souborů Cryptoloop. Proto automaticky zvolí dostupné loopback zařízení.
Po dokončení práce systém souborů odpojte příkazem:
umount /mnt/crypto
Do souboru /etc/fstab lze přidat následující řádek:/dev/sda1 /mnt/crypto ext3 noauto,encryption=aes-256 0 0
Nyní můžete zařízení jednoduše připojit příkazem:
mount /mnt/crypto
To je vše. Hodně štěstí.
Použití souboru místo oddílu
Stejně snadné je vytvořit šifrovaný systém souborů uvnitř souboru v jiném systému souborů. Tato možnost je užitečná zejména v
případech, kdy chcete tento soubor zálohovat – například vypálením na disk DVD atd. Soubor lze pak také snadno přenést do
jiných počítačů.
Chcete-li nejdříve vytvořit soubor velikosti 100 MB, který bude obsahovat náhodná data, zadejte následující příkaz:
dd if=/dev/urandom of=/mojedata.aes bs=1k count=100000
Pokud chcete velikost souboru změnit, upravte příslušným způsobem hodnotu parametru count. Výše uvedený příkaz vytvoří 100
000 bloků s velikostí 1 kB, ale tuto hodnotu můžete podle potře-by změnit. Musíte pouze zajistit, aby měl soubor dostatečnou
velikost k vytvoření zvoleného systé-mu souborů. Místo parametru /mojedata.aes můžete zadat libovolný název souboru a cestu,
pokud je na oddílu dostatek místa.
Pak lze v rámci tohoto souboru vytvořit šifrovaný systém souborů podobně jako ve výše uvedeném příkladu:
losetup -e aes-256 /dev/loop0 /mojedata.aes
Nyní je možné vytvořit systém souborů:
mkfs.ext3 /dev/loop0
a připojit jej:
mount -t ext3 /dev/loop0 /mnt/crypto
Nakonec loopback zařízení odpojte:
umount /mnt/crypto losetup -d /dev/loop0
Později můžete systém souborů připojit takto:
mount /mojedata.aes /mnt/crypto -oencryption=aes-256
Chcete-li soubor přesunout nebo jej vypálit na disk CD či DVD, nezapomeňte jej nejdříve odpojit.
Šifrovaný kořenový oddíl
Příprava systému
V tomto dokumentu naleznete informace, jak zabezpečit osobní data zašifrováním kořenového oddílu v systému Linux pomocí
silné šifry. Své komentáře posílejte Christophu Devinovi (http://www.cr0.net:8040/about/).
Nastavení rozložení oddílů
Pevný disk (budeme používat označení hda) by měl obsahovat alespoň tři oddíly:
¥
¥
¥
hda1 : tento malý nešifrovaný oddíl požádá o zadání hesla, aby bylo možné připojit šifro-vaný kořenový oddíl
hda2 : tento oddíl bude obsahovat šifrovaný kořenový oddíl. Ponechte mu dostatečnou velikost
hda3 : na tomto oddílu se nachází současná instalace systému GNU/Linux
V této fázi nejsou oddíly hda1 ani hda2 využité. Na oddílu hda3 je aktuálně nainstalována použí-vaná distribuce systému Linux.
Adresáře /usr a /boot nelze z tohoto oddílu přenést jinam. Následuje příklad možného rozložení oddílů:
# fdisk -l /dev/hda
Disk /dev/hda: 255 heads, 63 sectors, 2432 cylinders Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System /dev/hda1 1 1 8001 83 Linux /dev/hda2 2 263 2104515 83
Linux /dev/hda3 264 525 2104515 83 Linux /dev/hda4 526 2047 12225465 83 Linux
Požadované balíčky
Pokud používáte distribuci Debian, jsou nutné následující balíčky:
apt-get install gcc make libncurses5-dev patch bzip2 wget
Chcete-li si usnadnit kopírování a vkládání, můžete také nainstalovat:
apt-get install lynx gpm
V ostatních distribucích budou balíčky podobných jmen.
Instalace systému Linux 2.4.29
Existují dva hlavní projekty, které do jádra doplňují podporu šifrování pomocí loopback zařízení: Cryptoloop a Loop-AES. Tento
postup je založen na nástroji Loop-AES, informace o nástroji Cryp-toloop najdete v knize v návodu „Cryptoloop“. Nástroj LoopAES nabízí mimořádně rychlou a vysoce optimalizovanou implementaci algoritmu Rijndael v jazyce Assembler. Díky tomu
posky-tuje v počítačích s procesorem IA-32 (x86) maximální výkon. Kromě toho existují určité pochyb-nosti týkající se
bezpečnosti nástroje Cryptoloop.
V některých distribucích mohou být nástroje Loop-AES již součástí jádra a připraveny k použití (vyzkoušejte make menuconfig , viz
instrukce dále, a přesvědčte se). Jestliže vaše jádro tuto pod-poru nemá, budete si muset vytvořit potřebné zázemí sami. Nejdříve
si stáhněte a rozbalte balíček Loop-AES:
cd /usr/src wget http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2 tar -xvjf loop-AES-v3.0b.tar.bz2
Poté je nutné stáhnout a nainstalovat záplatu zdrojového kódu jádra:
wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.29.tar.bz2 tar -xvjf linux-2.4.29.tar.bz2 cd linux-2.4.29 rm include/linux/loop.h drivers/
block/loop.c patch -Np1 -i ../loop-AES-v3.0b/kernel-2.4.28.diff
Nastavte mapu klávesnice:
dumpkeys | loadkeys -m -> drivers/char/defkeymap.c
Dále nakonfigurujte jádro. Nezapomeňte nastavit následující možnosti:
make menuconfig
Block devices --->
<*> Loopback device support
[*] AES encrypted loop device support (NEW)
<*> RAM disk support(4096) Default RAM disk size (NEW)[*] Initial RAM disk (initrd) support
File systems --->
<*> Ext3 journalling file system support
<*> Second extended fs support
(important note: do not enable /dev file system support)
Přeložte jádro a nainstalujte je:
make dep bzImage make modules modules_install cp arch/i386/boot/bzImage /boot/vmlinuz
Používáte-li zavaděč grub, aktualizujte soubor /boot/grub/menu.lst nebo /boot/grub/grub.conf :
cat > /boot/grub/menu.lst << EOF default 0 timeout 10 color green/black light-green/black title Linux
root (hd0,2) kernel /boot/vmlinuz ro root=/dev/hda3 EOF
Jinak aktualizujte soubor /etc/lilo.conf a spusťte zavaděč lilo:
cat > /etc/lilo.conf << EOF lba32 boot=/dev/hda prompt timeout=60 image=/boot/vmlinuz
label=Linux
read-only
root=/dev/hda3
EOF lilo
Nyní můžete systém restartovat.
Instalace systému Linux 2.6.10
Postupujte stejně jako v předchozí části, ale tentokrát použijte záplatu kernel-2.6.10.diff pro Loop-AES. Také zkontrolujte, zda
není aktivována podpora zařízení cryptoloop. Uvědomte si, že pod-pora modulů vyžaduje, abyste nainstalovali balíček moduleinit-tools.
Instalace balíčku util-linux-2.12p
Chcete-li doplnit podporu silného šifrování, musíte záplatovat a znovu přeložit program losetup, který je součástí balíčku utillinux. Stáhněte si, rozbalte a záplatujte balíček util-linux:
cd /usr/src wget http://ftp.kernel.org/pub/linux/utils/util-linux/util-linux-2.12p.tar.bz2 tar -xvjf util-linux-2.12p.tar.bz2 cd util-linux-2.12p patch Np1 -i ../loop-AES-v3.0b/util-linux-2.12p.diff
Pokud chcete používat hesla kratší než 20 znaků, zadejte:
CFLAGS=”-O2 -DLOOP_PASSWORD_MIN_LENGTH=8”; export CFLAGS
V prvé řadě byste měli dbát na bezpečnost. Proto rozhodně nepovolujte hesla kratší než 20 znaků.Soukromí dat není zadarmo, ale
je nutné za ně „platit“ formou dlouhých hesel.Přeložte program losetup a nainstalujte jej jako uživatel root:
./configure && make lib mount mv -f /sbin/losetup /sbin/losetup~ rm -f /usr/share/man/man8/losetup.8* cd mount gzip losetup.8 cp losetup /sbin
cp losetup.8.gz /usr/share/man/man8/ chattr +i /sbin/losetup
Vytvoření šifrovaného kořenového oddílu
Zaplňte cílový oddíl náhodnými daty:
shred -n 1 -v /dev/hda2
Nastavte šifrovací loopback zařízení:
losetup -e aes256 -S xxxxxx /dev/loop0 /dev/hda2
Jako prevence optimalizovaných slovníkových útoků se doporučuje přidat parametr -S xxxxxx, kde „xxxxxx“ je náhodně zvolená
hodnota seed (můžete například zadat „gPk4lA“). Vybranou hodnotu seed si poznamenejte, abyste ji nezapomněli. Chcete-li se
vyhnout problémům s mapou klávesnice při spouštění, nepoužívejte také v hesle znaky mimo základní část tabulky ASCII (např.
písmena s diakritikou). Web Diceware (http://www.diceware.com/) umožňuje jednoduše vytvořit silná hesla, která si však můžete
snadno zapamatovat.
Nyní vytvořte na zařízení souborový systém ext3:
mke2fs -j /dev/loop0
Zkontrolujte, zda jste zadali správné heslo:
losetup -d /dev/loop0 losetup -e aes256 -S xxxxxx /dev/loop0 /dev/hda2
mkdir /mnt/efs mount /dev/loop0 /mnt/efs
Můžete porovnat šifrovaná a nešifrovaná data:
xxd /dev/hda2 | less xxd /dev/loop0 | less
Nyní je čas nainstalovat šifrovaný systém Linux. Používáte-li distribuci GNU/Linuxu (jako např. Debian, Slackware, Gentoo,
Mandriva, RedHat/Fedora, SuSE atd.), spusťte následující příkaz:
cp -avx / /mnt/efs
Jestliže máte k dispozici knihu Linux From Scratch, postupujte podle popisu v příručce s následující změnou:
¥
Kapitola 6 – Instalace balíčku util-linux:
Aplikujte záplatu Loop-AES po rozbalení zdrojových souborů.
¥
Kapitola 8 – Nastavení systému LFS jako spustitelného:
Přejděte na další kapitolu, „Nastavení spouštěcího zařízení“.
Nastavení spouštěcího zařízení
Vytvoření ramdisku
Nejdříve použijte na šifrovaném oddílu příkaz chroot a vytvořte připojovací bod spouštěcího zaří-zení:
chroot /mnt/efs mkdir /loader
Potom vytvořte počáteční disk ramdisk (initrd – init ramdisk), který budete později potřebovat:
cd dd if=/dev/zero of=initrd bs=1k count=4096 mke2fs -F initrd mkdir ramdisk mount -o loop initrd ramdisk
Pokud používáte nástroj grsecurity, může se zobrazit chybová zpráva „Permission denied“ (Opráv-nění odepřeno). V tomto
případě je nutné spustit příkaz mount mimo prostředí příkazu chroot. Vytvořte hierarchii systému souborů a zkopírujte do ní
požadované soubory:
mkdir ramdisk/{bin,dev,lib,mnt,sbin} cp /bin/{bash,mount} ramdisk/bin/ ln -s bash ramdisk/bin/sh mknod -m 600 ramdisk/dev/console c 5 1
mknod -m 600 ramdisk/dev/hda2 b 3 2 mknod -m 600 ramdisk/dev/loop0 b 7 0 cp /lib/{ld-linux.so.2,libc.so.6,libdl.so.2} ramdisk/lib/ cp /lib/
{libncurses.so.5,libtermcap.so.2 } ramdisk/lib/ cp /sbin/{losetup,pivot_root} ramdisk/sbin/
Jestliže se zobrazí zpráva typu „/lib/libncurses.so.5: No such file or directory“ nebo „/lib/libtermcap.so.2: No such file or
directory“ (Tento soubor nebo adresář neexistuje), nemusíte se znepokojovat. Shell bash vyžaduje pouze jednu z těchto dvou
knihoven. Chcete-li zjistit, která z knihoven je skutečně nutná, můžete zadat:
ldd /bin/bash
Přeložte program sleep, který zabrání tomu, aby byla výzva k zadání hesla zahlcena zprávami jádra (např. o registraci
jednotlivých zařízení USB).
cat > sleep.c << "EOF" #include <unistd.h> #include
<stdlib.h>
int main( int argc, char *argv[] ) { if( argc == 2 )
sleep( atoi( argv [1] ) );
return( 0 ); } EOF
gcc -s sleep.c -o ramdisk/bin/sleep rm sleep.c
Vytvořte skript init:
cat > ramdisk/sbin/init << "EOF" #!/bin/sh
/bin/sleep 3
echo -n "Zadejte hodnotu seed: " read SEED
/sbin/losetup -e aes256 -S $SEED /dev/loop0 /dev/hda2 /bin/mount -r -n -t ext3 /dev/loop0 /mnt
while [ $? -ne 0 ]
do /sbin/losetup -d /dev/loop0 /sbin/losetup -e aes256 -S $SEED /dev/loop0 /dev/hda2 /bin/mount -r -n -t ext3 /dev/loop0 /mnt
done
cd /mnt /sbin/pivot_root . loader exec /usr/sbin/chroot . /sbin/init EOF
chmod 755 ramdisk/sbin/init
Odpojte loopback zařízení a zkomprimujte soubor initrd:
umount -d ramdisk rmdir ramdisk gzip initrd mv
initrd.gz /boot/
Spouštění z disku CD-ROM
Rozhodně doporučuji spouštět systém z média pouze pro čtení, jako např. ze spustitelného diskuCD-ROM.Stáhněte si a rozbalte
balíček syslinux:
wget http://ftp.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.07.tar.bz2 tar -xvjf syslinux-3.07.tar.bz2
Nakonfigurujte program isolinux:
mkdir bootcd cp /boot/{vmlinuz,initrd.gz } syslinux-3.07/isolinux.bin bootcd echo “DEFAULT /vmlinuz initrd=initrd.gz ro root=/dev/ram0” \
> bootcd/isolinux.cfg
Vytvořte obraz ISO spustitelného disku CD-ROM:
mkisofs -o bootcd.iso -b isolinux.bin -c boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -J -hide-rrmoved -R bootcd/ cdrecord -dev 0,0,0 -speed 4 -v bootcd.iso
rm -rf bootcd{,.iso}
Spouštění z oddílu pevného disku
Spouštěcí oddíl může přijít vhod, pokud ztratíte spustitelný disk CD. Nezapomeňte, že oddíl hda1 umožňuje zápis, a proto není
bezpečný. Používejte jej pouze v nouzových případech!
Vytvořte na zařízení souborový systém ext2 a připojte jej:
dd if=/dev/zero of=/dev/hda1 bs=8192 mke2fs /dev/hda1 mount /dev/hda1 /loader
Zkopírujte jádro a počáteční disk ramdisk:
cp /boot/{vmlinuz,initrd.gz} /loader
Používáte-li zavaděč grub:
mkdir /loader/boot cp -av /boot/grub /loader/boot/ cat > /loader/boot/grub/menu.lst << EOF default 0 timeout 10 color green/black light-green/
black title Linux
root (hd0,0)
kernel /vmlinuz ro root=/dev/ram0
initrd /initrd.gz
EOF grub-install --root-directory=/loader /dev/hda umount /loader
Jestliže používáte zavaděč lilo:
mkdir /loader/{boot,dev,etc} cp /boot/boot.b /loader/boot/ mknod -m 600 /loader/dev/hda b 3 0 mknod -m 600 /loader/dev/hda1 b 3 1 mknod -m
600 /loader/dev/hda2 b 3 2 mknod -m 600 /loader/dev/hda3 b 3 3 mknod -m 600 /loader/dev/hda4 b 3 4 mknod -m 600 /loader/dev/ram0 b 1 0 cat
> /loader/etc/lilo.conf << EOF lba32 boot=/dev/hda prompt timeout =60 image=/vmlinuz
label=Linux
initrd=/initrd.gz
read-only
root=/dev/ram0
EOF lilo -r /loader umount /loader
Závěrečné kroky
Stále v rámci prostředí příkazu chroot upravte soubor /etc/fstab tak, aby obsahoval řádek:
/dev/loop0 / ext3 defaults 0 1
Odstraňte soubor /etc/mtab a ukončete příkaz chroot (pomocí exit). Nakonec spusťte příkaz umount -d /mnt/efs a restartujte
systém. I v případě nějaké chyby můžete stále spustit nešifro-vaný oddíl zadáním příkazu „Linux root=/dev/hda3“ na výzvu
„LILO:“.
Pokud vše proběhlo úspěšně, můžete nyní změnit oddíly na disku a zašifrovat oddíly hda3 i hda4 . V následujících skriptech se
předpokládá, že na oddílu hda3 bude uloženo odkládací zařízení swap a oddíl hda4 bude obsahovat adresář /home. Nejdříve byste
měli oba oddíly inicializovat:
shred -n 1 -v /dev/hda3 shred -n 1 -v /dev/hda4 losetup -e aes256 -S xxxxxx /dev/loop1 /dev/hda3 losetup -e aes256 -S xxxxxx /dev/loop2 /dev/
hda4 mkswap /dev/loop1 mke2fs -j /dev/loop2
Dále vytvořte skript ve spouštěcím adresáři systému a aktualizujte soubor fstab :cat > /etc/init.d/loop << "EOF "#!/bin/sh
if [ "`/usr/bin/md5sum /dev/hda1`" != \
"5671cebdb3bed87c3b3c345f0101d016 /dev/hda1" ] then echo -n
"VAROVÁNÍ! Ověření integrity oddílu hda1 se NEZDAŘILO stiskněte klávesu Enter." read fi
echo "První heslo zvolené výše" | \ /sbin/losetup -p 0 -e aes256 -S xxxxxx /dev/loop1 /dev/hda3
echo "Druhé heslo zvolené výše" | \ /sbin/losetup -p 0 -e aes256 -S xxxxxx /dev/loop2 /dev/hda4
/sbin/swapon /dev/loop1
for i in `seq 0 63` do echo -n -e "\33[10;10]\33[11;10]" > /
dev/tty$i done
EOF
chmod 700 /etc/init.d/loop ln -s ../init.d/loop /etc/rcS.d/S00loop vi /etc/fstab ... /dev/loop2 /home ext3 defaults 0 2
Tisk v Linuxu
Úvod
Tento dokument by měl obsahovat všechno, co potřebujete vědět k nastavení tiskových služeb na linuxovém stroji. Představuje
souhrn informací o tom, jak v Linuxu cokoliv generovat, prohlížet, faxovat a tisknout. Téměř vše platí i pro uživatele jiných volně
šiřitelných operačních systémů typu Unix. Život tomu chtěl, že je to o něco složitější než v klikacím světě Microsoftu a Apple, na
druhé straně je to ale o něco pružnější a určitě jednodušší na správu ve velkých sítích.
Dokument je strukturován tak, že většině lidí bude stačit přečíst jenom první polovinu, nebo tak nějak. Většina obskurních a na
situaci závislých informací je uvedena v druhé polovině a lze je snadno najít v obsahu. Informace z kapitoly „Ghostscript“ nebo
„Sítě“ jsou pravděpodobně užitečné téměř pro každého.
Shledáte-li tento dokument nebo internetové stránky http://www.linuxprinting.org/ užitečnými,
uvažujte o nákupu něčeho (třeba inkoustu), čím byste tyto stránky a úsilí jejich tvůrců podpořili. Poslední verzi tohoto dokumentu
najdete na http://www.linuxprinting.org/; také jej najdete jako součást LDP na http://www.tldp.org/ a na nejbližších zrcadlech.
Terminologie
V tomto dokumentu se pokusím používat konzistentní terminologii tak, aby byla přínosem pro všechny uživatele volně šiřitelných
systémů typu Unix, a dokonce i jiných volně šiřitelných systé-mů. Bohužel však existuje celá řada nejednoznačných názvů a také
množství sice jednoznačných, avšak nevhodně zvolených názvů. Uveďme si kvůli srozumitelnosti krátký slovníček výrazů:
UNIX
UNIX je operační systém vyvinutý výzkumníky v Bellových laboratořích. Na jeho kódu je založena řada (často komerčních)
operačních systémů, které také spadají do této kategorie.
Un*x
Un*x není příliš vhodně zvolený symbol. Používá se k označení operačních systémů typu Unix. Operační systém typu Unix
poskytuje něco, co se podobá programovému rozhraní POSIX, resp. jeho přirozenému aplikačnímu rozhraní (API, Application
Programming Interface). Do kategorie Un*x spadají Linux, FreeBSD, Solaris, AIX, a dokonce i některé specializované systémy,
např. Lynx nebo QNX.
Linux
Linux je jádro typu Unix doplněné různým periferním softwarem, které napsal Linus Torvalds a stovky dalších programátorů.
Toto jádro je základem nejrozšířenějšího operačního systému kategorie Un*x.
GNU
Projekt GNU („GNU's Not Unix“) dlouhodobě usiluje o vytvoření plně volně šiřitelného operační-ho systému typu Un*x. Tento
projekt je v mnoha ohledech zdrojem nejmodernějších trendů v oblasti volně šiřitelného softwaru.
GNU/Linux
Operační systém GNU/Linux je kompletní systém složený z jádra a z periferních programů, který poskytuje prostředí GNU, v
němž mohou běžet knihovny, utility, uživatelské programy atd. Pro-dejci kompletního systému GNU/Linux jsou firmy Red Hat,
Debian, Caldera, SuSE, TurboLinux atd. GNU/Linux se ovšem velmi často zkracuje na pouhý Linux.
Přímo k věci
Nejrychlejší metoda, jak začít, bude pravděpodobně použít konfigurační nástroje dodávané s vaším systémem. Za předpokladu, že
obsahují podporu vašeho ovladače a ovladač vaší tiskár-ny, mělo by být docela snadné takto rychle provést základní nastavení.
Informace o konfigurač-ních nástrojích různých dodavatelů najdete v kapitole „Řešení jednotlivých distribucí“.
Pokud konfigurační nástroje dodavatele nefungují, měli byste zjistit, zda vaše tiskárna vůbec fun-govat může. V kapitole „Seznam
tiskáren z hlediska kompatibility s Linuxem“ najdete odkaz na seznam kompatibilních tiskáren.
Pokud tiskárna má s určitým ovladačem fungovat, zjistěte, zda jej máte nainstalován, a pokud ne, nainstalujte jej. Typicky byste
měli být schopni najít upravený balík Ghostscript obsahující nověj-ší verzi tohoto programu a doplňující ovladače. Pokud jej
nenajdete, můžete si jej přeložit sami
– tento proces není triviální, ale je dobře dokumentovaný. Podrobnosti o systému Ghostscript
najdete v kapitole „Ghostscript“.Po instalaci správného ovladače zkuste tiskárnu znovu nakonfigurovat pomocí nástrojů dodavatele. Nepovede-li se to, zkuste jiný nástroj podle doporučení v kapitole „Jak to funguje“. Pokudnepomůže ani to, budete muset
provést konfiguraci sami, opět podle návodu v téže kapitole.
Pokud tiskárna stále nefunguje, bude potřeba něco diagnostiky. V takovém případě bude nejlepší si nejprve přečíst větší část
tohoto dokumentu, abyste zjistili, jak věci mají fungovat. Pak budete mít výrazně lepší pozici na hledání potíží.
Kde naleznete pomoc
Diskusní skupiny comp.os.linux.hardware, comp.os.linux.setup a comp.periphs.printers mají urči-tou část věnovanou otázkám
souvisejícím s obecnou problematikou tisku. Existují i další hojně navštěvované diskusní skupiny; najdete je mimo jiné i v
archivu Googlu. Dále jsou na Internetu diskusní skupiny linuxprinting.foo dostupné jak běžnými prohlížeči, tak i pomocí
protokolu NNTP; zkuste si je najít.
Také zkuste sami pohledat na příbuzných stránkách na Internetu. Vhodným místem, kde můžete
začít, je například http://www.linuxprinting.org/, kde je mimo jiné i řada relevantních odkazů. Další pomoc naleznete v různých
diskusních skupinách, e-mailových konferencích, zákaznických linkách distributora atd. Chcete-li kontaktovat přímo mě, učiňte
tak, prosím, na diskusním fóru http://www.linuxprinting.org/, což poskytne příležitost k odpovědi i jiným účastníkům a pomůže i
jiným nešťastníkům s podobnými problémy.
Jak tisknout
Tisknout budete různými příkazy podle toho, jaký tiskový spooler máte nainstalován.
Pomocí LPD a příkazu lpr v systému BSD
Pokud jste si pro tisk již nastavili lpd (nebo to udělal správce systému, případně už prodejce), stačí se už jen naučit používat
příkaz lpr. Jeho popis a popis několika dalších příkazů souvisejících s tiskem, které byste pravděpodobně měli znát, naleznete v
dokumentu Printing Usage HOWTO (http://www.tldp.org/HOWTO/Printing-Usage-HOWTO.html) anebo v manuálových
stránkách lpr(1).
Stručně: Jméno fronty zadáte pomocí -P a pak zadáte jméno souboru, který má být vytištěn. Neza-dáte-li nic, tiskne se ze stdin.
Volby ovladače se obvykle z lpr nezadávají, avšak některé systémy akceptují volby např. -o, -Z nebo -J.
Příklad 1. lpr
lpr /etc/hosts lpr -J “my hosts file” /etc/hosts lpr -P mylaserjet /etc/services
Pomocí LPD a příkazu lp v systému System V
V různých variantách Unixu se můžete setkat se dvěma množinami příkazů. Tiskové systémy LPD v operačních systémech
založených na BSD (*BSD, Linux) používají lpr (tisk), lpq (vypiš frontu), lprm (zruš úlohu), zatímco systémy na bázi System V
používají lp (tisk), lpstat (vypiš frontu), cancel (zruš úlohu). Jsou to například systémy Solaris, SCO a řada dalších.
Konvence a příkazy SYSV jsou pochopitelně popsány v manuálových stránkách příkazu lp. Fron-tu zadáte volbou -d a dále
volitelně jméno souboru. Není-li zadáno, bude se vypisovat ze stdin.
Příklad 2. lp
lp /etc/hosts lp -d mylaserjet /etc/services
Pomocí CUPS
CUPS nabízí rozhraní pro příkazové řádky jak System V, tak i systémů z Berkeley. Znamená to, že k tisku můžete používat jak
příkaz lpr, tak i lp. Máte-li například balík skriptů, které obsahují výlučně lp, nebo jste zvyklí jenom na jeden ze systémů z
kuchyně System V, resp. BSD, je to znač-ná úleva.
Grafické tiskové nástroje
Většina tiskových systémů sama o sobě nabízí jen velmi jednoduché řádkové rozhraní. Namísto přímého použití příkazu lpr dáte
možná přednost nějakému grafickému rozhraní. Ta obecně umožňují nastavit různé možnosti tisku (tiskárnu, typ papíru, řazení,
počet kopií a podobně) snad-no použitelnou grafickou metodou. Některá z nich nabízejí i další funkce.
KDEPrint
KDEPrint zajišťuje uživatelský přístup k tiskovým subsystémům (CUPS, LPD, RLPR, LPRng atd.) pomocí grafického
uživatelského rozhraní KDE. Pomocí tohoto nástroje můžete snadno tisknout, spravovat úlohy a tiskárny a taktéž tiskové démony.
KDEPrint je náhradou starších nástrojů QtCUPS a KUPS. Je vhodný jak pro uživatele, tak i pro vývojáře. Od verze KDE 2.2.0 je
jeho sou-částí a má řadu zajímavých funkcí.
KDEPrint má tiskové dialogové okno programu kprinter, které umožňuje výběr cílové tiskárny a změnu voleb. K cílovým
tiskárnám patří i několik virtuálních tiskáren, kam můžete posílat elek-tronickou poštu, faxy nebo soubory PDF.
Obrázek 11.1 kprinter
Program kprinter můžete používat s aplikacemi, které mají konfigurovatelný příkaz pro tisk. Jsou to například Mozilla nebo
OpenOffice.
Obrázek 11.2 Použití kprinter s Mozillou
V dialogovém okně KDEPrint také můžete zadat Print Preview. Tento příkaz je realizován tak, že předá tiskový soubor přes různé
filtry, které jej upraví pro tisk na obrazovce pomocí KGhostView nebo pomocí nějaké externí aplikace (např. gv).
Pomocí KJobViewer můžete prohlížet, přesouvat a rušit tiskové úlohy.
Obrázek 11.3 KJobViewer
Další informace o KDEPrint naleznete na http://printing.kde.org/.
XPP
Pokud jako tiskový spooler používáte CUPS, můžete použít program XPP (viz obrázek 11.4).
Generuje se pomocí knihovny FLTK, takže je nezávislý na pracovním prostředí. Chcete-li tímto programem tisknout, spusťte xpp
a vyberte soubor (nebo jej nevybírejte, pokud chcete xpp použít namísto lpr pro tisk ze stdin). Pak ze seznamu nakonfigurovaných
tiskáren zvolte tiskárnu a případné parametry, které chcete pro tisk použít. Na obrázku 11.5 vidíte příklad panelu s parametry se
zvýrazněním standardních parametrů CUPS.
Pokud jej používáte se systémem rozhraní ovladačů Foomatic, můžete nastavovat i číselné parametry, které CUPS normálně
nepodporuje. Obvykle se týkají takových funkcí jako barevné ladění, nastavení kazet atd. Příklad viz obrázek 11.6.
Všechny volby a vybranou tiskárnu lze uchovat pomocí tlačítka „Save Settings“.
Obrázek 11.4 Hlavní okno XPP
Obrázek 11.5 Okno voleb CUPS/XPP
Obrázek 11.6 Okno voleb Foomatic CUPS/XPP
GPR
GPR (http://www.compumetric.com/linux.html, autor Thomas Hubbell) využívá k filtrování post-skriptových úloh kód z CUPS a
poskytuje možnost snadného řízení úloh. Některé volby (např. vícecestné tisky, výběr stránky apod.) jsou implementovány přímo
pomocí GPR, zatímco většina ostatních až tiskárnou, resp. filtrem spooleru.
GPR pracuje s LPD nebo s LPRng nebo může být přeloženo zvlášť pro použití s GNUlpr. Je-li pře-loženo normálně, používá
přímo libppd (firmy VA) k vytváření postskriptu pro určitou tiskárnu, který předá příkazu lpr. Je-li přeloženo pro GNU variantu
lpr, předá příkazu lpr společně s uve-denými volbami postskriptovou úlohu v původní (nemodifikované) podobě. To je
pravděpodob- ně lepší způsob, neboť umožňuje spooleru přesměrování postskriptu na různé tiskárny, je-li to
nutné; bohužel vyžaduje GNU lpr, který se příliš nepoužívá (i když jeho instalace je triviální). Při používání GPR nejdříve vyberte
tiskárnu (jménem fronty LPD) a přesvědčte se, že GPR zaved-lo správný soubor PPD. Pokud se tak nestalo, musíte zadat jméno
souboru PPD a v konfigurač-ním dialogu zadat volby pro tiskárnu (dialog spustíte tlačítkem Printer Configuration; obsahuje různá
nastavení tiskových voleb definovaných PPD).
Jakmile zkonfigurujete tiskárnu v GPR, můžete tisknout úlohy tak, že zadáte jméno souboru a vyberete příslušné volby z panelů
„Common“ a „Advanced“. Volby z „Common“ implementuje pro všechny tiskárny přímo GPR, zatímco volby „Advanced“ pro
danou tiskárnu jsou definovány
Obrázek 11.7 Hlavní volby GPR
Obrázek 11.8 Běžné volby GPR
v souboru PPD. Panely s volbami jsou na obrázcích 8 a 9. Novější a modernější náhradou GPR se zdá být GtkLP (http://
gtklp.sourceforge.net/), viz následující obrázek.
Obrázek 11.9 Volby GPR pro tiskárnu
Obrázek 11.10 Tiskový program GtkLP
Tisková zařízení jádra
Pro obsluhu paralelního portu existují dvě úplně odlišná zařízení – které z nich používáte, závisí na verzi vašeho jádra (a to
můžete zjistit příkazem uname -a). Ovladače se změnily v jádře 2.1.33; prakticky všechny dnešní systémy používají jádra 2.2
nebo vyšší; takže klidně můžete přeskočit na kapitolu popisující zařízení parport.
Poznámka platná pouze pro oba typy ovladačů: Nejdůležitější asi je, že řada uživatelů zjistila, že Linux nedetekuje paralelní port,
pokud v BIOSu nevypnou podporu „Plug-and-Play“. (Není to velké překvapení, PnP záznamy pro jiná než PCI zařízení,
používané ve Windows a obdobných systémech, představují takovou malinkou katastrofu.)
Zařízení lp (jádra <= 2.1.32)
Za předpokladu, že máte přeloženou nebo nahranou podporu zařízení lp (pokud je nahrána, bude výstup příkazu cat /proc/devices
obsahovat zařízení lp), pak jádro (<= 2.1.32) poskytuje jedno nebo více zařízení /dev/lp0, /dev/lp1, /dev/lp2. Tato zařízení se
nepřiřazují dynamic-ky, každé odpovídá konkrétní hardwarové vstupně-výstupní adrese. Znamená to, že první a jedi-ná tiskárna
může být klidně lp0 nebo lp1 v závislosti na hardwaru. Prostě zkuste obojí.
Někteří uživatelé si stěžují, že obousměrný port není detekován, pokud použijí starší jednosměr
ný kabel. V takovém případě zkontrolujte, zda používáte správný kabel. Na jednom portu nemůžete současně spustit ovladače
(moduly) plip a lp (s jádrem 2.0). Může-te nicméně kdykoliv jeden nebo druhý ovladač nahrát ručně, případně démonem kerneld
u jader
2.x (a novějších 1.3.x). Při správném nastavení přerušení a dalších parametrů ovšem můžete na jednom portu používat plip a na
druhém lp. Úspěšně se to podařilo úpravami ovladačů; zajíma-lo by mě, zda se to někomu povedlo pouze vhodnými parametry
příkazů.
Existuje nástroj tunelp, který s jádrem 2.0 umožňuje nastavovat přerušení a další parametry paralelních portů.Pokud je ovladač lp součástí jádra, přijímá jádro parametr lp= pro nastavení přerušení a vstupně--výstupní adresy.
Pokud je ovladač lp součástí jádra, můžete použít příkazový řádek programů LILO/LOADLIN a nastavit adresy a přerušení, které
bude ovladač používat. Syntaxe: lp=port0[,irq0[ ,port1[,irq1[,port2[,irq2]]]]]. Například: lp=0x378,0 nebo lp=0x278,5,0x378,7 . Pokud
chcete tuto funkci použít, musíte definovat všechny používané porty, neexistují žádné implicitní hodnoty. Vestavěný ovladač
můžete vypnout parametrem lp=0.
Pokud ovladač nahráváte jako modul, můžete vstupně-výstupní adresu a přerušení definovat na příkazovém řádku insmod (nebo
v souboru /etc/conf.modules, pokud používáte kerneld) s obvyklou syntaxí parametrů. Parametry jsou io=port0,port1, port2 a
irq=irq0,irq1,irq2. Další informace viz manuálová stránka příkazu insmod.
Zdrojový kód ovladače paralelního portu v jádře 2.0 najdete v souboru /usr/src/linux/dri-vers/char/lp.c.
Zařízení parport (jádra >= 2.1.33)
Počínaje jádrem 2.1.33 (se záplatou až pro 2.0.30) je zařízení lp pouhým klientem nového zaříze-ní (ovladače/modulu) parport .
Přidáním zařízení parport se odstranila řada problémů s původ-ním ovladačem zařízení lp – bylo možné sdílet port s jinými
ovladači, bylo zavedeno dynamické přiřazování dostupných portů číslům zařízení namísto pevného vztahu mezi vstupně-výstupní
adresou a zařízením a další.
Díky novému ovladači parport se mohla objevit celá řada nových paralelních ovladačů pro zaří-zení, jako jsou mechaniky Zip,
CD-ROM a disky Backpack a další. Některé z nich existují i v jád-rech 2.0; zkuste je najít na webu.
Hlavním rozdílem, kterého si můžete všimnout ve vztahu k tisku, je dynamické přiřazení zařízení lpparalelním portům. Tedy to,
co v Linuxu 2.0 bylo lp1, může být v Linuxu 2.2 klidně lp0. Pokud přecházíte z jádra s ovladačem lp na jádro s ovladačem parport ,
nezapomeňte to zkontrolovat.
Většina oblíbených problémů s tímto zařízením vzniká právě díky chybné konfiguraci:
Distribuce
Některé distribuce Linuxu nemají správně nastaven soubor /etc/modules.conf (nebo /etc/conf.modules), takže se ovladač v okamžiku
potřeby nenahraje správně. S posledními ver-zemi nástroje modutils vypadá správný řádek v souboru modules.conf takto:
alias /dev/printers lp # jenom pro devfs? alias /dev/lp* lp # jenom pro devfs? alias parport_lowlevel parport_pc # chybí v Red Hat 6.0-6.1
BIOS
Řada BIOSů obsluhuje paralelní port jako zařízení Plug-and-Play. Tím se ovšem perfektně jednoduché a prakticky vždy přítomné
zařízení rozšiřuje o naprosto zbytečné složitosti. Pokud Linux nedetekuje paralelní port správně, vypněte u něj podporu PnP (ve
většině BIOSů nastavujete LPT1 ). Správné nastavení bude obvykle legacy, ISA nebo 0x378 – určitě ale ne disabled.
Doporučujeme také dokumentaci ve zdrojových kódech jádra (http://people.redhat.com-/twaugh/parport/html/parportguide.html)
nebo stránky http://people.redhat.com/twaugh/parport/.
Sériová zařízení
Sériová zařízení se v Linuxu obvykle jmenují podobně jako /dev/ttyS1. Nástrojem stty můžete interaktivně zobrazovat nebo měnit
nastavení sériových portů, nástrojem setserial pak můžete nastavovat některé další parametry, přerušení a vstupně-výstupní adresy
nestandardních portů. Podrobnější debatu na téma sériových portů v Linuxu najdete v dokumentu Serial-HOWTO.
Pokud používáte pomalou sériovou tiskárnu s řízením toku, může dojít k tomu, že se ztrácejí části tiskových úloh. Může to
způsobovat sériový port, který se standardně chová tak, že všechny nepřenesené znaky ze svého buferu odstraní 30 sekund po
zavření zařízení. Bufer má délku 4 096 znaků, a pokud tiskárna používá softwarové řízení toku a je dost pomalá na to, aby
nestihla zpra-covat celý bufer do 30 sekund od chvíle, kdy tiskový program zavře sériový port, konec buferu se ztratí. Pokud
příkazem cat soubor > /dev/ttyS2 správně vytisknete krátké soubory, ale u dlouhých se konec souboru ztratí, může jít o tento
případ.
Interval 30 sekund je možné změnit parametrem closing_wait příkazu setserial (verze 2.12 a vyšší). Sériové porty se typicky
inicializují voláním setserial v souboru rc.serial . Můžete toto volání upravit taky, aby kromě ostatních parametrů rovnou nastavilo
i delší interval closing_wait.
USB zařízení USB 1.1
Podpora USB je v Linuxu značná. USB lze použít se všemi pozdními modely jádra 2.2 a se všemi jádry 2.4 a novějšími. Jádro
musí pochopitelně mít zabudovanou podporu USB, buď jako součást jádra nebo jako zaváděný modul (doporučeno).
Modulární jádro vyžaduje tyto moduly:
usb-core.o
usb-uhci.o nebo uhci.o nebo usb-ohci.o
printer.o
Konkrétní verze modulů usb-uhci.o, uhci.o a usb-ohci.o závisí na typu základní desky, resp. adaptéru. Intel, Via a adaptéry založené
na Via jsou UHCI (v tomto případě můžete použít buď usb-uhci.o nebo uhci.o). Typ HCI (Host Controller Interface) zjistíte
příkazem lspci -v|grep HCI.
USB 2.0
Vysokorychlostní přenos na zařízení USB 2.0 vyžaduje připojení řadiče USB 2.0 a ovladač EHCI (ehci-hcd.o ). Pro USB 2.0 je
doporučeno jádro 2.4 nebo vyšší.
Praktické rady
Je nutno si zapamatovat, že zařízení USB jsou přidělována dynamicky. Tiskárna USB je při zapnu-tí nebo připojení přiřazena
souboru zařízení (/dev/usb/lp*). V důsledku toho mohou být tisko-vé úlohy posílány na nesprávnou tiskárnu, neboť je zapínáte v
určitém pořadí. Zasílání úloh na správnou fyzickou tiskárnu zajišťuje CUPS dle speciálního URI obsahujícího značku, model a
séri-ové číslo tiskárny.
I když v Linuxu lze využívat většinu tiskáren USB, existují výjimky. Například zařízení MF od Epsonu (Stylus CX3200/CX5200)
vracejí nesmysly, když prostřednictvím IOCTL zvolíte řetězec IEEE-1284 ID, například s kódem CUPS „usb“. Je nutno zvolit ID
řetězec v souladu s proprietární metodou firmy Epson.
Získat ID řetězce z tiskáren USB můžete pomocí několika nástrojů, které napsal Till Kamppeter. Programy getusbprinterid.pl
(http://www.linuxprinting.org/download/printing/getusbprinterid.pl) a usb_id_test.c (http://www.linuxprinting.org/download/
printing/usb_id/test.c) jsou funkčně totož-né, první z nich je však napsaný v Perlu a druhý v C. Jak jsme se zmínili shora, nová
zařízení MF od firmy Epson jsou výjimkou, avšak v nástroji ttink z balíku MTink (http://xwtools.automatix.de/) je proprietární
metoda firmy Epson implementována.
Další informace o USB naleznete na Linux USB Website (http://www.linux-usb.org/).
Podporované tiskárny
Jádro Linuxu vám umožní bavit se s jakoukoliv tiskárnou, kterou připojíte k sériovému, paralelní-mu nebo USB portu, plus s
jakoukoliv síťovou tiskárnou. To ale samo o sobě nestačí – musíte být také schopni generovat data, kterým bude tiskárna rozumět.
Typicky mezi nepoužitelné tiskárny patří tiskárny označované jako „Windows“ nebo „GDI“. Jazyk pro ovládání těchto tiskáren je
úplně nebo částečně nedokumentován, stejně jako podrobnosti o návrhu tiskového mechanismu. Typic-ky výrobce dodává s
tiskárnou ovladač pro Windows a vesele je prodává pouze uživatelům Win-dows; proto se tyto tiskárny označují také jako
Winprinters. V některých případech dodává výrob-ce ovladače i pro NT, OS/2 a jiné operační systémy.
Řada těchto tiskáren v Linuxu nefunguje. Některé z nich fungují, některé fungují pouze částečně (obvykle díky tomu, že někdo
pomocí reverzního překladu ovladače zjistil, jak s tiskárnou zachá-zet). Viz seznam použitelných tiskáren dále v této kapitole.
Některé tiskárny jsou něco mezi. Například některé modely tiskáren NEC implementují zjednodušenou verzi ovládacího jazyka
PCL, díky čemuž mohou v rozlišení 300 DPI na tiskárně tisknout programy ovládající PCL. Ovšem pouze NEC ví, jak z tiskárny
dostat plné možné rozlišení 600 DPI.
Pokud už některou z těchto windowsových tiskáren máte, existují různé prapodivné cestičky, jak je využít i v Linuxu, jde ale o
poměrně nehezké postupy. Další podrobnosti o využití těchto tis-káren najdete v kapitole „Tiskárny výlučně pro Windows“.
PostScript
Co se týče tiskáren v Linuxu, nejlepší volba je koupit tiskárnu, jejíž firmware nativně podporuje PostScript. Prakticky všechny
unixové programy produkující tiskový výstup jej vytvářejí jako Pos tScript, takže je zjevně příjemné mít tiskárnu, která jej přímo
podporuje. Bohužel, podpora PostSc
riptu bývá kromě laserových tiskáren jen zřídkavá, a někdy se prodává pouze jako drahý doplněk. Unixové programy a obecně
publikační průmysl se ustálily na používání PostScriptu coby stan-dardního jazyka pro práci s tiskárnami. Má to několik důvodů:
Načasování
PostScript se objevil jako součást Apple Laserwriter, perfektní tiskárny k Macintoshům, které jsou zodpovědné za revoluci v
publikování v 80. letech.
Nezávislost na zařízení
Pomocí PostScriptu je možné generovat výstup na rastrové obrazovce, vektorové obrazovce, faxu nebo prakticky jakémkoliv
tiskovém zařízení bez nutnosti úprav původního programu. Výstup PostScriptu bude na jakémkoliv zařízení vypadat stejně,
samozřejmě v rámci možností daného zaří-zení. Před vznikem PDF se k výměně složitějších dokumentů používal právě
PostScript. Hlavním důvodem, proč tento standard nezůstal jediným, je to, že Windows typicky neobsahují prohlížeč PostScriptu,
takže Adobe doplnil PostScript o hypertextové odkazy a kompresi, výsledek pojme-noval PDF, začal distribuovat prohlížeče
tohoto formátu a vytvořil trh pro své „destilační“ nástro-je (jejichž funkce plní i programy ps2pdf a pdf2ps balíku ghostscript).
Jde o kompletní programovací jazyk
Můžete pomocí něj vytvářet programy, které budou dělat prakticky cokoliv. Většinou je to užiteč-né k definici procedur, které pak
v rámci celého dokumentu stále dokola opakují stejné akce, například vykreslení loga nebo pozadí stránek. Neexistuje ale žádný
důvod, proč byste pomocí PostScriptu nemohli třeba počítat číslo π.
Jde o otevřený formát
PostScript je kompletně dokumentován ve volně dostupných publikacích (které najdete v každém slušnějším obchodě ve světě) a
také na adrese http://partners.adobe.com/asn/developer/techno-tes/postscript.html. I když tvůrcem formátu a dominantní
komerční implementace je Adobe, nezá-vislé implementace nabízejí i jiní výrobci, například Aladdin (tvůrce nástroje
Ghostscript).
Tiskárny bez PostScriptu
Pokud nemáte finance na nákup (obvykle drahé) postscriptové tiskárny, můžete použít jakoukoliv tiskárnu, kterou podporuje
Ghostscript, volně šířený interpret PostScriptu, používaný namísto přímé podpory PostScriptu tiskárnou. Většina linuxových
distribucí obsahuje z licenčních důvodů pouze poněkud zastaralou verzi Ghostscriptu. Naštěstí obvykle existuje možnost získat i
aktuální verzi Ghostscriptu.
Společnost Adobe vytvořila nový jazyk pro práci s tiskárnami, pojmenovaný PrintGear. Pokud vím, jde o výrazně zjednodušený
binární jazyk s jistými rysy PostScriptu, nicméně nekompatibilní s PostScriptem. Neslyšel jsem, že by jej Ghostscript podporoval.
Některé tiskárny s jazykem Print-Gear však podporují i jiné jazyky, jako například PCL, a tyto tiskárny pak v Linuxu bez potíží
fun-gují (pokud je ovšem PCL implementován přímo v tiskárně, a ne v ovladači pro Windows).
Adobe dále nabízí implementaci PostSciptu, pojmenovanou PressReady. Chová se podobně jako Ghostscript a nabízí podporu
PostScriptu na tiskárnách, které ji nativně neobsahují, nevýhodou ovšem je, že tento program funguje pouze ve Windows.
Které tiskárny fungují?
Chystáte-li se kupovat tiskárnu, máte několik možností, kde zjistit, zda bude fungovat. Kolektivněudržovaná databáze tiskáren
(http://www.linuxprinting.org/database.html) se snaží o vyčerpávají-cí seznam stavu podpory různých tiskáren v Linuxu. Najdete
zde i informace o tom, jaký ovladačs kterou tiskárnou použít.
Nejlepším tipem pro ty, kdo kupují novou tiskárnu, je seznam na adrese http://www.linuxprinting.org/suggested.html. Obsahuje
zejména barevné inkoustové a černobílé laserové tis-kárny. Stránky dokonce můžete sponzorovat tím, že si koupíte tiskárnu od
některého z autorizo-vaných prodejců uvedených na adrese http://www.linuxprinting.org/affiliate.html.
Některé fungující tiskárny a odkazy na další stránky naleznete na ghostscriptovém seznamu
http://www.cs.wisc.edu/ ~ghost/doc/printer.htm.Googlovské diskusní skupiny http://groups.google.com/ obsahují stovky
dobrozdání „funguje“a „nefunguje“. Vyzkoušejte všechny tři, a až si vyberete, ověřte si, zda ji naleznete v databázi tis-káren
http://www.linuxprinting.org/database.html, aby do budoucna byla v seznam uvedenasprávně.
Tiskárny z hlediska kompatibility s Linuxem
V této kapitola byla původně shrnuta databáze tiskáren (http://www.linux-foundation.org/en/ OpenPrinting/Database/
DatabaseIntro) se specifikacemi zařízení, poznámkami, informacemi o ovladačích apod. Tuto databázi jsme z důvodu
neaktuálnosti z knihy vyřadili a odkazujeme vás na výše uvedenou on-line databázi. On-line seznam je interaktivní; do seznamu
může přidávat položky každý a také se to průběžně děje, takže si seznam také pečlivě prohlédněte. Když v něm svoji tiskárnu
nenaleznete, můžete ji do něj přidat.
Obrázek 11.11 Databáze podporovaných tiskáren
Poznamenejme ještě, že tento seznam pochopitelně není úplně přesný; občas se v něm objeví nesprávné informace, které jsou
později odstraněny. Neověřené položky jsou označeny hvězdič-kou (*). Než tiskárnu vybranou dle tohoto seznamu zakoupíte, pro
jistotu si ještě ověřte její vlast-nosti v některé googlovské diskusní skupině.
Tiskárny jsou z hlediska kompatibility rozděleny do čtyř kategorií:
Dokonalá
Dokonalé tiskárny tisknou dokonale – lze využít všech možností tiskárny včetně barev, plné roz-lišovací schopnosti atd. V
některých případech jsou jako dokonalé označeny tiskárny s nezdoku-mentovanými režimy „rozšířeného rozlišení“, které
nefunguje; obecně je rozdíl v kvalitě tak malý, že nemá smysl se jím zabývat.
Dobrá
Tiskne dobře, ale má určité nedostatky buď při tisku nebo při jiných funkcích.
Částečně použitelná
Je možno tisknout, avšak pravděpodobně nikoli barevně anebo se špatným rozlišením. Informa-ce o nedostatcích viz on-line
seznam.
Těžítko
Nic nevytisknete pořádně; obvykle kvůli nedostatkům ovladače a/nebo dokumentace, podle níž je možno ovladač napsat. Těžítko
se někdy „zlepší“, a to buď když někdo přijde na to, že ovladač přece jen funguje, nebo když někdo napíše nový. Ani s jedním, ani
s druhým však nepočítejte.
Vzhledem k tomu, že tyto informace pocházejí od tuctů různých osob, žádná z nich není zaruče-ná; položky označené hvězdičkou
(*) jsou mírně podezřelé. Skutečnost si lze snadno ověřit na internetových stránkách daného ovladače nebo výrobce tiskárny.
Jak kupovat tiskárnu
Volba tiskárny není dnes nic jednoduchého, existuje celá řada modelů, z nichž je možno vybírat. Uveďme si několik tipů, podle
nichž se při koupi můžete orientovat:
Cena
Dostanete to, za co zaplatíte. Většina tiskáren v ceně mezi 200–300 dolary tiskne v rozumné kva-litě, nicméně má vysoké náklady
na stránku. U některých tiskáren stojí jedna či dvě nové náplně stejně jako celá tiskárna ! Navíc nejlevnější tiskárny nevydrží příliš
dlouho. Typicky mají nejlevněj-ší tiskárny střední dobu mezi poruchami zhruba tři měsíce – což je docela málo, pokud má být
tiskárna hodně používána.
Inkoustové tiskárny
Tiskové hlavy inkoustových tiskáren se po jisté době nenávratně ucpou, čili nutná je možnost časem hlavu vyměnit. Tiskové
hlavy těchto tiskáren jsou drahé, přičemž kombinovaná hlava s náplní stojí zhruba 10krát (!!!) tolik co samotná náplň. Proto je
rozumné volit takové tiskárny, kde hlava není integrovaná s náplní. Tento typ tiskáren vyrábí Epson, HP u řady DeskJet používá
kombinované hlavy. Canon používá tři nezávisle na sobě vyměnitelné náplně – což je asi nejlep-ší řešení. Na druhé straně, náplně
do tiskáren HP nejsou až tak hrozně drahé a kvalita tisku těch-to tiskáren je asi nejlepší. Tiskárny Canon stojí ohledně kvality až
na třetím místě – a tiskárny HP a Epson jsou zatím v Linuxu nejlépe podporované.
Laserové tiskárny
U laserových tiskáren je nutné měnit tiskový válec a toner plus zásobník nespotřebovaného tone-ru. Nejlevnější řešení kombinuje
válec s tonerem v jedné velké náplni, tyto tiskárny mají největší provozní náklady. Nejlepší velkokapacitní tiskárny používají
samostatný toner nebo alespoň samo-statnou tonerovou kazetu a samostatný zásobník na odpad.
Fotografické tiskárny
Nejlepší barevný výstup ve fotografické kvalitě poskytují tiskárny s plynulým tónováním, které kombinují halogenidy stříbra a
laserové osvícení a vyrábějí – překvapivě – opravdové fotografie! Tyto tiskárny ovšem stojí daleko více než tiskárny obyčejné, ale
například Ofoto.com nabízí jed-norázové tisky fotografií za rozumné ceny. Výsledek je vynikající, ani nejlepší inkoustové
tiskárny nemají šanci na srovnání.
Nejvyšší a za rozumnou cenu dosažitelnou kvalitu nabízejí (nebo spíš nabízely?) sublimační tiskárny, například série Alp
(používají tepelný přenos pevného barviva nebo přímo sublimaci bar-viva), nebo fototiskárny Sony běžné spotřebitelské úrovně.
Podpora těchto tiskáren v Linuxu je, bohužel, slabá (v jedné referenci, kterou jsem získal, se hovoří o pruzích a zrnitém obrazu) a
ani pak není jisté, zda bude možné použít nejvyšší kvalitu sublimačního přenosu. O tiskárnách Sony nemám žádné informace.
Běžnější inkoustové tiskárny pro tisk fotografií používají šesti nebo sedmibarevný tisk (CMYKcm nebo CMYKcmy). Provoz
těchto speciálních tiskáren je drahý. Buď vám dojde modrá a musíte vyměnit celou barevnou kazetu nebo je možné doplňovat
barviva samostatně, ale náplň pak stojí majlant. Drahý je také speciální papír – nemůžete očekávat vysokou kvalitu při tisku na
běžný kancelářský papír. Viz dále kapitola věnovaná tisku fotografií a popis nastavení barev v Ghostscriptu.
Novější barevné laserové tiskárny jsou už mnohem levnější, pro běžný tisk mohou být zajímavé. Stránka na barevné laserové
tiskárně vyjde levněji než na inkoustové tiskárně. Na fotografie však ještě nejsou příliš vhodné. Je docela možné, že barevné
laserové tiskárny už brzy nahradí ty otravné černobílé.
Rychlost
Rychlost je úměrná možnostem procesoru tiskárny, kapacitě připojení a ceně tiskárny. Nejrychlej-ší tiskárny jsou síťové
postscriptové tiskárny s výkonným interním procesorem. Rychlost tisku běž-ných tiskáren bude zčásti ovlivněna rychlostí
vykreslování Ghostcriptu, proto je vhodné použít rozumně výkonný počítač – zejména stránky se spoustou barev mají velké
nároky na paměť tis-kového počítače. Pokud máte dostatek paměti, mělo by všechno fungovat bez potíží.
Formuláře
Pokud chcete tisknout formuláře s více kopiemi, potřebujete jehličkovou (úhozovou) tiskárnu. Řada společností stále vyrábí
jehličkové tiskárny, které většinou emulují tradiční modely firmy Epson a fungují tak bez potíží.
Samolepky
Existují dvě podporované řady speciálních tiskáren na samolepky – Dymo-Costar a Seiko SLP. Ostatní tiskárny mohou a nemusí
pracovat. Avery vyrábí samolepicí štítky různých velikostí ve for-mátu A4, takže můžete štítky tisknout i na normálních
tiskárnách.
Plottery
K tisku na velké formáty se dnes obvykle používají obří inkoustové tiskárny, oblíbené jsou mode-ly firmy HP. Existují i menší
inkoustové tiskárny vhodné pro tisk na formát A3. Většina těchto tis-káren používá jazyky RTL, HP-GL nebo HP-GL/2, což jsou
všechno proprietární vektorové jazyky společnosti HP, výstup je typicky generován přímo aplikačními programy.
Spoolovací programy
Až donedávna měli uživatelé Linuxu jednoduchou volbu – všichni používali stejný starý lpd, pře-vzatý prakticky doslova z kódu
Net-2 BSD. Dokonce i dnes většina dodavatelů tento program distribuuje. Nicméně situace se mění. Systémy SVR4 včetně Sun
Solaris používají úplně jiné řeše-ní spooleru, postavené kolem programu lpsched.
V současné době lze vybírat z více dobrých systémů. Postupně je všechny popíšu, přečtěte si popi-sy a rozhodněte se sami.
Nejjednodušší moderní systém s grafickým rozhraním je PDQ, hodí se jak pro normální domácí uživatele, tak i (v hybridním
uspořádání pdq/lprng) pro větší prostředí. V komerčním nasazení, kde se vesměs používají síťové postscriptové tiskárny, je
dobrou alterna-tivou rozhraní jako GPR s LPRng ; přímo pracuje s možnostmi PPD a má o něco pěknější rozhra-ní. V jiných
případech je dobrou volbou CUPS, má vynikající podporu postscriptových tiskáren a nabízí dále podporu IPP, webové rozhraní a
další funkce.
CUPS
CUPS (http://www.cups.org/) se stal ve většině současných distribucí standardním tiskovým systé-mem. Čím se liší od ostatních
tiskových systémů? Je implementací protokolu IPP (Internet Printing Protocol), což je nový standard, který má vyřešit nedostatky
protokolu LPD. CUPS rovněž pod-poruje LPD, SMB a AppSocket (JetDirect) s omezenou funkcionalitou. Implementaci řídil
Michael Sweet ze společnosti Easy Software Products; je šířený pod GPL. Oproti původnímu protokolu LPD má IPP celou řadu
výhod:
Plánovač je internetový server HTTP 1.1 a poskytuje i internetové rozhraní.
Můžete se dotázat zařízení IPP, které volby a formáty dokumentů podporuje.
Řízení přístupu, které může omezovat tiskové úlohy, řízení prací a příkazy pro správu systému, které přicházejí nebo
odcházejí na určené počítače a tiskárny. Přístup k CUPS můžete podobně jako v programu Apache řídit prostřednictvím direktiv
Allow a Deny.
Podpora proxy (neboť IPP používá http).
■Podpora šifrování. Všichni hlavní prodejci operačních systémů i tiskáren v současnosti aktivně podporují IPP. IPP je
standardním tiskovým protokolem ve Windows 2000 (musí být nainstalován IIS) a může být lepší volbou pro uživatele volně
šiřitelného softwaru než proprietární protokol SMB. Nicméně, ve Win-dows 2000 automaticky stahovaný ovladač tiskárny
spolupracuje pouze s SMB, nikoli s IPP. Pro správce s mnoha windowsovskými klienty to může být důvod, proč pro sdílení
tiskárny SMB dáva-jí přednost systémům Samba nebo CUPS. CUPS má řadu velice dobrých vlastností včetně např. voleb pro
kvalitu tisku; rozhraní pro Internet, GUI a příkazové řádky; a filtrovací systém založený na mime typech se silnou podporou Post-Scriptu.Existuje několik
množin PPD, které můžete používat s CUPS:
Vestavěné
Implicitní instalace CUPS obsahuje generické PPD pro devítijehlové a dvacetičtyřjehlové mati-cové tiskárny Epson, tiskárny
Stylus Color a Stylus Photo firmy Epson, LaserJet a DeskJet firmyHP a tiskárny štítků Dymo. Umožní tisk na mnoha
modelech tiskáren, avšak neumožní využi-tí speciálních funkcí těchto modelů.
Foomatic (http://www.linux-foundation.org/en/OpenPrinting/Database/Foomatic)Foomatic generuje PPD vhodný pro použití
se všemi ovladači tiskáren, které mají veškerépodrobnosti v databázi linux-foundation.org. Lze jej využívat se skriptem
foomatic-rip, kterýpoužívají volně šiřitelné ovladače. V současnosti podporuje mnoho tiskáren v tomto systému.Tvoří základ
pro podporu nepostscriptových tiskáren ve většině distribucí Linuxu. CUPS a Foo-matic jsou čím dál oblíbenější tiskové
systémy a lze je doporučit k širokému použití.
Postscriptové PPD
CUPS může používat soubory PPD dodané prodejcem přímo pro postscriptové tiskárny. Býva-jí součástí dodávky
windowsovských ovladačů tiskáren nebo je lze nalézt na stránkách pro-dejců tiskáren. Máte-li si možnost vybrat si mezi
ovladačem pro Windows 9x a Windows NT/W2K, zvolte raději Windows NT. Pro řadu postscriptových tiskáren distribuuje
soubory také firma Adobe (http://www.adobe.com/products/printerdrivers/winppd.html).
ESP Print Pro
Firma Easy Software Products, Inc. (http://www.easysw.com/) prodává CUPS v balíku se sadou proprietárních ovladačů. I
když nejsou volně šiřitelné, lze jimi ovládat mnoho běžných tiská-ren. Balík je ve srovnání s cenou jednoho ovladače
poměrně drahý, avšak své místo na trhu určitě nalezne. Obsahuje i grafické nástroje.
Gimp-Print
Ovladače Gimp-Print (http://gimp-print.sourceforge.net/) jsou vysoce kvalitní ovladače pro tis-kárny Canon, Epson, Lexmark
a PCL a je možno je využít se systémy Ghostscript, CUPS, Foo-matic a Gimp.
OMNI (http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)
Omni je balík vytvořený IBM, v současné době podporuje více než 450 tiskáren. Ovladač tis-kárny OMNI je distribuován
IBM pod licencí LGPL.HPIJS (http://hpijs.sourceforge.net/)HPIJS podporuje v současnosti kolem 150 tiskáren firmy HP ve
vynikající tiskové kvalitě (zatím
pouze prostřednictvím Foomatic). Od verze 1.0.1 byla z licence odstraněna klauzule „hp Pro
duct Only“ a ovladače jsou distribuovány pod licencí BSD.Program XPP (http://cups.sourceforge.net/xpp/) dodaný třetí
stranou (viz obrázek 11.4) nabízíuživatelské funkcionalitě CUPS velmi zdařilé grafické rozhraní včetně skvělého rozhraní
provolby v průběhu tisku (viz obrázek 11.5). Další informace o XPP viz kapitola „XPP“.
LPD
LPD, původní Line Printer Daemon z BSD Unixu, je v unixovém světě standardem již řadu let. Je k dispozici na všech unixových
systémech a nabízí minimální množinu funkcí pokrývajících potře-by z doby sdílení počítačů. Navzdory specifické historii je i
dnes užitečný jako základní tiskový spooler. K rozumnému použití s moderními tiskárnami vyžaduje specifická nastavení, jako
jsou různé filtrační skripty a uživatelská rozhraní. To všechno ale existuje a funguje.
LPD je rovněž název síťového tiskového protokolu, definovaného dokumentem RFC 1179. Tento protokol umí nejen démon LPD,
ale v zásadě každý tiskový server, síťové tiskárny i jiné spoolovací systémy. LPD je nejmenší společná množina funkcí
standardního síťového tiskového prostředí.
LPRng (viz kapitola „LPRng“) je výrazně lepší implementace standardního LPD návrhu. Pokud musíte používat LPD, zvolte
raději LPRng. Vyžaduje o hodně méně magie k tomu, abyste jej donu-tili dělat přesně to, co potřebujete, a všechny čáry jsou
dobře dokumentovány. LPRng je v zásadě rozšířenou implementací LPD s vylepšenou bezpečností a doplněnou funkcionalitou.
Po světě se toulá řada různých zdrojových podob LPD. Pravděpodobným oficiálním vlastníkem je nějaký derivát BSD Unixu,
nicméně každý vesele implementuje různé změny, které se neznámý-mi způsoby prolínají, a tak lze jen velmi obtížně určit, jakou
konkrétní verzi LPD kdo používá. Z těch veřejně dostupných LPD nabízí GNUlpr (http://sourceforge.net/projects/lpr/) verzi s
několi-ka drobnými úpravami, které vylepšují uživatelské rozhraní. GNUlpr podporuje zadávání para-metrů přepínačem -o, ty se
pak předávají filtrům. Je to podobné funkci, nabízené i řadou tradič-ních unixových dodavatelů a analogické (i když
nekompatibilní) s mechanismem přepínače -z programu LPRng.
Používáte-li LPD, je nejlepší ovládat jej pomocí vnějšího programu („front-endu“). Je však z čeho vybírat; nejlepší jsou asi
KDEPrint, GPR (viz kapitolu „Grafické tiskové nástroje“) a XPP. Existují i další; můžete mi o nich napsat.
LPRng
Někteří prodejci Linuxu dodávají LPRng, což je novější implementace LPD. Mnohem snáze se spra-vuje ve velkých instalacích
(rozuměj: více než jedna tiskárna, nějaké sériové tiskárny nebo nějaké neobvyklé síťové non-lpd tiskárny) a není naprogramován
tak zmateně jako lpd. Dalo by se o něm dokonce říci, že je bezpečný – neexistují binární soubory s příznakem SUID a podporuje
autenti-zaci prostřednictvím PGP a Kerbera.
LPRng také obsahuje některá vzorová nastavení pro běžné síťové tiskárny – zejména laserové tis-kárny HP – které obsahují i
účtovací možnosti. LPRng používá víceméně stejný základní model filtrů jako lpd v BSD, takže podpora LPD (http://
www.linuxprinting.org/lpd-doc.html) na stránkách linuxprinting.org platí i pro LPRng. To umožňuje efektivní využívání volně
šiřitelných ovladačů pro více tiskáren.
LPRng je distribuován buď pod licencí GPL nebo Artistic.
PPR
PPR (http://ppr.trincoll.edu/) je spooler zaměřený na PostScript, který obsahuje základní post-scriptovou lexikální analýzu, z níž
odvozuje řadu užitečných vlastností. Má dobré účtovací mož-nosti, dobrou podporu pro klienty Appletalk, SMB a LPD a mnohem
lepší zpracování chyb než lpd. Podobně jako ostatní spoolery může PPR na obsluhu nepostscriptových tiskáren volat Ghost-script.
PPR byl napsán a je používán na Trinity College. Licence je podobná BSD; libovolně použitelný, příspěvek se však považuje za
povinnost.
Ostatní PDQ
PDQ znamená „Print, Don’t Queue“ (tiskni, nečekej ve frontě) a způsob tisku tomu odpovídá. PDQ je tiskový systém s
vestavěnou výkonnou syntaxí pro konfiguraci ovladačů, který nepoužívá tiskového démona. Zahrnuje možnost nastavovat
parametry tiskárny a používat grafické nebo řád-kové nástroje, jimiž mohou uživatelé tyto parametry nastavit. Uživateli se zobrazí
hezký dialog, ve kterém může nastavit rozlišení, duplexní režim, typ papíru a další.
Spouštění všech filtrů v uživatelském režimu má řadu výhod – prakticky se eliminují bezpečnost-ní problémy vznikající v
PostScriptu, efektivně lze tisknout vícesouborové úlohy LaTeXu jako sou-bory dvi a další.
PDQ není bez vad: Ta nejznámější je, že zpracovává celou úlohu před tím, než ji odešle na tis-kárnu. V případě rozsáhlých úloh je
PDQ poněkud nepraktický a tisk může skončit kopírování stovek megabajtů tam a zpět na disku. A co je horší, pomalé ovladače,
jako např. ovladače kva-litnějších inkoustových tiskáren, ani nezahájí tisk, dokud Ghostscript a ovladač neukončí zpraco-vání. To
může trvat i několik minut.
PDQ ovšem má svoje opodstatnění; má jednoduchý návrh, který uživateli nebrání v řízení tisku, nepřekračuje žádné obvyklé
bezpečnostní hranice, a není tedy bezpečnostním rizikem, která můžete tak často vidět v jiných systémech. Navíc je malý.
Systém PDQ bohužel nikdo dál nevyvíjí. Pokud by se někdo takový našel, byl by velice vítán.
GNUlpr
GNUlpr spatřil světlo světa jako příspěvek VA Linuxu sponzorovaný firmou HP. Bohužel dnes je už téměř mrtev.
CPS
Coherent Printing System (http://www.tww.cx/cps.php) je množina skriptů v Perlu, které se nazý-vají lpr, lpd, lprm a lpq.
Nahrazují programy stejného jména, které jsou součástí většiny systé-mů Linux.
CEPS
Cisco Enterprise Print System vyvinul Damian Ivereigh, když pracoval jako správce systému ve firmě Cisco. Udělal víc, než za
co byl placen – v zájmu odstranění administrativních nepořádků vyvinul nový tiskový systém. Systém poskytl k volnému použití
pod licencí GNU General Public License. Instalace CEPS se však vyplatí jen ve velkých společnostech.
Jak to celé funguje
Abyste si dokázali poradit s různými záludnostmi tisku, je nutné chápat, jak celý tiskový systém funguje. Všechny systémy
fungují v zásadě stejně, i když se může poněkud lišit pořadí některých kroků, případně mohou být některé vynechány.
Obrázek 11.12 Činnost spooleru
Uživatel odesílá tiskovou úlohu společně s nastavenými parametry. Data úlohy jsou obvykle, byť ne vždycky,
PostScript.
Spooler zkopíruje úlohu a parametry přes síť směrem k tiskárně.
Spooler čeká na dostupnost tiskárny.
Spooler uplatní na úlohu uživatelem zvolené parametry a provede překlad dat úlohy do nativního jazyka tiskárny, což
typicky není PostScript. Tomuto kroku se říká filtrování a vět-šina problémů s tiskem spočívá právě v dobře nastaveném
filtrování.
Úloha je hotova. V této fázi spooler obvykle provede potřebný úklid. Pokud došlo při zpra-cování úlohy k nějaké chybě,
spooler typicky uživatele nějakým způsobem (například e-mailem) upozorní.
Obrázek 11.13 Zjednodušený nákres CUPS
CUPS
Úlohu pomocí CUPS vytisknete jak pomocí příkazů z BSD (viz kapitolu „LPD“), tak i ze systému
System V, což je pro ty, kdo mají zkušenost alespoň s jedním z těchto systémů, velmi snadné. Původně CUPS postrádal vnitřní
program („backend“), jako má LPD, což bylo rychle napraveno. Nyní existují vnitřní programy přinejmenším pro systémy IPP,
LPD, SMB, JetDirect, USB, Netatalk k paralelním i sériovým tiskárnám. Můžete si najít i jiné anebo napsat vlastní.
Vestavěných ovladačů, jejichž prostřednictvím byste mohli tisknout na většině tiskáren (avšak nikoli s maximálním rozlišením),
existuje jen několik. K systému CUPS můžete přidat soubor PPD pro postscriptový ovladač, chcete-li však tisknout v nejlepší
kvalitě na vaší báječné nové tiskárně HP Deskjet, máte smůlu. Snad přinese nápravu Foomatic. Můžete jej zkombinovat s CUPS.
Foo-matic ke svým kouzlům používá filtry CUPS, které se jmenují foomatic-rip. K popisu funkcí tiská-ren používají soubory
PPD, a to i u nepostscriptových tiskáren. V současnosti je kombinace CUPS
+ Foomatic doporučovaným tiskovým systémem. Některé linuxové distribuce už ji používají
a jejich počet jenom poroste.Plánovač CUPS nejen přijímá úlohy, nýbrž také spravuje internetové rozhraní. Můžete přidávata
ubírat tiskárny, rušit úlohy, spouštět a zastavovat tisky. Přenosy tiskových úloh budou k dispo-zici v pozdější verzi.
LPD
LPD znamená Line Printer Daemon a v různých kontextech se touto zkratkou označuje jak samotný démon, tak celá skupina
programů, které zajišťují tiskový spooling. Jsou to:
lpd (http://www.linuxprinting.org/man/lpd.8.html)
Spoolingový démon. Jedna instance běží a řídí celý tisk na počítači, další instance běží pro
každou tiskárnu v době, kdy tiskne. lpr (http://www.linuxprinting.org/man/
lpr.1.html)
Uživatelský příkaz pro tisk. Kontaktuje lpd a přidá úlohu do fronty. lpq (http://
www.linuxprinting.org/man/lpq.1.html)
Vypíše seznam úloh ve frontě.
lpc (http://www.linuxprinting.org/man/lpc.8.html)
Příkaz pro řízení tiskového systému. Umožňuje zastavovat, spouštět, měnit pořadí a podobně
úloh ve frontách. lprm (http://www.linuxprinting.org/man/lprm.1.html)
Odstraňuje úlohu z fronty.
Jak to zapadá do sebe? Odehrávají se následující kroky:
Při startu systému se spouští démon lpd. Čeká na spojení a spravuje tiskové fronty.
Uživatel zadává úlohy k tisku příkazem lpr , popřípadě grafickým rozhraním jako GPR, PDQ a podobně; lpr kontaktuje
po síti lpd a předá mu datový soubor (obsahující tištěná data) a řídicí soubor (obsahující parametry úlohy).
Když se uvolní tiskárna, spustí hlavní lpd svou další instanci, která obslouží tisk úlohy.
Synovský lpd spustí příslušný filtr (definovaný příznakem if v souboru /etc/printcap) a výsledná data pošle na tiskárnu.
Tento systém byl původně navržen v době, kdy většina tiskáren byly řádkové tiskárny – tedy v době, kdy se převážně tiskly čistě
textové soubory. Umístěním všech potřebných kroků do pří-slušných filtrů je možné pomocí lpd vyhovět i nárokům moderního
tisku (tedy, alespoň jakžtakž
– řada jiných systémů funguje lépe).
Při tvorbě filtrů pro LPD je možné použít řadu užitečných programů. Jsou to mimo jiné:
gs
Ghostscript je softwarový interpret PostScriptu (označovaný též jako Raster Image Processor nebo RIP). Jako vstup přijímá
PostScript a výstup vytváří v různých ovládacích jazycích tiskáren nebo v různých grafických formátech. O tomto programu
hovoříme v kapitole „Ghostscript“.
ppdfilt
Samostatná verze jedné z komponent CUPS. Filtruje PostScript, provádí některé základní transfor-mace (jako například řazení
více kopií) a doplňuje uživatelem nastavené parametry na základě PPD souboru (PostScript Printer Definition), který bývá
obvykle dodáván s tiskárnou.
ppdfilt je nejlépe používat se systémem LPD, který akceptuje volby (podobně jako GNUlpr nebo LPRng) a skriptový filtr, který
převede uživatelské volby do ekvivalentu příkazu ppdfilt. Ve VA Linux a v HP existuje upravený balík, který dělá přesně toto; s
postscriptovou tiskárnou jsou výsledky velmi dobré. Informace o tomto systému viz kapitola „LPD pro postscriptové tiskárny“.
ps2ps
Jde o skript dodávaný s Ghostscriptem. Filtruje PostScript na jednodušší PostScript na nižší úrov-ni jazyka. Je to užitečné, pokud
máte starší postscriptovou tiskárnu, protože většina moderních programů produkuje i moderní PostScript.
mpage
Tento nástroj přijímá vstup v PostScriptu a generuje výstup s více stránkami tištěného textu na jedné tiskové stránce. Tuto funkci
nabízí i řada dalších programů, například enscript, nenscript a a2ps.
a2ps
Program a2ps, any-to-ps, přijímá vstup v různých formátech a konvertuje je na PostScript.
Jak všechno nastavit
V případě běžných konfigurací můžete tuto kapitolu pravděpodobně ignorovat a přejít rovnou ke kapitole „Řešení jednotlivých
distribucí “ nebo ještě lépe, nahlédnout do dokumentace dodavatele. Většina distribucí Linuxu nabízí jeden či více
„blbuvzdorných “ nástrojů, které umožňují za běžných podmínek a při běžných tiskárnách vše dále popsané jednoduše nastavit.
Pokud nástroje dodavatele nefungují nebo pokud byste chtěli interaktivně řídit parametry tisku při tisku, měli byste použít jiný
systém. Dobrou volbou je PDQ, nabízí velmi dobrou funkčnost a jed-noduchou konfiguraci. Dalším dobrým systémem je APS
Filter, který konfiguruje fronty a filtry LPD na většině unixových systémů.
Dále můžete vyzkoušet rozhraní tiskového systému na stránkách http://www.linuxprinting.org/, která umožňují propojit řadu
volně šířených ovladačů s různými spoolovacími systémy. Po zavr-šení celého projektu budou tato rozhraní nabízet nejlepší
funkčnost – podporují všechny typy volně šířených ovladačů, podporují uživatelská nastavení a všechny běžné spoolery.
Konfigurace CUPS
Používáte-li klienta s CUPS a server CUPS je už zkonfigurovaný, instalace tiskáren na vašem kli
entovi už nemůže být jednodušší: Neuděláte vůbec nic. Klient si pomocí všesměrového přenosu
najde server CUPS a automaticky zkonfiguruje tiskárny, které jsou nainstalovány na tomto tisko
vém serveru. To je funkce, kterou je na velkých sítích nutno skutečně ocenit.
Ruční konfigurace tiskáren s CUPS je také chuťovka. Pokud s takovou prací teprve začínáte, bylo
by asi lepší použít internetové rozhraní. Jestliže však je tiskáren, které máte zkonfigurovat, více,
bude rychlejší pracovat pomocí příkazových řádků.
URL internetového rozhraní CUPS je implicitně http://hostname:631/admin. Je-li to nutné, v souboru cupsd.conf je možno změnit font.Obecná syntaxe přidání tiskárny z příkazového řádku je lpadmin -p printer -E -v device -m
ppd.Příkazem lpadmin s volbou -p přidáme nebo změníme tiskárnu. Tiskárny jsou uloženy v soubo-ru. Volbou -x zrušíme
uvedenou tiskárnu. Další volby viz manuálové stránky příkazu lpadmin.
Příklad 3. Příklady příkazových řádků
/usr/sbin/lpadmin -p testpr1 -E -v socket://192.168.1.9 -m deskjet.ppd /usr/sbin/lpadmin -p testpr2 -E -v parallel:/dev/lp0 -m
laserjet.ppd /usr/sbin/lpadmin -x testpr1
Další informace o konfiguraci tiskáren a o volbách naleznete v dokumentaci CUPS (http://www.cups.org/documentation.html,
přístupná bývá i na http://localhost:631 v sekci „Docu-mentation“). Konfigurační postupy jsou také v Software Administrators
Manual.
Konfigurace LPD
Hodně linuxových systémů obsahuje LPD. V této kapitole popisujeme základní nastavení LPD, podrobnostem o vytváření
složitějších filtrů a o síťovém tisku se věnujeme samostatně.
Základní konfigurace LPD
Základní nastavení LPD vede k systému, který umí řadit úlohy do fronty a tisknout je. Nestará se
o to, zda tiskárna bude úlohám rozumět a výsledný vzhled dokumentů asi nebude dokonalý. Někde ale musíme začít.
Chcete-li do LPD přidat frontu, musíte upravit soubor /etc/printcap a vytvořit nový adresář pod /var/spool/lpd .
Záznam v /etc/printcap vypadá takto: # LOCAL djet500lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:sh:
Tímto definujeme frontu pojmenovanou lp, dj a deskjet, umístěnou v adresáři /var/spool-/lpd/dj , bez limitu velikosti úlohy, ze které
se tiskne na zařízení /dev/lp0 a která k úloze nepři-dává hlavičkovou stránku (například s údajem o tom, kdo úlohu vytvořil).
Teď si přečtěte manuálovou stránku printcap (http://www.linuxprinting.org/man/printcap.5.html). Výše uvedený příklad vypadá
velmi jednoduše, je v něm ale zrada – pokud na tiskárnu DeskJet 500 nebudeme posílat data, kterým bude tiskárna rozumět,
budou se tisknout divné věci. Napří-klad pokud vytisknete normální unixový text, bude tiskárna doslovně interpretovat řídicí
znaky LF a výsledkem bude:
This is line one. This is line two. This is
line three.
a tak dále. Pokud tímto způsobem budeme tisknout PostScript, dostaneme krásný výpis post
scriptových příkazů zobrazený v tomto „schodišťovém“ efektu, výsledek ale k ničemu moc nebude.Zjevně je potřeba něco navíc,
a to je právě úkolem filtrace. Pozorný čtenář, který nepřeskočilmanuálovou stránku printcap, jistě postřehl parametry if a of. Nuže,
if neboli input filter je to,co teď potřebujeme.
Pokud si napíšeme krátký skript, který ke znakům LF doplní i znaky CR, můžeme zrušit schodiš-ťový efekt. Přidáme tedy řádek
s parametrem if:lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:if=/var/spool/lpd/dj/filter:\
:sh:
Filtrační skript může vypadat například takto:
#!perl # The above line should really have the whole path to perl # This script must be executable: chmod 755 filter while(<STDIN>){chomp $_;
print "$_\r\n";}; # You might also want to end with a form feed: print "\f";
Pokud bychom to všechno udělali, dostaneme frontu, jejímž prostřednictvím můžeme tisknout normální textové soubory a
dostaneme použitelné výsledky. (Ano, existují asi čtyři miliony lepších způsobů, jak filtr napsat, ale nejsou tak názorné. Klidně to
udělejte efektivněji.)
Posledním zbývajícím problémem je fakt, že tisk prostého textu dneska málokoho nadchne – roz-hodně bychom chtěli tisknout i
PostScript, grafiku a podobně. Jistě to jde a je to poměrně jedno-duché. Celá finta spočívá v rozšíření schopností výše uvedeného
filtru.
Takovému filtru říkáme „magický“ filtr. Nenamáhejte se s tím psát si jej sami, pokud netisknete vyloženě avantgardní formáty –
řada už existuje a mají snadno použitelná interaktivní konfigurační rozhraní. Stačí prostě zvolit vhodný existující filtr:
Foomatic-rip
Foomatic-rip (http://www.linuxprinting.org/lpd-doc.html) je filtr používající data z databáze Linux-Printing.org. Podporuje
prakticky všechny volně distribuované ovladače tiskáren včetně ghost-scriptových ovladačů, uniprintových ovladačů a různých
filtrů, které se potulují po Internetu; foo-matic-rip pracuje s CUPS, LPRng, LPD, GNUlpr, PPR a PDQ bez spooleru.
APS Filter
APS Filter (http://www.apsfilter.org/) je filtr určený pro použití v různých Unixech. Podporuje prak-ticky všechny ghostscriptové
ovladače. I on pracuje s různými typy LPD, včetně základního BSD i LPRng.
Tiskové filtry RHS
RHS je filtrační systém vytvořený společností Red Hat. Jeho distribuce začala, pokud vím, ve verzi Red Hat 4, kde sloužil jako
základ pro grafickou nástavbu printtool pro snadnou konfiguraci tis-káren. Jiné distribuce včetně Debianu dnes distribuují
kombinaci rhs-printfilter/printtool. Jedná se asi o nejrozšířenější filtrační systém.
Systém rhs je založen na ASCII databázi, která je jeho součástí. Ta obsahuje údaje o podpoře řady ovladačů Ghostscript a
Uniprint, nepodporuje však ovladače filtrového typu. Filtry navíc příliš nepodporují uživatelskou volbu parametrů tisku.
Printtool ukládá v adresáři fronty konfigurační soubor postscript.cfg . V tomto souboru podob-nému shell skriptům představuje
každé nastavení jednu proměnnou. V neobvyklých případech můžete užitečné zásahy provést přímo modifikací konfiguračního
souboru, kterou nemusí umož-ňovat printtool – typicky půjde o specifikaci neobvyklého ghostscriptového ovladače nebo PPD
souboru u VA verze rhs-printfilters.
VA Linux v rámci kontraktu s HP obsahuje některá vylepšení systému rhs-printfilters. Správné verze umožňují volbu parametrů
postscriptových tiskáren, které jsou řízeny PPD soubory. O tomto systému hovoříme v kapitole „LPD pro postscriptové tiskárny“.
Použití těchto filtrů má jednu nevýhodu: Starší verze lpd nespouštějí filtr if pro vzdálené tiskár-ny, zatímco většina novějších verzí
ano (i když často jen bez parametrů). Verze LPD obsažené v moderních distribucích Linuxu a FreeBSD jej spouštějí, verze LPD
ve většině komerčních Unixů ne. Více informací na toto téma uvádíme dále v kapitole věnované tisku v síti. Pokud pracujete jen
s lokálně připojenými tiskárnami, tyto problémy se vás netýkají.
LPD pro postscriptové tiskárny
I když většina verzí LPD nezpracovává PostScript dobře (bez ohledu na uživatelská nastavení), VA Linux nedávno modifikoval
LPD a filtrační software Red Hat, takže nyní podporuje postscriptové tiskárny poměrně dobře. Vzhledem k tomu, že úmyslem
bylo věnovat kód projektu GNU, dostal název GNUlpr (http://lpr.sourceforge.net/).
Jak to funguje
Nový systém VA používá soubory PPD – Postscript Printer Definition. PPD soubory poskytuje výrobce tiskárny a obsahují
informace o funkcích, které tiskárna umí, společně s postscriptovým kódem, jenž tyto funkce aktivuje. V systému VA funguje
klasické schéma LPD poněkud odlišně.
Uživatel může nastavovat parametry příznakem -o. Můžete například zadat -o MediaType: Transparency při tisku na
fólii. Je však možné také použít nástavby jako GPR (http://www.compumetric.com/linux.html), které umožňují volit parametry v
dialogovém rozhraní. Příslušné obrázky můžete vidět v kapitole „Grafické tiskové nástroje“.
LPR předá parametry LPD jako rozšířené atributy v řídicím souboru LPD.
Modifikovaná verze rhs-printfilters obdrží rozšířené parametry v proměnných prostředí a pomocí ppdfilt je přidá k
tiskovým datům.
Získání a instalace
RPM balíky nebo zdrojové kódy můžete získat na domovské stránce projektu na SourceForge (http://sourceforge.net/projects/lpr).
Informace o instalaci najdete v instalačním dokumentu micro-HOWTO (http://printing.sourceforge.net/gpr-libppd-uhowto.html).
V zásadě musíte odinstalovat původní Red Hat verzi balíků printtool, lpd a rhs-printfilters a nainstalovat jejich VA verze spo-lečně
s balíky ppdfilt, gpr a s dalšími nástroji.
Dále potřebujete PPD soubor pro svou postscriptovou tiskárnu. Tyto soubory se obvykle dají snadno najít. VA Linux a HP
distribuují PPD soubory pro řadu modelů Laserjet. Další výrobci poskytují PPD soubory ke svým tiskárnám, Adobe distribuuje
PPD soubory pro řadu tiskáren (http://www.adobe.com/products/printerdrivers/winppd.html).
V současné době je instalace většiny nástrojů poměrně obtížná. Budoucí instalační nástroje mají být postaveny nad konfigurační
knihovnou tiskáren, libprinterconf, která umožňuje automatickou detekci a konfiguraci rhs-printfilter pro síťové i lokální tiskárny.
Je možné použít GPR i samostatně, bez modifikovaného LPD, a dokonce i bez rhs-print-filters. GPR je možné přeložit s
podporou kompletního zpracování postscriptových úloh. Tato možnost může být z hlediska instalace jednodušší pro
uživatele, kteří nepotřebují tisk-nout přímo přes lpr.
Nastavení parametrů PostScriptu
Po nastavení LPD systému s podporou PostScriptu můžete parametry tiskáren nastavovat dvěma způsoby:
Pomocí grafického rozhraní
Abyste mohli použít GPR, musíte nejprve vybrat správný soubor PPD. Pak budou na záložce Advanced k dispozici parametry
tiskárny. Základní parametry ppdfilt najdete na záložce Common.
Z příkazového řádku Tato verze lpr podporuje přepínač -o. S jeho pomocí můžete zadat jakoukoliv dvojici para-metr/hodnota
podle PPD souboru vaší tiskárny. Předpokládejme například, že soubor PPD obsahuje následující:
*OpenUI *PrintQuality/Print Quality: PickOne
*DefaultPrintQuality: None
*OrderDependency: 150 AnySetup *PrintQuality
*PrintQuality None/Printer Setting: ""
*PrintQuality Quick/QuickPrint: "<< /DeviceRenderingInfo ...
*PrintQuality Normal/Normal: "<< /DeviceRenderingInfo << /...
*PrintQuality Pres/Presentation: "<< /DeviceRenderingInfo ...
*PrintQuality Image/1200 Image Quality: "<< /DeviceRenderi...
*CloseUI: *PrintQuality
Parametr PrintQuality povoluje hodnoty Quick, Normal, Pres a Image. Na příkazovém řádku můžete zadat:
% lpr -o PrintQuality:Image file.ps
Kromě toho existuje řada voleb společných pro všechny tiskárny, ty budou fungovat stejně jako volby definované v souboru PPD.
Jsou to například:
page-ranges
Rozsah stránek pro tisk, například page-ranges:2-3 page-set
Umožňuje tisknout pouze liché (odd) nebo sudé (even) stránky. Například pageset: odd number-up
Na každý list můžete vytisknout více stránek, například number-up:2
Další parametry najdete na manuálové stránce ppdfilt.
Přístupová práva k souborům
Na základě spousty žádostí uvádím výpis přístupových práv u důležitých souborů na svém systé-mu. Nastavení lze provést i
lepšími způsoby, například pomocí příznaku SGID pro binární pro-gramy, nemusí být vše nastaveno SUID root. Jde o implicitní
nastavení systému a funguje dobře. (Upřímně řečeno, pokud by implicitní nastavení nefungovalo, je čas na změnu dodavatele...)
-r-sr-sr-x 1 root lp /usr/bin/lpr* -r-sr-sr-x 1 root lp /usr/bin/lprm* -rwxr--r--1 root root /usr/sbin/lpd*
-r-xr-sr-x 1 root lp /usr/sbin/lpc* drwxrwxr-x 4 root lp /var/spool/lpd/ drwxr-xr-x 2 root lp /var/
spool/lpd/lp/
Lpd musí běžet jako root, aby se mohl připojit na nízký síťový port, určený pro službu lpd. Po připojení na port by měl přejít na
UID lp.lp nebo tak nějak, ale nemyslím, že to dělá. I to je jeden z důvodů, proč nepoužívat standardní BSD LPD.
Velké instalace
Velké instalace, čímž myslím sítě s více než dvěma tiskárnami nebo počítači, mají speciální poža
davky. Dále uvádíme několik doporučení.
Pro velké sítě je velice vhodný systém CUPS, neboť má řadu velmi dobrých vlastností. Namátkou
jmenujme alespoň třídy tiskáren, řízení přístupu a automatickou konfiguraci klienta.
V opravdu velkých prostředích je problémem už samotná distribuce nastavení printcap a filtrů.Tyto problémy řeší Cisco Enterprise
Print System (http://ceps.sourceforge.net/) a představuje takdobrý začátek, případně téměř kompletní řešení, v závislosti na
skutečných potřebách. Střednía velká prostředí si mohou vystačit s nativními funkcemi LPRng nebo CUPS.
Každá tiskárna by měla mít jedno řídicí místo, odkud může administrátor pozastavovat, řadit a přesměrovávat frontu.
Lze to implementovat tak, že vše budete tisknout na lokální server, který pak úlohy řadí a směruje je na správné tiskárny.
Rozsáhlejší prostředí nebo distribuované sítě mohou používat samostatný server pro každou budovu nebo jinou jednotku.
Používejte CUPS nebo LPRng, přinejmenším na serverech – BSD LPD má příliš mnoho chyb na „opravdové“ použití.
Nemusíte mi ale věřit – vyzkoušejte si různé spoolery a zjistíte, který vám vyhovuje nejvíce.
Klientské systémy by neměly používat vlastní tiskové konfigurace. V systému CUPS je možno v jedné podsíti provést
klientskou konfiguraci tiskáren automaticky. CUPS dokon-ce můžete zkonfigurovat (BrowsePoll) tak, aby vybral příslušné
tiskárny v jiných podsítích, čímž ušetříte klientovi práci s konfigurací. Tuto funkci lze implementovat pomocí rozšíře-né syntaxe
printcap v LPRng, takže můžete mít všude stejný printcap. CUPS to řeší pomocí distribuované databáze.
Tiskové fronty by se neměly jmenovat podle typu tiskárny, ale nějak rozumně, například podle umístění tiskárny nebo
podle možností tiskárny. Za tři roky, až se tiskárna pokazí, ji budete moci nahradit jinou a nedojde ke zmatkům.
Vytvořte webové stránky s podrobnými informacemi o tiskárnách, včetně jejich umístění, možností a podobně. Mohly
by případně vypisovat i obsah tiskové fronty a umožnit sma-zání úloh z fronty. Ve složitých síťových prostředích není možné
pracovat bez dostatečné dokumentace.
Používejte internetovou stránku, která zobrazuje podrobné informace o všech tiskárnách včetně umístění, funkcí apod.
Měla by se zobrazovat i fronta s tlačítkem pro odstranění úlohy z této fronty. Bez odpovídající dokumentace není možné nastavit
komplexní síťové prostředí.
Na systémech Windows a Apple používejte všude buď konkrétní ovladače konkrétních tis-káren (Samba podporuje
mechanismus automatické aktualizace ovladačů) anebo ještě lépe, používejte všude obecný postscriptový ovladač. Nikdy
nemíchejte různá nastavení, jednoduché textové editory často vytvářejí na různých ovladačích různé výstupy a uživate-lé se těžko
vyrovnávají s tím, když se výsledná podoba výtisku mění pro každou dvojici klient/tiskárna.
Pokud je to možné, tisknete-li velké objemy dokumentů, kupte si velkokapacitní tiskárnu. Pokud na to nemáte, využijte
funkci více tiskáren na jedné frontě, podporovanou LPRng, a obstarejte si chůvu – tiskárny jsou složitá mechanická zařízení a v
intenzivním provozu mají tendenci papír zmuchlat nebo spotřebovat...
Nevěřte tomu, že tiskárna musí být připojena k počítači, ethernetové „tiskové servery“ stojí méně než 100 dolarů.
Možnost umístit tiskárnu kdekoliv, kde je síť, je velká výhoda oproti vynucenému umístění poblíž počítače. Snadno pak tiskárny
soustředíte na jedno centrální místo.
Používejte SNMP nebo jiné monitorovací mechanismy, které jsou k dispozici – snadno pak bude moci pověřená osoba
doplňovat papír, toner a podobně. Správu tiskáren s podpo-rou SNMP umožňuje například npadmin (viz kapitolu „npadmin“).
Účtování
Standardní LPD nabízí jen malou pomoc při účtování tisku. V parametru af souboru printcap můžete definovat jméno účtovacího
souboru, to se však pouze předává jako parametr filtru if. Sami pak musíte zajistit, aby filtr provedl zápis do účtovacího souboru,
a sami jej pak musíte zpra-covávat (tradiční formát je vhodný zejména pro řádkové tiskárny a špatně se analyzuje v Perlu, takže
není důvod se jej držet). Pokud jako filtr použijete program foomatic-rip, musíte jej také upravit, protože vyžaduje specifikaci
účtovacího souboru v konfiguračním souboru.
CUPS účtuje stránky tak, že úlohy předává prostřednictvím filtru pstops, který předpokládá vstup v PostScriptu. „Normální“
(nepostscriptové) úlohy započítává jako 1 stránku, což znamená, že při tisku z windowsového klienta s normálním ovladačem
nebude účtování fungovat.
Ghostscript nabízí operátor PageCount, který lze použít k určení počtu stránek v každé úloze
– typicky pouze na konec každé postscriptové úlohy doplníte pár řádků pro zápis údajů do účto
vacího souboru. Pěkný příklad najdete v souboru unix-lpr.sh v distribuci Ghostscriptu. Implementace účtování unix-lpr provádí
zápis do účtovacího souboru přímo z interpretu Ghost-scriptu a není tak použitelná s doporučeným parametrem -dSAFER. Lepší
řešení by bylo po skon-čení úlohy zjistit počet stránek PJL dotazem na tiskárnu nebo napsat v PostScriptu kód, který vypí-še počet
stránek na stdout – zde jej lze snadno odchytit a zpracovat bez nutnosti zápisu do sou-boru.
Spooler LPRng obsahuje příklad implementace účtování pro tiskárny HP – předpokládám, že používá PJL dotazy na tiskárny.
Tento způsob by měl fungovat u většiny PJL, postscriptových a SNMP tiskáren, které podporují obousměrnou komunikaci.
Pokud máte síťovou tiskárnu s podporou SNMP, můžete pomocí programu npadmin zjistit počet stránek po skončení každé úlohy.
Tato metoda by měla spolehlivě fungovat pro všechny typy úloh. Další informace o programu npadmin najdete v kapitole
„npadmin“.
Řešení jednotlivých distribucí
Tato kapitola je ze své podstaty neúplná. Klidně mi pošlete informace o své oblíbené distribuci. Kromě toho existuje řada
samostatných balíků, které usnadňují konfiguraci tiskáren v Unixu. Hovoříme o nich v kapitole „Jak všechno nastavit“, najděte si
část odpovídající vámi používanému tiskovému spooleru.
Red Hat
Red Hat obsahuje grafický nástroj pro administraci tiskáren, printtool, který umožňuje přidávatvzdálené i síťové tiskárny.
Umožňuje zvolit typ Ghostscriptem podporovaných tiskáren a dále zaří-zení, na něž se bude tisknout. Pak v /etc/printcap definuje
tiskovou frontu a používá filtračníprogram z balíku rhs-printfilters k podpoře PostScriptu a dalších běžných vstupních typů.
Totořešení funguje poměrně dobře a v běžných situacích se velmi snadno nastavuje.
Red Hat 6.x obsahuje BSD verzi LPD, Red Hat 7.x používá standardně LPRng. S Red Hatem 6.x a 7.x narazíte v okamžiku, kdy
máte tiskárnu, kterou jejich standardní Ghostscript nepodporuje (používají GNU Ghostscript namísto Aladdin Ghostscriptu, takže
je podporo-váno méně tiskáren). Podívejte se do seznamu podporovaných tiskáren (http://www.linuxprinting.org/printer_list.cgi),
kde zjistíte, zda standardní Red Hat vaši tiskárnu podporuje.
Pokud ne, můžete si nainstalovat Aladdin Ghostscript a balíky lpdomatic nebo apsfilter, které vědívšechno o tiskárnách
podporovaných nejnovějším Ghostscriptem i o některých dalších.V Red Hat Linuxu 8.0 je stále implicitně instalován LPRng, i
když si můžete vybrat CUPS. Avšak
i když explicitně vyberete pouze CUPS, zůstává LPRng nainstalovaný. Ve verzi 8.1 by konečně měl
být CUPS implicitním spoolerem.
Ve verzi Red Hat 9.0 je CUPS konečně implicitní.
Debian
Debian nabízí volbu mezi standardním LPD, LPRng a CUPSem. LPRng a CUPS jsou zjevně lepší volby. PDQ najdete v
nestabilní verzi. Dále Debian nabízí různé konfigurační nástroje, nejlepší volbou je asi APS Filter verze 5 nebo vyšší, protože
obsahuje podporu pro ovladače uniprint LPRng a Ghostscriptu. Podporován je i printtools od Red Hatu pro ty uživatele, kteří mají
rádi grafické nástroje.
SuSE/openSUSE
Tiskový systém v SuSE Linuxu je založen na APS Filter s některými vylepšeními. APS Filter od SuSE rozeznává všechny běžné
formáty souborů (včetně HTML, pokud je nainstalován program html2ps). V systémech SuSE jsou dvě možnosti nastavení
tiskáren:
YaST umožňuje nastavit tiskárny „PostScript“, „DeskJet“ a „Other“, podporované ovladači Ghostscript, kromě toho je
možné nastavit tiskárny HP GDI (DeskJet 710/720, 820, 1000, pomocí balíku ppa). YaST zapíše do /etc/printcap údaje pro každou
tiskárnu („raw“, „ascii“, „auto“ a „color“, pokud jde o barevnou tiskárnu). Dále YaST vytvoří adresář fronty a nastaví soubory
apsfilterrc , kde můžete doladit některá nastavení (preload Ghost scriptu, velikost a orientace papíru, rozlišení, escape sekvence
tiskárny a podobně). Pomo-cí YaST je možné nastavovat i síťové tiskárny (TCP/IP, Samba a Novell NetWare).
Kromě toho SuSE obsahuje i standardní program SETUP z původního balíku APS Filter (s některými vylepšeními).
Tento konfigurační skript spustíte příkazem lprsetup. Jakmile si zvyknete na jeho rozhraní, budete moci konfigurovat lokální i
síťové tiskárny.
Instalační manuál SuSE popisuje oba postupy instalace.
Wolf Rogner ohlásil se SuSE některé problémy. Vadit mohou následující věci:
Klasický skript SETUP z APS Filter není v pořádku stejně jako konfigurační nástroj v KDE. Použijte YaST. [Ed: Už to
funguje? Od ohlášení už uplynulo dost času.]
U síťových tiskáren ovládaných přes Ghostscript budete muset nejprve odkomentovat řádek
REMOTE_PRINTER=“ remote“ v /etc/apsfilterrc. Pak pomocí YaST nastavte tis-kárnu a pomocí konfigurace sítě nastavte
vzdálenou tiskovou frontu.
YaST nepodporuje barevné laserové tiskárny, takže nastavte černobílou tiskárnu a pak všude v printcap změňte mono na
color. Možná budete muset přejmenovat i adresář fronty.
Mandrake/Mandriva
Ve verzi 7.2 používá Mandrake standardně CUPS. Administrativní rozhraní poskytuje program QtCUPS. Snažili se poskytnout co
možná nejvíce ovladačů a používají PPD soubory pro CUPS, generované mým vlastním rozhraním foomatic (http://
www.linuxprinting.org/foomatic.html).
Starší verze Mandrake, pokud vím, používaly stejné nástroje jako Red Hat.
Slackware
Slackware obsahuje APS Filter. Skript SETUP je nainstalován jako program apsfilterconfig. Rozumné nastavení byste měli být
schopni vytvořit prostým spuštěním tohoto programu. Slackware 9.0 obsahuje i CUPS, ale implicitní je stále LPRng + APS Filter.
Ghostscript
Ghostscript (http://www.cs.wisc.edu/~ghost/) je nesmírně významný program pro softwarově říze-ný tisk. Většina programů v
Unixu generuje výstup v PostScriptu, jehož podpora je u většiny tis-káren (draze) placený doplněk. Ghostscript je naproti tomu
zadarmo a z postscriptového vstupu vygeneruje výstup v jazyce, kterému rozumí vaše tiskárna.
Ghostscript existuje v několika podobách. Komerční verzi Ghostscriptu, Aladdin, lze zadarmo používat pro osobní potřebu, nesmí
však být distribuována komerčními entitami. Tato verze je zhruba rok napřed před free verzí. Momentálně například podporuje
řadu barevných inkousto-vých tiskáren, které starší verze neznají, a má také výrazně lepší podporu PDF.
Hlavní free verzí Ghostscriptu je GNU Ghostscript, což je jednoduše stará verze Aladdin Ghost scriptu. Díky tomuto poněkud
podivnému uspořádání je Aladdin samofinancující se free projekt. Vývoj vede L. Peter s několika zaměstnanci a nové verze
licencuje dodavatelům hardwaru a soft-waru k použití v komerčních produktech. I když toto uspořádání umožňuje L. Peterovi už
řadu let pracovat na Ghostscriptu, bohužel znemožňuje spolupráci s širší vývojářskou komunitou. Toto řešení zejména
nevyhovuje autorům ovladačů. Plány L. Petera na odchod do důchodu předpo-kládají zapojení širší komunity, takže zvažuje
změnu licence a vytvořil projekt na SourceForge.
Třetí verzí Ghostscriptu je ESP Ghostcript, udržovaný společností Easy Software Products (autoři CUPS) na základě kontraktu se
společností Epson. ESP Ghostscript je kombinací ovladačů gimp print projektu a GNU Ghostscriptu plus vybraných doplňků.
Tato verze ještě není plně funkční, ale brzy by měla být vylepšena a měla by usnadnit život majitelům tiskáren s ovladači gimpprint.
Ať už gs (http://www.linuxprinting.org/man/gs.1.html) používáte jakkoliv, rozhodně jej vždy spou-štějte se zákazem přístupu k
souborům (parametr -dSAFER). PostScript je plnohodnotný progra-movací jazyk a škaredý program v PostScriptu vám může
způsobit řadu problémů.
Abychom nezapomněli, PDF, Portable Document Format od Adobe, je (přinejmenším od verze 1.3) pouze o trochu více než
komprimovaný PostScript. Ghostscript umí zpracovávat PDF stejně jako PostScript. Možná tak budete první v okolí, kdo umí
přímo tisknout PDF.
Spuštění Ghostscriptu
Typicky se Ghostscript spouští filtrem, který používáte (doporučuji Foomatic), pro účely ladění je však často užitečné spouštět jej
přímo; gs -help vypíše stručný seznam parametrů a dostupných ovladačů (jsou uvedeny ovladače, s nimiž je Ghostscript přeložen,
nejde o úplný seznam všech podporovaných ovladačů).
Pro účely testování budete gs spouštět například takto:
gs <parametry> -q -dSAFER -sOutputFile=/ dev/lp1 test.ps
Doladění výstupu Ghostscriptu
Existuje řada věcí, které můžete podniknout, pokud není výstup Ghostscriptu uspokojivý (může
te vlastně provést naprosto cokoliv, protože máte k dispozici zdrojový kód). Některé z těchto možností jsou popsány v
Ghostscript User Guide (soubor Use.htm,http://www.cs.wisc.edu/~ghost/aladdin/doc/Use.htm, v distribuci Ghostscriptu, měli
byste jej najítv /usr/doc nebo /usr/share/doc). Vybrané možnosti můžete použít jako parametry ovladačeve filtračním systému.
Velikost a umístění výstupu
Umístění, velikost a poměr stran obrázku na stránce se v Ghostscriptu řídí ovladači specifickými pro danou tiskárnu. Pokud
zjistíte, že tištěné stránky jsou příliš krátké, příliš dlouhé nebo dvojná-sobně veliké, podívejte se do zdrojového kódu ovladače a
upravte parametry, které uznáte za vhodné. Bohužel, každý ovladač je jiný, takže neumím říct, co přesně kde nastavit, nicméně
vět-šina ovladačů je rozumně dokumentovaná.
Gamma, velikost bodu atd.
Většina tiskáren jiných než laserových trpí tím, že mají velké tiskové body. Výsledkem jsou příliš tmavé obrázky. Pokud máte
tento problém s jinak neupravitelným ovladačem, můžete zkusit pou-žít vlastní transformační funkci. Vytvořte následující soubor
v adresáři lib Ghostscriptu a jeho název přidejte při spouštění gs před název tisknutého souboru. Možná budete muset upravit konkrétní hodnoty tak, aby vyhovovaly vaší tiskárně. Zmenšíte-li je, tisk bude světlejší. Zejména pokud ovladač používá k rastrování
barev Floyd-Steinbergův algoritmus, bude rozumné použít menší hodnoty (0,2–0,15).
%!
%transformační funkce pro CMYK
{0.3 exp} {0.3 exp} {0.3 exp} {0.3 exp} setcolortransfer
Nastavením těchto hodnot můžete „opravit“ tiskárnu, které netiskne určitá barva. Pokud se bude-te o něco takového snažit,
doporučuji jako test soubor colorcir.ps , dodávaný s Ghostscriptem (v adresáři examples ).
U řady novějších barevných ovladačů existují řádkové parametry nebo konfigurační soubory, které umožňují pomocí gamma
korekce a dalších nastavení uzpůsobit tiskárnu různým typům papíru. Než začnete nevyhovující tisky opravovat přímo zásahy do
PostScriptu, zkuste nejprve tato nastavení.
Barevný tisk v Ghostscriptu
Barevný dithering je v Ghostscriptu implicitně optimalizován pro zařízení s nízkým rozlišením. Dit-hering je poměrně bídný díky
snaze vytvářet výstup 60 PPI (ne DPI, ale PPI – počet „zdánlivých“ barevných bodů na palec po provedení ditheringu). Na
moderních barevných tiskárnách je výstup nehezký, zejména inkoustové tiskárny s kvalitním papírem jsou schopny tisknout s
mnohem lep-ším PPI.
Můžete to upravit parametrem -dDITHERPPI=x, kde x je požadovaná hodnota. Nemusí to fun-govat pro všechny ovladače, řada
novějších ovladačů ( například ovladač stp pro Epson Stylus) používá vlastní dithering a tento parametr nebere na vědomí. Jiné
ovladače mohou používat buď standardní ghostscriptový dithering nebo svůj vlastní (například bjc600 pro tiskárny Canon Bubblejet).
Dithering v Ghostscriptu je poměrně hloupý. Jádro Ghostscriptu jednoduše nepodporuje řadu věcí potřebných pro kvalitní tisk na
moderních tiskárnách. Řada projektů, které by tuto situaci řešily (a svět otevřeného softwaru je schopen tato řešení poskytnout), je
brzděna licenční politikou Ghostscriptu a jeho uzavřeným vývojem. Na setkání Open Source Printing Summit 2000 (http://
www.linuxprinting.org/summit.html) tuto situaci řešili všichni, jichž se to týká, a dá se čekat, že v brzké době dojde ke zlepšení.
Sítě
Jednou z funkcí většiny spoolerů je, že podporují přes síť tisk na tiskárny fyzicky připojené k jiným počítačům nebo přímo do
sítě. Při vhodné kombinaci filtračních skriptů a vybraných nástrojů můžete transparentně tisknout na tiskárny ve všech typech sítí.
Tisk na unixové lpd stroje
Aby mohly vzdálené počítače tisknout na vaší tiskárně protokolem LPD, musíte je uvést v soubo-ru /etc/hosts.equiv nebo /etc/
hosts.lpd. (Pozor na to, že soubor host.equiv způsobuje celou řadu dalších efektů; než sem nějaký počítač uvedete, měli byste dobře
vědět, co děláte.) Pomocí příznaku rs můžete povolit tisk jenom určitým uživatelům vzdáleného systému – přečtě-te si manuálové
stránky lpd.
Když používáte lpd
Abyste mohli tisknout na vzdáleném počítači, záznam v /etc/printcap by měl vypadat nějak takto:
# REMOTE djet500
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:rm=machine.out.there.com:\
:rp=printername:\
:sh:
V tomto uspořádání stále existuje i lokální fronta spravovaná démonem lpd. Pokud by vzdálený stroj nebyl dostupný, budou úlohy
čekat v lokální frontě, dokud je nebude možné odeslat.
Když používáte rlpr
Pomocí rlpr můžete odeslat tiskovou úlohu přímo do vzdálené fronty, aniž byste museli konfigu-rovat lpd. Je to užitečné zejména
v situacích, kdy pouze čas od času tisknete na různé tiskárny. Z dokumentace k rlpr uvádíme:
„Rlpr používá TCP/IP k odeslání tiskových úloh na lpd servery kdekoliv v síti.“ Na rozdíl od lpr rplr nevyžaduje, aby lokální
počítač „znal“ vzdálenou tiskárnu, na níž chcete tisk-nout (například prostřednictvím /etc/printcap), a je tedy považován za
pružnější řešení s men-šími nároky na administraci. Je možné použít rlpr kdekoliv, kde se používá klasické lpr,a je s ním zpětně
kompatibilní. Hlavní výhodou rlpr je možnost vzdáleně tisknout odkudkoliv kdeko-liv bez ohledu na to, jak je nakonfigurován
systém, z nějž tisknete. Může fungovat jako filtr stej-ně jako tradiční lpr, takže vzdálení klienti jako netscape, xemacs atd. mohou
velmi jednoduše tisk-nout na lokální tiskárně.
Balíček s rlpr je k dispozici na Metalabu, ftp://metalab.unc.edu/pub/Linux/system/printing/.
Tisk na Windows nebo Sambu
V praktickém návodu „Sdílení tisku mezi systémy Windows a Debian“ z této knihy najdete více informací než zde.
Když používáte lpd
Je možné směrovat tiskovou frontu přes program smbclient (součást balíku samba, http://www.linuxprinting.org/man/
smbclient.1.html) na tiskovou službu SMB na protokolu TPC/IP. Samba obsahuje skript smbprint, který to zajišťuje. Stručně
řečeno, v adresáři fronty pří-slušné tiskárny vytvoříte konfigurační soubor a jako filtr if nastavíte skript smbprint.
Záznam v /etc/printcap bude vypadat takto: lp|remote-smbprinter:\
:sh:\
:lp=/dev/null:\
:sd=/var/spool/lpd/lp:\
:if=/usr/local/sbin/smbprint:
Přečtěte si dokumentaci uvedenou ve skriptu smbprint, kde naleznete více informací o potřebných nastaveních.Kromě toho můžete použít smbclient a směrovat soubor přímo na tiskovou službu SMB, bez pou-žití lpd. Viz
manuálové stránky.
Tisk na NetWare
Balík ncpfs obsahuje program nprint, který poskytuje stejné funkce jako smbprint, ovšem v sítích NetWare. Balík ncpfs můžete
získat na Metalabu, ftp://metalab.unc.edu/pub/Linux/sys-tem/filesystems/ncpfs/. Z dokumentace pro verzi 0.16 uvádíme:
S pomocí ncpfw můžete v Linuxu připojovat svazku na serveru NetWare. Můžete také tisknout do tiskových front NetWare nebo
fronty NetWare obsluhovat spoolerem v Unixu. Potřebujete jádro
1.2.x nebo 1.3.54 nebo vyšší; ncpfs nefunguje s jádry 1.3.x nižšími než 1.3.54.
Když používáte lpd
Abyste mohli nprint použít s lpd, napište si malý skript, který bude tisknout stdin na tiskárnu NetWare, a ten nainstalujte jako filtr
if pro frontu lpd. Dostanete něco jako: sub2 |remote-NWprinter:\
:sh:\
:lp=/dev/null:\
:sd=/var/spool/lpd/sub2:\
:if=/var/spool/lpd/nprint-script:
Skript nprint by mohl vypadat přibližně takto:#! /bin/sh# Nejprve zkuste účet guest bez hesla!/usr/local/bin/nprint -S net -U name -P passwd q printq-name -
Tisk na tiskárny EtherTalk (Apple)
Balík netatalk obsahuje něco podobného jako nprint a smbclient. Postup tisku na a ze sítí Apple už byl popsán daleko lépe, než
bych to dokázal já. Podívejte se na dokument Linux Netatalk HOWTO (http://thehamptons.com/anders/netatalk/).
Tisk na síovou tiskárnu
Řada tiskáren obsahuje přímo ethernetové rozhraní a je možné na ně přímo tisknout, typicky pro-tokolem LPD. Držte se instrukcí,
které jsou přiloženy u tiskárny nebo jejího síťového adaptéru, nic-méně obecně platí, že na těchto tiskárnách „běží“ lpd a nabízí
jednu nebo více front, na které můžete tisknout. Tiskárny HP mohou fungovat například s takovouto konfigurací:
lj-5|remote-hplj:\ :sh:\
:sd=/var/spool/lpd/lj-5:\
:rm=printer.name.com:\
:rp=raw:
Tiskárny HP LaserJet s rozhraním JetDirect obecně nabízejí dvě tiskové fronty – raw, která umí tisknout PCL (a případně
PostScript ), a text, jenž zpracovává čisté ASCII (a umí se automaticky vyrovnat se „schodišťovým“ efektem). Pokud máte
tříportový JetDirect Plus3, fronty se jmenují raw1, text2 a tak dále.
Společnost ISS identifikovala nebezpečí DoS útoku, kterým je možno zablokovat rozhraní tiskáren HP JetDirect. Většina z nich
byla popsána na podzim 98. Tento typ problémů je u podobných zaří-zení poměrně běžný, obecně by neměla být přístupná z
běžného Internetu.
Ve velkých prostředích, zejména tam, kde některé tiskárny nepodporují přímo PostScript, je rozumné zřídit vyhrazený tiskový
server, na nějž budou všechny počítače tisknout a na kterém poběží všechny ghostscriptové úlohy. Díky tomu bude možné s
frontami manipulovat příkazy topq a lprm.
Navíc bude takovýto server udržovat fronty jednotlivých tiskáren, takže uživatelé „vytisknou“ úlohy okamžitě a budou moci
pokračovat v práci, aniž by museli čekat, než skončí tisk jiných úloh jiných uživatelů. Doporučuje se to také, pokud máte starší
JetDirect, snižuje se zaseknutí tiskárny.
Provedete to tak, že na tiskovém serveru vytvoříte frontu, která bude tisknout přímo na HP LJ se
síťovým rozhraním, a všechny klienty v síti nastavíte tak, aby tiskli na LPD frontu na tomto serveru. Některé síťové tiskárny HP
zjevně ignorují nastavení úvodní stránky, které posílá klient. Tisk inter-ně generované úvodní stránky můžete vypnout tak, že se
na tiskárnu připojíte telnetem, dvakrát zmáčknete Enter, napíšete „banner: 0“ a „quit“. Tímto způsobem můžete měnit i jiná
nastavení, jejich seznam získáte příkazem „?“.
Všechna nastavení je možné měnit programem webJetAdmin od HP (http://www.hp.com/ go/ webjetadmin). Tento balík běží jako
démon a na zvoleném portu reaguje na HTTP požadavky. Nabízí formuláře a applety, kterými je možné řídit HP tiskárny v síti.
Teoreticky může ovládat i uni-xové tiskové fronty, provádí to ale přes službu rexec, která není nijak zabezpečena. Použití této
funkce vám rozhodně nedoporučuji.
Tisk na zařízení AppSocket
Některé tiskárny (a některé „tiskové servery“) podporují pouze ubohý pseudoprotokol, komuni-kující přímými TCP spojeními,
někdy se označuje jako protokol AppSocket. Do této kategorie spa-dají zejména starší modely karet JetDirect (a některé
JetDirectEx). V zásadě se tiskne tak, že musí-te navázat TCP spojení s tiskárnou na určitém portu (typicky 9100 nebo 9100, 9101
a 9102 u tří-portových karet) a po tomto spojení odeslat tiskovou úlohu. LPRng obsahuje podporu odeslání úlohy na libovolný
port, u BSD LPD to není tak jednoduché. Asi nejlepším řešením je použít nástroj netcat.
Pokud by to nefungovalo, je možné tisk implementovat mimo jiné i pomocí Perlu programem, který uvádíme dále. Lepší výkon
dosáhnete s programem netcat (nc), který dělá téměř to samé obecnějším postupem. Ve většině distribucí by měl být tento
program k dispozici.
Spuštění if pro vzdálené tiskárny ve starém LPD
Zvláštností starších verzí lpd je to, že pro vzdálené tiskárny nespouští rozhraní if. (Verze od 0.43 nebo tak nějak jsou upraveny na
základě změn ve FreeBSD a if už se spouští vždy.) Pokud nara-zíte na to, že potřebujete pro vzdálenou tiskárnu spustit if a vaše
verze lpr to neumí, můžete to
vyřešit tak, že vytvoříte dvě fronty a budete úlohy předávat mezi nimi. Podívejme se na následu-jící konfiguraci v printcap:lj-5:\
:lp=/dev/null:sh:\
:sd=/var/spool/lpd/lj-5:\
:if=/usr/lib/lpd/filter-lj-5: lj-5-remote:sh:rm=printer.name.com:\
:rp=raw:sd=/var/spool/lpd/lj-5-raw:
ve světle skriptu filter-lj-5:
#!/bin/sh gs <options> -q -dSAFER -sOutputFile=- - | \ lpr -Plj-5-remote -U$5
Volba -U u lpr funguje pouze tehdy, je-li lpr spuštěn jako démon, a slouží k nastavení správné-ho jména vlastníka úlohy v
sekundární frontě. Možná byste měli použít nějakou spolehlivější metodu získání uživatelského jména, protože ne ve všech
případech je předáváno jako pátý para-metr. Viz manuálové stránky printcap (http://www.linuxprinting.org/man/printcap.5.html).
Tisk z Windows
Tisk z klientů Windows (a případně OS/2) je podporován přímo protokolem SMB z balíku Samba,
který podporuje rovněž sdílení souborových systémů Unixu ve Windows. Samba obsahuje vyčerpávající dokumentaci a rovněž
dokument Samba FAQ, který pokrývá nej-častější způsoby použití. Můžete buď nakonfigurovat filtr na Unixu a tisknout na něj
PostScript nebo můžete na všech stanicích Windows nainstalovat ovladače příslušné tiskárny a tisknout přímo bez filtru. Použití
nativních ovladačů Windows může v některých případech produkovat lepší výsledky, je to ale administrativně náročnější, zejména
pokud je stanic mnoho. Zkuste tedy nejprve PostScript. Nové verze Samby podporují mechanismus automatického stažení
ovladače, poskytovaný servery Windows NT.
Nějaké informace najdete také v již zmíněném návodu „Sdílení tisku mezi systémy Windows a Debian“.
Tisk z Apple
Netatalk podporuje tisk klientů Apple protokolem EtherTalk. Další informace najdete v dokumentu
Netatalk HOWTO, http://thehamptons.com/anders/netatalk/.Modernější verze Macu dokážou tisknout i přes TCP/IP protokolem
LPD. UV nabízí velmi pěknoustránku http://www.itc.virginia.edu/desktop/mac/ip_printing/ip_printing.html, kde se dozvíte podrobnosti o nastavení.
Tisk z NetWare
Balík ncpfs obsahuje démona pserver, který umí poskytovat službu tiskového serveru frontám NetWare. Pokud vím, tento systém
vyžaduje NetWare založený na Bindery, tedy NetWare 2.x, 3.x nebo 4.x s aktivací přístupu k bindery.
Další informace o ncpfs a také o programu pserver najdete na FTP stránkách ncpfs (ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/).
Administrace síových tiskáren
Většina síťových tiskáren podporuje nějakou metodu vzdálené správy. Často jde o snadno použi-telné webové rozhraní. Ještě
užitečnější je podpora správy přes SNMP. Typicky tak můžete zjistit zajímavé informace o stavu tiskárny, jako jsou množství
toneru a papíru, o zatížení tiskárny a můžete také měnit některá nastavení. Ovládání tiskáren přes SNMP a řada dalších věcí
týkajících se tisku je standardizována skupinou Printer Working Group pod IEEE, http://www.pwg.org/.
npadmin
Npadmin (http://npadmin.sourceforge.net/) je řádkový program poskytující rozhraní k běžným SNMP funkcím síťových tiskáren.
Implementuje standard Printer MIB (http://www.ietf.org/rfc/ rfc1759.txt) a některá proprietární řešení výrobců, která se týkají
zejména starších zařízení. Pod-porovány jsou jak funkce printer-discovery, tak i různé stavové dotazy na tiskárny.
Program npadmin má vynikající manuálovou stránku (http://npadmin.sourceforge.net/man/) a existuje i v balíčcích RPM a dpkg
pro distribuce, které tento typ balíčků používají.
Další SNMP nástroje
Kromě npadmin existuje i několik dalších užitečných SNMP nástrojů: snmptraplogd může logo-vat události SNMP trapů. Je to
užitečné pro sledování zaseknutí papíru, vyčerpání papíru a podob-ně, jednoduché je také přesměrování konkrétních událostí na
e-mail a podobně.
I když npadmin nabízí jednoduchou podporu SNMP rozhraní většiny síťových tiskáren, některé tiskárny používají i různá
proprietární rozšíření, která npadmin nezná. V takovém případě může-te použít nástroje CMU SNMP, které podporují libovolné
operace SNMP GET a SET. S trochou práce tak budete moci využít všechny funkce, které SNMP vaší tiskárny nabízí. Budete
potřebovat specifikaci výrobce, abyste zjistili, co všechny proměnné znamenají – výrobci často předpokláda-jí, že uživatelé
používají výhradně jimi dodávané proprietární nástroje.
Knihovna libprinterconf (http://sourceforge.net/project/?group_id=3648) VA Linuxu nabízí funkci detekce síťových tiskáren.
Identifikace tiskáren probíhá podle vestavěné databáze signatur tiská-ren. Tato databáze není momentálně příliš rozsáhlá, pokrývá
ale většinu běžných modelů.
Jak vytvořit něco, co stojí za vytisknutí
Teď už se dostáváme k poslednímu kroku v softwarovém řetězci. V zásadě Linux umí spustit řadu typů binárních souborů s
různým stupněm úspěšnosti: Linux/x86, Linux/Alpha, Linux/Sparc, Linux/foo, iBCS, Win16/Win32s (pomocí dosemu a Wine),
Mac/68k (pomocí Executor) a Java. My budeme hovořit pouze o nativním Linuxu a běžném unixovém softwaru.
Značkovací jazyky
Většina značkovacích (mark-up) jazyků se hodí zejména pro větší nebo opakující se projekty, kdy počítač upravuje pomocí
značek vzhled textu tak, aby vypadal jednotně.
nroff
Jde o jeden z prvních značkovacích jazyků na původní verzi Unixu. Nejznámějším příkladem věcí formátovaných pomocí
maker *roff jsou manuálové stránky. Řada lidí na ně nedá dopus-tit, nicméně alespoň podle mě má nroff příliš záhadnou
syntaxi (viz obrázek 11.14) a v sou-časné době nepředstavuje nejlepší volbu. Je ale dobré vědět, že manuálovou stránku
můžete vysázet přímo v PostScriptu pomocí programu groff. Většina příkazů man to umí sama pří-kazem man -t foo | lpr.
Obrázek 11.14 Příklad vstupu pro roff
TeX
TeX a balík maker LaTeX představují jeden z nejrozšířenějších značkovacích jazyků na unixo-vých systémech, i když TeX
nepochází původně z Unixu a je k dispozici na řadě různých systé-mů. V LaTeXu se velmi často vytvářejí technické
dokumenty, protože je velmi zjednodušena problematika sazby a LaTeX je navíc jeden z mála systémů, který podporuje sazbu
matema-tických vzorců jak kompletně, tak i dobře. Výstupem TeXu je formát dvi, který je možné pro-gramy dvips a dvilj
konvertovat na PostScript nebo PCL. Pokud budete chtít nainstalovat TeX nebo LaTeX, nainstalujte celou skupinu balíků
teTeX, která obsahuje všechno. Nové verze TeXu obsahují i pdfTeX a pdfLaTeX, které vytvářejí přímo soubory PDF. Více o
TeXu najdete např. na stránkách http://www.cstug.cz/.
K dispozici jsou i příkazy pro vkládání odkazů a navigačních funkcí do PDF dokumentů.
SGML
Pro unixové systémy existuje přinejmenším jeden volně šířený parser SGML, díky němuž vznikl dokumentační systém
Linuxdoc, založený na SGML. Může podporovat i jiné DTD, zejména DocBook. Tento dokument byl napsán v DocBookDTD SGML, příklad vidíte na následujícím obrázku.
Obrázek 11.15 Příklad vstupu pro LaTeX
Obrázek 11.16 Příklad DocBook SGML
Textové WYSIWYG procesory
Programů pro WYSIWYG práci s textem je dostatek. Existují úplné kancelářské balíky, jeden z nich je pro osobní potřebu zdarma
(StarOffice).
StarOffice/OpenOffice.org
Sun Microsystems distribuoval původní StarOffice pro Linux zdarma, ale následně jej přejme-noval na OpenOffice, otevřel
vývoj a uvolnil zdrojový kód pod open-source licencí. Dnes si můžete stáhnout kompletní kancelářský balík např. z adresy
http://www.openoffice.cz. Sun tento kancelářský balík pod názvem StarOffice stále prodává. V podstatě jde o upravený OpenOffice.org s přidanými funkcemi, podporou atd. StarOffice/OpenOffice.org je kompletní kan-celářský balík obsahující
všechny funkce, které byste očekávali, včetně importu a exportu dokumentů ve formátu Microsoft Office (tedy Word a
podobně). Existuje mini-HOWTO doku-ment popisující získání a instalaci tohoto balíku. Tiskovým výstupem je PostScript,
takže by měl fungovat s jakoukoliv tiskárnou, která v Linuxu funguje. Na OpenOffice.org je postaven i český produkt
602Office.
WordPerfect
Corel distribuuje základní verzi WordPerfectu 8 pro Linux zdarma a prodává různé balíky Word Perfect Office 2000
(obsahující WordPerfect, Corel Draw a Quatro Pro verze 9). Stránka Linux WordPerfect Fonts and Printers (http://
www.rodsbooks) obsahuje informace o konfigu-raci WordPerfectu pro použití s Ghostscriptem nebo s originálními ovladači
WordPerfectu (které jsou stejné jako ovladače pro DOS pro případ, že by ovladač vaší tiskárny v distribuci nebyl).
Applix
Applix je multiplatformní (Unixy, Windows a další) kancelářský balík prodávaný společností Applix. Red Hat a SuSE jej
prodávaly rovněž v době, kdy neexistovala jiná varianta, nyní jej prodává už zase jen Applix. Jedná se o jediný aplikační balík
v nativním unixovém stylu, prav-děpodobně se vám bude líbit jeho unixový přístup k věci.
AbiWord
AbiWord, http://www.abisource.com/, je jeden z několika GPL WYSIWYG editorů. Jde o velmi pěkný editor založený na
formátu XML. Podporuje také import souborů z Wordu. Vývoj Abi-Wordu stále pokračuje, už dnes je ale velmi dobře
použitelný.
Obrázek 11.17 AbiWord
LyX
LyX je rozhraní k LaTeXu, které vypadá velmi slibně. Další informace najdete na adrese http://www.lyx.org/. Existuje i KDE
verze LyXu, pojmenovaná Klyx.
Obrázek 11.18 LyX
Maxwell
Maxwell je jednoduchý textový editor založený na formátu MS RTF, který začal jako komerční produkt a nyní se distribuuje
pod GPL.
KOffice
Moderní kancelářský balík integrovaný s prostředím KDE, více na http://www.koffice.org. Pod-poruje formát Open Document
– nativní formát balíku OpenOffice.org.
Uvítám informace o dalších produktech.
Tisk fotografií
Abyste z normálních tiskáren získali slušné fotografie, je nutné uhlídat celou řadu detailů. Pokud ještě nemáte fototiskárnu,
podívejte se na tipy v kapitole „Jak kupovat tiskárnu“.
Ghostscript a fotografie
Ghostscript má potíže s tiskem barevných fotografií u většiny ovladačů. Problémy spočívají v několika věcech:
■ Řada ovladačů má špatně vyladěnou podporu barev. Barvy často neodpovídají podobě na obrazovce a výtisku ve
Windows. Na druhé straně, všechny ovladače i samotný Ghost script mají nastavitelnou barevnou podporu. Jednou z
možností je nastavení gama korekce (viz kapitola „Gamma, velikost bodu atd.“), další jsou popsány v dokumentačním
souboru Use.htm Ghostscriptu.
Vím pouze o jediném ovladači pro Ghostscript, který podporuje šesti a sedmibarevný tisk, momentálně je v beta-verzi
a podporuje modely Epson Stylus Photo. Tvrdí se, že barevný výstup je lepší než u originálního ovladače pro Windows. Jádro
Ghostscriptu nepodporu-je jiné barevné modely než CMYK a RGB, je nutné tuto podporu dopracovat.
Ghostscript často generuje nehezký dithering a vytváří různé chyby, například proužky. Dithering lze obvykle opravit,
viz kapitola „Barevný tisk v Ghostscripu“ a dokumentace k příslušnému ovladači.
Obrázek 11.19 Kancelářský balík KOffice
Některé z těchto problémů lze upravit doladěním Ghostscriptu. Podrobnosti najdete v kapitole „Ghostscript“. Nastavování
parametrů Ghostscriptu se výrazně zjednoduší, pokud je deklarujete jako parametry tiskového systému.
Momentálně je tedy lepší fotografie tisknout jiným systémem než Ghostscriptem, takové progra-my samozřejmě existují.
Nejvýznamnějším je tiskový doplněk pro GIMP, který podporuje tisk na Epson Stylus a na postscriptových tiskárnách (s
podporou PPD). Část podporující Epson Stylus existuje i pro Ghostscript jako ovladač stp. Další variantou jsou externí programy
pnm-to-něco, podporující tisk na tiskárnách, jako je Lexmark – tyto programy provádějí tisk mapování pixel-napixel. Nejlepší
řešení je samozřejmě koupě postscriptové tiskárny, ty lze obvykle plně ovládat dostupnými programy a při tisku využít všech
možností tiskárny, případně pořízení tiskárny s kva-litním nativním ovladačem pro Linux.
Papír
U barevných inkoustových tiskáren závisí kvalita tisku významně na použitém papíru. Drahé lesk-lé papíry umožňují tisknout v
téměř fotografické kvalitě, výstup na klasický kancelářský papír dává obvykle ušmudlané barvy a rozplizlé detaily. Speciální
matné papíry do inkoustových tiskáren dávají výsledek někde uprostřed a hodí se zejména pro tisk finálních podob dokumentů.
Tvrdé lesklé fotografické papíry dávají stejný výsledek jako „normální“ lesklé fotopapíry, výsledek však více připomíná
klasickou fotografii.
Nastavení tiskárny
Při tisku fotografií byste na většině barevných inkoustových tiskáren měli použít nejkvalitnější (a nejpomalejší) režim tisku, jinak
budou větší plochy pruhované nebo barevně nejasné. V Ghost-scriptu obvykle stačí zvolit nejvyšší rozlišení. U postscriptových
tiskáren budete možná muset před samotnou úlohou tiskárnu nastavit nějakým příkazem podle PPD souboru. PPD podpora v
GIMP neobsahuje nastavení kvality tisku (rozuměj specifické nastavení konkrétní tiskárny), nicméně pro vlastní potřebu jsem si
tuto podporu doplnil – pokud chcete, kontaktujte mne. Pokud používáte PDQ nebo CUPS, budete moci snadno nastavovat
všechny parametry tiskárny.
U postscriptových tiskáren nabízí tato nastavení i libppd VA Linuxu a GPR.
Trvanlivost tisku
Barevné výtisky z inkoustových tiskáren obvykle za pár let vyblednou, zejména pokud jsou vysta-veny slunečnímu světlu – to je
vlastnost inkoustu. Tiskárny s výměnnými inkoustovými náplněmi, jako Epson nebo Canon, mohou pracovat i s takzvaným
archivním inkoustem, který je na bled-nutí méně náchylný. Novější tiskárny obvykle používají pigmentové inkousty, které
neblednou tak rychle jako starší barvené inkousty. Nicméně pro delší skladování se inkoustové výtisky obecně nehodí – vypalte si
obrázky na CD a uskladněte je takto.
Komerční programy
Existuje program xwtools, http://home.t-online.de/home/jj.sarton/startE.htm, který umožňuje tisk fotografií se všemi parádičkami
na vybraných tiskárnách Epson, HP a Canon. Bohužel byl napsán pod NDA, takže nejsou k dispozici jeho zdrojové kódy.
Balík ESP Print Pro společnosti Easy Software podporuje některé jinak nepodporované tiskárny.
Tyto ovladače nejsou ideální pro tisk fotografií, ale aspoň fungují.Tisk fotografií lze vylepšit také použitím jiných ovladačů, za
všechny jmenujme například komerč-ní Turboprint, http://www.turboprint.de.
Další informace
Tiskárny výlučně pro Windows
Jak už bylo řečeno dříve, některé tiskárny jsou ze své podstaty nepodporované, protože neznají žádný „normální“ komunikační
jazyk, namísto toho využívají procesoru počítače k vykreslení tis-kového rastru, který se pak fixní rychlostí posílá na tiskárny. V
některých případech tyto tiskárny umějí i něco normálního jako PCL, ale často ani to ne. U některých (opravdu „low-end“
modelů ) tyto tiskárny dokonce ani nepoužívají běžnou paralelní komunikaci, ale spoléhají na to, že ovla-dač emuluje to, co má
řešit hardware (například řízení komunikace).
Každopádně, pokud na nějakou takovou hrůzu narazíte, existuje několik možných řešení.
Redirektor Ghostscriptu
V současné době existuje tiskový ovladač pro Ghostscript (jmenuje se mswinpr2), který tiskne pomocí GDI volání Windows.
Existuje také nástroj pro přesměrování portu, redmon, který umož-ňuje úlohu před konečným tiskem prohnat přes Ghostscript
(podobně jako to dělá filtr if v LPD v Unixu). Díky tomu mohou Windows tisknout PostScript s použitím originálního ovladače.
Pokud na tiskárně nemůžete tisknout přímo, můžete ji exportovat jako postscriptovou tiskárnu pomocí programů redmon,
Ghostscript a mswinpr2 ve Windows a tisknout pomocí ovladače od výrobce.
HP Winprinters
Některé tiskárny HP používají „Printing Performance Architecture“ (což je marketingový výraz pro „ta tiskárna je moc levná, než
aby uměla PCL“). Tato metoda je podporována překladačem pbm2ppa Tima Normana. V zásadě použijete Ghostscript k
vykreslení PostScriptu do rastrového obrázku ve formátu pbm a pak použijete pbm2ppa ke konverzi tohoto rastru do interní ho
rastru tiskárny, který je možné vytisknout. V současné době už by měl být tento program k dispozici i jako ovladač pro
Ghostscript.
Tento program můžete získat na adrese http://www.rpi.edu/~normat/technical/ppa/, pbm2ppa podporuje některé modely HP 720,
820 a 1000. Podrobnosti se dozvíte v dokumentaci k tomuto balíku. Nové tiskárny HP jsou již dobře podporovány projektem
HPIJS, viz http:// hplip.sourceforge.net/supported_devices/index.html.
Lexmark Winprinters
Většina levných inkoustových tiskáren Lexmark používá proprietární jazyk, a jsou to tedy klasic-ké Winprinters. Nicméně
Henryk Paluch napsal program, který umí tisknout na tiskárně Lexmark 7000. Možná bude schopen rozšířit podporu i o barevný
tisk a další tiskárny Lexmark. Další infor-mace najdete na adrese http://bimbo.fjfi.cvut.cz/~paluch/l7kdriver/.
Podobně existují i ovladače pro modely 5700, 1000, 1100, 2070, 3200 a další. Podívejte se do data-báze podporovaných tiskáren,
kde najdete i odkazy na příslušné ovladače.
Jak tisknout na fax
Na fax můžete tisknout s pomocí nebo bez pomoci modemu.
Použití faxmodemu
Existuje řada faxovacích programů, které umožňují faxovat a přijímat dokumenty. Jedním z nej-lepších je HylaFAX Sama
Lefflera, http://www.hylafax.org/. Podporuje všechno možné, počínaje více modemy až po broadcasting.
SuSE obsahuje klienta HylaFAX napsaného v Javě, který údajně pracuje na jakékoliv platformě s podporou Javy (včetně
Windows a Linuxu ). Kromě toho pro většinu platforem existují i faxoví klienti nepoužívající Javu, v Linuxu bude téměř jisté
nastavit faxování podle vašich potřeb.
Další možností, vhodnější pro malé instalace, je efax, http://casas.ee.ubc.ca/efax/, program, který odesílá a přijímá faxy. Program
mgetty umí spolupracovat s efaxem a přijímat faxy (a také hlaso-vou poštu a interaktivní přihlášení).
Služba Remote Printing Service
Existuje experimentální služba, kam můžete poslat e-mail obsahující to, co chcete někomu poslat na fax. Podporován je i
PostScript, takže i přesto, že služba není dostupná všude, může být veli-ce užitečná. Další informace o této službě najdete na
adrese http://www.tpc.int/.
Komerční faxové služby
Řada společností nabízí faxové služby přes Internet. Například EFax, http://www.efax.com/, nabí-zí zdarma příjem faxů přes email a odesílání faxů za poplatek. Podobné služby nabízejí i další společnosti.
Náhled před tiskem
Téměř vše, co jde vytisknout, si můžete také prohlédnout na obrazovce.
PostScript
Ghostscript obsahuje ovladač pro X Window, který se nejlépe používá s prohlížečem PostScriptu gv (http://wwwthep.physik.unimainz.de/~plass/gv/). Nové verze tohoto programu umí zobrazit i soubory PDF. Program gv je náhradou staršího prohlížeče
Ghostview, nové rozhraní je mnohem pěknější a chytřejší než původní.
Obrázek 11.20 Gv
Tex dvi
Soubory DeVice Independent TeXu si můžete v X Window prohlížet pomocí xdvi, http://www.linuxprinting.org/man/xdvi.1.html.
Moderní verze xdvi volají pro vykreslení specialit PostScriptu Ghostscript.
Existuje také ovladač pro VT100, jmenuje se dgvt. Prohlížeč tmview používá knihovnu svgalib, pokud nemáte nic lepšího k
dispozici.
Adobe Reader
Adobe Reader existuje i pro Linux, můžete si jej stáhnout na http://www.adobe.com/.
Kromě toho můžete použít xpdf, což je volně šiřitelný software a bývá součástí distribucí. I gv podporuje prohlížení PDF souborů
pomocí gs pod X Window, viz například předchozí obrázek.
Sériové tiskárny a LPD
Použití sériových tiskáren s lpd je trochu složité.
Nastavení v printcap
LPD nabízí pět parametrů, kterými můžete v /etc/printcap nastavit všechny vlastnosti sériové-ho portu a připojení tiskárny. Přečtěte
si manuálovou stránku programu printcap(http://www.linuxprinting.org/man/printcap.5.html) a popis parametrů br# , fc# , xc# , fs# a
xs# .Poslední čtyři představují bitové mapy sloužící k nastavení portu, parametr br# nastavuje přeno-sovou rychlost, například
br#9600 .
Velmi jednoduchý je převod nastavení stty (http://www.linuxprinting.org/man/stty.1.html) na příznaky pro printcap. Podívejte se na manuálovou stránku stty.Pomocí stty nastavte port tiskárny tak, abyste byli schopni příkazem
cat na tiskárnu poslata vytisknout soubor. Takto vypadá příkaz stty -a pro můj port tiskárny:
dina:/usr/users/andy/work/lpd/lpd# stty -a < /dev/ttyS2 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U;
eof = ^D; eol = <undef>; eol2 = <undef>; start = ^ Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; min = 1; time = 0; -parenb parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase tostop -echoprt -echoctl -echoke
Jediné rozdíly tohoto nastavení proti nastavení při startu systému jsou příznaky -clocal, -crtscts a ixon. Možná budete potřebovat
úplně jiná nastavení v závislosti na tom, jaké používá tiskárna řízení přenosu.
Ve skutečnosti musíte stty použít poněkud zvláštním způsobem. Protože stty pracuje s terminá-lem připojeným na standardní
vstup, manipulujete se sériovým portem pomocí znaku „<“ tak, jak to vidíte výše.
Jakmile máte stty nastaveno správně, takže příkaz cat file > /dev/ttyS2 (v mém případě) pošle soubor na tiskárnu, podívejte se do
souboru /usr/src/linux/include/asm-i386/termbits.h. Tento soubor obsahuje řadu příkazů #define a několik struktur. (Případně můžete
tento soubor poslat na tiskárnu (to vám funguje, že?) a použít jej jako referenci.) Najděte si část, která začíná:
/* c_cflag bit meaning */ #define CBAUD 0000017
V této části najdete význam bitů pro parametry fc# a fs#. Všimněte si, že názvy v tomto soubo-ru odpovídají názvům, které se
objevují ve výstupu příkazu stty. Neříkal jsem, že to bude jedno-duché?
Všimněte si, která nastavení jsou ve výstupu příkazu stty uvedena znakem „-“. Sečtěte hodnoty u všech těchto parametrů (hodnoty
jsou v osmičkové soustavě). Tím dostáváte bity, které musíte vynulovat, a tato hodnota slouží jako argument parametru fc# .
Nicméně hned vzápětí budeme
nastavovat potřebné bity, takže nejjednodušší je prostě nejprve vynulovat všechno, což můžete
provést volbou fc#0177777 (já to tak dělám).Teď sečtěte hodnoty u parametrů, u nichž není uveden na začátku výpisu příkazu stty
znak -.V mém případě jde o parametry CS8 (0000060), HUPCL (0002000) a CREAD (0000200). Dále neza-pomeňte na příznaky
nastavující přenosovou rychlost (u mne je to 0000015). Všechno sečtěte,v mém případě dostanete hodnotu 0002275. To je
argument pro parametr fs# (v mém případěstačí zadat fs#02275).
Stejný postup s nulováním a nastavováním bitů proveďte i s další částí souboru, c_lflag . V mémpřípadě se nenastavuje nic, takže
používám parametry xc#0157777 a xs#0.
Starší sériové tiskárny vynechávající znaky
Jon Luckey upozornil, že některé starší sériové tiskárny s levným sériovým rozhraním a malou vyrovnávací pamětí opravdu myslí
STOP, když to v řízení přenosu signalizují. Zjistil, že pokud pří-kazem setserial (http://www.linuxprinting.org/man/
setserial.8.html) vypnul frontu u sériového portu s čipem 16550, vyřešil se problém s vynecháváním znaků. (Stačí pouze označit
typ uart jako 8250.)
Co chybí?
Ještě stále chybí řada částí do úplného tiskového systému. Existují projekty, které se je snaží dopl-nit, ovšem většina z nich
doposud nic rozumného nevyřešila a snahy o standardizaci potřebných protokolů a API jsou stále v plenkách, ale situace se
postupně zlepšuje. Do snahy o standardiza-ci se dnes zapojují velcí linuxoví hráči i firmy vyrábějící tiskárny, viz http://
www.linux-foundation.org/en/OpenPrinting.
Propojení
Existuje obecný problém donutit všechny části, aby spolu navzájem komunikovaly, zejména mechanismem nezávislým na
použitém spooleru. Tento problém se nejzřetelněji projevuje u dojemné snahy aplikací řídit všechny „obvyklé“ tiskové funkce.
Autor aplikace prostě nemá možnost zjistit informace o tiskárně, úlohách a podobně, neexistuje standardizovaná metoda
vytvoření úlohy, žádný rozumný způsob, jak se dozvědět stav úlohy, dokonce ani žádný stan-dardní způsob generování tiskových
dat (i když většina moderních systémů nabízí nějaká speci-fická řešení).
Fonty
Obsluha fontů je hrozně nešikovná. Obrazovka, tiskárna, aplikace a datové soubory by měly mít v ideálním případě přístup ke
stejným fontům. To však, bohužel, není pravda. S příchodem xft2 a fontconfig – což začnou šířit nejnovější distribuce – by to
mělo být vyřešeno. Pokud vím, Red-hat 8.0 je první distribuce, která používá xft2. V současné době jej používají snad všechny
moder-ní distribuce a podpora práce s fonty se razantně zlepšila. Více o fontech najdete v návodu „Opti-mální použití písem v
systému Linux“.
Ovladače
Stav na poli volně šířených ovladačů je poměrně bídný. I když se za posledních pár let dost vylep
šily, ne všechny tiskárny jsou podporovány.
V této oblasti hrají hlavní roli prodejci tiskáren. S rostoucí oblibou Linuxu bude pro ně čím dál tím
těžší ignorovat tuto skupinu uživatelů. Většina výrobců dnes už nabízí nativní ovladače pro Linux,
nejlepší podporu mají pravděpodobně tiskárny HP díky projektu HPIJS.
Sdílení tisku mezi systémy
Windows a Debian
Úvod
Debian GNU/Linux (http://www.debian.org) patří k předním distribucím udržovanou dobrovolní-ky Linuxu. Bohužel může být
nastavení tiskáren v Debianu obtížné. Snadné není ani vyhledání instrukcí pro sdílení tiskáren mezi systémy Windows a Linux za
použití nejnovějších nástrojů. Oba problémy se snaží rychle a jednoduše vyřešit tento dokument.
Dozvíte se, jak používat nástroje příkazového řádku při konfiguraci systému Debian pro tisk. Zjistíte, jak odesílat dokumenty ze
systému Linux na tiskárny systému Windows a jakým způsobem lze sdílet tiskárny Linux s počítači Windows. Ukážeme si též
řešení některých potíží. Tento návod je zaměřen ryze prakticky, komplexní informace o tiskovém systému v Linuxu najdete v
návodu „Tisk v Linuxu“ dále v této knize. Nutno také dodat, že v jiných distribucích bude postup pravděpodobně velmi podobný.
Začínáme
Součásti tisku v systému Linux
Používat budeme hlavně následující součásti:
CUPS
Common UNIX Printing System (http://www.cups.org) je systém pro zpracování tisku v Linuxu a sada podpůrných programů pro
používání a správu tiskáren.
Samba
Samba (http://www.samba.org) je software, který umožňuje počítačům s jiným systémem než Win-dows, aby na síti vypadaly
jako systém Windows díky implementaci protokolu pro sdílení tiská-ren a souborů.
Ovladače tiskárny
Web LinuxPrinting.org (http://www.linuxprinting.org) nabízí obrovský počet ovladačů tiskáren a nabízí databázi tiskáren
podporovaných v systému Linux. Pro každý model tiskárny, který chce-te používat v systému Linux, musíte stáhnout příslušný
ovladač. Ovladač tiskárny se skládá ze sou-boru PPD a filtrovacího programu, případně jde jen o soubor PPD pro tiskárny
PostScript.
Vyžadované balíčky
Součástí standardního archívu Debian jsou všechny požadované programy a knihovny. Tyto balíč-ky si můžete stáhnout a
nainstalovat za použití běžných nástrojů Debianu. Potřebovat budete následující balíčky:
cupsys
Tiskový server pro systém CUPS.
cupsys-bsd
Příkazy CUPS BSD.
cupsys-client
Klientské programy pro CUPS.
foomatic-bin
Podpůrné programy pro tisk z webu LinuxPrinting.org.
samba
Server Samba SMB/CIFS pro UNIX.
smbclient
Klient Samba SMB/CIFS pro UNIX.
gs-esp
ESP Ghostscript (http://www.cups.org/ghostscript.php). Není k dispozici jako balíček pro Debian verze 3.0 (známý také jako
Woody), použijte místo něj balíček gs.
a2ps
Nástroje GNU A2PS (http://www.gnu.org/software/a2ps/).Tyto balíčky nainstalujete pomocí následujících příkazů. Pro spuštění
těchto příkazů se musíte při-hlásit jako root nebo použít sudo:
apt-get update apt-get install cupsys cupsys-bsd cupsys-client foomatic-bin samba smbclient gs-esp a2ps
Některé tiskárny mohou vyžadovat další balíčky. Například pro správné fungování mnoha tiská-ren HP InkJet, DeskJet a LaserJet
je nutné nainstalovat balíček hpijs. Soubory PPD pro tyto tiskár-ny jsou označeny řetězcem „hpijs“ v názvu souboru.
Nastavení lokální tiskárny
Pro konfiguraci tiskáren se používá příkaz lpadmin. V následujícím příkladu nastavíte laserovou tiskárnu prostřednictvím CUPS.
Pro spuštění těchto příkazů se musíte přihlásit jako root nebo pou-žít sudo:
/usr/sbin/lpadmin -p Laser -v parallel:/dev/lp0 -P /root/laser.ppd /usr/bin/enable Laser /usr/sbin/accept Laser /usr/sbin/lpadmin -d Laser
Měli byste vědět, že bash má vestavěný příkaz s názvem enable (viz část „Bash pro začátečníky“),
takže uživatelé bashe musí pro povolení tiskáren použít úplnou cestu (/usr/bin/enable). První příkaz vytvoří novou tiskárnu s
názvem „Laser“, která je připojená k prvnímu paralelnímu portu a používá soubor PPD /root/laser.ppd. Poté je tiskárna „Laser“
povolena prostřednictvím příkazu enable a příkazem accept zajistíte příjem tiskových úloh. Poslední příkaz nastavuje „Laser “
jako výchozí tiskárnu.
Je-li tiskárna připojena k portu USB nebo neznáte správnou konfiguraci, zkuste použít příkaz
/usr/sbin/lpinfo -v pro zobrazení seznamu dostupných tiskáren. Spuštěním příkazu /usr/bin/lpoptions -l se ujistěte, zda je správně
nastavena velikost papírua další možnosti pro tiskárnu. Podrobnější informace o konfiguraci tiskárny jsou k dispoziciv
dokumentaci CUPS.
Základy tisku v systému Linux
Obrázek 12.1 Tisk na lokální tiskárnu
Dokumenty se zpracovávají buď příkazem lpr nebo lp, za kterým následuje název souboru. Fron-tu a stav tiskárny můžete
zobrazit pomocí příkazu lpstat -o či lpstat -p. Tiskovou úlohu můžete zrušit příkazem cancel nebo lprm, za kterým následuje
identifikátor úlohy.
Démon systému CUPS se nazývá cupsd. Převádí dokumenty na PostScript a poté je převádí na for-mát, který je nativní pro
tiskárnu (viz obrázek 12.1). Tiskárny, které nerozumí formátu PostScript, používají pro dokumenty rastrový formát. Rastrové
formáty mohou být mnohem větší než původ-ní PostScript a jejich odeslání na tiskárnu bude trvat déle.
Filtry jsou programy, které slouží k převádění dokumentů z jednoho formátu na jiný. Program CUPS se bude snažit nalézt
nejvhodnější filtr pro vámi odeslané dokumenty. Pokud není nainsta-lovaný žádný formát vhodný pro převod dokumentu, zobrazí
se chybová zpráva podobná této: „lpr: unable to print file: client-error-document-format-not-supported.“
Mnoho aplikací neobsahuje filtry pro vlastní formáty dokumentů. Dokumenty vytvořené v těchto aplikacích lze tisknout pouze v
rámci dané aplikace, nikoliv standardními tiskovými příkazy. Případně musí být dokument exportován do formátu PostScript či
jiného standardního tiskového formátu.
Tisk na počítače s Windows
Připojení k Windows
Obrázek 12.2 Síťový tisk na Windows tiskárnu
Nativním protokolem Windows pro sdílení souborů a tiskáren je SMB (CIFS). Při komunikaci s Windows počítači používáme
software Samba, který těmto protokolům rozumí, viz obrázek 12.2. Před nastavením systému CUPS na tisk do Windows se
pomocí programu smbclient přesvědčte, že se můžete připojit k počítači s Windows.
Následující příklad ukazuje, jak se spojit s počítačem, na kterém běží Windows:
/usr/bin/smbclient -L rice -U fred
added interface ip=10.6.7.234 bcast=10.6.7.255 nmask=255.255.255.0 Got a positive name query response from 10.6.7.8 ( 10.6.7.8 ) Password:
(not shown)
Sharename
PRINTER$
INKJET
STUFF
IPC$
Type
Disk
Comment
Printer
Disk
IPC
Remote Inter Process Communication
Příkaz smbclient se zeptal počítače s názvem „rice“, jaké jsou jeho sdílené prostředky, a použí-val přitom identitu uživatele
„fred“. Na výsledku vidíte, že počítač s Windows sdílí tiskárnu s názvem INKJET.
Není-li dostupná názvová služba Windows, nelze použít jméno a musíte počítač s Windows iden-tifikovat pomocí jeho IP adresy
a parametru -I například takto:
/usr/bin/smbclient -I 10.6.7.8 -L rice -N
Více informací o použití programu smbclient najdete v dokumentaci k Sambě.
Nastavení systému CUPS
Po nalezení sdílené tiskárny Windows můžete nastavit CUPS tak, aby ji začal používat. Nejdříve zkontrolujte, zda má vaše
instalace systému CUPS k dispozici tiskovou komponentu podporující protokol SMB pomocí následujícího příkazu:
ls -l /usr/lib/cups/backend/smb
Jestliže tento soubor neexistuje, vyrobte ho následujícím příkazem:
ln -s `which smbspool` /usr/lib/cups/backend/smb
Dále si ukážeme přidání tiskárny, kterou jsme našli v předchozí kapitole. Všechny následující kroky budete muset provést buď
jako uživatel root nebo pomocí příkazu sudo:
/usr/sbin/lpadmin -p RicePrinter -v smb://fred:mypass@rice/INKJET -P /root/inkjet.ppd /usr/bin/enable RicePrinter /usr/sbin/accept RicePrinter /
usr/sbin/lpadmin -d RicePrinter
Jak jsme již říkali, uživatelé příkazového interpretru bash musí pro povolení tiskáren použít úpl
nou cestu k programu enable (/usr/bin/enable) z důvodu kolize s interním příkazem bashe. Příkaz lpadmin nastaví v Linuxu
tiskárnu s názvem „RicePrinter“ sdílenou ze systému Windows. Použije přitom její název na vzdáleném počítači a dále netbios
(windows) název počítače „rice“ a uživatele „fred“ s heslem „mypass“. Následně tiskárnu povolí a nastaví ji jako výchozí tiskárnu
v sytému, viz příklad v kapitole „Nastavení lokální tiskárny“.
Tiskárna je připravena k použití a můžete si ji otestovat. Zkuste nyní vytisknout nějaký soubor přímo pomocí příkazu lp /cesta/k/
souboru, nikoliv z aplikace.
Sdílení tiskáren s počítači Windows
Základy sdílení
Obrázek 12.3 Sdílení tiskárny
Samba používá pro sdílení souborů a tiskáren s počítači Windows démony nmbd a smbd. První z nich – nmbd – funguje jako
názvová služba Windows, přičemž vysílá název vašeho počítače do systémů Windows v místní síti LAN. Démon smbd přijímá
soubory a požadavky na tisk z počíta-čů Windows (viz obrázek 12.3).
Ovladače tiskáren Windows budete muset stáhnout a nainstalovat pro každou tiskárnu sdílenou v systému Linux. Ovladače
tiskáren Windows naleznete na webu výrobce dané tiskárny.
Konfigurace Samby
Jestliže chcete povolit anonymní přístup ke své tiskárně, budete muset vytvořit uživatelský účet pro vzdálené tiskové úlohy:
/usr/sbin/adduser --system --disabled-password smbprint
Tento příkaz přidá do vašeho systému uživatele s názvem „smbprint“. Ujistěte se, že v domovském adresáři uživatele /home/
smbprint je dostatek prostoru pro soubory programu pro zpracování tisku. Zkontrolujte, že uživatel smbprint nemá ve vašem
systému oprávnění pro čtení či úpravu důležitých souborů a adresářů. Pokud jste nakonfigurovali CUPS pro zamezení tisku pro
určité uži-vatele, musíte povolit uživateli smbprint přístup k tiskárnám, které chcete sdílet.
Konfiguračním souborem Samba je /etc/samba/smb.conf. V následujícím příkladu nastavujeme konfigurační soubor pro použití
CUPS s uživatelem smbprint:
[global]
printcap name = cups
printing = cups
security = share
[printers] browseable = yes printable = yes public = yes create mode = 0700 guest only = yes use client driver = yes guest account = smbprint path
= /home/smbprint
Tato konfigurace umožní tisk komukoli, kdo se může prostřednictvím sítě připojit k vašemu počí-tači, a nedoporučuje se pro
počítače v nedůvěryhodných sítích, například s přímým připojením k Internetu. Potřebujete-li implementovat řízení přístupu,
nastavte security = user nebo secu-rity = domain a přečtěte si další informace v dokumentaci Samby.
Po přidání výše uvedených nastavení do konfiguračního souboru Samba musíte program Samba restartovat pomocí příkazu:
/etc/init.d/samba restart
Konfigurace tiskového systému CUPS
Ovladače tiskáren Windows formátují výstup pro tiskárnu před jeho odesláním do sítě. CUPS je nutné nakonfigurovat, aby bylo
možné přijmout naformátovaný výstup. Učiníte tak změnou násle-dujícího řádku z /etc/cups/mime.convs :
application/octet-stream application/vnd.cups-raw 0 -
Změňte také tento řádek z /etc/cups/mime.types :
application/octet-stream
Nyní musíte CUPS nastavit tak, aby byla povolena připojení
z jiných počítačů v síti. Přidejte násle-dující řádky do /etc/
cups/cupsd.conf: <Location /printers> AuthType None Order
Deny,Allow Deny From None Allow From All </Location>
Stejně jako v konfiguraci Samba povoluje tato konfigurace připojení kteréhokoli počítače k vašim tiskárnám a nedoporučuje se
pro počítače v nedůvěryhodných sítích. Informace o omezení pří-stupu k tiskárnám naleznete v souboru cupsd.conf a v
dokumentaci CUPS. Nakonec restartujte cups za použití následujícího příkazu:
/etc/init.d/cupsys restart
Tiskárny Linuxu by nyní měly být nasdíleny pro počítače Windows v místní síti LAN. Proveďte obvyklé kroky pro přidání síťové
tiskárny do počítačů Windows a nezapomeňte vytisknout testovací stránku.
Řešení potíží
Nedaří se připojení k tiskárnám v systému Windows
Pokud se smbspool (nástroj smbclient používaný v CUPS) nepodaří správně připojit k tiskárně v systému Windows, vypíše
chybové zprávy, které bohužel nejsou příliš užitečné. Jednou takovou zprávou je „Unable to connect to SAMBA host: Success“ . Další
možnou chybou připojení je, že dokument zůstává ve frontě při tisku na tiskárnách Windows.
Prostřednictvím následujícího příkazu zobrazte poslední záznamy v logu CUPS:
/usr/bin/tail /var/log/cups/error_log
Zobrazí-li se zpráva „cli_connect() failed...“ nebo podobná, nemohl nástroj smbspool najít počítač Windows, ke kterému se
pokoušíte připojit. Zkontrolujte správnost názvu hostitelského počítače Windows. Ověřte, zda je počítač Windows zapnutý a zda
je připojení k síti funkční. Ujis-těte se, jestli je možné připojit se pomocí smbclient, jak je uvedeno v kapitole „Připojení k Windows “.
Jestliže se zobrazí zpráva „SMB tree connect failed: ERRSRV – ERRinvnetname“ nebo podobná, nástroj smbclient se připojil k počítači
Windows, ale nemohl se připojit k požadované tiskárně. Zkontrolujte název sdílené tiskárny prostřednictvím smbclient, jak je
uvedeno v kapito-le „Připojení k Windows“.
Jiné potíže
Může se stát, že nebudete moci tisknout na místní tiskárně a tiskové úlohy se ztrácejí z fronty, aniž by proběhl tisk. Mohou se také
zobrazovat nejasné chybové zprávy, jako je například „Child pro-cess 2384 exited with status 32.“.
Rozšiřte úroveň logování systému CUPS na debug (ladění), aby se zobrazilo více zpráv o tom, co se stalo před selháním tiskové
úlohy.
1. V textovém editoru otevřete hlavní konfigurační soubor CUPS /etc/cups/cupsd.conf .
2. Změňte řádek s „LogLevel warn“ na „LogLevel debug“.
Uložte konfigurační soubor a zavřete textový editor.
Restartujte server CUPS prostřednictvím příkazu:
/etc/init.d/cupsys restart
Logy tiskového systému CUPS můžete sledovat pomocí tohoto příkazu:
/usr/bin/tail -f /var/log/cups/error_log
Měli byste vidět řádek s textem „Scheduler shutting down due to SIGTERM“. To znamená,
že server CUPS byl úspěšně zastaven. Znovu odešlete tiskovou úlohu a čekejte na užitečnou zprávu ladění, která se zobrazí.
Příklademtakové zprávy ladění je „GNU Ghostscript 7.05: Can’t start ijs server ‘hpijs’“.V tomto případě je řešením instalace balíčku
hpijs, ve kterém jsou chybějící programy.
Jestliže nemůžete určit příčinu chyby, zkuste v síti Internet vyhledat klíčové termíny obsažené ve zobrazené chybové zprávě; je
pravděpodobné, že podobný problém již řešil někdo před vámi. Může-te také zkusit aktualizovat na nejnovější verze balíčky
uvedené v kapitole „Vyžadované balíčky“.
Jak na spam
Úvod
Účel tohoto dokumentu
Tento dokument obsahuje informace o vysoce efektivních a neinvazivních metodách filtrování a blokování spamu a malware v
průběhu příchozích transakcí protokolu SMTP na poštovním ser-veru s důrazem na odstranění zavlečeného spamu (collateral
spam ).
Celý text dokumentu popisuje metody obecně, součástí je však také jednoduchý příklad implementace s využitím agenta přenosu
zpráv Exim a dalších specifických softwarových nástrojů.
Komu je dokument určen
Dokument je určen správcům poštovních systémů, kteří se vyznají ve zkratkách, jako je např. SMTP, MTA/MDA/MUA, DNS/
rDNS nebo MX. Dokument není určen pro koncové uživatele, kteří hledají řešení pro filtrování spamu v prostředí svého
poštovního klienta (např. Evolution, Thun-derbird, mail.app nebo Outlook Express). Takový uživatel však samozřejmě může na
tento doku-ment upozornit správce své domény (firemní, školní atd.).
Nejnovější verze tohoto dokumentu
Nejnovější verzi tohoto dokumentu naleznete na adrese http://slett.net/spam-filtering-for-mx/. Informace na této adrese můžete
kontrolovat pravidelně, dokument je průběžně aktualizován o opravy a různá doplnění.
Zpětná vazba
Rád od vás uslyším o vašich zkušenostech s technikami a nástroji, popsanými v tomto dokumen-tu, stejně jako jakékoliv jiné
komentáře, dotazy, rady nebo příspěvky, které máte. Prosím zašlete mi zprávu elektronické pošty na adresu <tor na slett.net> .
Pokud zvládnete implementovat tech-niky popsané v tomto dokumentu pro jiné agenty přenosu zpráv, jako je např. Sendmail
nebo Postfix, dejte mi prosím vědět.
Co budete potřebovat?
Postupy popsané v tomto dokumentu vyžadují přístup k systému příchozí pošty pro doménu, do které přicházejí zprávy
elektronické pošty. Kromě toho bude nutné na systému instalovat softwa-re a případně modifikovat konfigurační soubory agenta
přenosu zpráv.
Diskuse v tomto dokumentu jsou obecného rázu a je možné je využít u různých agentů přenosu zpráv. Vzorová implementace je
určena pro software Exim. Tato implementace zahrnuje i jiné soft-warové nástroje, jako je např. SpamAssassin. Podrobnosti
implementace naleznete v dodatku A.
Poznámky k typografickým konvencím
SMTP příkazy v této kapitole vyznačujeme tučným písmem, čili např. takto: RCPT TO, EHLO. Tučně jsou vyznačeny i
komunikační kódy protokolu. Části konfiguračních souborů stejně jako jména funkcí čí seznamů v nich jsou sázeny
neproporcionálním písmem ($acl_m0 ).
Struktura dokumentu
Dokument obsahuje následující kapitoly:
Základy – obecný popis protokolu SMTP.
Metody filtrování – popis metod filtrování nevyžádané pošty v transakcích protokolu SMTP.
Další témata k zamyšlení – problémy, které souvisejí s problematikou filtrování.
Otázky a odpovědi – pokus o zapracování nejdůležitějších otázek a odpovědí.
Vzorová implementace metod filtrování s využitím softwaru Exim je uvedena v kapitole „Imple-mentace s využitím softwaru
Exim“.
Základy
V této kapitole naleznete informace o výhodách filtrování zpráv v průběhu příchozí transakce pro-tokolu SMTP. Tento způsob
filtrování není až tak obvyklý, většinou se filtrování provádí až ve fázi směrování nebo doručení zprávy. Součástí této kapitoly je
stručný popis transakce protokolu SMTP.
Proč filtrovat zprávy v průběhu transakce protokolu SMTP? Status Quo
Pokud dostáváte spam, zvedněte ruku a držte ji nahoře. Pokud dostáváte prostřednictvím elektronické pošty viry nebo jiný
malware, také zvedněte ruku. Pokud dostáváte falešná oznámení
o doručení zprávy (Delivery Status Notification) typu „Zpráva nedoručitelná“, „Nalezen virus“ nebo „Prosíme potvrďte
doručení“, která jsou reakcí na nikdy nezaslané zprávy, zvedněte ruku také. Tyto zprávy se obecně označují termínem zavlečený
spam (collateral spam). Tato forma spamo-vých zpráv způsobuje při filtrování nejvíce problémů, protože se filtruje hůř než
„standardní“ spam nebo malware a protože tyto zprávy mohou značně mást všechny příjemce, kteří nemají dosta-tečné schopnosti
porozumět jednotlivým záhlavím zprávy. Zvýšený zájem uživatelů způsobují hlavně falešné zprávy o virech. Nicméně platí, že
pokud uživatel dostává pravidelně větší množ-ství takových falešných zpráv, začne je postupem času ignorovat a to může vést k
přehlédnutí anebo ignorování vážně míněných legitimních varování (například od správce sítě). A jako posled-ní tělocvičný prvek
poprosíme ty z vás, kteří díky chybné klasifikaci spamovým filtrem nebo anti-virovým programem přišli o legitimní zprávu,
zvedněte prosím do výšky vaši nohu.
Pokud jste před čtením této kapitoly stáli a pořád stojíte, je to možná tím, že nemáte úplně jasno v tom, co se může přihodit
zprávám elektronické pošty. Pokud jste již prováděli nějaký způsob filtrování spamu, třeba jen ručním přesouváním zpráv do
složky s odstraněnou poštou, nebo jste prováděli experimenty s primitivními filtrovacími postupy, jako jsou například seznamy
zakáza-ných položek služby DNS (např. SpamHaus, SPEWS nebo SORBS), existuje jistá pravděpodobnost, že jste smazali i
legitimní zprávy.
Příčina
Spam, stejně jako mnoho dalších artefaktů chtivosti, je sociální nemoc. Říkejme jí chřipka nebo jakkoliv jinak, základní princip je
totiž podobný. Spočívá v tom, že nižší formy života hledají způ-sob, jak zničit větší ekosystém, a pokud se jim to podaří, dojde to
do takového konce, kdy zničí i svoje vlastní útočiště.
Teď zanechme filozofování: Vy – správce poštovního systému – čelíte velmi konkrétnímu dilema
tu při hledání způsobů, jak se s tímto odpadem vypořádat. Při zpracování pošty existují v konvenčním způsobu, jakým jsou zprávy
zpracovávány a předává-ny mezi jednotlivými komponentami softwaru pro doručování nebo směrování zpráv, jistá ome-zení. V
obvyklé implementaci přijímá většinu nebo všechny příchozí zprávy, které jsou adresová-ny pro danou doménu, jeden nebo více
poštovních serverů. Tyto servery často směrují zprávy pro další zpracování na jeden nebo více dalších serverů ve vnitřní síti nebo
je přímo doručují do poš-tovních schránek uživatelů. Pokud kterýkoliv ze serverů zjistí, že není schopen provést požado-vané
doručení zprávy nebo jinou funkci, vygeneruje a vrací zpět na adresu odesílatele původní zprávy oznámení o stavu doručení.
Současně s tím, jak organizace začaly nasazovat antivirové a antispamové programy, bylo obvyk-le cestou nejmenšího odporu
zjištěno, že nejvhodnější umístění pro tyto programy se nachází přímo na cestě doručování zpráv například mezi jednotlivými
poštovními servery nebo hostitel-skými systémy doručování zpráv anebo softwarem doručování zpráv. Obvyklým způsobem
filtro-vání spamu je například směrování zpráv přes software SpamAssassin ještě před vlastním doruče-ním zprávy do poštovní
schránky uživatele nebo celý systém filtrování spamu spoléhá na schop-nosti filtrování přímo v poštovních klientech jednotlivých
uživatelů.
Možnosti, které se u těchto způsobů filtrování nabízejí po rozpoznání spamové nebo zavirované zprávy, jsou poměrně omezené:
Odesílateli je možné vrátit oznámení o stavu doručení. Problém je, že téměř veškerý spam i zavirované zprávy obsahují
falešnou adresu odesílatele. Pokud na takové zprávy bude systém odpovídat, s největší pravděpodobností se to dotkne nevinných
obětí – je to srov-natelné s varováním babičky ze Švédska, která používá počítač se systémem Mac OS X a neví nic o počítačích,
že její počítač je infikován červem Blaster. Dále to pak znamená, že i vy se stanete generátorem zavlečeného spamu.
Zprávu je možné přesunout do spamového koše bez zaslání oznámení o stavu doručení zpět odesílateli. To může být
problém v případě falešných pozitivních detekcí, protože ani odesílatel, ani příjemce se nikdy nedozví, co se se zprávou stalo (a
příjemce se ani nedozví, že zpráva kdy existovala).
V závislosti na tom, jakým způsobem uživatelé přistupují ke svým zprávám (přistupují s využitím protokolu IMAP,
využívají webový přístup, ale nikoliv v případě, kdy zprávy sta-hují s využitím protokolu POP3), je možné potenciální spam
přesouvat do zvláštní složky, která může být například součástí nastavení poštovního účtu.
Poslední možnost je zřejmě nejlepší, ale v závislosti na tom, jak pravidelně nebo nepravidelně složku s potenciálním spamem
uživatel prochází, může dojít k přehlédnutí nebo nechtěnému sma-zání legitimních zpráv, které byly chybně klasifikovány a
přesunuty do této složky.
Řešení
Jak určitě sami tušíte, jediné řešení tohoto problému je provádět filtrování spamu a antivirovou kontrolu při přijímání zprávy
poštovním serverem, tj. v průběhu probíhající transakce protokolu SMTP se vzdáleným hostitelem. Pokud se v průběhu transakce
ukáže, že zpráva je nevyžádaná, je možné provést příkaz reject protokolu SMTP a dále není nutné řešit dilemata popsaná výše.
Výsledkem je, že:
Doručení většiny nevyžádaných zpráv je možné zastavit již v průběhu transakce protoko-lu SMTP ještě před vlastním
přijetím obsahu zprávy, což šetří šířku pásma i čas procesoru.
Při filtrování je možné využít například zpožďování transakcí protokolu SMTP nebo grey-listing, což jsou metody, které
se nedají provádět v pozdějších fázích zpracování zpráv.
V případě nedoručení zprávy (například díky chybně zadané adrese příjemce zprávy) je
možné uvědomit odesílatele zprávy bez generování nevyžádaného zavlečeného spamu. V tomto dokumentu naleznete
kromě jiného informace o tom, jak zabránit nepřímému generování zavlečeného spamu díky odmítnutí zpráv z
důvěryhodných zdrojů, jako jsou například mailinglisty nebo servery a poštovní účty v jiných doménách.
Poznámka
Nedůvěryhodné hostitelské systémy mohou v případě odmítnutí zprávy generovat zavle-čený spam. Pokud takový
hostitelský systém nepracuje v režimu open proxy nebo open relay, pravděpodobně doručuje zprávy pouze od
legitimních odesílatelů, jejichž adresy jsou platné. Pokud systém pracuje v režimu open proxy nebo open relay, je
lepší zprávu odmítnout a nechat ji shnít uloženou v odchozí frontě zpráv tohoto systému.
■ Je umožněna ochrana před zavlečeným spamem z jiných adres (například falešných zpráv
typu „Máte virus“, které zasílá antivirový program). Tak jo, už můžete dát ruce dolů. A pokud stojíte jen na jedné noze, už
si můžete stoupnout na obě.
Pro a proti
Některé metody filtrování jsou pro použití v průběhu transakce protokolu SMTP vhodnější než
jiné. Některé jsou prostě lepší než jiné. Téměř všechny však mají své pro a proti.Tyto klady i zápory platí i pro metody popsané v
tomto dokumentu. Platí například následujícítvrzení:
Je možné říci, že kontroly prováděné s využitím systému DNS mohou znevýhodnit jednot-livé odesílatele zpráv v
závislosti na poskytovateli jejich internetového připojení a ne na základě obsahu příslušných zpráv.
Dále je možné říci, že metody zpožďování transakcí protokolu SMTP nebo greylisting jsou snadno překonatelné a s
postupem doby budou méně účinné a budou degradovat kvalitu služby pro legitimní zprávy.
Dá se říci, že některá schémata autorizace odesílatele, jako například SPF (Sender Policy Framework) dávají
poskytovatelům připojení k Internetu možnost „zablokovat“ si své zákazníky v tom smyslu, že neumožní dostatečně využívat
poštovních služeb těm, kteří se
připojují v různých sítích, nebo těm, kteří přeposílají zprávy mezi různými hostitelskými systémy.
Od těchto protikladů se budeme raději držet dál a v dokumentu naleznete popis fungování růz-ných dostupných metod spolu s
vysvětlením všech možných vedlejších efektů a s popisem auto-rových zkušeností s jejich využíváním.
V současnosti existují některé způsoby filtrování, které jsou v tomto dokumentu v tichosti pominuty:
■ Systémy typu výzva/odezva (challenge/response), jako je např. TDMA. Tyto systémy nejsou pro filtrování protokolu
SMTP s využitím časových zpoždění vhodné, protože tyto systémy pracují na principu přijetí zprávy a následném vracení
požadavku o potvrzení na adresu odesílatele zprávy z příkazu MAIL FROM:. Tato metoda je již za hranicí rozsahu tohoto
dokumentu.
Poznámka
Autor dokumentu se nedomnívá, že systémy typu výzva/odezva jsou obecně vhodné. Jednak generují zavlečený spam,
vyžadují speciální pozornost u zpráv zasílaných auto-matizovanými zdroji, jako jsou například měsíční bankovní
výpisy, a degradují použi-telnost elektronické pošty díky tomu, že odesílatelé legitimních zpráv se nechtějí zatě-žovat
s požadavky na potvrzení nebo nevědí, jak na požadavek na potvrzení reagovat, a tudíž se legitimní zprávy, pro které
uživatel z nějakého důvodu nepotvrdí požadavek na potvrzení, mohou ztratit.
Bayesovy filtry. Tyto filtry vyžadují před nasazením v produkčním prostředí trénink, který může být specifický pro
konkrétního uživatele a konkrétní jazyk. Díky tomu tento způsob není vhodný pro použití v průběhu transakce protokolu SMTP.
Technologie mikroplateb, které nejsou pro blokování nevyžádané pošty vhodné, dokud nebudou virtuální poštovní
známku obsahovat úplně všechny odesílané zprávy. (Zatím to vypadá, že se využívají pro opačné účely – tzn. pro přijetí takové
zprávy, která obsahuje známku a která by byla za jiných okolností odmítnuta.)
Jednotlivé metody uvedené v dokumentu jsou při detekci nevyžádané pošty co možná nejpřes-nější a jsou vybrány tak, aby v co
nejmenší míře zabránily vzniku falešných pozitivních detekcí. Zprávy elektronické pošty jsou pro uživatele důležité a ti jim věnují
svůj čas a úsilí. Metody a nástroje, které odmítají velké množství legitimních zpráv, ukazují na nedostatek respektu jak k lidem,
kteří zprávy zasílají, tak k Internetu jako celku.
Poznámka
Názor autora je v přímém rozporu s názorem velkého počtu tzv. spamových hacktivistů, například se správci seznamu
zakázaných položek SPEWS (viz http://www.spews.org/). Jed-ním z přímých cílů správců tohoto seznamu je bojovat proti
zavlečenému spamu hlavně vyvíjením tlaku na poskytovatele připojení k Internetu.
Toto obvykle nejsou použitelné metody. Vezměme v úvahu rozvojové země a předpokládejme fakt, že v takových zemích jsou
poskytovateli širokopásmového připojení regulované monopoly. Myslím, že tento příklad ilustruje přesnou příčinu problému s
důvěryhodností poskytovatelů.
Obecně však platí, že existují lepší a přesnější způsoby, jak filtrovat nevyžádanou poštu.To platí zvláště pro filtrování s využitím
časového zpoždění, protože koncoví uživatelé obvyklenemají možnost ovlivnit jednotlivá kritéria, která jsou pro filtrování zpráv
použita.
Transakce protokolu SMTP
Protokol SMTP slouží pro doručování zpráv v prostředí Internetu. Podrobný popis protokolu naleznete v dokumentu RFC 2821 a
také v dokumentu Davea Rockera o architektuře internetové pošty (http://www.brandenburg.com/specifications/draft-crockermail-arch-00.htm).
Doručení poštovní zprávy vyžaduje provedení transakce protokolu SMTP mezi hostitelem, který se připojuje (klient), a
hostitelem, který připojení přijímá (server). Pro účely této diskuse budeme předpokládat, že hostitel, který se připojuje, je
klientský počítač a hostitel, který připojení přijímá, je poštovní server.
V průběhu transakce protokolu SMTP klient zasílá příkazy protokolu SMTP jako například EHLO, MAIL FROM:, RCPT TO:
nebo DATA. Server na každý příkaz odpovídá numerickým kódem slo-ženým ze tří číslic, který udává, jestli byl příkaz přijat
(kódy 2xx), jestli byl příkaz předmětem dočasného selhání nebo omezení (kódy 4xx) nebo jestli příkaz selhal definitivně nebo
trvale (kódy 5xx). Za kódem následuje textové vysvětlení. Úplný popis těchto kódů je součástí doku-mentu RFC 2821.
Transakce protokolu SMTP se ve vzorovém případě skládá z následujících kroků:
Transakce protokolu SMTP
Klient
Server
Iniciuje připojení k serveru pomocí protokolu TCP.Zobrazí úvodní zprávu protokolu SMTP, tzn. text, který začíná kódem . Tento
kód udává, že server je připraven přijímat příkazy protokolu SMTP (nebo
ESMTP, což je nadmnožina proto-kolu SMTP): 220 název_domény ESTMP...
Identifikuje se příkazem Hello, bu (v současnosti se Přijme identifikaci kódem . Pokud klient použil rozšířenou nepoužívá) nebo
, za kterým následuje úplný název verzi příkazu Hello (), server ví, že klient je schopen domény: EHLO úplný_název_domény
zpracovat víceřádkové odezvy, a proto klientovi zašle několik
řádků textu, ve kterých uvede jednotlivé vlastnosti serveru:
250-úplný_název_domény Hello ... 250-SIZE 52428800 250-8BITMIME 250PIPELINING 250-STARTTLS 250-AUTH 250 HELP Pokud je součástí odezvy
vlastnost , znamená to, že klient může od tohoto okamžiku zasílat více
příkazů najed-nou bez toho, aby postupně čekal na odezvu na každý
příkaz.
Začne transakci identifikací odesílatele (Envelope Sender): Zašle kód , který udává, že server akceptuje odesílatele.
MAIL FROM:<adresa@odesílatele>
Identifikuje jednotlivé příjemce zprávy (Envelope Recipient) Zasílá příslušnou odezvu na každý příkaz (, nebo , postupně
jednoho po druhém s využitím příkazu: v závislosti na tom, jestli je doručení příslušnému příjemci RCPT TO:<adresa@příjemce>
povoleno, je předmětem dočasného omezení nebo odmítnuto).
Zašle příkaz , kterým serveru oznámí připravenost
Zašle kód , který indikuje, že příkaz byl dočasně přijat.
zaslat text zprávy.
Přenese text zprávy, která začíná jednotlivými řádky záhlaví Zašle kód , kterým udává, že zpráva byla přijata. (dle RFC 2822),
např. From:, To:, Subject:, Date:, Message-ID:. Záhlaví a tělo zprávy jsou odděleny prázdným řádkem. Konec zprávy je
identifikován znakem tečka („.“) na zvláštním řádku.
Pokud klient zasílá více zpráv, následuje další příkaz . Odpojí se. V opačném případě
zašle příkaz nebo se přímo odpojí.
Metody filtrování
V této kapitole naleznete popis různých metod filtrování nevyžádané pošty v průběhu probíhají-cí transakce protokolu SMTP a
také popis různých vedlejších efektů, které doprovázejí použití těchto metod filtrování.
Zpoždění transakcí protokolu SMTP
Jednou z nejúčinnějších metod blokování spamu je zavedení zpoždění v příchozích transakcích protokolu SMTP. To je primitivní
forma tzv. teergrubingu, viz http://www.iks-jena.de/ mitarb/lutz/usenet/teergrube.en.html.
Většina spamu a téměř všechny zavirované zprávy jsou na poštovní server doručovány pomocí specializovaného klientského
softwaru, který je optimalizovaný pro přenosy vysokého objemu zpráv v krátkém časovém okamžiku. Tento klientský software je
obvykle označován termínem rat-ware.
Aby bylo možné výše uvedené zadání splnit, autoři ratwaru obvykle využívají pár „zkratek“, které se trochu odchylují od
specifikace protokolu SMTP z dokumentu RFC 2821. Jednou z takových zkratek je, že ratware bývá velmi netrpělivý, zvláště při
komunikaci s poštovními servery, které odpovídají pomalu. Ratware například zkouší provést zaslání příkazu HELO nebo EHLO
ještě předtím, než server zobrazí úvodní zprávu protokolu SMTP, nebo se pokusí o zřetězení několika příkazů protokolu SMTP
ještě předtím, než server zveřejní informace o svých vlastnostech s vyu-žitím klíčového slova PIPELINING.
Někteří agenti přenosu zpráv (například Exim) takováto porušení konvencí protokolu SMTP pova-žují za chyby synchronizace a
okamžitě ukončují příchozí připojení. Pokud takového agenta pře-nosu zpráv využíváte, pravděpodobně v logovacích souborech
uvidíte mnoho záznamů o takto ukončených připojeních. Frekvence výskytu takových „chyb“ se zvyšuje současně s tím, jestli
jsou před zobrazením úvodní textové zprávy protokolu SMTP prováděny kontroly, které zabírají jistý čas (například kontrola s
využitím seznamu povolených položek služby DNS), protože klienti s rat-warem prostě nemohou čekat na odezvu ze serveru tak
dlouho. (Mají spoustu práce, doručují spam lidem.)
Proto je možné do transakce vnést dodatečné zpoždění. Například je možné čekat:
20
20
20
20
sekund před zobrazením úvodní textové zprávy protokolu SMTP.
sekund po úvodním příkazu Hello (EHLO nebo HELO).
sekund po příkazu MAIL FROM:.
sekund po každém příkazu RCPT TO:.
Kde se ale vzalo právě 20 sekund? Proč ne zrovna minuta? Nebo několik minut? Dokument RFC 2821 udává, že klient, který
zasílá zprávu, by měl čekat na každou odezvu protokolu SMTP něko-lik minut. Problém je, že některé hostitelské systémy, které
přijímají zprávy (například ty, které vyu-žívají Exim), mohou provádět pro každou příchozí poštovní transakci ověření adresy
odesílatele. Pokud některý uživatel z vaší domény zašle zprávu takovému hostitelskému systému, systém nej-prve kontaktuje
poštovní server (identifikovaný MX záznamem ) vaší domény a pokusí se ve vaší doméně transakcí protokolu SMTP ověřit adresu
odesílatele. Výchozí maximální časový interval takového ověření adresy odesílatele je 30 sekund. Pokud by časové zpoždění
trvalo takto dlouho, ověření adresy odesílatele by mohlo selhat a díky tomu by doručení zpráv z vaší domény mohlo být
odmítnuto (obvykle chybou typu dočasného selhání, při které se pokus o doručení zprávy opa-kuje po dobu cca 5 dnů předtím,
než je původní zpráva definitivně vrácena odesílateli).
Jinými slovy, 20 sekund je dostatečně dlouho na to, aby nezpůsobilo problémy při normálním
doručování legitimních zpráv.Pokud nechcete taková časová zpoždění používat v každé transakci protokolu SMTP (napříkladmáte
velmi vytížený server), je možné tato zpoždění používat selektivně. V těchto případech sezpoždění uplatní například pouze tehdy,
když:
Dojde k problému při zjišťování informací o hostitelském systému pomocí DNS.
Dojde k jakémukoliv problému v průběhu transakce protokolu SMTP.
Dojde k pokusu o transakci u poštovního serveru, který má mezi jednotlivými MX zázna-my nejnižší prioritu. Ratware
se obvykle zaměřuje na takové hostitelské systémy, legitimní agenti přenosu zpráv obvykle využívají poštovní servery s nejvyšší
prioritou.
Použití selektivního zpoždění transakcí může být dobrým výchozím bodem při implementaci dalších kontrol, které budou
popsány v následujících kapitolách. Pravděpodobně určitě nebudete chtít odmítnout příchozí poštovní zprávy pouze na základě
výsledků kontroly s využitím seznamu SPEWS, nicméně na druhou stranu tato kontrola může poskytnout dostatek informací pro
použití zpoždění transakcí. Výsledkem pak je, že doručování legitimních zpráv není (kromě lehkého zpoždění) nijak ovlivněno.
Na druhou stranu, pokud zjistíte jasné příznaky spamu (například kontrolami prováděnými v rámci transakce protokolu SMTP) a
váš server to umožní, můžete jej nakonfigurovat pro další dodateč-né zpoždění například o délce 15 minut a teprve potom
doručení zprávy definitivně odmítnout.
Poznámka
Při zpožďování příchozích transakcí protokolu SMTP je nutné mít na paměti, že čekání a zpoždění současně blokuje
prostředky protokolu TCP a také jiné zdroje serveru (napří-klad paměť). Pokud je server zatížený, implementace zpoždění
transakcí protokolu SMTP může zvýšit riziko v případě útoku typu odepření služby. Řešením je například okamžité
ukončení příchozího připojení bezprostředně poté, co je nezvratně zjištěno, že odesílate-lem je klient s ratwarem.
Použití zpoždění nemá jinou výhodu než přibrzdění spamera v úsilí dosáhnout zprávami co možná nejvíce uživatelů ještě před
provedením dalších následných kontrol (například s využitím seznamu povolených položek služby DNS).
Z vlastních zkušeností autora je možné říci, že zavedení selektivního zpoždění transakcí protoko-lu SMTP způsobí chyby
synchronizace u cca 50 % všech odmítnutých příchozích pokusů o doru-čení zpráv. Proto je možné říci, že téměř 50 % příchozí
nevyžádané pošty je možné zastavit s vyu-žitím zpoždění transakcí protokolu SMTP.
Kontrola s využitím systému DNS
Údaje o konkrétním hostitelském systému je možné získat ještě předtím, než se začnou provádět příkazy protokolu SMTP, pomocí
systému DNS (Domain Name System). Pro zjištění, jestli daná adresa IP porušuje nebo splňuje některá vybraná kritéria, je možné
využít některé seznamy zaká-zaných položek systému DNS a pro zjištění integrity hostitelského systému se dá využít vyhledá-ní
dopředného a reverzního záznamu systému DNS.
Předmětem kontrol s využitím systému DNS mohou být různé datové položky, postupně zjištěné v průběhu transakce protokolu
SMTP (například název hostitelského systému, uvedený klientem v příkazu Hello). Více podrobností o jednotlivých položkách
naleznete v dalších kapitolách.
Na místě je ovšem varování. Kontroly s využitím systému DNS nemusí být spolehlivé (například v případě, kdy daný server
systému DNS neodpovídá ) a ne vždy jednoznačně identifikují spam. Pokud je váš poštovní server velmi zatížený, mohou kontroly
prodloužit dobu zpracování zpráv. Na druhou stranu tyto kontroly mohou poskytnout užitečné informace pro účely záznamu
informací do logovacích souborů.
Seznamy zakázaných položek systému DNS
Seznamy zakázaných položek systému DNS (dříve také označované termínem „Real-time Black-hole lists“ podle původního
seznamu z adresy mail-abuse.org) jsou zřejmě nejpoužívanějším nástrojem pro blokování spamu v průběhu transakce protokolu
SMTP. Server, který zprávu přijí-má, provede jednou nebo i několik vyhledávání reverzních záznamů systému DNS v různých
seznamech zakázaných položek, např. „dnsbl.sorbs.net“, „opm.blitzed.org“ nebo „lists.dsbl.org“. Pokud je daný záznam v
seznamu nalezen, obvykle to znamená odmítnutí doručení zprávy.
Poznámka
Podobné seznamy se používají i pro jiné účely. Seznam „bondedsender.org“ obsahuje povo-lené (=důvěryhodné) položky
systému DNS. Vlastníci adres protokolu IP těchto položek slo-žili finanční zálohu, která bude snížena v případě, kdy z
dané adresy začnou odcházet spa-mové zprávy. Ostatní seznamy mohou obsahovat adresy protokolu IP pro konkrétní
zemi, konkrétní poskytovatele připojení atd.
Kromě adresy DNS (záznam typu „A“) je možné vyhledat i záznam typu „TXT“, který obsahuje jed-nořádkový popis zakázané
položky, kterou je vhodné zahrnout do odezvy odmítající doručení zprávy. Pokud to chcete vyzkoušet, je možné použít příkaz
host, který je dostupný u většiny systé-mů Linux nebo UNIX:
host -t txt 2.0.0.127.dnsbl.sorbs.net
Podobných seznamů existují stovky, každý z nich má jiná kritéria pro zařazení položky do sezna-mu a jiné zásady pro vyřazení
položky ze seznamu. Některé seznamy dokonce kombinují více kri-térií a při reverzním vyhledávání vracejí různá data v
závislosti na konkrétním kritériu, které je použito u vyhledávané adresy. Reverzní vyhledání pro doménu sbl-xbl.spamhaus.org
vrací adre-su 127.0.0.2 pro všechny adresy protokolu IP, které podle správců seznamu SpamHaus přímo patří spamerům nebo
jejich poskytovatelům, vrací adresu 127.0.0.4 pro všechny hostitelské systémy, které fungují jako zombie, a vrací adresu 127.0.0.6
pro všechny servery, které pracují v režimu open proxy.
Některé seznamy bohužel obsahují rozsáhlé bloky adres protokolu IP, které nejsou přímo zodpovědné za generování spamu,
nemají jasné zásady pro zařazení nebo vyřazení položek nebo obsahují chybné informace o zařazených adresách.
Poznámka
Například servery odchozí pošty největšího poskytovatele připojení k Internetu na světě, firmy Comcast, v době psaní
tohoto dokumentu využívaly seznam SPEWS Level 1. Je urči-tě jasné, že Comcast chce ve své síti efektivně prosadit
vlastní zásady přijatelného využí-vání (AUP – Acceptable use policy), nicméně tento seznam má dopad na 30 % všech
uži-vatelů Internetu v USA, což jsou z valné většiny „nevinní“ zákazníci, mezi nimiž je i autor tohoto dokumentu.
Co je však ještě horší, informace uveřejněné v části FAQ na stránkách seznamu SPEWS uvádějí: Většina seznamů z
úrovně Level 1 obsahuje bloky adres, které přímo vlastní spa-meři nebo které podporují spamové operace s pouze
několika nebo žádnými jinými zjištěnými legitimními zákazníky. Tato informace je technicky přesná, pokud
předpokládáme,
že Comcast podporuje spamové operace, a pokud se zaměříme na slovo „žádnými“. Ve
skutečnosti je tato informace naprosto zavádějící.
Slepá důvěra v takové seznamy může způsobit problémy při doručování pošty. Mnoho správců poštovních systémů místo
odmítnutí doručení zprávy na základě jediné pozitivní odezvy od některého seznamu zakázaných položek systému DNS využívá
seznamy daleko rafi-novaněji. Kontrola se provádí u více různých seznamů a jednotlivé pozitivní výsledky jsou ohod-noceny
nějakou váhou. Pokud celkový součet vah pro danou adresu protokolu IP přesáhne jistou
prahovou hodnotu, doručování zpráv z této adresy je odmítnuto. Takovým způsobem využívá seznamy zakázaných položek
systému DNS například filtrující software SpamAssassin. Kontrolu s využitím seznamů je také možné využít jako podmínku pro
aktivaci zpoždění transak
ce protokolu SMTP. Pokud je daný hostitelský systém uveden v seznamu, server může zpožďovat odezvy na každý příkaz
protokolu SMTP například o 20 sekund. Jako podmínku pro aktivaci zpož-dění je samozřejmě možné využít i jiná kritéria (viz
kapitola „Zpoždění transakcí protokolu SMTP“).
Kontrola integrity záznamů systému DNS
Systém DNS je možné také využít tak, že se nejprve provede reverzní vyhledání na základě adresy protokolu IP systému, který
navazuje spojení, a výsledný vyhledaný název se použije při následném dopředném vyhledání. Pokud je původní adresa protokolu
IP obsažena ve výsledku dopředného vyhledání, je tím pro danou adresu protokolu IP ověřena integrita záznamů systému DNS. V
opač-ném případě nejsou informace v systému DNS pro systém, který navazuje spojení, korektní.
Odmítnutí zpráv na základě kontroly integrity může být vhodnou volbou pro militantní členy poli-cie systému DNS, kteří si
nastavují záznamy typu MX pro své vlastní osobní domény a neštítí se odmítat doručení legitimních zpráv jako součást taktiky,
kterou chtějí donutit odmítnuté odesíla-tele ke kontrole a případné opravě jejich záznamů v systému DNS. Pro všechny ostatní
může být kontrola integrity záznamů systému DNS použita jako jedna z více různých kontrol. Podobně jako v předchozí kapitole
i u kontroly integrity platí, že to může být vhodná podmínka pro aktivaci zpoždění transakcí protokolu SMTP.
Kontroly transakce protokolu SMTP
V průběhu transakce protokolu SMTP je možné provádět různé typy kontrol příkazů i jejich argu-mentů, které vzdálený hostitel
zasílá. Jednoduchým příkladem může být kontrola názvu hostitel-ského systému z části Hello.
I v případě, kdy dojde k rozhodnutí odmítnout pokus o doručení zprávy již v úvodních fázích transakce protokolu SMTP, není
nutné provést odmítnutí hned. Místo toho je vhodné zpozdit ode-sílatele aktivací zpoždění až do příkazu RCPT TO: a zprávu
odmítnout po tomto příkazu.
Důvodem je, že některé typy ratwaru neumí odmítnutí v úvodních fázích transakce protokolu SMTP správně vyhodnotit a snaží se
zprávu doručit znovu. Většina ratwaru však opakované poku-sy vzdá v případě, kdy dojde k odmítnutí transakce po příkazu RCPT
TO:.
Kontroly úvodní fáze Hello (HELO/EHLO)
Podle dokumentu RFC 2821 by měl být prvním příkazem transakce protokolu SMTP, který klient zasílá, příkaz EHLO (pokud
není podporovaný, tak HELO), následovaný úplným názvem domé-ny odesílatele. Tomuto příkazu se také většinou říká pozdrav
Hello. Pokud není k dispozici úplný
název domény odesílatele, může klient použít adresu protokolu IP uzavřenou v hranatých závor
kách takto: [1.2.3.4]. Tento způsob se nazývá „písmenná“ notace adresy IPv4.Jak je zřejmé, ratware v příkazu Hello použije úplný
název domény pouze výjimečně. Ratware seobvykle spíše snaží skrýt identitu odesílajícího hostitelského systému nebo
vygenerovat falešnéstopy v záhlaví „Received“ zprávy. Mohou to být například:
Neúplné názvy (názvy bez teček), například název domény příjemce bez teček.
Libovolné adresy IP (tzn. nekorektně uvedená adresa podle definice písmenné notace). Může to být například adresa
hostitelského systému příjemce nebo prostě jakákoliv náhodná adresa.
Název domény příjemce zprávy nebo úplný název domény vašeho poštovního serveru.
Názvy jiných domén, například yahoo.com nebo hotmail.com.
Názvy neexistujících domén nebo názvy domén bez existujících poštovních serverů.
Prázdný název.
Jednoduché kontroly syntaxe HELO/EHLO
Některá narušení dokumentu RFC 2821 se zkontrolují snadno a jsou jasným důkazem, že odesíla-jící hostitelský systém využívá
nějaký typ ratwaru. Transakci protokolu SMTP je tedy v takových případech možné odmítnout a ukončit buď okamžitě nebo až
po příkazu RCPT TO:.
Nijak se neomezujte odmítat ty transakce, u kterých je v příkazu Hello použita adresa protokolu IP neuzavřená v hranatých
závorkách. I když při kontrolách povolíte všechna možná doporučení a návrhy obsažené v dokumentu RFC 2821, určitě
zaznamenáte, že adresa protokolu IP by měla být vždy uzavřena v hranatých závorkách.
Poznámka
Tato kontrola je za normálních okolností při boji se spamem velmi účinná, nicméně exis
tují zprávy o tom, že některé instalace softwaru listserv firmy L-Soft používají v příkazu
Hello adresu protokolu IP neuzavřenou v hranatých závorkách.
Hostitelským systémům, které v příkazu Hello použijí adresu protokolu IP nebo hostitelský název vašeho systému, je možné vrátit
peprnou zprávu s odmítnutím. Důvod je jasný – jde o podvrh. V tomto případě je také možné odesílatele ztrestat extrémně
dlouhým zpožděním transakce pro-tokolu SMTP, mohou to být i řádově hodiny.
Zkušenost autora říká, že žádné legitimní systémy v prostředí Internetu se neprezentují jiným systémům s využitím písmenné
notace adresy protokolu IP (tzn. [x.y.z.w]). Platí, že všechny hos-titelské systémy, které přímo zasílají zprávy, by měly používat
úplný název domény. Jediný pří-pad použití písmenné notace adresy IP autor zaznamenal při použití klientských poštovních programů (např. Ximian Evolution), které využívaly poštovní server jako odchozí server protokolu SMTP. Je samozřejmostí, že
písmenné notace adresy IP jsou v takovém případě povoleny pouze pro adresy z místní sítě.
U neúplných názvů domény (názvy bez teček) je možné odmítnutí provést nebo i neprovést. Exi
stují řídké výjimky, u kterých je i neúplný název domény legitimní. Stejně tak je možné transakci odmítnout v případě, kdy název
hostitelského systému obsahuje neplatné znaky. V prostředí internetových domén jsou platnými znaky všechny alfanumerické
znaky a pomlčka s tím, že pomlčka nesmí být použita jako první znak. (Stejně tak je možné za platný znak považovat podtržítko,
protože se často využívá u chybně nakonfigurovaných klientů se systémem Windows.)
Pokud transakce začne přímo příkazem MAIL FROM: bez úvodního příkazu Hello, je řešení
nasnadě: Slušní lidé nejprve pozdraví.Na poštovních serverech autora jsou odmítnuty všechny transakce, které nevyhoví
kontrolám syn-taxe příkazu Hello. K odmítnutí transakce pak dojde po příkazu RCPT TO:. Mezitím následujízpoždění transakce
o délce 20 sekund pro všechny ostatní příkazy protokolu SMTP (HELO/EHLO,MAIL FROM: a RCPT TO:).
Kontrola příkazu Hello s využitím DNS
Hostitelské systémy, které prošly prvními kontrolami příkazu Hello, je dále možné kontrolovat s využitím systému DNS. V této
fázi je možné:
Provést dopředné vyhledání zadaného názvu a porovnat výsledek s adresou IP hostitelského systému, který navázal
spojení.
Provést reverzní vyhledání adresy IP hostitelského systému, který navázal spojení a porov-nat výsledný název s tím,
který byl uveden v příkazu Hello.
Pokud obě kontroly proběhnou bez problému, název byl úspěšně ověřen. Váš agent přenosu zpráv může mít implementovanou
možnost provedení této kontroly. Software Exim (viz kapitolu „Implementace s využitím softwaru Exim“) umožní kontrolu
provést nastave
ním parametru helo_try_verify_hosts = * a vytvořit seznam řízení přístupu, který na základě podmínky verify = helo provede
příslušnou akci. Tato kontrola je z pohledu výpočetního a síťového výkonu poněkud náročnější než prostá kontrola syntaxe. Na rozdíl od kontroly syntaxe v tomto případě překlepy nebo chyby v názvech pokaždé nemusejí ukazovat na
ratware, některé velké domény, například hotmail.com, yahoo.com nebo amazon.com velmi často používají příkazy Hello, které
nejsou verifikovatelné.
Na serverech autora se provádí ověřování pomocí DNS v případě, kdy pro odesílatele ještě neby-lo (v závislosti na předchozích
kontrolách) aplikováno zpoždění transakce. Pokud kontrola s vyu-žitím systému DNS selže, aplikuje se zpoždění 20 sekund pro
každý další příkaz transakce proto-kolu SMTP. Současně je vytvořeno záhlaví s varováním „X-HELO-Warning“, které je později
při-dáno do zprávy a zvyšuje u softwaru SpamAssassin váhu pro možné odmítnutí zprávy po přijetí vlastních dat zprávy.
Kontroly adresy odesílatele
Poté, co klient uvede v příkazu MAIL FROM: <adresa_odesílatele> adresu odesílatele, je možné provést ověření platnosti této
adresy několika způsoby.
Poznámka
Speciální případ je prázdná adresa odesílatele, tzn. MAIL FROM: <>, která se používá
u oznámení o stavu doručení nebo jiných automaticky generovaných odezev. Prázdná
adresa by měla být při kontrolách vždy akceptována.
Kontrola syntaxe adresy odesílatele
Vyhovuje zadaná adresa formátu <uživatel@doména>? Je část doména částí syntakticky správně zapsaného úplného názvu
domény ? Většina agentů přenosu zpráv – MTA – tyto kontroly prová-dí automaticky.
Kontrola falešné adresy
Pokud uživatelé zasílají veškerou odchozí poštu pomocí několika málo poštovních serverů, je možné odmítnout zprávy z jiných
hostitelských systémů, kde je název domény odesílatele shod-ný s vaší doménou.
Obecnější alternativa této kontroly je použití SPF (Sender Policy Framework).
Kontrola platnosti adresy odesílatele
Pokud je adresa místní (=z místní domény), je část adresy před znakem @ shodná s existující poš-tovní schránkou v místní
doméně?Pokud je adresa cizí, existuje doména, uvedená za znakem @?
Kontrola platnosti odesílatele zpětným voláním (Sender Callout Verification)
Tento mechanismus implementují někteří agenti přenosu zpráv, například Exim nebo Postfix. Mechanismus ověřuje část adresy
před znakem @. Terminologií použitou v softwaru Postfix se tato kontrola nazývá „Ověření adresy odesílatele“ („Sender Address
Verification“).
Při této kontrole poštovní server, který přijímá zprávu, kontaktuje s využitím záznamu typu MX poštovní server v doméně získané
z adresy odesílatele a pokusí se provést druhou transakci pro-tokolu SMTP, jako by chtěl doručit do vzdáleného systému zprávu
na tuto adresu odesílatele. Žád-nou zprávu samozřejmě nezasílá a po přijetí nebo odmítnutí příkazu RCPT TO: transakci ukončí.
Pro takové ověření adresy odesílatele ve vzdáleném systému Exim používá prázdnou adresu odesílatele. Cílem je zjistit, jestli by
vzdálený systém akceptoval případné oznámení o stavu doručení zaslané na adresu odesílatele.
Software Postfix při ověření adresy odesílatele využívá jako adresu místního odesílatele adresu <postmaster@doména> , kde část
doména je převzata ze systémové proměnné $myorigin. Z toho důvodu je vhodné s takovou adresou odesílatele zacházet stejným
způsobem jako s prázdnou adresou (tzn. nepoužít zpoždění transakce protokolu SMTP, nepoužít greylisting, ale vyžadovat
signaturu odesílatele v adrese příjemce). Podrobnosti o této implementaci naleznete v příloze A.
Tato kontrola pro jednoznačné rozhodnutí o přijetí nebo odmítnutí příchozí zprávy rozhodně nestačí. Neplatné adresy odesílatele
obsahují v některých případech i legitimní zprávy (například automaticky generované výpisy z účtu). Nešťastným vedlejším
efektem spamu je i to, že někteří uživatelé mají snahu komolit adresu odesílatele ve své odchozí poště (to však častěji ovlivní
záhla-ví „From:“ zprávy, nikoliv skutečnou adresu odesílatele v příkazu MAIL FROM:).
Je nutné mít na paměti, že tato kontrola pouze ověří platnost adresy, nikoliv autenticitu odesíla
tele zprávy. Jako poslední poznámku je nutné uvést, že existují systémy, např. „aol.com“, které zařazují do seznamu zakázaných
položek všechny vzdálené systémy, které se snaží provést ověření adresy odesílatele. Takové systémy jsou často obětí spamu,
který obsahuje podvrženou, avšak platnou adresu odesílatele, a výsledkem je velké množství požadavků na ověření platnosti
odesílatele. Takovým způsobem je možné provádět i distribuované útoky odepření služby a vy se sami snad-no takovým
způsobem můžete stát loutkou v rukou spamerů.
Kontroly adresy příjemce
Určitě si řeknete, že taková kontrola je jednoduchá. Adresa příjemce je buď platná, a to znamená doručení zprávy, nebo neplatná
a v takovém případě dojde k jejímu odmítnutí. Zkusíme si však vše rozebrat podrobně.
Obrana proti open relay
Poštovní server by nikdy neměl doručovat zprávy ze vzdálených systémů do jiných vzdálených systémů! (Pokud ovšem není
odesílatel dostatečným způsobem autorizován.)
To zní jako samozřejmost, ale často se tato vlastnost přehlíží. Ne každý má také dokonalé znalosti všech internetových standardů,
které mají vztah k adresám elektronické pošty nebo způsobům doručování.
Pokud si nejste jisti, jestli váš agent přenosu zpráv náhodou nefunguje v režimu open relay, může-te jej zkusit otestovat s využitím
domény „relay-test.mail-abuse.org“. V příkazovém řádku napište příkaz:
telnet relay-test.mail-abuse.org
To je služba, která s využitím různých testů ověří, jestli je váš SMTP server schopen přesměrová
vat zprávy na vzdálené poštovní adresy, a vyzkouší i různé jiné způsoby přesměrování. Zabránit, aby servery nepracovaly v
režimu open relay, je extrémně důležité. Pokud server pra-cuje jako open relay a spameři jej objeví, zcela určitě se vzápětí
dostanete na různé seznamy zaká-zaných položek systému DNS. Pokud se o vás správci takových seznamů dozví (buď si server
sami otestují nebo na základě upozornění), určitě v seznamech budete uvedeni na velmi dlouhou dobu.
Kontrola adresy příjemce
Tohle zní jednoduše, ale nemusí tomu vždy tak být.
Pokud jsou poštovní účty a poštovní schránky uloženy na jediném příchozím poštovním serveru,
stačí ověřit část adresy před znakem @ a nalézt, jestli taková poštovní schránka existuje. Žádný
problém.
Existují dvě situace, kdy je ověření adresy příjemce obtížnější:
Váš server slouží jako záložní poštovní server pro doménu příjemce.
Váš server přesměrovává veškerou poštu pro vaši doménu na jiný server (předpokládejme
na server ve vnitřní síti). Alternativou ke kontrole adresy příjemce je příjem všech adres v rámci dané domény, což ovšem
znamená, že cílový server může generovat oznámení o stavu doručení pro neplatné adresy. To dále znamená, že se stanete
generátorem zavlečeného spamu.
Teď se zaměříme na to, jak ověřit adresy příjemce u výše zmíněných situací.
Ověření příjemce zpětným voláním
To je mechanismus, který používají někteří agenti přenosu zpráv, například Exim nebo Postfix pro ověření části adresy příjemce
před znakem @ (princip fungování naleznete v části Kontrola plat-nosti odesílatele zpětným voláním). V terminologii softwaru
Postfix se tato kontrola nazývá „Ově-ření adresy příjemce“ („Recipient Address Verification“).
V tomto případě se server pokusí kontaktovat cílový hostitelský systém a ověřit všechny adresy příjemců ještě předtím, než server
přijme příkaz RCPT TO: od hostitelského systému, který zprá-vu zasílá.
Takové řešení je jednoduché a elegantní. Funguje u každého agenta přenosu zpráv, který je spuš-těn na cílovém hostitelském
systému bez nutnosti přístupu do adresářových služeb. Pokud navíc takový agent přenosu zpráv provádí kontrolu adresy příjemce
s využitím fuzzy logiky (např. ser-very Lotus Domino), kontrola přesně zjistí, jestli je adresu příjemce možné akceptovat nebo ne,
což ne vždy může platit pro ostatní metody popsané dále.
Ujistěte se, že kontrola nechává netknutou původní adresu odesílatele pro případnou kontrolu zpětným voláním. V opačném
případě nemusí být odezva od cílového hostitelského systému přes-ná. V takových případech může taková kontrola například
odmítnout vracené zprávy (zprávy bez odesílatele) pro systémové uživatele nebo aliasy.
Tento mechanismus podporují kromě jiných agentů přenosu zpráv i Exim a Postfix.
Adresářové služby
Dobrým řešením je také využití adresářových služeb (tj. jednoho nebo více serverů LDAP), které může agent přenosu zpráv
dotazovat. Většina nepoužívanějších agentů přenosu zpráv podporuje protokoly LDAP, NIS nebo různé jiné backendové systémy,
které je možné použít pro poskyto-vání informací o uživatelských účtech.
Hlavním problémem při použití adresářových služeb je, že cílový hostitelský systém musí adresářovou službu využívat pro
mapování uživatelských jmen na poštovní schránky, a pokud cílový systém adresářové služby nevyužívá, je nutné provést
příslušnou konfiguraci.
Replikované seznamy poštovních schránek
Pokud pro vás ani jedna možnost není použitelná, je nutné se vrátit k „adresářové službě chudé-ho správce“, což je periodické
kopírování aktuálního seznamu poštovních schránek ze systému, kde jsou uloženy, na poštovní server. Agent přenosu zpráv pak
tento seznam využije při ověřo-vání platnosti adres příjemců v příkazu RCPT TO:.
Pokud hostitelský systém, na kterém jsou uloženy poštovní schránky, využívá nějakou verzi ope-račního systému UNIX nebo
Linux, je možné vytvořit skript, který seznam poštovních schránek vygeneruje, například z lokálního souboru /etc/passwd, a pak jej
překopíruje na poštovní server s využitím příkazu scp z balíku nástrojů OpenSSH. Následně je možné nechat takový skript automaticky spouštět v zadaných časových intervalech pomocí nástroje cron.
Obrana proti slovníkovému útoku
Slovníkový útok je termín, který popisuje takové transakce protokolu SMTP, při kterých se odesí-lající hostitelský systém snaží
pomocí řady příkazů RCPT TO: zjistit možné adresy příjemců na základě obecných jmen (obvykle podle abecedy, začíná se
jménem „aaron“, někdy slovník obsa-huje náhodná jména nebo se začíná někde uprostřed abecedy). Pokud danou adresu server
při-jme, spamer si ji přidá do svého seznamu.
Některé poštovní servery, obzvláště velkých organizací, jsou častými oběťmi takových útoků. Z pohledu spamera je
pravděpodobnost uhádnutí nějakého uživatelského jména daleko větší u velké společnosti než u malé firmy s několika uživateli.
Efektivní způsob, jak takovým útokům čelit, je používat zvětšující se zpoždění transakce po každém neúspěšném pokusu o
uhádnutí adresy. První neexistující příjemce například způsobí zpoždění 20 sekund, další způsobí zpoždění 30 sekund atd.
Akceptace jediného příjemce pro oznámení o stavu doručení
Legitimní oznámení o stavu doručení by mělo být zasíláno pouze na adresu jediného příjemce – původce původní zprávy, která
způsobila vygenerování oznámení. Připojení je možné ukončit v případě, kdy je adresa odesílatele prázdná a existuje více
příjemců.
Greylisting
Základní princip greylistingu je uveden v dokumentu Evana Harrise na adrese http://projects. puremagic.com/greylisting/.
Jak to funguje
Podobně jako u zpoždění transakcí protokolu SMTP je i greylisting jednoduchý, ale vysoce efek-tivní mechanismus pro
odfiltrování zpráv, které jsou zasílány ratwarem. Základní myšlenkou grey-listingu je kontrola, jestli mezi odesílatelem a
příjemcem zprávy existuje nějaký vztah (bráno čistě
z pohledu zasílání zpráv). Pro většinu legitimních zpráv takový vztah existuje a jejich doručení
proto probíhá normálně.Pokud zatím takový vztah neexistuje, doručení zprávy je dočasně odmítnuto (odezvou protokoluSMTP
číslo 451). Legitimní agenti přenosu zpráv se na tuto odezvu zachovají v souladu s logikoudoručování zpráv, tzn. za nějaký
časový interval se o doručení pokusí znovu.
Poznámka
Je to sice výjimečné, ale i některé „legitimní“ hromadné odesílače zpráv (např. groups.yahoo.com) dočasně odmítnutý
přenos neopakují. Evan Harris sestavil seznam tako-vých serverů, který je vhodné použít pro seznam povolených položek.
Seznam naleznete zde: http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?view=markup.
Ratware se na rozdíl od legitimního poštovního serveru pokusí o opakovaný přenos okamžitě
nebo to vzdá a zkouší další oběť ze svého seznamu adres.Pro jednoznačnou identifikaci vztahu mezi odesílatelem a příjemcem
zprávy se sbírají tři základníinformace, které se souhrnně označují jako triplet. Je to:
Odesílatel zprávy z příkazu MAIL FROM:.
Adresa protokolu IP hostitelského systému odesílatele.
Příjemce zprávy z příkazu RCPT TO:.
Při pokusu o doručení zprávy, který je dočasně odmítnut, se triplet uloží do vyrovnávací paměti. Zde zůstane dočasně uložen po
daný časový interval (obvykle 1 hodina). Po této době je přene-sen do seznamu povolených položek a další pokus o doručení již
proběhne úspěšně. Pokud se během dalšího časového intervalu (například 4 hodiny) nevyskytne další pokus o doručení, triplet je
z vyrovnávací paměti odstraněn.
Pokud se triplet, který byl součástí seznamu povolených položek, nevyskytne při doručování za dlouhý časový interval
(minimálně 1 měsíc, to stačí na pokrytí například měsíčních výpisů z účtů atd.), je definitivně odstraněn, aby seznam tripletů
nerostl donekonečna.
Hodnoty časových intervalů jsou převzaty přímo z původního dokumentu Evana Harrise. Praxí však bylo zjištěno, že časový
interval pro dočasné uložení tripletu v seznamu povolených polo-žek je vhodné zvětšit, protože někteří poskytovatelé (například
earthlink.net) opakují pokus
o doručení zprávy třeba až za 6 hodin.
Poznámka
Vetší organizace obvykle pro odchozí poštu využívají více poštovních serverů. Pro okamžité doručení může být například
použita celá skupina serverů. Pokud první pokus
o doručení selže, zpráva je předána na záložní server, který využívá delší fronty zpráv. U takových organizací selžou první
dva pokusy o doručení dané zprávy.
Greylisting pro více poštovních serverů
Pokud organizace provozuje více poštovních serverů a každý server spravuje svou databázi tripletů, pak platí:
■ První doručení zprávy od daného odesílatele jednomu z uživatelů poštovního serveru může být teoreticky zpožděno
maximálně N krát původní zpoždění (1 hodina), kde N je počet poštovních serverů. Je to díky tomu, že pokus o další
doručení zprávy může být opa-kován s využitím jiného poštovního serveru, než je ten, který vrátil kód 451 na první pokus
o doručení zprávy. Hostitelský systém odesílatele může v nejhorším případě opakovat pokusy o doručení zprávy na první
poštovní server za delší dobu, než jsou 4 hodiny, nebo až po vypršení platnosti tripletu, což způsobí, že pokus o doručení
je opakovaně odmítán,
dokud to hostitelský systém odesílatele nevzdá (obvykle po 4 dnech).
V praxi je to velmi nepravděpodobné. Pokud je pokus o doručení dočasně odmítnut, ode
sílatel se bezodkladně snaží o doručení s využitím jiného poštovního serveru ze seznamu
záznamů typu MX pro danou doménu. Díky tomu může zprávu po úvodní hodině přijmout
kterýkoliv jiný poštovní server domény.
■ V případě, že triplet byl přesunut do seznamu povolených položek na jednom poštovním serveru, další zpráva se stejným
tripletem podstoupí stejný cyklus dočasného odmítnutí a zpoždění v případě, že je doručována pomocí jiného poštovního
serveru.
Z těchto důvodů je vhodné databázi tripletů implementovat jako sdílenou pro všechny poštovní servery. Pokud však na systému s
databází dojde k nějakému výpadku, je nutné zajistit odpoví-dající akci (například povolení všech pokusů o doručení). Také je
možné využít nějaký způsob replikace a nechat server SMTP použít při vyhledávání v databázi tripletů jiný replikovaný server.
Výsledky
Z vlastní zkušenosti autora greylisting zvládne odfiltrovat cca 90 % pokusů o doručení nevyžáda-né pošty i poté, co byly
aplikovány dříve popsané kontroly transakcí protokolu SMTP. Pokud se greylisting použije jako technologie první obrany,
pravděpodobně zachytí ještě vyšší procento nevyžádané pošty.
Při použití greylistingu téměř nedochází ke vzniku falešných pozitivních detekcí. Všichni hlavní agenti přenosu zpráv provádějí
po prvním dočasném odmítnutí zprávy opakování doručení, což je chování, které v důsledku vede k úspěšnému doručení
legitimních zpráv.
Nevýhodou greylistingu je, že legitimní zpráva od odesílatele, který danému příjemci ještě žádnou zprávu v minulosti nezaslal,
bude doručena s cca hodinovým zpožděním (nebo s větším zpožděním při použití více poštovních serverů).
Schémata autorizace odesílatele
Pro ověření odesílatele byla vytvořena různá schémata, která ověřují nejen platnost adresy odesílatele, ale také autenticitu
odesílatele. Vlastník internetové domény specifikuje určitá kritéria, která musí být splněna, aby bylo zaručeno bezpečné
doručování v rámci odesílatelů v dané doméně.
Dvě uveřejněná schémata zahrnují:
MX záznamy typu MAIL-FROM, vytvořené Paulem Vixiem <[email protected]>
Záznamy typu RMX (Reverse Mail Exchange), které jsou doplněním systému DNS. Auto-rem je Hadmut Danisch
<[email protected] >
U obou schémat musí všechny zprávy od uživatele uživatel@doména.com pocházet z hostitel-ských systémů v zóně DNS domény
< doména.com>.Obě schémata se dále vyvíjela, ale kromě jiného také větvila.
Technologie Sender Policy Framework
SPF ( předtím se využíval název „ Sender permitted From“) je pravděpodobně nejznámější schéma autorizace odesílatele. Je
založeno na principech původních schémat, popsaných výše, ale umož-ňuje větší flexibilitu v kritériích, která může vytvářet a
zveřejňovat vlastník domény.
Informace SPF je zveřejněna jako záznam typu TXT v zóně DNS nejvyšší úrovně pro danou doménu. Záznam může obsahovat
následující informace:
Hostitelské systémy, ze kterých je povoleno zasílat zprávy.
Přítomnost signatury GPG (GNU Privacy Guard) v odchozích zprávách z domény.
Jiná kritéria, podrobnosti viz http://spf.pobox.com/.
Struktura záznamu typu TXT prochází neustálým vývojem, nicméně základní vlastnosti jsou již sta-noveny. Záznam začíná
řetězcem v=spfl , za kterým následují modifikátory:
a – adresa protokolu IP vlastní domény je platným odesílatelem
mx – server příchozí pošty pro doménu je také platným odesílatelem
ptr – pokud reverzní dotaz s adresou protokolu IP vede na název v rámci doménové části adresy odesílatele, je to platný
odesílatel
Každý modifikátor může mít prefix plus (+), minus (-), otazník (?) nebo tilda (~), který udává auto
ritativní zdroj, neautoritativní zdroj, neutrální zdroj a pravděpodobně neautoritativní zdroj. Každý modifikátor může být rozšířen
dvojtečkou, za kterou následuje alternativní název domény. Pokud například využíváte doménu Comcast, může zóna DNS
obsahovat například následující řetězec: -ptr:client.comcast.net ptr:comcast.net, ten udává, že odchozí zpráva nikdy nebude pocházet
z hostitelského systému, který má adresu cokoliv.client.comcast.net, ale může pocházet z hostitelských systémů s adresami
cokoliv.comcast.net.
Informace SPF je aktuálně publikována pro většinu nejznámějších internetových domén, jako jsou
například aol.com, altavista.com, dyndns.org, earthlink.net nebo google.com.Schémata autorizace odesílatele (obecně) a
technologie SPF (částečně) nejsou přijímány univer-zálně. Námitkou proti používání těchto technologií je, že vlastníci domény
mohou takovým způ-sobem vytvořit monopol na odesílání zpráv od svých uživatelů a zákazníků.
Další nevýhodou je, že technologie SPF koliduje s tradičním přeposíláním zpráv – hostitelskýsystém, který zprávu přeposílá,
nemusí mít na základě informací ze SPF v doméně odesílateleoprávnění takovou akci provést. Tento problém částečně řeší
technologie SRS (Sender RewritingScheme), při jejímž použití systém, který zprávu přesměrovává, současně upravuje adresu
odesí-latele do formátu:
uživatel=zdrojová.doména@přeposílaná.doména
Schéma Sender-ID firmy Microsoft
Technologie se podobá technologii SPF v tom, že kritéria pro akceptaci jsou uložena v záznamu typu TXT v zóně DNS domény
odesílatele. Místo využití jednoduchých klíčových slov jsou infor-mace MS CIDE uloženy v rozsáhlých strukturách ve formátu
XML. Schéma XML je zveřejněno pod licencí firmy Microsoft.
Zatímco technologie SPF je primárně používaná pro kontrolu adresy odesílatele z části MAIL FROM: dané zprávy, MS CIDE se
primárně využije pro ověření záhlaví vlastní zprávy dle definice v dokumentu RFC 2822. Takovou kontrolu je však možné
nejdříve provést až po doručení vlast-ních dat zprávy před zasláním poslední odezvy s kódem 250.
Autor se upřímně domnívá, že tato technologie je zabitá již při svém uveřejnění. Navíc je zatížená patentem a jen zvyšuje složitost
celého procesu.
přes to poslední verze softwarových nástrojů pro práci se SPF, uveřejněné na adrese http://spf.pobox.com/, umějí kontrolovat
kromě SPF i informace uvedené ve strukturách MS Caller-ID.
Schéma RMX++
Je součástí technologie SCAF (Simple Caller Authorization Framework). Schéma vytvořil Hadmut
Danisch, který je také autorem původního RMX. Technologie RMX++ umožňuje provádět dynamickou autorizaci způsobem,
který se využívá u webových serverů a protokolu HTTP. Vlastník domény zveřejní umístění autorizačního serveru v systému
DNS a hostitelský systém příjemce pak kontaktuje tento autorizační server a získá od něj autorizační záznam, kterým ověří
autenticitu odesílatele.
Toto schéma umožňuje vlastníkovi domény dokonalou kontrolu nad kritérii použitými pro auten-tizaci adresy odesílatele bez
nutnosti zveřejňovat informace o struktuře sítě (jako v případě infor-mací SPF ve statických záznamech typu TXT). Příkladem
přímo od Hadmuta je třeba autorizační server, který nepovolí odeslání více jak 5 zpráv z dané adresy mimo pracovní dobu a v
případě překročení tohoto limitu vygeneruje varování.
Technologie SCAF není omezena pouze na zprávy elektronické pošty, ale umožní provádět auten
tizaci i pro jiné služby, například VoIP. Jednou nevýhodou schématu RMX++, na kterou upozorňuje Rick Stewart
<rick.stewart@theinter netco.net >, je vliv na výpočetní a síťové zdroje. Odezvy ze serveru HTTP nebývají tak často uklá-dány
do vyrovnávacích pamětí jako informace získané přímo za systému DNS a sestavit a zaslat požadavek HTTP je daleko náročnější
než provést dotaz do systému DNS.
Rick dále upozorňuje na to, že díky dynamické povaze schématu RMX++ se případné chyby vzniklé při autentizaci špatně
vyhledávají. Pokud existuje limit 5 zpráv za den a jedinou zprávu je nutné díky chybám kontrolovat pětkrát, spotřebuje se celý
limit na doručení jediné zprávy.
Více informací o schématu RMX, RMX++ a SCAF naleznete na adrese http://www.danisch.de/ work/security/antispam.html.
Kontrola obsahu zprávy
V této kapitole naleznete informace o kontrole vlastního obsahu zprávy. Takové kontroly prová-dějí klasické antivirové a
antispamové programy, protože pracují se zprávou až po jejím přijetí. V našem případě budeme tyto kontroly provádět ještě před
zasláním ukončovacího kódu 250, takže bude možné odmítnout doručení zprávy místo toho, abychom se stali později zdrojem
zavle-čeného spamu.
V případě, že jsou poštovní servery, které zpracovávají příchozí poštu, hodně zatížené (velká orga-nizace, málo serverů), je
provádění kontrol obsahu zpráv přímo na serveru nevýhodné. Poměrně značnou část výkonu serveru si také zaberou antivirové a
antispamové programy. Výhodné řeše-ní je v takovém případě zřejmé, stačí pro tyto programy vyhradit zvláštní počítač. Většinu
serve-rových verzí antispamového a antivirového softwaru je možné spouštět ze sítě, v tomto případě z poštovního serveru. Více
informací naleznete v dalších kapitolách, kde bude podrobně popsá-na implementace systému pro různé agenty přenosu zpráv.
Kontroly záhlaví zprávy
Chybějící záhlaví
Dokument RFC 2822 udává, že zpráva by měla obsahovat minimálně tato záhlaví:
From: ...
To: ...
Subject: ...
Message-ID: ...
Date: ...
Pokud kterýkoliv řádek chybí, znamená to, že zpráva pravděpodobně nebyla vygenerovaná agentem přenosu zpráv a jedná se o
nevyžádanou poštu.
Poznámka
Někteří specializovaní agenti přenosu zpráv, například některé servery mailinglistů, nege
nerují záhlaví Message-ID: pro vrácené zprávy (oznámení o stavu doručení) automaticky.
Takové zprávy jsou jednoznačně identifikované chybějící adresou v části MAIL FROM:.
Syntaktická kontrola adres v záhlaví
Adresy, které jsou součástí záhlaví zpráv (tj. To:, Cc:, From:), by měly být syntakticky správné.
Jednoduchá kontrola adres v záhlaví
Každá adresa v záhlaví zprávy by měla splňovat následující kritéria:
Pokud je adresa lokální, obsahuje část adresy před znakem @ existující poštovní schránku?
Pokud je adresa vzdálená, existuje doména z části adresy za znakem @?
Ověření adres ze záhlaví zpětným voláním
Tato kontrola funguje stejně jako ověření adresy odesílatele nebo ověření adresy příjemce. Každá vzdálená adresa ze záhlaví je
ověřena s využitím primárního poštovního serveru (zjištěného ze záznamu typu MX) odpovídající vzdálené domény. Tím se zjistí,
jestli vzdálený poštovní server může přijímat oznámení o stavu doručení.
Úložiště signatur zpráv nevyžádané pošty
Společným znakem zpráv nevyžádané pošty je, že jsou zasílány na velké množství adres. Pokud 50 jiných příjemců zprávu
označilo jako nevyžádanou poštu, proč tento fakt nevyužít při zjišťová-ní, jestli danou zprávu přijmou nebo odmítnout? Proč
nezajít ještě dále a nevytvořit zvláštní adre-su, tzv. spamovou past, která se stane zdrojem pro úložiště signatur zpráv nevyžádané
pošty?
Jsem rád, že tyto dotazy zazněly. Jednoduchou odpovědí je, že taková úložiště již existují. Patří mezi ně například:
Razor (viz http://razor.sourceforge.net/).
Pyzor (viz http://pyzor.sourceforge.net/).
DCC (Distributed Checksum Clearinghouse, viz http://rhyolite.com/anti-spam/dcc/).
Tyto nástroje se postupně vyvinuly od nejjednodušších verzí, které na základě kontrolního součtu zprávy byly schopny zjistit, že
přijatá zpráva je identická kopie jiné zprávy již klasifikované jako nevyžádaná pošta, až k důmyslným pozdějším verzím, které
vyhodnocují společné hlavní znaky záhlaví i těla zprávy a jsou schopny odhalit a správně detekovat i drobné úpravy zpráv
nevyžádané pošty.
Kontroly na binární smetí
Zprávy, které obsahují netisknutelné znaky, se vyskytují pouze zřídka. Výskyt takové zprávy s nej-větší pravděpodobností
znamená virus nebo v některých jiných případech spam, který obsahuje text v nějakém exotickém jazyce bez odpovídajícího
kódování MIME.
Zvláštním případem jsou zprávy, které obsahují znaky NUL (ordinální hodnota tohoto znaku je 0). I v případě, kdy se rozhodnete
kontrolu netisknutelných znaků neprovádět, je vhodné ponechat alespoň kontrolu na znak NUL. Je to proto, že někteří agenti
přenosu zpráv, jako je například Cyrus Mail Suite, takové zprávy automaticky odmítnou.
Poznámka
Protokol IMAP nepovoluje přenos znaků NUL na poštovního klienta uživatelů, takže se vývojáři z firmy Cyrus rozhodli,
že nejjednodušší způsob, jak se vyrovnat se zprávami, které takové znaky obsahují, je odmítnout doručení.
Pokud tedy takový software používáte, je nutné tyto výjimky nějak ošetřit. Na druhou stranu, specifikace RFC 822 (dnes již
zastaralá) používání znaků NUL ve zprávě explicitně nezakazuje. Proto je místo odmítnutí doručení zprávy vhodné před předáním
zprávy softwaru Cyrus zajistit odstranění znaků NUL ze zprávy.
Kontroly kódování MIME
Další vhodnou kontrolou je kontrola struktury MIME v příchozích zprávách. Chyby nebo nekonzistence vzniklé při dekódování
MIME nejsou příliš časté, ale pokud vzniknou, je více než pravděpodobné, že zpráva je spam. Takové chyby mohou navíc
způsobit potenciální problémy při dalších kontrolách příloh zprávy nebo kontrolách antivirovým nebo antispamovým programem.
Krátce řečeno, pokud je kódování MIME chybné, zprávu je vhodné odmítnout.
Kontroly příloh zprávy
Kdy se naposledy stalo, že jste potřebovali od někoho poslat spořič obrazovky (soubor s přípo
nou .scr ) nebo soubor s informacemi o programu (soubor s příponou .pif)?Je velmi vhodné zvážit blokování všech zpráv, které
obsahují v příloze spustitelné soubory, tzn.soubory, jejichž název obsahuje třípísmennou příponu podobnou těm uvedeným výše.
Tato kon-trola zabere znatelně méně výpočetního výkonu než antivirový skener a může také zachytit ještěneznámé viry, pro které
antivirový program nemá příslušné informace ve své virové databázi.
Podrobný seznam přípon souborů naleznete na adrese http://support.microsoft.com/ defa-ult.aspx?scid=kb;EN-US;290497.
Antivirové programy
V současnosti jsou dostupné různé serverové antivirové programy. Mezi nejznámější patří například:
Sophie (viz http://www.vanja.com/tools/sophie/)
KAVDaemon (viz http://www.kapersky.com)
ClamAV (viz http://www.clamav.net/)
Dr.WEB (viz http://www.sald.com/)
Pokud nechcete blokovat všechny potenciálně nebezpečné soubory na základě jejich názvu (vez-měme třeba soubory .zip), jsou
takové programy velmi užitečné. Programy jsou kromě jiného schopny zachytit i viry, které nejsou přenášeny v podobě příloh
souborů (tak byl například pře-nášen virus Bagle.R v březnu 2004).
Systém, na kterém se provádí antivirová kontrola, nemusí být nutně poštovní server. Většinu těch
to antivirových programů je možné spustit i na vzdáleném systému přes síť. Antivirový software obvykle viry vyhledává na
základě signatur známých virů, tzv. virových defi-nicí. Tyto definice je nutné pravidelně aktualizovat současně s tím, jak vznikají
nové viry. Pro co možná nejpřesnější kontrolu by antivirový software měl být vždy aktualizovaný na svou poslední verzi.
Antispamové skenery
Antispamový software se používá ke klasifikaci zpráv s využitím rozsáhlé množiny heuristických kritérií, které zahrnují obsah
zprávy, dodržování standardů nebo různé síťové kontroly, například kontroly s využitím seznamů zakázaných položek systému
DNS nebo úložišť signatur zpráv nevy-žádané pošty. Na konci tohoto procesu antispamový software každou zprávu ohodnotí
složeným skórem, které udává pravděpodobnost, že zpráva je nevyžádaná pošta. Pokud toto skóre přesáh-ne jistou hranici, je
zpráva klasifikována jako nevyžádaná pošta.
Dva nejpoužívanější serverové spamové filtry jsou:
SpamAssassin (viz http://spamassassin.apache.org/)
BrightMail (viz http://www.brightmail.com/)
Tyto nástroje procházejí neustálým vývojem, protože spameři hledají způsoby, jak různé kontroly obejít. Příkladem může být
třeba „kreativní“ abeceda, která využívá podobnosti různých znaků (jeden příklad za všechny: V1/\GRA = viagra). Podobně jako
u antivirového softwaru i u antispamového softwaru platí, že je nutná pravidelná aktualizace na nejnovější verzi.
Autor využívá software SpamAssassin, nicméně tento software není nasazen v první obranné linii, čímž se šetří výpočetní výkon.
Z cca 500 zpráv nevyžádané pošty za den se zhruba 50 zpráv dosta-ne až do místa, kde je kontroluje software SpamAssassin
(hlavně díky tomu, že autor si zprávy přeposílá ještě z jiného účtu, takže výše popsané kontroly nejsou účinné). Z tohoto množství
zpráv pak v poštovní schránce autora končí zhruba jedna zpráva za 2–3 dny.
Blokování zavlečeného spamu
Zavlečený spam (collateral spam) je s využitím technik popsaných v tomto dokumentu daleko obtížněji filtrovatelný, protože
pochází z legitimních poštovních serverů, které využívají standard-ní software pro přenos zpráv (např. Postfix, Sendmail nebo
Exim). Velkou výzvou pak bývá roz-lišení těchto zpráv od legitimních oznámení o stavu doručení, které jsou generovány jako
odezva na zprávu zaslanou jedním z vlastních uživatelů.
Filtr na falešná varování před počítačovými viry
Zavlečený spam tohoto typu obvykle pochází z varování před počítačovými viry, která jsou zasílaná antivirovými programy.
Poznámka
Důvod, proč autoři antivirového softwaru důvěřují pravosti adresy odesílatele ve zprávě,
která obsahuje virus, je zřejmě námětem na podrobnější psychoanalytickou studii.
Text předmětu takových falešných varování (záhlaví Subject:) a ostatní charakteristiky těchto zpráv jsou vytvářeny přímo
antivirovým softwarem. Proto je velmi snadné sestavit seznam společných znaků takových zpráv a odfiltrovat je.
Tuto práci za vás naštěstí udělal už někdo jiný. Seznam falešných varování před počítačovými viry udržuje Tim Jackson
<[email protected]>. Seznam je možné použít v softwaru SpamAssassin a je k dispozici na adrese http://www.timj.co.uk/linux/
bogus-virus-warnings.cf.
Uveřejnění informací SPF pro doménu
Účelem záznamů SPF (Sender Policy Framework) je chránit před nevyžádanou poštou, která fal
šuje adresu odesílatele, a tudíž před zneužitím legitimních adres elektronické pošty. Pokud uveřejníte záznamy SPF v zóně DNS
vaší domény, hostitelské systémy příjemce zprávy, které provádějí kontroly s využitím SPF, by neměly akceptovat zprávy s
podvrženými adresami odesílatele. Stejně tak by tyto systémy neměly pro takové nedoručitelné zprávy zasílat oznámení
o stavu doručení zpět do vaší domény.
Signatura odesílatele zprávy
Poněkud odlišný způsob, se kterým autor v současnosti experimentuje, využívá přidání signatury odesílatele do adresy uvedené v
části MAIL FROM: a následnou kontrolu této signatury v adrese RCPT TO: před přijetím příchozího oznámení o stavu doručení.
Vygenerovaná adresa odesílatele může mít například následující formát:
odesílatel=signatura@doména
Normální odpovědi na zprávy jsou zpracovány beze změny. Odpovědi se zasílají na adresu ze
záhlaví From: nebo Reply-To:, která jsou přenášena beze změny.Zní to snadno, že? Naneštěstí je vygenerování signatury, která je
pro tyto účely vhodná, poněkudsložitější, než to může na první pohled vypadat. Existují některé protichůdné požadavky, se kterými je nutné počítat.
■ Vygenerovaná signatura adresy odesílatele by měla být v rukou spamera bezcenná. To zna-mená, že součástí signatury by
mělo být časové razítko, u kterého je možné kontrolovat platnost:
odesílatel=časové_razítko=kontrolní součet@doména
■
Při zasílání zprávy do domény, která využívá greylisting, je nutné, aby adresa odesílatele zůstávala pro daného příjemce
konstantní. V opačném případě bude zpráva neustále odmí-tána. Pokud budeme počítat i s tímhle, je možné vygenerovat
signaturu pro odesílatele v závislosti na adrese příjemce:
odesílatel=příjemce=doména.příjemce=kontrolní_součet@doména
Taková adresa nemá omezenou časovou platnost, a pokud z ní začne chodit nevyžádaná pošta, bude určitě známý zdroj –
je obsažen v adrese příjemce. Kromě toho je možné sig-natury specifických adres příjemců snadno blokovat bez vlivu na
doručování jiných zpráv stejnému příjemci.
■ Při využívání mailinglistů je možné narazit na dva problémy. Odpovědi na zprávy s poža-davkem na zařazení nebo
vyřazení z mailinglistu jsou obvykle zasílány bez adresy odesí-latele.
◆ První problém se týká serverů, které zasílají odezvu zpět na adresu odesílatele ze zprá-vy s požadavkem na zařazení
nebo vyřazení (jako v případě <[email protected]>). Problém je, že příkazy pro server, který zajišťuje mailinglist
(např. subscribe nebo unsubscribe) jsou obvykle zasílány na jiné adresy (např. <discuss-sub [email protected]> a
<[email protected]>), než je adresa pou-žitá pro vlastní mailinglist. V tomto případě se tedy bude adresa
uživatele, který žádá
o zařazení, lišit od adresy odesílatele ve zprávách zaslaných serveru mailinglistu a bude se lišit i od adres, které budou
vygenerovány u požadavků na vyřazení z mailinglistu. Výsledkem může být situace, kdy není možné do mailinglistu
zasílat příspěvky nebo požádat o vyřazení. Vhodným kompromisem je v tomto případě zařadit do signatury
odesílatele pouze doménu příjemce. Adresa odesílatele pak může vypadat například takto:
název_přispěvatele=en.tldp.org=kontrolní_součet@doména.přispěvatele
◆ Druhý problém se týká těch uživatelů, kteří zasílají odpovědi přímo na adresu pro odpovědi zjištěnou ze záhlaví
zprávy s požadavkem (jako např. <spam-l-re [email protected]>). Protože tato adresa neobsahuje signaturu,
odpověď od serveru s mailinglistem může být na vašem serveru blokovaná. Tento problém se dá řešit pouze tak, že se
servery s mailinglistem umístí do seznamu povolených položek tak, aby bylo umožněno vracení zpráv na adresy
příjemců i bez signatury.
V souvislosti se zmíněnými problémy začíná tato technologie ztrácet dech. Dalším problémem je, že v případě, kdy původní
zpráva nebyla zaslána přes váš poštovní server, jsou legitimní ozná-mení o stavu doručení odmítána. Výše uvedená opatření je
proto vhodné provádět pouze pro ty uživatele, kteří nezasílají zprávy s využitím poštovních serverů mimo vaši síť.
V situaci, kdy není možné využít žádnou z výše uvedených technik, umožní signatury nejen eli-minovat zavlečený spam, ale také
poučit vlastníky poštovních serverů, kteří (předpokládejme nezaviněně) takový spam generují. Pozitivním vedlejším efektem je,
že poštovní servery, které využívají ověření adresy odesílatele zpětným voláním, obdrží pozitivní odpověď na ověření pouze v
případě, kdy byla původní zpráva zaslána vaším poštovním serverem. Klíčové však je, že pou-žitím těchto metod se spamerům
snižuje možnost podvržení a zfalšování adres odesílatele.
Uživatelům je určitě vhodné umožnit, aby se sami rozhodli, jestli chtějí jako součást odesílané pošty signatury uvádět, a pokud se
rozhodnou pro používání signatur, pak určit, které hostitelské systémy mají mít umožněno vracet zprávy bez signatury adresy.
Pokud mají uživatelé vytvořený systémový účet přímo na poštovním serveru, je to například možné zajistit tak, že si uživatel
vytvoří vlastní „konfigurační“ soubor přímo ve své domovské složce.
Příjem vrácených zpráv pouze pro existující uživatele
I v případě, kdy se provádí kontrola signatur adres odesílatele, existuje slabé místo, díky kterému může být umožněn příjem
falešných odpovědí na zprávy. Jedná se o kontrolu zpráv, které jsou zaslané na nějaké systémové aliasy (např. postmaster nebo
mailer-daemon). Platí však, že pokud takoví uživatelé nezasílají žádné zprávy, neměli by dostávat žádné odpovědi.
Zprávy je tedy možné odmítnout v případě, kdy jsou zaslané na některý ze systémových aliasů nebo pokud pro danou adresu
příjemce neexistuje příslušná poštovní schránka.
Další témata k zamyšlení
V souvislosti s filtrováním zpráv v rozsáhlých systémech, při kterém se využívá časových interva-lů, je nutné vzít v úvahu
následující fakta.
Více poštovních serverů příchozí pošty
Většina domén obsahuje více poštovních serverů příchozí pošty (v systému DNS využívají více záznamů typu MX). Pokud je na
primárním poštovním serveru použito filtrování, které využívá časové intervaly, je nutné toto filtrování použít i u ostatních
záložních poštovních serverů. Pokud by tomu tak nebylo, hostitelský systém, který odesílá zprávy, by mohl filtrování jednoduše
obejít tak, že zprávy zašle na záložní poštovní server(y).
Pokud nejsou záložní servery ve vaší správě (například se využívá serverů poskytovatele připoje-ní), je vhodné zvážit, jestli je
vůbec nutné uvádět v informacích o doméně v systému DNS více záznamů typu MX. Pokud celý poštovní systém funguje tak, že
záložní poštovní servery pouze automaticky přeposílají všechny došlé zprávy na primární poštovní server, je možné ostatní záznamy typu MX v informacích o doméně odstranit. Pokud dojde k výpadku primárního poštovní-ho serveru, nic se nestane,
protože hostitelské systémy odesílatelů zpráv se pokoušejí o zaslání
nedoručených zpráv dalších několik dní. Jediná situace, za které je vhodné mít několik poštovních serverů, je stav, kdy je nutné
provádět vyvažování výkonu mezi více servery, tzn. že doména přijímá více zpráv, než je schopen jeden poštovní server obsloužit.
V takovém případě je vhodné výpočetně náročné úlohy (antivirová a antispamová kontrola) přesunout na jiné servery, což může v
důsledku znamenat, že pro příjem pošty bude stačit pouze jediný server.
Pokud se přeci jen rozhodnete využívat více poštovních serverů, je nutné, aby všechny záložní servery byly, co se filtrování zpráv
týče, nakonfigurovány stejně jako primární server. Více informací o používání více poštovních serverů naleznete v kapitole
Greylisting.
Blokování přístupu na jiné servery SMTP
Žádný server SMTP, který není uvedený v záznamech typu MX pro doménu v systému DNS, by neměl akceptovat příchozí
připojení z Internetu. Veškerý příchozí poštovní provoz by měl jít pouze přes vyhrazený poštovní server.
Toto pravidlo neplatí pouze pro server SMTP. Pokud v síti využíváte servery, které slouží pro inter-ní potřebu, omezte přístup k
takovým serverům z Internetu pomocí firewallu.
Přeposílané poštovní zprávy
Konfiguraci filtrování je nutné nastavit tak, aby nedocházelo k odmítání takových zpráv, které jsou přeposílány z takových
důvěryhodných zdrojů, jako jsou například:
záložní poštovní servery. Pokud využíváte záložní server, dá se samozřejmě předpokládat, že většina nevyžádané pošty
je již odfiltrovaná.
servery s mailinglisty, které odebírají vaši uživatelé. Takové zprávy je samozřejmě možné filtrovat (a určitě je to lepší
přístup, než by zprávy měly skončit v černé díře). Pokud však dojde k odmítání takových zpráv, může to vést až k automatickému
vyřazení daného uži-vatele z mailinglistu.
■ ostatní účty uživatelů vaší domény. Odmítání takových zpráv může generovat zavlečený spam anebo způsobit problémy
hostitelskému systému, který zprávy přeposílá.
U dvou posledních uvedených zdrojů vzniká logistický problém. Tyto zdroje jsou specifické pro každého příjemce ve vaší
doméně. Jak zařídit, aby si každý uživatel mohl vytvořit svůj seznam povolených položek, a jak zajistit, aby se obsah jednotlivých
seznamů promítl v celkové konfigu-raci filtrování SMTP například pro celou doménu? Pokud je zpráva přeposílána více
příjemcům ve vaší doméně (to může být například případ mailinglistu), jak rozhodnout, čí seznam povolených položek použít?
V tomto případě neexistuje univerzální řešení a je nutné vše řešit individuálně. Můžete se napří-klad rozhodnout pro příjem všech
zpráv bez ohledu na jejich spamovou klasifikaci v případě, kdy jsou zaslány z hostitelského systému, který figuruje alespoň v
jednom ze všech seznamů povole-ných položek libovolného uživatele. Odezvu na jednotlivé příkazy RCPT TO: je možné
vytvářet na základě kontroly odpovídajícího hostitelského systému odesílatele s pomocí seznamu povole-ných položek
příslušného uživatele. Pokud je hostitelský systém v seznamu nalezen, je možné nastavit příznak, který zabrání odmítnutí zprávy
při dalších kontrolách. V takových případech je také vhodné používat výsledný seznam jako sjednocení všech seznamů
povolených položek jed-notlivých uživatelů.
Podrobnosti naleznete v popisu konkrétní implementace filtrování v dodatcích.
Uživatelská nastavení a data
Existují situace, kdy je nutné uchovávat nastavení a data pro každého uživatele domény zvlášť. Pokud například využíváte pro
filtrování příchozí pošty software SpamAssassin, můžete pro jed-notlivé uživatele umožnit nastavení vlastních prahových hodnot
pro klasifikaci spamu, povolené jazykové a znakové sady nebo testovací data pro Bayesův filtr.
Stěžejním bodem je, že filtrování protokolu SMTP s využitím časových intervalů se provádí na systémové úrovni ještě předtím,
než jsou zprávy doručeny jednotlivým uživatelům, což do jisté míry neumožní používat individuální nastavení pro jednotlivé
uživatele. Jediná zpráva může mít více příjemců a na rozdíl od přeposílané zprávy není v tomto případě vhodné použít sjednocené
nastavení ode všech uživatelů – adresátů zmíněné zprávy. Vezměme například v úvahu situaci, kdy jednotliví příjemci zprávy jsou
z různých zemí a hovoří různými jazyky.
Výjimkou je samozřejmě případ, kdy se počet příjemců zprávy v příchozích zprávách omezí na hodnotu 1. Zprávu je za této
podmínky možné analyzovat a kontrolovat na základě individuálních nastavení příslušného uživatele.
To se zajistí akceptováním prvního příkazu RCPT TO: a následným zasláním odezvy s kódem 451. Pokud je odesílatelem zprávy
legitimní poštovní server, ví, jak tuto odezvu vyhodnotit, a pokusí se o další doručení později.
Samozřejmě existuje i jiný způsob, který využije zpoždění, takže u všech zpráv s vícenásobným příjemcem zpozdí doručení
například o 30 minut na jednoho příjemce. V prostředí velké organi-zace však tento způsob nemusí být nejvhodnější, protože v
takovém prostředí probíhají diskuse s využitím poštovních zpráv takřka v reálném čase a zpoždění zpráv by mohlo mít negativní
dopa-dy např. na plánování nebo při řešení nějakých akutních situací.
Dalším problémem, který se opět týká v hlavní míře prostředí velké organizace, je, že příchozí zprávy jsou pro doručení obvykle
dále předávány na interní servery a jednotliví uživatelé na poš-tovním serveru ani nemají vytvořené své uživatelské účty.
Individuální nastavení pro jednotlivé uživatele se dá použít i v takovém prostředí, ale vyžaduje to dodatečné úsilí např. s využitím
vyhle-dávání v databázi nebo v adresáři LDAP a je na zvážení každého, jestli takové řešení implemen-tovat.
Otázky a odpovědi
V této kapitole je uvedeno shrnutí některých otázek, které při čtení dokumentu čtenáře určitě napadnou. Pokud máte dotaz, který
zde není uveden, a rádi byste v této kapitole viděli odpověď, prosím, napište na adresu <[email protected]> .
Když se spameři přizpůsobí
Otázka: Co se stane, když se spameři přizpůsobí a obejdou jednotlivé způsoby filtrování, popsa-né v tomto dokumentu?
Odpověď: Hm, to záleží na konkrétní situaci. Některé popsané způsoby filtrování (například kontroly protokolu SMTP nebo
greylisting) jsou zaměřeny na specifické chování ratwaru. Dá se předpokládat, že chování ratwaru se určitě změní v případě, kdy
bude uvedené kontroly provádět dostatečné množství poštovních serverů. Hatmut Danish uvádí: „Ratware obsahuje neúplnou
implementaci protokolu SMTP proto, že vývojáře rat-waru nic nenutí k tomu, aby implementaci zdokonalili. Pokud daná
implementace funguje, proč ztrácet čas jejím zdokonalováním? Kvalita ratwaru se však postupem doby zvyšuje a stejně tak se
zvyšuje i kvalita spamových zpráv. Pokud začne dostatečný počet lidí odmítat spam tak, že budou kontrolovat implementaci
protokolu SMTP, autoři spamového softwaru prostě svůj software vylepší.“
Autoři ratwaru budou muset řešit následující problémy:
■
Pro překonání zpoždění transakcí protokolu SMTP budou muset čekat na každou odezvu od serveru SMTP, ke
kterému se ratware připojuje. V tomto případě je pak dosaženo pod-statného snížení zpráv, které je hostitelský systém spamera
schopen v daném čase odeslat. Protože spameři zápasí s časem a snaží se doručit maximum zpráv ještě předtím, než jsou
odfiltrovány s využitím seznamů zakázaných položek systému DNS nebo filtrů obsahu zpráv, bude nutné zdokonalit efektivitu
nástrojů, které zpoždění transakcí provádějí.
Efekt je podobný cílům, které mají tzv. schémata mikroplateb, kdy odesílatel stráví něko-lik sekund výpočtem signatury
pro každého příjemce zprávy a tuto signaturu přidá do záhlaví zprávy tak, aby ji mohl příjemce ověřit. Pokud pomineme složitost
takových sché-mat, je hlavním rozdílem to, že vyžadují participaci pokud možno všech uživatelů na světě. Efektivní filtrování
nevyžádané pošty je pak zaručeno pouze při účasti co největšího počtu uživatelů. Zpoždění transakcí protokolu SMTP je na
druhou stranu efektivní už u prvního hostitelského systému, který je implementuje.
Pro překonání kontroly příkazu HELO/EHLO musí ratware dodat korektní informace, tzn. musí se identifikovat úplným
názvem domény. To umožní lepší sledování trasy zpráv zvláš-tě u takových agentů přenosu zpráv, kteří neprovádějí automatické
vkládání výsledku reverzního dotazu do systému DNS do záhlaví Received: přenášené zprávy.
Pro překonání všech kontrol protokolu SMTP musí ratware doplňovat vlastní platnou adresu odesílatele (nebo alespoň
platnou adresu odesílatele v rámci své domény).
Pro překonání greylistingu se budou muset pokoušet o opakování přenosu dočasně odmít-nutých zpráv v limitu 1
hodina (ale ne za déle než 4 hodiny). Aby se minimalizovaly vyu-žité prostředky, bude si ratware zřejmě uchovávat místo kopie
každé odmítnuté zprávy pouze seznam dočasně odmítnutých příjemců a za daný časový interval se pokusí o nové hromadné
dor učení.
Greylisting zůstane i v budoucnu účinný hlavně ve spojení se seznamy zakázaných polo-žek systému DNS, které jsou
naplňované ze spamových pastí. Je to dáno tím, že hodino-vé zpoždění po odmítnutí zprávy umožní aktualizaci seznamu
o hostitelský systém, který spam zasílá.
Všechny softwarové nástroje, antivirové i antispamové, se neustále vyvíjejí. Jejich efektivní použí
vání je zaručeno pouze v případě, kdy používáte nejnovější, aktualizované verze.Stejně tak se bude vyvíjet i tento dokument.
Spolu s tím, jak se změní povaha nevyžádané pošty,se bude měnit i přístup lidí při hledání způsobů, jak nevyžádanou poštu
blokovat.
Implementace s využitím softwaru Exim
V následujících kapitolách naleznete implementaci technik blokování spamu, které jsou popsány v tomto dokumentu, s využitím
agenta přenosu zpráv Exim.
Co budete potřebovat
Pro všechny uvedené příklady budete potřebovat agenta přenosu zpráv Exim, pokud možno s doplňkem Exiscan-ACL od Toma
Kistnera. Předpřipravené balíčky, které obsahují Exim i Exis-can-ACL, existují pro většinu současných distribucí Linuxu a také
pro FreeBSD. Podrobnosti nalez-nete na webových stránkách Exiscan-ACL (viz http://duncanthrax.net/exiscan-acl/).
Poznámka
Software Exim je oblíbený zejména mezi uživateli distribuce Debian GNU/Linux (viz http://www.debian.org/), protože je
to výchozí agent přenosu zpráv této distribuce. Pokud používáte Debian (verzi Sarge nebo novější), můžete získat Exim a
Exiscan-ACL instalací balíčku exim4-daemon-heavy:
# apt-get install exim4-daemon-heavy
Příklad implementace uvedený v této kapitole ještě navíc obsahuje:
SpamAssassin (viz http://spamassassin.apache.org/) – oblíbený nástroj na filtrování spamu, který analyzuje obsah
zpráv s využitím rozsáhlé množiny heuristických metod.
greylistd (viz http://packages.debian.org/unstable/mail/greylistd) – jednoduché řešení pro greylisting, které bylo
vytvořeno uživateli s ohledem na software Exim.
V následujících příkladech se využívá ještě další software.
Konfigurační soubor Exim
Konfigurační soubor Eximu obsahuje na začátku globální definice (této části konfiguračního sou-boru budeme říkat hlavní sekce),
které jsou následovány dalšími sekcemi.
Poznámka
Při použití balíčku exim4-config mají uživatelé distribuce Debian možnost rozdělit konfi-guraci Eximu do více malých
částí, které jsou uloženy v jednotlivých podsložkách (např. /etc/exim4/conf.d), nebo nechat konfiguraci uloženou v jediném
souboru.
Při výběru první možnosti (je doporučována) je možné jednotlivé části upravené konfigu-race oddělit od výchozí
konfigurace, která je součástí balíčku exim4-config, vytvořením nových souborů v příslušných podsložkách. V tomto
případě není nutné upravovat již exi-stující soubory. Například je možné vytvořit soubor s názvem /etc/exim4/conf.d/acl/
80_local-config_rcpt_to, kterým se definuje vlastní seznam řízení přístupu pro příkaz RCPT TO: (viz níže).
Každá sekce začíná textem:
begin název_sekce
Nejvíce konfiguračních úprav se bude provádět v části acl (tzn. za textem begin acl), ale budeme také upravovat položky v sekcích
transports a routers a také hlavní sekci na začátku souboru.
Seznamy řízení přístupu ACL (Access Control List)
Exim od verze 4.XX obsahuje pravděpodobně nejsofistikovanější a nejflexibilnější mechanismus pro filtrování transakcí
protokolu SMTP s využitím časových intervalů, při kterém se využívá seznamů řízení přístupu.
Seznamy řízení přístupu je možné použít pro vyhodnocení přijetí nebo odmítnutí příchozí trans-akce protokolu SMTP přímo v
jednotlivých fázích, např. již od počátečního připojení vzdáleného hostitelského systému přes příkazy HELO/EHLO, MAIL
FROM: nebo RCPT TO:. V konfiguraci je například možné vytvořit seznam acl_rcpt_to, s pomocí kterého se bude provádět
kontrola pří-kazu RCPT TO: od vzdáleného hostitelského systému.
Každý seznam řízení přístupu sestává z posloupnosti příkazů neboli pravidel. Každý příkaz začí-ná popisem akce, to může být
např. accept, warn, require , defer nebo deny, následovaným seznamem podmínek nebo dalších nastavení přináležících k příkazu.
Jednotlivé příkazy jsou vyhodnocovány jeden po druhém, dokud nedojde k provedení konkrétní akce (výjimkou je pří-kaz warn).
Na konci každého seznamu řízení přístupu je implicitně vložena akce deny.
Jednoduchý příkaz v seznamu acl_rcpt_to může vypadat například takto: deny
message = přeposílání není povoleno
!hosts = +relay_from_hosts
!domains = +local_domains : +relay_to_domains
delay = 1m
Pomocí této sekvence bude příkaz RCPT TO: (a tím i doručení zprávy) odmítnut v případě, kdy zpráva není doručována jedním z
hostitelských systémů ze seznamu „+relay_from_hosts“, a pokud doména příjemce zprávy není ze seznamu „+local_domains“
nebo „+relay_to_domains.“ Před zasláním odezvy protokolu SMTP s kódem 550 bude server čekat 1 minutu.
Aby bylo možné provést vyhodnocení daného seznamu řízení přístupu v dané fázi transakce pro-tokolu SMTP, je nutné s daným
seznamem svázat jednu ze zásad řízení (policy control). Aby bylo například možné provést vyhodnocení seznamu acl_rcpt_to při
zpracování příkazu RCPT TO: , je nutné v hlavní sekci konfiguračního souboru softwaru Exim (před kterýmkoliv klíčovým slo-vem
begin ) uvést:
acl_smtp_rcpt = acl_rcpt_to
Úplný seznam zásad řízení naleznete v kapitole 14 – specifikace softwaru Exim.
Rozšíření
Kromě základních seznamů řízení přístupu jsou k dispozici různá rozšíření, která zahrnují pro-měnné vyhodnocované při běhu
programu, funkce pro vyhledávání, operace s řetězci nebo regu-lárními výrazy, seznamy hostitelských systémů nebo domén atd.
Podrobný popis pro konkrétní verzi x.x0 (tzn. 4.20, 4.30) je možné najít v souboru spec.txt. Seznamy řízení přístupu nalezne-te v
kapitole 38.
Software Exim poskytuje 20 proměnných, které je možné použít pro všeobecné účely a do kte-rých je možné přiřazovat hodnoty
v příkazech ze seznamů řízení přístupu:
$acl_c0 -$acl_c9 uchovají hodnoty, které jsou perzistentní v rámci celého připojení SMTP.
$acl_m0 / $acl_m9 uchovají hodnoty při příjmu zprávy, pak jsou ale resetovány. Jsou také resetovány po provedení
příkazů HELO, EHLO, MAIL a RSET.
Možnosti a nastavení
Hlavní sekce konfiguračního souboru Exim (před prvním klíčovým slovem begin) obsahuje různá makra, zásady řízení a jiná
obecná nastavení. Zkusme definovat několik maker, která budou pou-žita později.
# Definice omezení velikosti zprávy. Tuto hodnotu využijeme v seznamu
# řízení přístupu DATA.
MESSAGE_SIZE_LIMIT = 10M
# Maximální velikost zprávy, pro kterou bude spuštěna antivirová nebo
# antispamová kontrola.
# Toto nastavení umožní snížit zatížení při zpracování velmi velkých zpráv.
MESSAGE_SIZE_SPAM_MAX = 1M
# Makro, které definuje klíč použitý při generování různých
# kontrolních součtů nebo hašovacích hodnot.
# TOTO NASTAVENÍ PROSÍM ZMĚŇTE!
SECRET = tajný-klíč
Zkusme objasnit některá obecná nastavení softwaru Exim:
# Selhání služby DNS (SERVFAIL) bude považováno za chybu při vyhledání.
# Díky tomu bude možné později odmítnout adresy odesílatele
# v neexistující doméně nebo v doméně, pro kterou neexistuje server
# služby DNS.
dns_again_means_nonexist = !+local_domains : !+relay_to_domains
# Aktivace kontroly příkazu HELO pro všechny hostitelské systémy
helo_try_verify_hosts = *
# Zrušení omezení maximálního počtu příchozích připojení, která je
# možné obsloužit najednou. Nastavení se provádí proto, aby bylo
# možné obsluhovat další nová příchozí připojení i při použití zpoždění
# transakcí protokolu SMTP
smtp_accept_max = 0
# ..až dokud není zatížení systému rovno hodnotě 10
smtp_load_reserve = 10
# Zákaz zveřejnění vlastnosti protokolu ESMTP “PIPELINING” všem
# hostitelským systémům.
# Nastavení se provádí kvůli ratwaru, který se snaží řetězit příkazy.
pipelining_advertise_hosts = :
Nakonec je nutné definovat vybrané zásady řízení pro 5 seznamů řízení přístupu, pomocí kterých bude možné kontrolovat
všechny hlavní fáze příchozí transakce protokolu SMTP:
acl_smtp_connect = acl_connect acl_smtp_helo = acl_helo acl_smtp_mail
= acl_mail_from acl_smtp_rcpt = acl_rcpt_to acl_smtp_data = acl_data
Tvorba seznamů řízení přístupu – první verze
V sekci acl (následuje bezprostředně za příkazem begin acl) je nutné definovat příslušné sezna-my řízení přístupu. Při vytváření
seznamů budou využity některé metody, popsané v předchozích kapitolách tohoto dokumentu, včetně kontrol systému DNS a
kontrol protokolu SMTP. V této verzi se většina kontrol provede v seznamu acl_rcpt_to a ostatní seznamy zůstanou prázdné. Je to
díky tomu, že ratware obvykle neumí vyhodnotit odmítnutí zprávy v dřívějších fázích transakce protokolu SMTP. Většina klientů
ratwaru vzdá doručení zprávy až v případě, kdy dojde k odmít-nutí po zpracování příkazu RCPT TO:.
Nejprve všechny seznamy vytvoříme, použijeme je později.
Seznam acl_connect
# Tento seznam se použije na začátku transakce při příjmu příchozího # připojení. Kontroly se provádí pro zjištění, jestli příchozí
připojení # přijmout nebo odmítnout.
acl_connect: # V této fázi nebudeme provádět žádné kontroly. accept
Seznam acl_helo
# Tento seznam se použije pro kontrolu příkazu HELO nebo EHLO # v příchozí transakci protokolu SMTP. Kontroly se provádí pro zjištění, #
jestli transakci při zpracování příkazu HELO nebo EHLO přijmout nebo # odmítnout.
acl_helo: # V této fázi nebudeme provádět žádné kontroly. accept
Seznam acl_mail_from
# Tento seznam se použije pro kontrolu příkazu MAIL FROM:
# v příchozí transakci protokolu SMTP. Kontroly se provádí pro zjištění,
# jestli transakci po kontrole adresy odesílatele přijmout nebo odmítnout.
acl_mail_from: # Přijmout příkaz. accept
Seznam acl_rcpt_to
# Tento seznam se použije pro kontrolu příkazu RCPT TO:
# v příchozí transakci protokolu SMTP. Kontroly se provádí pro zjištění,
# jestli transakci po kontrole adresy příjemce přijmout nebo odmítnout.
acl_rcpt_to:
# Akceptuje zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontroly se provádí pro prázdnou adresu odesílatele.# Akceptuje
zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.# Ověření příjemce se v tomto případě neprovádí,
protože klienty# jsou v mnoha případech hloupé klientské programy, které neumí# dobře obsloužit chybové kódy protokolu SMTP.accept
hosts = : +relay_from_hosts
# Akceptuje zprávy, které byly zaslány s využitím autentizovaného # připojení z libovolného hostitelského systému. Tyto zprávy obvykle #
pocházejí od hloupých klientských programů, takže je ověření # příjemce vypuštěno. accept
authenticated = *
###################################################################### # Kontroly s využitím systému DNS
###################################################################### # # Výsledky těchto kontrol jsou uloženy ve
vyrovnávací paměti, takže # u vícenásobných příjemců se tato kontrola neprovádí víckrát. # # Pokud se daný hostitelský systém vyskytuje v
některém ze seznamů # zakázaných položek systému DNS, je zpráva odmítnuta. # Opatrně při výběru těchto seznamů, mnoho z nich způsobuje
# falešné pozitivní detekce a správci seznamů někdy nemají jasné zásady # pro odstranění položek ze seznamu.
#
deny
dnslists
= dnsbl.sorbs.net : \
dnsbl.njabl.org : \
cbl.abuseat.org : \
bl.spamcop.net
= $sender_host_address je uvedena v $dnslist_domain\
${if def:dnslist_text { ($dnslist_text)}}
message
# Pokud reverzn_ vyhled疣_ hostitelsk馼o syst駑u odes匀atele selže # (tj. v syst駑u DNS
neexistuje reverzn_ z痙nam nebo se vsledn FF 81 n痙ev # neshoduje s původn_ adresou IP), je zpr
疱a odm咜nuta. # deny
message = Reverzn_ vyhled疣_ DNS selhalo pro $sender_host_address. !verify =
reverse_host_lookup
###################################################################### #
Kontroly př勛azů Hello
######################################################################
# Pokud vzd疝en FF 81 syst駑 uvede adresu IP, je zpr疱a odm咜nuta. # deny
message = Zpr疱a byla doručena ratwarem log_message = vzd疝en FF 81 hostitel použil v př勛azu
HELO/EHLO adresu IP condition = ${if isip {$sender_helo_name}{true}{false}}
# Podobn_ kontrola v př厓adě, kdy vzd疝en FF 81 syst駑 použije ｨ# někter FF 81 z n痙vů naš_ dom駭y.#
deny
message = Zpr疱a byla doručena ratwarem log_message = vzd疝en FF 81 hostitel použil v př勛azu
HELO/EHLO adresu IP condition = ${if match_domain{$sender_helo_name}\
{$primary_hostname:+local_domains:+relay_to_domains}\ {true}{false}}
deny message = Zpr疱a byla doručena ratwarem log_message = vzd疝en FF 81 hostitel nepoužil př勛
az HELO/EHLO condition = ${if def:sender_helo_name {false}{true}}
# Pokud kontrola př勛azu HELO selže, do těla zpr疱y se přid_ z疉lav_ # X-HELO-Warning:. #
log_message = vzd疝en FF 81 hostitel použil neověřiteln FF 81 př勛az HELO/EHLO !verify = helo
#
warn
message
= X-HELO-Warning: Vzdálený hostitel
$sender_host_address \
${if def:sender_host_name
{($sender_host_name) }}\
použil neověřitelný název $sender_helo_name
###################################################################### #
Kontroly adresy odes匀atele
######################################################################
# Pokud nen_ možn_ ověřit adresu odes匀atele, je zpr疱a odm咜nuta. # # Použit_ možnosti
„callout“ je na zvž疇n_ každ馼o. Obecně plat_, # že pokud je odchoz_ zpr疱a zas匀疣a s využit
匇 vyhrazen馼o syst駑u # (tzv. smarthost), ověřen_ ned_ ž疆nou užitečnou informaci. # #
Podrobnosti o chybn駑 pokusu o ověřen_ zpětnm vol疣匇 jsou # souč疽t_ odezvy s k E5 28em 550;
pokud je nutn_ podrobnosti vynechat, # stač_ změnit “sender/callout” na “sender/
callout,no_details”. # deny
message = <$sender_address> zřejmě nen_ platn_ \ adresa odes匀atele. !verify =
sender/callout
###################################################################### #
Kontroly adresy př勀emce
###################################################################### # Odm咜
nut_ zpr疱y se provede, pokud jm駭o v adrese obsahuje znaky @ # nebo % nebo / nebo | nebo !.
Tyto znaky se ve jm駭ě vyskytuj_ velmi # zř冝ka, ale občas je zkouš_ použ咜 uživatel_, kteř_ se
snaž_ # obej咜 omezen_ při přepos匀疣_ zpr疱. # # Odm咜nut_ zpr疱y se provede i v př厓adě,
kdy jm駭o zač匤_ tečkou. # Pr痙dn_ č疽ti adresy nejsou podle striktn劜o vkladu dokumentu #
RFC 2822 povoleny, ale Exim je umožňuje využ咜, protože se obvykle # norm疝ně použ咩aj_.
Pokud adresa zač匤_ tečkou, může to způsobit # probl駑 v př厓adě, kdy se jm駭o použ咩_ jako
n痙ev souboru (např勛lad # pro mailinglist). # deny
local_parts = ^.*[@%!/|] : ^\\.
# Ukončen_ připojen_ se provede v př厓adě, kdy je adresa odes匀atele # pr痙dn_, ale zpr疱a m_
v兤e adres př勀emců. Legitimn_ ozn疥en_ # o stavu doručen_ nen_ nikdy zasl疣o na v兤e
adres. # drop
message = Legitimn_ ozn疥en_ o stavu doručen_ nejsou zas匀疣a\
v兤e př勀emcům. senders = : postmaster@* condition = $recipients_count
# Odm咜nut_ adresy př勀emce se provede v př厓adě, kdy př勀emce je# z jin_ dom駭y, než
pro kterou se pošta zpracov疱_.#deny
message = Nepovolen FF 81 relaying!domains = +local_domains : +relay_to_domains
# Odm咜nut_ adresy př勀emce se provede v př厓adě, kdy adresa # nekoresponduje s existuj兤
_ poštovn_ schr疣kou. # Pokud poštovn_ schr疣ka nen_ uložena v aktu疝n匇 syst駑u (tj.
pokud # je aktu疝n_ syst駑 pro naši dom駭u z疝ožn_), provede se ověřen_ zpětnm # vol疣匇.
Pokud c匀ov FF 81 server neodpov冝_, adresa př勀emce se i # přesto přijme. # deny
message = nezn疥 FF 81 uživatel!verify = recipient/callout=20s,defer_ok
# V ostatn兤h př厓adech je adresa př勀emce OK.
#
accept
Seznam acl_data
# Tento seznam řízení přístupu se používá pro kontrolu obsahu zprávy # přijaté protokolem SMTP. Kontroly se provádějí postupně # za
sebou až do přijetí nebo odmítnutí zprávy.
acl_data:
# Přidání záhlaví Message-ID do zprávy zaslané klienty z vlastní domény # v případě, kdy záhlaví ve zprávě chybí. warn
condition = ${if !def:h_Message-ID: {1}}hosts = : +relay_from_hostsmessage = Message-ID: <E$message_id@$primary_hostname>
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host.
systému.# Akceptuje zprávy, přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.accept
hosts = : +relay_from_hosts
# Akceptování zprávy v případě, kdy byla zpráva přijata přes # autentizované připojení z libovolného hostitelského systému.#accept
authenticated = *
# Kontrola omezení velikosti zprávy # Odmítnutí zprávy v případě, kdy není korektní syntaxe záhlaví. # deny
#
deny
message
condition
= Velikost zprávy $message_size je větší než
limit \
MESSAGE_SIZE_LIMIT
= ${if >{$message_size}
{MESSAGE_SIZE_LIMIT}{true}{false}}
message = Zpr疱a nevyhovuje specifikaci standardu z RFC 2822 log_message = chyba při
syntaktick_ kontrole z疉lav_ zpr疱y !verify = header_syntax
# Odm咜nut_ zpr疱 ze vzd疝en馼o syst駑u, kter_ neobsahuj_ z疉lav_ # Message-ID nebo Date.
# Někteř_ specializovan_ agenti přenosu zpr疱 (někter_ mailinglistov_ # servery) negeneruj_ z疉
lav_ Message-ID pro vr當en_ zpr疱y automaticky. # Proto je přidan_ kontrola na nepr痙dnost
adresy odes匀atele. # deny
message = Zpr疱a nevyhovuje specifikaci standardu z RFC 2822 log_message = chyběj兤_ z疉
lav_ zpr疱y !hosts = +relay_from_hosts !senders = : postmaster@* condition = ${if or {{!
def:h_Message-ID:}\
{!def:h_Date:}\ {!def:h_Subject:}} {true}{false}}
# Varov疣_ v př厓adě, kdy platn_ adresa odes匀atele nen_ nalezena ani # v jednom ze z疉lav_
“Sender:”, “Reply-To:” nebo “From:”. # warn
message = X-Sender-Verify-Failed: Nenalezena platn_ adresa\
odes匀atele log_message = Nenalezen platn FF 81 odes匀atel !verify = header_sender
# Akceptov疣_ zpr疱y. # accept
Vložení zpoždění do transakcí protokolu SMTP Jednoduchý způsob
Nejjednodušší způsob zpoždění transakcí protokolu SMTP je pomocí klíčového slova delay u
kaž-dého posledního příkazu accept v každém již deklarovaném seznamu řízení přístupu takto:
accept delay = 20s
Kromě tohoto způsobu je možné přidávat dodatečná zpoždění u příkazů deny , které se používa-jí k vyhodnocení neplatných adres
příjemců zprávy u seznamu acl_rcpt_to. Tím je možné zpo-malit slovníkové útoky. Například:
deny
message = neznámý uživatel
!verify = recipient/callout=20s,defer_ok,use_sender
delay = ${eval:$rcpt_fail_count*10 + 20}s
Zde je nutné poznamenat, že není důvod vkládat zpoždění v seznamu acl_data až po přijetí zprá-vy. Ratware se obvykle v tomto
okamžiku odpojí bez čekání na odezvu od poštovního serveru. Jest-li se však klient v tomto okamžiku odpojí nebo neodpojí,
nemá vliv na to, jestli Exim provede doru-čení zprávy nebo ne.
Proměnná zpoždění
Pokud jste jako já, určitě budete chtít při filtrování implementovat proměnná zpoždění, jejichž délka závisí na hostitelském
systému, který provádí transakci protokolu SMTP. Jak již bylo uve-deno dříve v tomto dokumentu, je možné se rozhodnout
například tak, že nalezení hostitelského systému v seznamu zakázaných položek systému DNS nebo nemožnost ověřit údaje v
příkazu HELO/EHLO ještě neznamenají odmítnutí zprávy, ale jsou to dostatečné důvody pro zpoždění transakce protokolu SMTP.
Aby bylo možné implementovat proměnná zpoždění, je nutné přesunout některé kontroly, které byly součástí seznamu acl_rcpt_to ,
do dřívějších částí transakce protokolu SMTP. Takovým způ-sobem je možné aktivovat zpoždění okamžitě po zjištění nějakého
problému a tím zvýšit pravdě-podobnost způsobení chyby synchronizace v případě, kdy zprávu zasílá ratware.
Přesuny je možné provést takto:
Kontroly s využitím systému DNS je možné přesunout do seznamu acl_connect .
Kontroly příkazu Hello je možné přesunout do seznamu acl_helo. Jedinou výjimkou je, že v tomto okamžiku není možné
provést kontrolu na chybějící příkaz HELO/EHLO, pro-tože seznam se zpracovává jako odezva na příkaz HELO/EHLO. Tato
kontrola se proto provede v seznamu acl_mail_from.
Přesunout kontroly adresy odesílatele do seznamu acl_mail_from.
Z výše uvedených důvodů není vhodné odmítnout zprávu před příkazem RCPT TO:. Místo toho se provede konverze příkazů deny
na příkazy warn a pro uložení chybových zpráv a varování se využijí obecné proměnné seznamů řízení přístupu softwaru Exim.
Zbytek akcí se provede v ob-sluze příkazu RCPT TO:. Vše se provede takto:
■ Při rozhodnutí o odmítnutí doručení se chybová zpráva, která se využije v následné odez-vě s chybovým kódem 550, uloží
v proměnných $acl_c0 nebo $acl_m0:
Pokud se zjistí podmínka pro odmítnutí ještě před doručením vlastní zprávy (tzn. v seznamech acl_connect nebo
acl_helo ), použije se proměnná $acl_c0. Tato pro-měnná je perzistentní a její obsah se uchovává po celou dobu trvání připojení.
Poté co začne transakce přenosu zprávy (tzn. po příkazu MAIL FROM:), provede se zkopírování obsahu proměnné
$acl_c0 do proměnné $acl_m0 (její obsah se uchová-vá pouze v průběhu zpracování zprávy) a od této chvíle se opět začne používat
pro-měnná $acl_c0. Díky tomu podmínky, zpracovávané v dané zprávě, neovlivní násle-dující zprávy, přijaté v rámci stejného
připojení.
Podobným způsobem se provede uložení logovacích zpráv do proměnných $acl_c1 nebo $acl_m1 .
■ Pokud dojde ke zpracování podmínky, která nezaručuje okamžité odmítnutí zprávy, pro-vede se pouze uložení zprávy
(varování) do proměnné $acl_c1 nebo $acl_m1. Po spuš-tění transakce přenosu zprávy (tj. v seznamu acl_mail_from) se
obsah této proměnné přidá do záhlaví zprávy.
Pokud dojde k akceptování zprávy bez ohledu na výsledky jakýchkoliv dalších kontrol (například s využitím softwaru
SpamAssassin), je možné nastavit odpovídající příznak do proměnných $acl_c0 nebo $acl_m0 a proměnné $acl_c1 a $acl_m1
vynulovat.
Na začátku každého seznamu řízení přístupu až do seznamu acl_mail_from včetně se do proměnné $acl_m2 provede
uložení aktuálního času. Na konci každého seznamu řízení přístupu se obsah proměnné $acl_c1 nebo $acl_m1 použije pro aktivaci
zpoždění trans-akce protokolu SMTP o délce trvání 20 sekund.
Použití proměnných shrnuje následující tabulka.
Použití proměnných v seznamech řízení přístupu
Proměnné $acl_[cm]0 nenastavena $acl_[cm]0 nastavena
$acl_[cm]1nenastavena (zatím žádné rozhodnutí) Přijetí zprávy $acl_[cm]1nastavena Varování do záhlaví Odmítnutí zprávy
Pro ilustraci tohoto přístupu budou uvedeny dva příklady kontroly příkazu Hello. První z nich způsobí odmítnutí zprávy v
případě, kdy je součástí příkazu Hello adresa IP a druhá způsobí varo-vání o neověřitelném názvu v příkazu Hello. Dříve se obě
kontroly prováděly v seznamu acl_rcpt_to. Teď budou přesunuty do seznamu acl_helo.
acl_helo: # Zaznamená aktuální čas pro výpočet doby trvání zpoždění. warn
set acl_m2 = $tod_epoch
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host. systému.#
Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.#accept
hosts = : +relay_from_hosts
# Pokud vzdálený hostitelský systém použije v příkazu Hello adresu IP, # do proměnné $acl_c0 se uloží zpráva o odmítnutí a do proměnné
$acl_c1 # se uloží zpráva pro soubor protokolu. Hodnoty těchto proměnných se # využijí později při odmítnutí zprávy. V mezičase jejich
nastavení # znamená, že je nutné transakci zpozdit.
#
warn
condition
set acl_c0
= ${if isip {$sender_helo_name}{true}
{false}}
= Zpráva byla doručena ratwarem
set acl_c1
= vzdálený hostitel použil v příkazu HELO/
EHLO adresu IP
# Pokud selže ověřen_ př勛azu HELO, ulož_ se zpr疱a s varov疣匇 # do proměnn_ acl_c1.
Toto varov疣_ bude později vloženo do z疉lav_ # zpr疱y. V mezičase jejich nastaven_
znamen_, že je nutn_ transakci # zpozdit.
#
warncondition = ${if !def:acl_c1 {true}{false}}!verify = heloset acl_c1 = X-HELO-Warning:
Vzd疝en FF 81 hostitel $sender_host_address \
${if def:sender_host_name {($sender_host_name) }}\ se nespr疱ně
prezentoval jako $sender_helo_name log_message = vzd疝en FF 81 hostitel
použil neověřiteln FF 81 př勛az HELO/EHLO
#
# ... dalš_ kontroly, kter_ v tomto př勛ladu nejsou použity ...
#
# Akceptuje připojen_, ale pokud je v proměnn_ $acl_c1 uložena zpr疱a,
# odes匀atel bude zpožděn na celkovou dobu 20 sekund.
accept
set acl_m2 = ${if def:acl_c1 {${eval:20 + $acl_m2 - $tod_epoch}}{0}} delay = ${if >
{$acl_m2}{0}{$acl_m2}{0}}s
Pak se v seznamu acl_mail_from provede přesun zpráv z proměnných $acl_c{0,1} do
$acl_m{0,1}. Kromě toho se obsah proměnné $acl_c1 přidá do záhlaví zprávy.
acl_mail_from: # Zaznamená aktuální čas pro výpočet doby trvání zpoždění. warn set
acl_m2 = $tod_epoch
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host.
systému.# Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.#accept
hosts = : +relay_from_hosts
# Proměnné $acl_c0 and $acl_c1 obsahují zprávy o odmítnutí nebo # varování, která je nutné použít při všech dalších pokusech o doručení# v
rámci této transakce protokolu SMTP. Hodnoty je nutné uložit do # odpovídajících proměnných $acl_m{0,1} a vložit varování z proměnné#
$acl_m1 do záhlaví zprávy. (V případě odmítnutí zprávy proměnná# $acl_m1 obsahuje zprávu pro soubor protokolu, nicméně to nevadí,#
protože záhlaví bude odstraněno spolu s celou zprávou).#warn
set acl_m0 = $acl_c0set acl_m1 = $acl_c1message = $acl_c1
#
# ... další kontroly, které v tomto příkladu nejsou použity ...
#
# Akceptuje připojení, ale pokud je v proměnné $acl_c1 uložena zpráva,
# odesílatel bude zpožděn na celkovou dobu 20 sekund.
accept
set acl_m2 = ${if def:acl_c1 {${eval:20 + $acl_m2 - $tod_epoch}}{0}}
delay = ${if >{$acl_m2}{0}{$acl_m2}{0}}s
Všechny příslušné úpravy jsou součástí konečné verze seznamů řízení přístupu, které naleznete v dalších kapitolách.
Podpora greylistingu
Existuje více možností, jak implementovat podporu greylistingu v softwaru Exim. V následujících kapitolách popíšeme některé z
nich.
Démon greylistd
Greylistd je implementace, která využívá Python. Tato implementace bude použita ve výsledných seznamech řízení přístupu.
Greylistd pracuje jako samostatný démon a není závislý na externí databázi. Data démona greylistd jsou ukládána v podobě
32bitových hašovaných dat. Instalaci je možné nalézt na adrese http://packages.debian.org/unstable/mail/greylistd. Uživatelé
distribuce Debian mohou využít při instalaci APT:
# apt-get install greylistd
Pro kontrolu s využitím démona greylistd vložíme do seznamu acl_rcpt_to dva příkazy
přímo před poslední příkaz accept. # Pro získání stavu pro daný triplet (hostitel, odesílatel,
příjemce) se # využije démon „greylistd“. # # Greylisting se neprovádí pro zprávy bez
odesílatele, protože ověření # odesílatele zpětným voláním by nefungovalo (a pravděpodobně
by nebylo # možné zaslat zprávu systému, který toto ověřování provádí). # defer message =
$sender_host_address ještě není autorizován pro doručení\ zprávy z adresy <$sender_address>
na adresu\ <$local_part@$domain>. Prosím zkuste později. log_message = blokováno
greylistingem. domains = +local_domains : +relay_to_domains !senders = : postmaster@* set
acl_m9 = $sender_host_address $sender_address $local_part@$domain set acl_m9 =
${readsocket{/var/run/greylistd/socket}{$acl_m9}{5s}{}{}} condition = ${if eq {$acl_m9}
{grey}{true}{false}}
Pokud se nebude využívat signatury adresy odesílatele pro blokování falešných oznámení o stavu doručení, je možné přidat
podobnou sekvenci příkazů i do seznamu acl_data pro provedení grey-listingu pro zprávy s prázdným odesílatelem.
Data, která použijeme pro účely greylistingu, budou v takovém případě jiná než v předchozím pří-padě. Kromě toho, že proměnná
$sender_address zůstane prázdná, nebudou definovány ani hod-noty proměnných $local_part a $domain. Místo toho je možné použít
proměnnou $recipi-ents , která obsahuje seznam všech jednotlivých příjemců zprávy. Legitimní oznámení o stavu doru-čení by
mělo obsahovat pouze jednu adresu.
# Greylisting pro zprávy bez adresy odesílatele.
# Greylisting se v tomto případě neprování po příkazu RCPT TO:, protože
# by nefungovalo ověření odesílatele zpětným voláním ze vzdálených
# systémů.
#
defer
message = $sender_host_address ještě není autorizován pro zasílání\ oznámení o stavu doručení pro <$recipients >. \ Prosím zkuste
později.
log_message = blokováno greylistingem.senders = : postmaster@*set acl_m9 = $sender_host_address $recipientsset acl_m9 = ${readsocket
{/var/run/greylistd/socket}{$acl_m9}{5s}{}{}}condition = ${if eq {$acl_m9}{grey}{true}{false}}
Implementace s využitím databáze MySQL
Autorem následující implementace je Johannes Berg <[email protected]>. Implementace využívá částečně:
Práci Ricka Stewarta <[email protected]>, kterou naleznete na adrese http://theinternetco.net/projects/
exim/greylist.
Implementaci s využitím databáze Postgres od Tollefa Fog Heena <[email protected]>, kte-rou naleznete na adrese http://
raw.no/personal/blog/tech/Debian/2004-03-14-15-55_grey-listing.
Implementace nevyžaduje žádné externí programy, je založena na následujících skriptech a data-bázi MySQL. Archiv s aktuální
verzí skriptů a soubor README naleznete na adrese http:// johannes.sipsolutions.net/wiki/Projects/exim-greylist.
V systému musí být instalována databáze MySQL. V příkazovém řádku databáze MySQL se pro-vede vytvoření databáze exim4
se dvěma tabulkami exim_greylist a exim_greylist_log následujícím skriptem:
CREATE DATABASE exim4; use exim4;
CREATE TABLE exim_greylist ( id bigint(20) NOT NULL auto_increment, relay_ip varchar(80) default NULL, sender varchar(255) default
NULL, recipient varchar(255) default NULL, block_expires datetime NOT NULL default ‘0000-00-00 00:00:00’, record_expires datetime
NOT NULL default ‘9999-12-31 23:59:59’, create_time datetime NOT NULL default ‘0000-00-00 00:00:00’, type enum
(‘AUTO’,’MANUAL ’) NOT NULL default ‘MANUAL’, passcount bigint(20) NOT NULL default ‘’, blockcount bigint(20) NOT NULL
default ‘’, PRIMARY KEY (id )
);
CREATE TABLE exim_greylist_log ( id bigint(20) NOT NULL auto_increment,
listid bigint(20) NOT NULL,
timestamp datetime NOT NULL default ‘0000-00-00 00:00:00’,
kind enum(‘deferred’, ‘accepted’) NOT NULL,
PRIMARY KEY (id)
);
V hlavní sekci konfiguračního souboru agenta Exim je nutné deklarovat následující makra:
# definice databáze hide mysql_servers = localhost/exim4/uživatel/heslo
# nastavení # hodnoty těchto nastavení musí být platné hodnoty (xxx) pro použití # v příkazu MySQL DATE_ADD(..,INTERVAL xxx) #
Neplatné jsou hodnoty v jednotném čísle: “2 HOUR” místo “2 HOURS” GREYLIST_INITIAL_DELAY = 1 HOUR
GREYLIST_INITIAL_LIFETIME = 4 HOUR GREYLIST_WHITE_LIFETIME = 36 DAY GREYLIST_BOUNCE_LIFETIME = 0 HOUR
# zde je možné změnit názvy tabulek GREYLIST_TABLE=exim_greylist
GREYLIST_LOG_TABLE=exim_greylist_log
# dočasná deaktivace greylistingu se provede zakomentováním následujícího # řádku GREYLIST_ENABLED=
# odkomentováním následujícího řádku se aktivuje logování #GREYLIST_LOG_ENABLED=
# pod tímto komentářem již není nutné upravovat nic
.ifdef GREYLIST_ENABLED # databázová makra GREYLIST_TEST =
SELECT CASE \
WHEN now() > block_expires THEN “accepted” \
ELSE “deferred” \
END AS result, id \
FROM GREYLIST_TABLE \
WHERE (now() < record_expires) \
AND (sender = ‘${quote_mysql:$sender_address}’ \ OR
(type=’MANUAL’ \ AND ( sender IS NULL \ OR sender =
‘${quote_mysql:@$sender_address_domain}’ \ ) \ ) \ ) \ AND
(recipient = ‘${quote_mysql:$local_part@$domain}’ \ OR (type =
‘MANUAL’ \
AND ( recipient IS NULL \ OR recipient = ‘${quote_mysql:$local_part@}’ \ OR recipient = ‘${quote_mysql:@$domain}’ \
)\
)\
) \ AND (relay_ip = ‘${quote_mysql:
$sender_host_address}’ \ OR (type=’MANUAL’ \ AND
( relay_ip IS NULL \ OR relay_ip = substring
(‘${quote_mysql:$sender_host_address}’,1,length(relay_ip))
\ ) \ ) \ ) \ ORDER BY result DESC LIMIT 1
GREYLIST_ADD = INSERT INTO GREYLIST_TABLE \ (relay_ip, sender, recipient,
block_expires, \ record_expires, create_time, type) \
VALUES ( ‘${quote_mysql:$sender_host_address}’, \
‘${quote_mysql:$sender_address}’, \
‘${quote_mysql:$local_part@$domain}’, \
DATE_ADD(now(), INTERVAL GREYLIST_INITIAL_DELAY), \
DATE_ADD(now(), INTERVAL GREYLIST_INITIAL_LIFETIME), \
now(), \
‘AUTO’ \
)
GREYLIST_DEFER_HIT = UPDATE GREYLIST_TABLE \ SET blockcount=blockcount+1 \ WHERE id = $acl_m9
GREYLIST_OK_COUNT = UPDATE GREYLIST_TABLE \ SET passcount=passcount+1 \
WHERE id = $acl_m9
GREYLIST_OK_NEWTIME = UPDATE GREYLIST_TABLE \ SET
record_expires = DATE_ADD(now (),
INTERVAL
GREYLIST_WHITE_LIFETIME) \
WHERE id = $acl_m9 AND
type=’AUTO’
GREYLIST_OK_BOUNCE = UPDATE GREYLIST_TABLE \ SET
record_expires = DATE_ADD(now (),
INTERVAL
GREYLIST_BOUNCE_LIFETIME) \
WHERE id = $acl_m9 AND type=’AUTO’
GREYLIST_LOG = INSERT INTO GREYLIST_LOG_TABLE \ (listid, timestamp, kind) \
VALUES ($acl_m9, now(), ‘$acl_m8 ’)
.endif
V sekci seznamů řízení přístupu (v části po begin acl) je nutné deklarovat nový seznam řízení přístupu s názvem greylist_acl. .ifdef
GREYLIST_ENABLED # výsledkem vyhodnocení tohoto seznamu řízení přístupu je bu přijetí nebo # odmítnutí zprávy # Použití celého bloku
závisí na hodnotě GREYLIST_ENABLED # akceptování zprávy znamená, že podmínka je TRUE a doručení se odkládá # odmítnutí zprávy
znamená, že podmínka je FALSE a doručení se neodkládá
greylist_acl: # Pro normální doručení zprávy se provádí greylisting. # Kontrola tupletu, v proměnné acl_m8 vrací “accepted”, “deferred” nebo #
“unknown” a v proměnné acl_m9 identifikátor záznamu
warn set acl_m8 = ${lookup mysql{GREYLIST_TEST}{$value}{result=unknown}} # proměnná acl_m8 = “result=x id=y”
set acl_m9 = ${extract{id}{$acl_m8}{$value}{-1}} # proměnná acl_m9 obsahuje identifikátor záznamu nebo -1
set acl_m8 = ${extract{result}{$acl_m8}{$value}{unknown}} # proměnná acl_m8 obsahuje unknown/deferred/
accepted
# kontrola existence určitého tripletu, odložení doručení, pokud
# triplet neexistuje
accept
# pokud předchozí kontrola vrátila „unknown“
condition = ${if eq{$acl_m8}{unknown}{1}}
# přidání záznamu do databáze
condition = ${lookup mysql{GREYLIST_ADD}{yes}{no}}
# logování bez ohledu na výsledek
# pokud triplet nebyl nalezen, není nutné provádět logování,
# protože se to děje implicitně při vytvoření záznamu o času
.ifdef GREYLIST_LOG_ENABLED
warn condition = ${lookup mysql{GREYLIST_LOG}}
.endif
# kontrola, jestli je triplet stále blokován
accept
# pokud předchozí kontrola vrátila „deferred“, pak se odkládá
condition = ${if eq{$acl_m8}{deferred}{1}}
# a tato akce se zaznamená
condition = ${lookup mysql{GREYLIST_DEFER_HIT}{yes}{yes}}
# použití klíčového slova warn pro zjištění počtu záznamů
warn condition = ${lookup mysql{GREYLIST_OK_COUNT}}
# použití klíčového slova warn pro nastavení nového času vypršení# platnosti u automaticky vytvářených záznamů, ale pouze v případě,# kdy
zpráva nebyla oznámení o stavu doručení. V opačném případě se čas# nastaví na hodnotu now().warn !senders = : postmaster@*
condition = ${lookup mysql{GREYLIST_OK_NEWTIME}}
warn senders = : postmaster@*
condition = ${lookup mysql{GREYLIST_OK_BOUNCE}}
deny .endif
Tento seznam řízení přístupu je nutné zahrnout do seznamu acl_rcpt_to pro provádění greylis-tingu tripletů v případě, kdy adresa
odesílatele není prázdná. To umožní provést ověření odesílate-le zpětným voláním:
.ifdef GREYLIST_ENABLED
defer !senders = : postmaster@*
acl = greylist_acl
message = použit greylisting – pokuste se o doručení později .endif
Tento seznam se také zahrne do bloku acl_data , ale pouze v případě, kdy je adresa odesílate-le prázdná. Tím se zabrání, aby spamer
obešel greylisting jednoduše tím, že nastaví prázdnou adresu odesílatele.
.ifdef GREYLIST_ENABLED
defer senders = : postmaster@*
acl = greylist_acl
message = použit greylisting – pokuste se o doručení později .endif
Přidání kontrol pro SPF (Sender Policy Framework)
V této kapitole naleznete dva různé způsoby kontroly záznamů SPF s využitím agenta přenosu zpráv Exim. Kromě těchto
explicitních mechanismů je více sofistikovaných kontrol záznamů SPF s přiřazováním ohodnoceného skóre dle výsledků kontrol
SPF součástí softwaru SpamAssassin.
I když by bylo možné provádět tyto kontroly již v seznamu acl_mail_from, je zde problém, který toto rozhodnutí ovlivňuje: SPF
není kompatibilní s klasickým přeposíláním zpráv. Pokud hostitel-ský systém, který zprávu přeposílá, nevyužívá nějakou
implementaci SRS, může vše skončit odmít-nutím přeposílané zprávy, protože pochází z hostitelského systému, který není dle
záznamů SPF autorizovaný pro přeposílání zpráv z domény, která je součástí adresy odesílatele v příkazu MAIL FROM:. Tomuto
problému se zabrání tak, že se provede dodatečná kontrola uživatelských sezna-mů hostitelských systémů, ze kterých je možné
přeposílané zprávy přijímat. Toto je možné pro-vést až po provedení příkazu RCPT TO:, když už známe uživatelské jméno
příjemce. Proto tuto kontrolu přidáme před greylisting anebo před poslední příkaz accept v seznamu acl_rcpt_to.
Kontrola SPF s využitím doplňku Exiscan-ACL
Poslední verze doplňku Exiscan-ACL od Toma Kistnera obsahují nativní podporu pro SPF. Použi-tí je velmi jednoduché. Stačí
přidat podmínku spf, kterou je možné vyhodnocovat s libovolným klíčovým slovem pass, fail , softfail, none , neutral, err_perm nebo
err_temp . Následující kód je nutné vložit ještě před implementací greylistingu anebo před poslední příkaz accept :
# Dotaz na informace SPF pro doménu odesílatele zprávy.
# Podle výsledku se rozhodne, jestli je hostitelský systém odesílatele
# zprávy autorizovaný pro doručení zprávy.
# Pokud ne, je zpráva odmítnuta.
#
deny
message = [SPF] $sender_host_address nemá umožněno zasílat zprávy \
z domény $sender_address_domain
log_message = kontrola SPF selhala
spf = fail
# Přidání záhlaví SPF-Received: do zprávy
warn
message = $spf_received
Tento kód provede odmítnutí zprávy v případě, že vlastník domény z adresy odesílatele nepovo-lil doručování zpráv z
hostitelského systému, který zprávu zasílá. Tím se dává vlastníkům domén do rukou „moc“ rozhodovat o tom, kdo může odesílat
zprávy z jejich domény. Doporučovaná alternativa je kombinovat kontroly SPF s ostatními kontrolami, například s ověřením
adresy ode-sílatele zpětným voláním (stejně tak jako u předchozích kontrol platí, že nemá cenu tyto kontro-ly provádět v případě,
kdy se provádí zasílání zpráv s využitím vyhrazeného hostitelského systé-mu, tzv. smarthost).
# Odmítnutí zprávy v případě, kdy není možné adresu odesílatele ověřit
# s využitím zpětného volání a pokud informace SPF pro doménu odesílatele
# neumožňují hostitelskému systému provádět zasílání zpráv.
#
deny
message = Adresa odesílatele zřejmě není platná, informace SPF \
neumožňují systému $sender_host_address \
provádět zasílání zpráv z domény $sender_address_domain
log_message = kontrola SPF selhala
!verify = sender/callout,random,postmaster
!spf = pass
# Přidání záhlaví SPF-Received: do zprávy
warn
message = $spf_received
Kontroly s využitím balíčku Mail::SPF::Query
Balíček Mail::SPF::Query je oficiální testovací sada pro SPF, kterou naleznete na adrese http://spf.pobox.com/downloads.html.
Uživatelé distribuce Debian si mohou nainstalovat balíček libmail-spf-query-perl.
Balíček Mail:SPF:Query obsahuje démona spfd, který naslouchá požadavkům v rámci domény systému UNIX. Součástí však
není init-skript, který by zajistil automatické spuštění démona. V následujícím příkladu proto bude použit samostatný nástroj
spfquery.
Stejně jako u předchozího typu kontrol SPF je nutné i tento kód vložit před
kontroly s využitím greylistingu anebo před poslední příkaz accept v seznamu
acl_rcpt_to: # Pro zjištění stavu SPF daného hostitelského systému se použije #
“spfquery”. Pokud je návratová hodnota tohoto příkazu 1, # znamená to, že odesílatel
není autorizovaný. # deny message = [SPF] $sender_host_address nemá povoleno zasílat
zprávy \ z domény $sender_address_domain. log_message = kontrola SPF selhala set
acl_m9 = -ipv4=$sender_host_address \ -sender=$sender_address \ -helo=
$sender_helo_name set acl_m9 = ${run{/usr/bin/spfquery $acl_m9}} condition = ${if eq
{$runrc}{1}{true}{false}}
Kontroly kódování MIME a typů souborů
Tyto kontroly závisejí na vlastnostech doplňku Exiscan-ACL Toma Kistnera. Exiscan-ACL obsahu-je podporu pro dekódování
MIME a kontroly přípon názvů souborů. Tato kontrola zablokuje vět-šinu virů u systémů Windows, ale ne ty, které jsou přenášeny
v souborech typu .ZIP, nebo tako-vé, které využívají jinou zranitelnost, například poštovního klienta Outlook.
Tyto kontroly je nutné zahrnout do seznamu acl_data před poslední
příkaz accept. # Odmítnutí zpráv, které obsahují vážné chyby kódování
MIME. # deny message = Zjištěna chyba kódování MIME ($demime_reason)
demime = * condition = ${if >{$demime_errorlevel}{2}{1}{0}}
# Rozbalení kontejnerů v kódování MIME a odmítnutí souborů s příponami,
# které využívají viry.
# Zde se provádí další volání příkazu demime, které ovšem vrátí výsledky
# uložené ve vyrovnávací paměti.
# Seznam přípon nemusí být úplný.
#
deny
message = Zde neakceptujeme přílohy s příponou “.$found_extension”. demime =
bat:btm:cmd:com:cpl:dll:exe:lnk:msi:pif:prf:reg:scr:vbs:url
Podmínka demime se při provádění těchto příkazů volá dvakrát. Zpráva ale ve skutečnosti není zpracovávána dvakrát, protože
výsledky jsou již uloženy ve vyrovnávací paměti.
Přidání antivirového softwaru
Doplněk Exiscan-ACL umí přímo pracovat s velkým počtem antivirových programů nebo s jakým-koliv jiným antivirovým
programem, který je možné spustit z příkazového řádku. Při použití anti-virového softwaru je nutné, aby hlavní sekce
konfiguračního souboru softwaru Exim udávala, který antivirový program se bude používat, a také další konfigurační nastavení,
platná pro daný typ antivirového programu. Základní syntaxe je:
av_scanner = typ:parametr1:parametr2:...
Například:
av_scanner = sophie:/var/run/sophie av_scanner = kavdaemon:/opt/AVP/AvpCtl av_scanner = clamd:127.0.0.1 1234 av_scanner = clamd:/opt/
clamd/socket av_scanner = cmdline:/path/to/sweep -all -rec -archive %s:found:’(.+)’ ...
V seznamu acl_data se pak pro antivirové testování využije podmínka
malware takto: deny message = Tato zpráva obsahuje virus ($malware_name)
demime = * malware = */defer_ok
Další informace o použití naleznete v souboru exiscan-acl-spec.txt.
Kontrola s využitím nástroje SpamAssassin
Kontrolu s využitím softwaru SpamAssassin je v prostředí softwaru Exim v průběhu transakce protokolu SMTP možné provádět
dvěma způsoby:
Podmínkou spam v doplňku Exiscan-ACL. Tento způsob bude popsán dále.
S využitím nástroje SA-Exim, který vytvořil Marc Merlins <[email protected]> přímo pro účely kontroly zpráv s
využitím softwaru SpamAssassin. Tento nástroj využívá rozhraní Eximu local_scan() buď přímo úpravou zdrojového kódu Eximu
nebo přes Marcův vlastní zásuv-ný modul dlopen(), který je součástí balíčků pro distribuci Debian exim4-daemon-light a exim4daemon-heavy. Nástroj SA-Exim implementuje kromě jiného i greylisting a teergru-bing. Protože kontrola se v tomto případě
může provést, až jsou k dispozici data obsahu zprávy, nejsou tyto kontroly tak užitečné, jako by byly v dřívějších fázích transakce
proto-kolu SMTP. Nástroje SA-Exim naleznete zde: http://marc.merlins.org/linux/exim/sa.html.
Spuštění nástroje SpamAssassin pomocí doplňku Exiscan-ACL.
Podmínka spam umožní předat zprávu buď nástroji SpamAssassin nebo BrightMail a odpovídají-cím způsobem se zachovat v
případě, kdy je zpráva klasifikována jako nevyžádaná pošta. Při vyhodnocení se ve výchozím nastavení provede připojení k
démonu SpamAssassin (spamd) na místním hostitelském systému. Adresu hostitelského systému a port je možné změnit
nastavením parametru spamd_address v hlavní sekci konfiguračního souboru Exim. Více informací nalezne-te v souboru exiscanacl-spet.txt , který je součástí dokumentace doplňku.
V dalším příkladu se bude provádět odmítnutí všech zpráv klasifikovaných jako spam. Obvykle je však vhodné uchovat kopii
takových zpráv ve zvláštní poštovní schránce, alespoň dočasně. Díky tomu mohou uživatelé obsah této schránky prohlížet a
hledat případné legitimní zprávy, které byly klasifikovány chybně.
Exim pro tyto případy nabízí akce, které je možné aplikovat na přijatou zprávu (například free-ze). Doplněk Exiscan-ACL přidává
další akci s názvem fakereject . Ta způsobí následující ode-zvu protokolu SMTP:
550-FAKEREJECT id= id_zprávy
550-Vaše zpráva byla odmítnuta, ale je uložena pro další vyhodnocení.
550 Pokud to byla legitimní zpráva, může být doručena příjemci(cům).
Tato vlastnost bude použita v následujících příkladech. Skript je nutné vložit do seznamu
acl_data před poslední příkaz accept :
# Volání nástroje SpamAssassin pro získání hodnot $spam_score
# a $spam_report.
# V závislosti na klasifikaci obsahuje proměnná $acl_m9 hodnotu
# “ham” nebo “spam”.
#
# Pokud je zpráva klasifikována jako spam, je odmítnuta.
#
warn
set acl_m9 = ham
spam = mail
set acl_m9 = spam
control = fakereject
logwrite = :reject: Odmítnutý spam (score $spam_score): $spam_report
#
#
Přidání
záhlaví
X-Spam-Status:
do
zprávy.
warn
message
logwrite
= X-Spam-Status: \
${if eq {$acl_m9}{spam}{Yes}{No}} (score $spam_score)\
${if def:spam_report {: $spam_report}}
= :main: Klasifikováno jako $acl_m9 (score $spam_score)
V tomto příkladu je hodnota proměnné $acl_m9 nastavena na „ham“. Pak se provede volání nástroje SpamAssassin pod účtem
uživatele mail. Pokud je zpráva klasifikována jako spam, pro-měnná $acl_m9 obsahuje hodnotu „spam“ a použije se odezva
fakereject . Nakonec je do zprá-vy přidáno záhlaví X-Spam-Status:. Cílem je, aby klientský systém nebo agent pro doručení zprávy
mohl toto záhlaví využít pro uložení zpráv s nevyžádanou poštou do zvláštní složky.
Konfigurace nástroje SpamAssassin
Výsledky vyhodnocení nástroj SpamAssassin ve výchozí konfiguraci vrací v poměrně podrobném formátu v podobě tabulky,
která je vhodná pro přidání k textu zprávy nebo pro uložení do pří-lohy zprávy. V tomto případě stačí stručný výsledek, který
bude uložen do záhlaví X-Spam-Sta-tus:. Pro nastavení zobrazování stručného výsledku je nutné do konfiguračního souboru (/etc/
spamassassin/local.cf , /etc/mail/spamassassin/local.cf) nástroje SpamAssassin přidat následující text:
### Šablona zobrazení výsledku clear_report_template report “_TESTSSCORES(, )_”
SpamAssassin obsahuje kromě jiného i Bayesův filtr, který je ve výchozí konfiguraci aktivovaný. V tomto příkladu bude filtr
deaktivován, protože vyžaduje trénink, který může být jiný pro kaž-dého uživatele, a proto není vhodný pro globální filtrování
protokolu SMTP:
### Deaktivace Bayesova filtru use_bayes 0
Aby se změny projevily, je nutné restartovat démona SpamAssassin (spamd).
Uživatelská nastavení a data
V některých situacích je nutné specifikovat individuální nastavení softwaru SpamAssassin, jako je například prahová hodnota pro
klasifikaci spamu, povolené jazykové a znakové sady, seznamy povolených a zakázaných položek pro odesílatele atd. přímo pro
jednotlivé uživatele. Uživatelé také mohou chtít individuálně využívat bayesovské filtrování, které je součástí softwaru
SpamAssassin.
Poznámka
I když platí, že trénink Bayesova filtru je individuální záležitost každého uživatele, je nutné poznamenat, že Bayesův filtr v
nástroji SpamAssassin není v některých případech vhod-ný. Je to znát hlavně u zpráv, do kterých spameři zahrnou velké množství
náhodných slov ze slovníku nebo celé odstavce textu (například jako metadata ve zprávách ve formátu HTML).
Jak bylo zmíněno v předchozích kapitolách tohoto dokumentu, je možné vynutit, aby zpráva obsa-hovala pouze jediného
příjemce. Lze toho docílit tak, že se od volajícího hostitelského systému akceptuje první příkaz RCPT TO: a další příjemci jsou
odmítnuti odezvou s kódem 451. Podob-ně jako u greylistingu platí, že pokud je odesílatel legitimní agent přenosu zpráv, ví, jak
tuto odez-vu vyhodnotit, a pokusí se o doručení zprávy dalším příjemcům později.
Jak akceptovat pouze jednoho příjemce v prostředí Exim
Do seznamu acl_rcpt_to se vloží za ověření adresy příjemce, ale ještě před jakýkoliv příkaz accept, který náleží k neautentizovaným
doručením od vzdálených hostitelů místním uživatelům (tj. před greylisting, před kontroly signatur atd.), následující příkazy:
# Omezení počtu příjemců v každé příchozí zprávě na jednoho # s cílem umožnit podporu pro individuální nastavení parametrů # (např. pro
SpamAssassin). # # POZNÁMKA: Každá zpráva zaslaná více uživatelům bude zpožděna
#
#
#
#
#
defer
o 30 minut nebo více na jednoho příjemce. To může významným
způsobem ovlivnit interaktivní diskuse, které využívají zprávy
elektronické pošty a jichž se účastní jak místní, tak
vzdálení účastníci.
message = Akceptuje se pouze jeden př勀emce zpr疱y. condition = $recipients_count
Předání jména uživatele do nástroje SpamAssassin
V seznamu acl_data se provede úprava podmínky spam z předchozí kapitoly tak, že se nástroji SpamAssassin předá uživatelské
jméno z adresy příjemce zprávy.
# Volání nástroje SpamAssassin pro získání hodnot $spam_score # a $spam_report. # V závislosti na klasifikaci obsahuje proměnná $acl_m9
hodnotu # “ham” nebo “spam”. # # Předává se uživatelské jméno, které je součástí adresy příjemce, # tj. část před prvním výskytem znaku „=“
nebo „@“, převedená na malá # písmena. Zpráva by díky předchozímu omezení již neměla mít více # příjemců. # # Pokud je zpráva klasifikována
jako spam, je odmítnuta. # warn
set acl_m9 = ham spam = ${lc:${extract{1}{=@}{$recipients}{$value}{mail}}} set acl_m9 = spam control = fakereject logwrite = :reject:
Odmítnutý spam (score $spam_score): $spam_report
Všimněte si, že místo použití funkce ${ local_part:...} bylo uživatelské jméno získáno ručním oddělením části adresy před znakem
„=“ nebo „@“. Je to díky tomu, že další znaky využijeme při kontrole signatury.
Aktivace individuálního nastavení uživatelů v nástroji SpamAssassin
Zaměříme se teď opět na SpamAssassin. Jako první změnu je možné provést odstranění nastavení parametru pro deaktivaci
Bayesova filtru, který globálně jeho použití zakázal. V dalším nastavení si bude moci každý uživatel sám určit, jestli toto
nastavení použije nebo ne.
Pokud se poštovní schránky na poštovním serveru mapují přímo na místní uživatelské účty s domovskou složkou, je vše hotovo.
Démon SpamAssassin ve výchozí konfiguraci provádí funkci setuid() s uživatelským jménem z parametru a ukládá uživatelská
data a nastavení přímo do
domovské složky uživatele. Pokud jsou poštovní schránky řešeny jinak (například je spravuje software Cyrus SASL nebo jiný
poštovní server), je nutné nástroji SpamAssassin sdělit, kde nalézt konfiguraci pro každého uživa-tele a jeho soubory dat. Démon
spamd také musí běžet pod účtem vybraného místního uživate-le. To vše proto, aby se nepokoušel provést funkci setuid() se
jménem neexistujícího uživatele.
Vše se zajistí zadáním příslušných parametrů, předaných démonu spamd při startu:
Na systému Debian je nutné upravit nastavení OPTIONS= v souboru /etc/default/spa-massassin.
Na systému Red Hat je nutné upravit nastavení SPAMDOPTIONS= v souboru /etc/syscon-fig/spamassassin.
■ U ostatních systémů je nutné příslušné parametry zjistit samostatně. Dále je možné použít
nastavení:
■-u
username udává uživatele, pod kterým bude spamd spuštěn.
■-x deaktivuje konfigurační soubory v domovských složkách uživatelů.
■--virtual-config-dir=/var/lib/spamassassin/%u udává uložení individuálních nastavení
jednotlivých uživatelů. Znaky „%u“ jsou nahrazeny příslušným uživatelským jménem. Démon spamd musí mít oprávnění
pro vytvoření a úpravy této složky:
# mkdir /var/lib/spamassassin# chown -R mail:mail /var/lib/spamassassin
Po provedení těchto změn je samozřejmě nutné restartovat démona spamd.
Implementace kontroly signatury adresy odesílatele
V této kapitole naleznete informace o implementaci signatury adresy odesílatele v odchozí poště a kontrolu signatury ve zprávách
bez odesílatele (např. oznámení o stavu doručení). Adresa odesílatele v odchozích zprávách bude upravena takto:
odesílatel=příjemce=doména.příjemce=kontrolní_součet@doména.odesílatele
Protože tato metoda může mít vedlejší dopady (například v případě mailinglistů), je nutné ji imple-mentovat tak, aby umožnila
individuální nastavení pro každého uživatele. Signatura adresy odesí-latele bude vytvořena pro odchozí zprávy pouze v případě,
kdy je v domovské složce odesílate-le zprávy umístěn soubor s názvem .return-path-sign , a pouze v případě, kdy doména, do které
je zpráva zasílána, je součástí tohoto souboru. Pokud soubor existuje, ale je prázdný, bude signatura vytvořena pro všechny
domény.
Podobně platí, že signatura u adresy příjemce bude vyžadovaná pouze u příchozích vrácených zpráv (tzn. zpráv bez odesílatele) v
případě, kdy v domovské složce příjemce existuje výše uve-dený soubor. Uživatelé mohou z této kontroly vyjmout konkrétní
hostitelské systémy díky sezna-mu povolených položek.
Protože tento způsob vyžaduje spolupráci s komponentami router a transport softwaru Exim, nebude součástí výsledné verze
seznamů řízení přístupu. Pokud je čtenář schopen pochopit postup uvedený v následujících kapitolách, pak určitě bude schopen
přidat příslušnou sekci do seznamu řízení přístupu samostatně.
Sekce pro vytvoření signatury adresy odesílatele
Nejprve je nutné vytvořit transport, který se použije pro vytvoření signatury adresy odesílatele pro doručení do vzdálených
domén:
remote_smtp_signed: debug_print = “T: remote_smtp_signed for $local_part@$domain” driver = smtp max_rcpt = 1 return_path =
$sender_address_local_part=$local_part=$domain=\
${hash_8:${hmac{md5}{SECRET}{${lc:\ $sender_address_local_part=$local_part=
$domain}}}}\ @$sender_address_domain
Část s uživatelským jménem adresy odesílatele teď obsahuje následující části, oddělené znakem rovná se („=“ ):
Uživatelské jméno odesílatele.
Uživatelské jméno adresy příjemce.
Doménu z adresy příjemce.
■
Řetězec, jedinečný pro danou kombinaci odesílatele a příjemce, vygenerovaný:
Zašifrováním tří předchozích částí pomocí funkce Eximu ${hmac{md5}…} s využitím řetězce s heslem, které bylo
deklarováno v hlavní části.
Vytvořením hašovaného řetězce, který sestává z 8 malých písmen s využitím funkce Eximu ${hash…}.
Poznámka
Pokud si myslíte, že vytváření haše je kanón na vrabce, musím s vámi souhlasit jen čás-tečně. V předchozí verzi
dokumentu byla použita pro vytvoření poslední komponenty sig-natury funkce ${hash_8:SECRET=....}. Při použití této
funkce však je možné, s přihléd-nutím k tomu, jak pracuje funkce ${hash....} v Eximu, a s využitím vzorků odchozích
zpráv pro různé příjemce, zjistit, jakým způsobem je signatura vytvářená. A jak správně poznamenal Matthew ByngMaddic <[email protected]>: Informace uvedené v tomto dokumentu si většina lidí prostě zkopíruje. No a pokud je
veškeré zabezpečení součástí klíče a klíč může být zpětně odhalen, což je pravděpodobně možné při využití několika
vzorků dat, spamer může začít generovat platné signatury pro libovolnou doménu – a jsme zpět na začátku. Podle mého je
vhodné být tvrdý hned od začátku.
Pokud je nutné provádět autentizaci pro doručování přes vyhrazený hostitelský systém (tzv. smart-host), je možné použít i
hosts_try_auth .
Vytvoření směrování pro doručování do vzdálených systémů
Nejprve je nutné před již existující směrovače, které obsluhují odchozí zprávy, přidat nový smě-rovač (myšleno v terminologii
Eximu ) zpráv. Tento směrovač využije pro doručování do vzdále-ných systémů transportní údaje z předchozí části, ale pouze v
případě, pokud v domovské slož-ce odesílatele existuje soubor .return-path-sign a pokud se doména příjemce nachází v tomto
souboru. Při přímém zasílání zpráv přes Internet do vzdálených cílových systémů:
# Vytvoření signatury adresy odesílatele pro doručení do vzdálených domén # v případě, kdy domovská složka odesílatele obsahuje soubor #
“.return-path-sign” a pokud se vzdálená doména vyskytuje v tomto souboru. # Pokud soubor existuje, ale je prázdný, signatura se vytváří vždy. #
dnslookup_signed: debug_print = “R: dnslookup_signed for $local_part@$domain” driver = dnslookup transport = remote_smtp_signed senders
= ! : * domains = ! +local_domains : !+relay_to_domains : \
${if exists {/home/$sender_address_local_part/.return-path-sign}\ {/home/$sender_address_local_part/.return-path-sign}\
{!*}}
no_more
nebo při použití vyhrazeného systému (tzv. smarthost):
# Vytvoření signatury adresy odesílatele pro doručení do vzdálených domén# v případě, kdy domovská složka odesílatele obsahuje soubor #
“.return-path-sign” a pokud se vzdálená doména vyskytuje v tomto souboru.# Pokud soubor existuje, ale je prázdný, signatura se vytváří vždy.
#smarthost_signed:
debug_print = “R: smarthost_signed for $local_part@$domain”driver = manualroutetransport = remote_smtp_signedsenders = ! : *route_list =
* smarthost.addresshost_find_failed = deferdomains = ! +local_domains : !+relay_to_domains : \
${if exists {/home/$sender_address_local_part/.return-path-sign}\ {/home/$sender_address_local_part/.return-path-sign}\
{!*}}
no_more
S ohledem na ostatní použité směrovače je možné přidat další parametry (například same_doma-in_copy_routing=yes). Všimněte si,
že tento směrovač se nepoužije pro zprávy, které neobsa-hují adresu odesílatele.
Poznámka
V uvedených příkladech je podmínka senders redundantní, protože soubor /home//.return-path-sign pravděpodobně
neexistuje. Pro účely zpřehlednění tuto podmínku uvádíme expli-citně.
Vytvoření nového směrovače pro doručování v rámci místní domény
Dále je nutné říci Eximu, aby příchozí adresy příjemců, které jsou ve formátu uvedeném výše, doručoval do poštovní schránky
identifikované částí signatury před prvním znakem rovná se („=“). Pro tyto účely je nutné ještě předtím, než doručení v rámci
místní domény zajistí jiné směrovače (například směrovač system alias), vytvořit směrovač redirect v sekci routers v konfiguračním
souboru:
hashed_local: debug_print = “R: hashed_local for $local_part@$domain” driver = redirect domains = +local_domains local_part_suffix = =* data
= $local_part@$domain
Adresy příjemců, které obsahují znak rovná se, jsou překonvertovány tak, že části, které následují za znakem rovná se, jsou
odříznuty. Pak se zpracují všechny ostatní směrovače.
Seznam řízení přístupu s kontrolou signatury
V poslední fázi implementace signatur je nutné nakonfigurovat Exim tak, aby zprávy doručované na platné adresy příjemců se
signaturou byly akceptovány vždy. Ostatní zprávy s prázdnou adre-sou odesílatele budou odmítnuty pouze v případě, kdy
příjemce využívá stejné schéma. Ani v jed-nom případě by se neměl provádět greylisting.
Následující zdrojový kód by měl být umístěn do seznamu acl_rcpt_to před kontroly SPF grey-listing anebo poslední příkaz accept :
# Akceptuje adresy příjemců v případě, kdy obsahují vlastní signaturu.
# To znamená, že aktuální zpráva je odpově (oznámení o stavu doručení,
# ověření příjemce zpětným voláním) na zprávu, která pochází od nás.
#
accept
domains
condition
= +local_domains
= ${if and {{match{${lc:$local_part}}{^(.*)=(.*)}}\
{eq{${hash_8:${hmac{md5}{SECRET}{$1}}}}{$2}}}\
{true}{false}}
# V opačn駑 př厓adě je to vr當en_ zpr疱a (tj. pokud neobsahuje adresu # odes匀atele), ale
pokud př勀emce vyžaduje kontrolu signatury, dojde # k odm咜nut_. # deny
message = Adresa neobsahuje platnou signaturu \ z vchoz_ dom駭y.\n\ Odpov冝疸e na
podvrženou adresu odes匀atele.
log_message = falešn_ vr當en_ zpr疱a.senders = : postmaster@*domains = +local_domainsset
acl_m9 = /home/${extract{1}{=}{${lc:$local_part}}}\
/.return-path-sign condition = ${if exists {$acl_m9}{true}}
Při zasílání zpráv hostitelským systémům, které provádějí ověřování adres odesílatele zpětným voláním v záhlaví zprávy,
například v záhlaví From: odchozí zprávy, může vzniknout problém. Příkaz deny v takovém případě určitě vyhodnotí takový pokus
o ověření negativně. Proto je vhod-né poslední příkaz deny změnit na příkaz warn, uložit informaci o odmítnutí do proměnné
$acl_m0 a provést odmítnutí až po příkazu DATA takto:
# V opačném případě je to vrácená zpráva (tj. pokud neobsahuje # odesílatele ), ale pokud příjemce vyžaduje kontrolu signatury, dojde # k uložení
zprávy o odmítnutí do proměnné $acl_m0 a zprávy pro soubor # protokolu do proměnné $acl_m1. Tyto zprávy se využijí později při # vlastním
odmítnutí zprávy. V mezičase to znamená, že je nutné # odesílatele dále brzdit. # warn
senders = : postmaster@*domains = +local_domainsset acl_m9 = /home/${extract{1}{=}{${lc:$local_part}}}/\
.return-path-sign condition = ${if exists {$acl_m9}{true}}
set acl_m0 = Adresa příjemce <$local_part@$domain> neobsahuje \
platnou signaturu z výchozí domény.\n\
Odpovídáte na podvrženou adresu odesílatele.
set acl_m1 = falešná vrácená zpráva pro <$local_part@$domain>.
Pokud příjemce zvolí používání signatur adresy odesílatele v ochozích zprávách, může chtít nakonfigurovat výjimky z používání
signatur v příchozí poště tak, že vybrané hostitelské systémy nebudou muset poskytovat signaturu v příchozích zprávách, a to ani
v případě, kdy zpráva neob-sahuje adresu odesílatele. Tyto výjimky se mohou uplatnit u některých vybraných konferenčních
serverů. Více informací naleznete v části Signatury adresy odesílatele.
Akceptace vrácených zpráv pouze pro reálně existující uživatele
Jak bylo zmíněno v části o blokování zavlečeného spamu, existuje slabé místo, které brání v zachytávání falešných zpráv s
oznámeními o stavu doručení, zasílaných na systémové uživatele a aliasy (např. postmaster). V této kapitole naleznete dva
způsoby, jak zajistit, že vrácené zprávy jsou akceptovány pouze pro uživatele, kteří generují odchozí poštu.
Kontrola poštovní schránky příjemce
Tato kontrola se provádí v seznamu acl_rcpt_to. Kontroluje se, zda adresa příjemce odpovídá nějaké místní poštovní schránce:
# Odmítnutí zpráv pro uživatele, kteří nemají vlastní poštovní schránku
# (tj. postmaster, webmaster atd.), v případě, kdy zpráva neobsahuje
# adresu odesílatele. Tito uživatelé neodesílají žádné zprávy,
# takže by neměli dostávat ani žádné vrácené zprávy.
#
deny
message = Tato adresa nezasílá poštovní zprávy. \
Odpovídáte na falešnou adresu odesílatele.
log_message = falešná vrácená zpráva pro <$local_part@$domain>
senders = : postmaster@*
domains = +local_domains
!mailbox check
Kontrola mailbox check závisí na tom, jakým způsobem se provádí doručování zpráv (i v tomto případě se odděluje část před
prvním znakem rovná se („=“) v adrese příjemce, aby se ošetřil pří-pad signatury adresy).
■ Pokud jsou poštovní schránky mapovány na místní uživatelské účty na serveru, je možné kontrolovat, jestli je možné
mapovat jméno příjemce na identifikátor uživatele, který odpo-vídá skutečným uživatelům v systému, tj. v rozsahu 500–
60 000:
set acl_m9 = ${extract{1}{=}{ ${lc:$local_part}}}
set acl_m9 = ${extract{2}{:}{${lookup passwd{$acl_m9}{$value}}}{0}}
condition = ${if and{{>={$acl_m9}{500}}{<${acl_m9}{60000}}}{true}}
■
Pokud jsou zprávy doručovány pomocí softwaru Cyrus s využitím protokolu IMAP, je možné pro kontrolu existence dané
poštovní schránky použít nástroj mbpath. Pak je samozřejmě nutné zajistit, aby uživatel, pod kterým je Exim spuštěn, měl
oprávnění pro kontrolu poštovních schránek (například je možné tohoto uživatele přidat do skupiny cyrus: #adduser
exim4 cyrus).
set acl_m9 = ${extract{1}{=}{ ${lc:$local_part}}}
condition = ${run {/usr/sbin/mbpath -q -s user.$acl_m9} {true}}
■
Pokud jsou všechny zprávy směrovány na jiný počítač, který provádí jejich doručování, je možné provádět ověření adresy
příjemce zpětným voláním a nechat tento jiný počítač roz-hodnout, jestli zprávu přijme. Při provádění zpětného volání je
nutné ponechat původní adresu odesílatele nezměněnou:
verify = recipient/callout=use_sender
V případě místně doručovaných zpráv tato kontrola poštovních schránek duplikuje funkce prová-děné směrovačem, a protože je
specifická pro mechanismus doručování zpráv na poštovním ser-veru z našeho příkladu, může perfekcionistům z řad čtenářů
připadat trochu nečitelná.
Kontrola prázdné adresy odesílatele ve směrovači pro zpracování aliasů
V konfiguraci pravděpodobně máte obsažen směrovač s názvem system_aliases pro přesměro-vání zpráv pro uživatele typu
postmaster nebo mailer-demon. Tyto aliasy se obvykle nepoužívají jako adresy odesílatele v ochozích zprávách. Proto je možné
zajistit, aby příchozí oznámení o stavu doručení nebyla takovým směrovačem směrována přidáním následující podmínky:
!senders = : postmaster@*
Příklad směrovače pro aliasy pak může vypadat například takto:
system_aliases:
driver = redirect
domains = +local_domains
!senders = : postmaster@*
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases }}
user = mail
group = mail
file_transport = address_file
pipe_transport = address_pipe
V tomto okamžiku jsou blokovány vrácené zprávy na některé systémové aliasy, nicméně ostatní aliasy víceméně odpovídají
existujícím systémovým uživatelům (např. „root“, „daemon“ atd.). Pokud jsou místně doručované zprávy doručovány přes
ovladač accept a pro ověření adresy pří-jemce se využívá kontrola check_local_user, jsou v tomto okamžiku zprávy směrovány
přímo na tyto systémové účty.
Řešení tohoto problému spočív á v přidání další dodatečné podmínky do směrovače, který řídí doručování místních zpráv (tj. např.
local_user ), kterou se zkontroluje, že příjemce existuje a navíc je to „normální“ uživatel. Kontrolu je možné například provést
porovnáním identifikátoru uživatele, který by měl ležet v rozsahu 500–60 000:
condition = ${if and {{>={$local_user_uid}{500}}\
{<{$local_user_uid}{60000}}}\
{true}}
Příklad směrovače pro doručování místních zpráv tedy může vypadat takto:
local_user:
driver = accept
domains = +local_domains
check_local_user
condition = ${if and {{>={$local_user_uid}{500}}\
{<{$local_user_uid}{60000}}}\
{true}}
transport = transport
Při implementaci této metody je nutné mít na paměti, že odmítnutí falešné vrácené zprávy bude realizováno odezvou s kódem 550
Unknown User, tj. stejnou odezvou, která se používá pro odmítnutí zprávy v případě neexistujícího příjemce.
Výjimky pro přeposílané zprávy
Po přidání všech uvedených kontrol do transakcí protokolu SMTP určitě zjistíte nepřímé genero-vání zavlečeného spamu jako
výsledek odmítnutí zpráv přeposílaných z důvěryhodných zdrojů, jako jsou například mailinglisty nebo poštovní účty v jiných
hostitelských systémech. Takové hos-titelské systémy je proto nutné přidat do seznamu povolených položek a vyjmout je z
procesu odmítnutí – minimálně těch odmítnutí, která vzniknou v důsledku antivirové nebo antispamové kontroly.
V tomto příkladu se bude provádět při zpracování příkazu RCPT TO: kontrola obsahu dvou sou-borů:
Globální seznam povolených položek /etc/mail/whitelist-hosts, který obsahuje záložní poštovní servery a ostatní povolené
odesílatele
Individuální seznam uživatelských povolených položek /home/user/.forwarders, který obsahuje hostitelské systémy, ze
kterých může daný uživatel přijímat přeposílané zprávy (tzn. mailinglisty nebo poštovní servery odchozích zpráv z jiných domén
atd.)
Pokud uživatelé poštovního serveru nemají místní uživatelské účty a domovské složky, je nutné cesty k souborům a samotné
vyhledávání přizpůsobit konkrétnímu systému (například vyhledá-vání v databázi nebo dotazy do adresáře LDAP ). Pokud je daný
hostitelský systém odesílatele nale-zen v některém z těchto seznamů, uloží se do proměnné $acl_m0 hodnota „accept“ a obsah proměnné $acl_m1 se smaže tak, jak je to popsáno v předchozí části. To je indikátor, který udává, že zpráva by neměla být v průběhu
zpracování dalších příkazů transakce protokolu SMTP odmít-nuta.
Do seznamu acl_rcpt_to se hned za ověření adresy příjemce, ale před příkazy accept , které se týkají kontrol neautentizovných
doručení zpráv ze vzdálených hostitelských systémů místním uži-vatelům (tj. před greylisting, kontroly signatur atd.), vloží
následující kód:
# Akceptuje zprávu v případě, kdy je hostitelský systém odesílatele
# uveden v globálním seznamu povolených položek. Dočasně nastaví
# proměnnou $acl_m9 tak, aby odkazovala na tento soubor.
# Pokud je hostitelský systém v seznamu nalezen, nastaví proměnnou
# $acl_m0 a smaže hodnotu proměnné $acl_m1, která zabrání následnému
# pozdějšímu odmítnutí zprávy.
#
accept
set acl_m9 = /etc/mail/whitelist-hosts
hosts = ${if exists {$acl_m9}{$acl_m9}}
set acl_m0 = accept
set acl_m1 =
# Akceptuje zprávu v případě, kdy je hostitelský systém odesílatele # uveden v souboru „.forwarders“ v domovské složce příjemce zprávy.#
Dočasně nastaví proměnnou $acl_m9 tak, aby odkazovala na tento soubor. # Pokud je hostitelský systém v souboru nalezen, nastaví
proměnnou# $acl_m0 a smaže hodnotu proměnné $acl_m1, která zabrání následnému # pozdějšímu odmítnutí zprávy.
#
acceptdomains = +local_domainsset acl_m9 = /home/$ {extract{1}{=}{${lc:$local_part}}}/.forwardershosts = ${if exists {$acl_m9}
{$acl_m9}} set acl_m0 = acceptset acl_m1 =
Kontrola obsahu proměnné $acl_m0 se provádí na více místech seznamu acl_data a zabrání se tím případnému odmítnutí legitimní
zprávy. Podobným způsobem je například možné zabránit odmít-nutí zpráv od hostitelských systémů ze seznamu povolených
položek v důsledku chybějících záhla-ví zprávy dle definice z dokumentu RFC 2822 takto:
denymessage = Zpráva nevyhovuje standardu dle RFC 2822log_message = chybějící záhlaví!hosts = +relay_from_hosts!senders = :
postmaster@*condition = ${if !eq {$acl_m0}{accept}{true}}condition = ${if or {{!def:h_Message-ID:}\
{!def:h_Date:}\ {!def:h_Subject:}} {true}{false}}
Odpovídající kontroly jsou součástí konečné verze seznamů řízení přístupu v další kapitole.
Konečná verze seznamů řízení přístupu
Tak pojďme na to. Bylo to dlouhé čtení, každopádně gratuluji všem, kteří to zvládli až sem. Následující seznamy řízení přístupu
zahrnují všechny kontroly, které byly popsány v této imple-mentaci. Některé však byly zakomentovány z těchto důvodů:
Greylisting. Greylisting vyžaduje buď instalaci dodatečného softwaru nebo poměrně složitou konfiguraci dodatečných
seznamů řízení přístupů a definicí v konfiguračním souboru Eximu. I přesto však tuto metodu doporučuji.
Antivirový program. Bohužel neexistuje jediný antivirový program, který používají všichni tak, jak je tomu u
antispamového programu v podobě softwaru SpamAssassin. Implemen-tace antivirových kontrol je však s pomocí dokumentace,
která je součástí doplňku Exis-can-ACL, poměrně snadná.
Individuální uživatelská nastavení pro SpamAssassin. Pro mnohé je to implementačně neakceptovatelné, protože
zahrnuje zpožďování zpráv pro všechny příjemce zprávy s výjimkou prvního.
Signatury adresy odesílatele. Existují omezení pro uživatele, kteří se připojují v různých sítích. Kromě konfigurace
seznamů řízení přístupu také vyžaduje i konfiguraci směrovačů a komponent pro transport zpráv.
Akceptace vrácených zpráv pouze pro reálně existující uživatele. Existuje více způsobů
implementace, které jsou závislé na způsobu doručování zpráv. Následují jednotlivé konečné
verze seznamů řízení přístupu.
Seznam acl_connect
# Tento seznam se použije na začátku transakce při příjmu příchozího # připojení. Testy se provádí, aby se zjistilo, jestli příchozí
připojení # přijmout nebo odmítnout.
acl_connect: # Zaznamená aktuální čas pro výpočet doby trvání zpoždění. warn
set acl_m2 = $tod_epoch
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host. systému.#
Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.accept
hosts = : +relay_from_hosts
# Pokud se hostitelský systém nachází v některém seznamu zakázaných # položek systému DNS, uloží se varování do proměnné $acl_c1. Toto #
varování bude později přidáno do záhlaví zprávy. V mezičase hodnota # této proměnné indikuje, že je nutné pokračovat v brzdění odesílatele #
zprávy. #
warn
!hosts
dnslists
set acl_c1
= ${if exists {/etc/mail/whitelist-hosts} \
{/etc/mail/whitelist-hosts}}
= list.dsbl.org : \
dnsbl.sorbs.net : \
dnsbl.njabl.org : \
bl.spamcop.net : \
dsn.rfc-ignorant.org : \
sbl-xbl.spamhaus.org : \
l1.spews.dnsbl.sorbs.net
= X-DNSbl-Warning: \
$sender_host_address je v seznamu $dnslist_domain\
${if def:dnslist_text { ($dnslist_text)}}
# Pokud selže reverzn_ vyhled疱疣_ v syst駑u DNS (tj. neexistuje # položka rDNS nebo
dopředn_ vyhled疱疣_ n痙vu nevr疸_ adresu IP, # kter_ je shodn_ s původn_ adresou IP), pak se
vygeneruje varov疣_ # do proměnn_ $acl_c1. Toto varov疣_ bude později uloženo do z疉lav_ #
zpr疱y. warn
condition = ${if !def:acl_c1 {true}{false}} !verify = reverse_host_lookup set acl_m9 = Reverzn_
vyhled疣_ DNS selhalo pro $sender_host_address set acl_c1 = X-DNS-Warning: $acl_m9
# Akceptuje připojen_. Pokud je v proměnn_ $acl_c1 uloženo nějak_ # varov疣_, bude transakce
protokolu SMTP zpožděna o 20 sekund. accept
set acl_m2 = ${if def:acl_c1 {${eval:20 + $acl_m2 - $tod_epoch}}{0}} delay = ${if >{$acl_m2}
{0}{$acl_m2}{0}}s
Seznam acl_helo
# Tento seznam se použije pro kontrolu příkazu HELO nebo EHLO # v příchozí transakci protokolu SMTP. Testy se provádí, aby se zjistilo, #
jestli transakci při zpracování příkazu HELO nebo EHLO přijmout nebo # odmítnout.
acl_helo: # Zaznamená aktuální čas pro výpočet doby trvání zpoždění. warn
set acl_m2 = $tod_epoch
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host. systému.#
Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.#accept
hosts = : +relay_from_hosts
# Pokud vzdálený hostitelský systém uvede svou adresu IP, připraví se # zpráva o odmítnutí do proměnné $acl_c0 a zpráva pro soubor protokolu #
do proměnné $acl_c1. Později budou použity v příkazu „deny“. # V mezičase hodnota této proměnné indikuje, že je nutné pokračovat # v brzdění
odesílatele zprávy. # warn
condition = ${if isip {$sender_helo_name}{true}{false}} set acl_c0 = Zpráva byla doručena ratwarem set acl_c1 = vzdálený hostitel použil
adresu IP v příkazu HELO/EHLO
# Podobně v případě, kdy hostitelský systém použije název naší # vlastní domény.
#
warn
condition
set acl_c0
set acl_c1
= ${if match_domain{$sender_helo_name}\
{$primary_hostname:+local_domains:+relay_to_domains}\
{true}{false}}
= Zpráva byla doručena ratwarem
= vzdálený systém použil naši doménu v příkazu HELO/EHLO
# Pokud kontrola př勛azu HELO selže, ulož_ se varov疣_ do proměnn_ # acl_c1. Toto varov疣_
se později přid_ do z疉lav_ zpr疱y. # V mezičase hodnota t騁o proměnn_ indikuje, že je nutn_
pokračovat # v brzděn_ odes匀atele zpr疱y. # warn
condition = ${if !def:acl_c1 {true}{false}}!verify = heloset acl_c1 = X-HELO-Warning: Vzd疝
en FF 81 host $sender_host_address \
${if def:sender_host_name {($sender_host_name) }}\ se vyd疱_ za
$sender_helo_name log_message = vzd疝en FF 81host použil
neověřiteln FF 81 př勛az HELO/EHLO.
# Akceptuje připojen_. Pokud je v proměnn_ $acl_c1 uloženo nějak_ # varov疣_, bude
transakce protokolu SMTP zpožděna o 20 sekund.accept
set acl_m2 = ${if def:acl_c1 {${eval:20 + $acl_m2 - $tod_epoch}}{0}} delay = ${if >
{$acl_m2}{0}{$acl_m2}{0}}s
Seznam acl_mail_from
# Tento seznam řízení přístupu se použije pro příkaz MAIL FROM: v příchozí # transakci protokolu SMTP. Testy se provádějí, aby se zjistilo,
jestli # zprávu přijmout nebo odmítnut na základě adresy odesílatele. #
acl_mail_from: # Zaznamená aktuální čas pro výpočet doby trvání zpoždění. warn
set acl_m2 = $tod_epoch
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP) # Kontrola se provádí pro prázdnou položku odesílajícího host.
systému. # Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí # přeposílání (relay) zpráv. # # Ověření odesílatele se zde
neprovádí, protože klientské poštovní # aplikace jsou ve většině případů jednoduché a neumějí správně zpracovat # chybové odezvy protokolu
SMTP. # accept
hosts = : +relay_from_hosts
# Akceptování zprávy, která je doručována autentizovaným připojením # z libovolného hostitelského systému. Takové zprávy pocházejí
většinou # přímo od klientských poštovních aplikací. # accept
authenticated = *
# Proměnné $acl_c0 a $acl_c1 obsahují zprávu o odmítnutí nebo varování, # které je nutné použít při každém pokusu o doručení v rámci
aktuální # transakce protokolu SMTP. Jejich hodnotu je nutné přiřadit # odpovídajícím proměnným $acl_m{0,1}, které jsou platné po dobu #
zpracování zprávy, a přidat varování z proměnné $acl_m1 do záhlaví # zprávy. (V případě odmítnutí zprávy proměnná $acl_m1 obsahuje
zprávu # pro soubor protokolu, nicméně záhlaví bude zrušeno současně # s odmítnutou zprávou). #
warnset acl_m0 = $acl_c0set acl_m1 = $acl_c1message = $acl_c1
# Pokud odesílatel nepoužil příkaz HELO/EHLO, do proměnné $acl_m0 se # uloží zpráva o odmítnutí a zpráva pro soubor protokolu do
proměnné # $acl_m1. Tyto zprávy budou později použity v příkazu „deny“. # V mezičase hodnota této proměnné indikuje, že je nutné
pokračovat # v brzdění odesílatele zprávy. # warn
condition = ${if def:sender_helo_name {0}{1}}set acl_m0 = Zpráva byla doručena ratwaremset acl_m1 = Vzdálený hostitel nepoužil
příkaz HELO/EHLO.
# Pokud není možné ověřit adresu odesílatele, do proměnné $acl_m1 se # uloží varování, které se přidá do záhlaví zprávy. Přítomnost této #
zprávy udává, že je nutné pokračovat v brzdění odesílatele zprávy. # # Dle uvážení je možné vynechat možnost „callout”. Pokud jsou odchozí #
zprávy zasílány s využitím vyhrazeného hostitelského systému (tzv. # smarthost), nedá ověření vzdáleným voláním žádné užitečné výsledky. #
warn
condition = ${if !def:acl_m1 {true}{false}}!verify = sender/calloutset acl_m1 = Neplatný odesílatel <$sender_address>message = XSender-Verify-Failed: $acl_m1log_message = $acl_m1
# Akceptuje odesílatele. Pokud je v proměnné $acl_c1 uloženo nějaké # varování, bude transakce protokolu SMTP zpožděna o 20
sekund.accept
set acl_m2 = ${if def:acl_c1 {${eval:20 + $acl_m2 - $tod_epoch}}{0}} delay = ${if >{$acl_m2}{0}{$acl_m2}{0}}s
Seznam acl_rcpt_to
# Tento seznam řízení přístupu se použije pro příkaz RCPT v příchozí # transakci protokolu SMTP. Testy se provádějí, aby se zjistilo, jestli #
zprávu přijmout nebo odmítnut na základě adresy příjemce. #
acl_rcpt_to:
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host.
systému.# Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.#
# Ověření odesílatele se zde neprovádí, protože klientské poštovní # aplikace jsou ve většině případů jednoduché a neumějí správně zpracovat #
chybové odezvy protokolu SMTP. accept
hosts = : +relay_from_hosts
# Akceptování zprávy, která je doručována autentizovaným připojením # z libovolného hostitelského systému. Takové zprávy pocházejí většinou
# přímo od klientských poštovních aplikací. # accept
authenticated = *
# Odmítnutí zprávy se provede, pokud jméno v adrese obsahuje znaky @ # nebo % nebo / nebo | nebo !. Tyto znaky se ve jméně vyskytují velmi #
zřídka, ale občas je zkouší použít uživatelé, kteří se snaží # obejít omezení při přeposílání zpráv. # # Odmítnutí zprávy se provede i v případě, kdy
jméno začíná tečkou. # Prázdné části adresy nejsou podle striktního výkladu dokumentu # RFC 2822 povoleny, ale Exim je umožňuje využít,
protože # se obvykle používají. Pokud adresa začíná tečkou, může to způsobit # problém v případě, kdy se jméno používá jako název souboru
(například # pro mailinglist). # deny
local_parts = ^. *[@%!/|] : ^\\ .
# Odmítnutí zprávy v případě, kdy proměnná $acl_m0 obsahuje zprávu # o odmítnutí. Kromě toho se provede upoždění transakce protokolu
SMTP # o 20 sekund. # deny
message = $acl_m0log_message = $acl_m1condition = ${if and {{def:acl_m0}{def:acl_m1}} {true}}delay = 20s
# Pokud je adresa příjemce z jiné domény, než pro kterou se pošta # zpracovává, provede se zpoždění transakce a odmítnutí. # deny
message = přeposílání (relay) zpráv není dovoleno!domains = +local_domains : +relay_to_domainsdelay = 20s
# Pokud je adresa příjemce z místní domény nebo z domény, pro kterou se # provádí přeposílání pošty, ale je neplatná, provede se zpoždění #
transakce a odmítnutí.
#
deny
message
!verify
delay
= neznámý příjemce
= recipient/callout=20s,defer_ok,use_sender
= ${if def:sender_address {1m}{0s}}
# Ukončen_ připojen_ se provede v př厓adě, kdy je adresa odes匀atele # pr痙dn_, ale zpr疱a m_
v兤e adres př勀emců. Legitimn_ ozn疥en_ # o stavu doručen_ nen_ nikdy zasl疣o na v兤e
adres.
#
drop
message
senders
condition
delay
= Legitimní oznámení o stavu doručení nejsou zaslána \
více příjemcům.
= : postmaster@*
= $recipients_count
= 5m
# Omezen_ počtu př勀emců v každ_ př兤hoz_ zpr疱ě na jednoho
# s c匀em umožnit podporu pro individu疝n_ nastaven_ parametrů
# (např. pro SpamAssassin).
#
# POZNﾁMKA: Každ_ zpr疱a zaslan_ v兤e uživatelům bude zpožděna
# o 30 minut nebo v兤e na jednoho př勀emce. To může vznamnm
# způsobem ovlivnit interaktivn_ diskuse, kter_ využ咩aj_ zpr疱y
# elektronick_ pošty a jichž se č俉stn_ jak m﨎tn_, tak
# vzd疝en_ č俉stn兤i. Proto je tato č疽t zakomentovan_.
#
defer message = Akceptuje se pouze jeden př勀emce zpr疱y.
condition = $recipients_count
# Akceptuje zpr疱u v př厓adě, kdy je hostitelsk FF 81 syst駑 odes匀atele
# uveden v souboru „.forwarders“ v domovsk_ složce př勀emce zpr疱y.
# Dočasně nastav_ proměnnou $acl_m9 tak, aby odkazovala na tento soubor.
# Pokud je hostitelsk FF 81 syst駑 v souboru nalezen, nastav_ proměnnou
# $acl_m0 a smaže hodnotu proměnn_ $acl_m1, kter_ zabr疣_ n疽ledn駑u
# pozdějš匇u odm咜nut_ zpr疱y.
#
accept domains = +local_domains set acl_m9 = /home/${extract{1}{=}{${lc:
$local_part}}}/.forwarders hosts = ${if exists {$acl_m9}{$acl_m9}} set acl_m0 = accept set
acl_m1 =
# Akceptuje zpr疱u v př厓adě, kdy je hostitelsk FF 81 syst駑 odes匀atele # uveden v glob疝n匇
seznamu povolench položek. Dočasně nastav_ # proměnnou $acl_m9 tak, aby odkazovala na
tento soubor. # Pokud je hostitelsk FF 81 syst駑 v seznamu nalezen, nastav_ proměnnou # $acl_m0 a
smaže hodnotu proměnn_ $acl_m1, kter_ zabr疣_ n疽ledn駑u # pozdějš匇u odm咜nut_ zpr疱y.
# accept
set acl_m9 = /etc/mail/whitelist-hostshosts = ${if exists {$acl_m9}{$acl_m9}}set acl_m0 =
acceptset acl_m1 =
# --------------------------------------------------------------------# Kontrola signatury adresy odes匀
atele.# Tato č疽t je zakomentovan_, protože vyžaduje dalš_ konfiguraci# v č疽tech ‘transports’ a
‘routers’.## Akceptuje adresy př勀emců v př厓adě, kdy obsahuj_ vlastn_ signaturu. # To
znamen_, že aktu疝n_ zpr疱a je odpově (ozn疥en_ o stavu doručen_,# ověřen_ př勀emce
zpětnm vol疣匇) na zpr疱u, kter_ poch痙_ od n疽.### accept# domains = +local_domains#
condition = ${if and {{match{${lc:$local_part}}{^(.*)=(.*)}}\# {eq{${hash_8:${hmac{md5}
{SECRET}{$1}}}}{$2}}}\# {true}{false}}
# V opačn駑 př厓adě je to vr當en_ zpr疱a (tj. pokud neobsahuje # odes匀atele, ale pokud př勀
emce vyžaduje kontrolu signatury, dojde# k odm咜nut_.## deny# message = Adresa neobsahuje
platnou signaturu \# z vchoz_ dom駭y.\n\# Odpov冝疸e na podvrženou adresu odes匀atele.#
log_message = falešn_ vr當en_ zpr疱a.# senders = : postmaster@*# domains =
+local_domains# set acl_m9 = /home/${extract{1}{=}{${lc:$local_part}}}\# /.return-pathsign# condition = ${if exists {$acl_m9}{true}}#
-------------------------------------------------------------------# --------------------------------------------------------------------# Odm咜nut_ zpr疱 pro uživatele,
kteř_ nemaj_ vlastn_ poštovn_ schr疣ku # (tj. postmaster, webmaster atd.), v př厓adě, kdy zpr疱
a neobsahuje # adresu odes匀atele. Tito uživatel_ neodes匀aj_ ž疆n_ zpr疱y, # takže by neměli
dost疱at ani ž疆n_ vr當en_ zpr疱y.# Pozn疥ka: Tato kontrola je zakomentovan_, protože z疱is_
na # způsobu doručov疣_ m﨎tn兤h zpr疱. Pokud chcete tuto kontrolu# použ咜, je nutn_
okomentovat pouze jednu z d疝e uvedench podm匤ek.#deny# message = Tato adresa nezas匀_
poštovn_ zpr疱y. \# Odpov冝疸e na falešnou adresu odes匀atele.# log_message = falešn_ vr當
en_ zpr疱a pro <$local_part@$domain># senders = : postmaster@*
# domains = +local_domains# set acl_m9 = ${extract{1}{=}{${lc:$local_part}}}## --- Pokud
maj_ př勀emci m﨎tn_ uživatelsk_ č偀y, odkomentovat 2 ř疆ky:# set acl_m9 = ${extract{2}{:}
{${lookup passwd {$acl_m9}{$value}}}{0}}# !condition = ${if and {{>={$acl_m9}{500}} {<
${acl_m9}{60000}}}{true}}# # --- Pokud se doručuje s využit匇 softwaru Cyrus, odkomentovat
ř疆ek:# condition = ${run {/usr/sbin/mbpath -q -s user.$acl_m9} {true}}#
-------------------------------------------------------------------# Dotaz na informace SPF pro dom駭u odes匀atele zpr疱y.
# Podle vsledku se rozhodne, jestli je hostitelsk FF 81 syst駑 odes匀atele
# zpr疱y autorizovan FF 81 pro doručen_ zpr疱y.
# Pokud ne, zpr疱a je odm咜nuta.
#
deny
message = [SPF] $sender_host_address nem_ umožněno zas匀at zpr疱y \
z dom駭y $sender_address_domainlog_message = kontrola SPF selhalaspf = fail
# Přid疣_ z疉lav_ SPF-Received: do zpr疱y
warn message = $spf_received
# Pro z﨎k疣_ stavu pro dan FF 81 triplet (hostitel, odes匀atel, př勀emce) se # využije d駑on
„greylistd“. # Před použit匇 dalš劜o k E5 28u je nutn_ nainstalovat d駑ona „greylistd“. # Viz: http://
packages.debian.org/unstable/main/greylistd # # Greylisting se neprov疆_ pro zpr疱y bez odes匀
atele, protože ověřen_ # odes匀atele zpětnm vol疣匇 by nefungovalo (a pravděpodobně by
nebylo # možn_ zaslat zpr疱u syst駑u, kter FF 81 toto ověřov疣_ prov疆_). # # defer # message =
$sender_host_address ještě nen_ autorizov疣 pro # doručení\ # zpr疱y z adresy <
$sender_address> na adresu\ # <$local_part@$domain>. Pros匇 zkuste později. # log_message =
blokov疣o greylistingem. # domains = +local_domains : +relay_to_domains # !senders = :
postmaster@* # set acl_m9 = $sender_host_address $sender_address # $local_part@$domain #
set acl_m9=${readsocket{/var/run/greylistd/socket}{$acl_m9}{5s}{}{}} # condition = ${if eq
{$acl_m9}{grey}{true}{false}} # delay = 20s #
------------------------------------------------------------------# Akceptuje př勀emce. accept
Seznam acl_data
# Tento seznam řízení přístupu se využívá pro kontrolu dat obsahu zprávy. # Testy se provádějí, aby se zjistilo, jestli zprávu přijmout nebo #
odmítnout na základě adresy příjemce.
acl_data: # Zaznamenání záhlaví warn
logwrite = Subject: $h_Subject:
# Přidání záhlaví Message-ID do zprávy zaslané klienty z vlastní domény # v případě, kdy záhlaví ve zprávě chybí. warn
condition = ${if !def:h_Message-ID: {1}}hosts = +relay_from_hostsmessage = Message-ID: <E$message_id@$primary_hostname>
# Akceptování zprávy přijaté z lokální služby SMTP (tj. ne přes TCP/IP)# Kontrola se provádí pro prázdnou položku odesílajícího host.
systému.# Akceptuje zprávy přijaté z hostitelských systémů, pro které se provádí# přeposílání (relay) zpráv.#accept
hosts = : +relay_from_hosts
# Akceptování zprávy, která je doručována autentizovaným připojením
# z libovolného hostitelského systému.
#
accept
authenticated = *
# Odmítnutí zprávy v případě, kdy proměnná $acl_m0 obsahuje zprávu # o odmítnutí. Kromě toho se provede upoždění transakce protokolu
SMTP # o 20 sekund. # deny
message = $acl_m0 log_message = $acl_m1 condition = ${if and {{def:acl_m0}{def:acl_m1}} {true}{false}} delay = 20s
# Vynucení kontroly omezení velikosti zprávy
#
deny
message = Velikost zprávy $message_size je větší než limit \ MESSAGE_SIZE_LIMIT
condition = ${if >{$message_size}{MESSAGE_SIZE_LIMIT}{yes}
{no}}
# Odmítnutí zprávy v případě, kdy není korektní syntaxe záhlaví.
#
deny message = Zpráva nevyhovuje specifikaci standardu z RFC 2822 log_message = chyba při syntaktické kontrole záhlaví zprávy !verify =
header_syntax
# Následující řádky odkomentujte pro odmítnutí zpráv bez záhlaví # Message-ID:, Date: nebo Subject:.# Někteří specializovaní agenti přenosu
zpráv (některé mailinglistové # servery) automaticky negenerují záhlaví Message-ID pro vrácené zprávy.# Proto je přidaná kontrola na
neprázdnost adresy odesílatele.## deny# message = Zpráva nevyhovuje specifikaci standardu z RFC 2822# log_message = chybějící záhlaví
zprávy# !hosts = +relay_from_hosts# !senders = : postmaster@*# condition = ${if or {{!def:h_Message-ID:}\# {!def:h_Date:}\# {!
def:h_Subject:}} {true}{false }}
# Varování v případě, kdy není nalezena platná adresa odesílatele ani
# v jednom ze záhlaví „Sender:”, „Reply-To:” nebo „From:”.
#
warn message = X-Sender-Verify-Failed: Nenalezena platná adresa\ odesílatele
log_message = Nenalezen platný odesílatel !verify = header_sender
# --------------------------------------------------------------------# Greylisting pro zprávy bez adresy odesílatele.# Pro tyto zprávy se neprovádí
greylisting po příkazu RCPT TO:, protože # by to kolidovalo se vzdálenými systémy, které provádějí ověřování# odesílatele zpětným voláním.#
Protože je adresa odesílatele prázdná, nepoužívá se.## Před použitím dalšího kódu je nutné nainstalovat démona „greylistd“.# Viz: http://
packages.debian.org/unstable/main/greylistd##defer# message = $sender_host_ address ještě není autorizován pro # doručení\# zprávy z adresy <
$sender_address> na adresu\# <$local_part@$domain>. Prosím zkuste později.# log_message = blokováno greylistingem.# senders = :
postmaster@*# condition = ${if !eq {$acl_m0}{accept}{true}}# set acl_m9 = $sender_host_address $recipients# set acl_m9 =${readsocket{/var/
run/greylistd/socket}{$acl_m9}{5s}{}{}}# condition = ${if eq {$acl_m9}{grey}{true}{false }}# delay = 20s
# ------------------------------------------------------------------# --- ZAČÁTEK KONFIGURACE EXISCAN -# Odmítnutí zpráv s chybami kódování MIME. # deny
message = Chyba kódování MIME ($demime_reason)demime = *condition = ${if >{$demime_errorlevel}{2}{1}{0}}
# Rozbalení kontejnerů v kódování MIME a odmítnutí souborů s příponami,
# které využívají viry.
# Zde se provádí další volání příkazu demime, které ovšem vrátí výsledky
# uložené ve vyrovnávací paměti.
# Seznam přípon nemusí být úplný.
#
deny
message = Zde neakceptujeme přílohy s příponou „.$found_extension”. demime = bat:btm:cmd:com:cpl:dll:exe:lnk:msi:pif:prf:reg:scr:vbs:url
# Zprávy větší než MESSAGE_SIZE_SPAM_MAX jsou přijaty bez antivirové # a antispamové kontroly accept
condition = ${if >{$message_size}{MESSAGE_SIZE_SPAM_MAX} {true}}logwrite = :main: Zpráva
nekontrolována \(velikost větší než MESSAGE_SIZE_SPAM_MAX)
# -------------------------------------------------------------------# Antivirová kontrola # Vyžaduje nastavení parametrů ‘av_scanner’ v hlavní sekci. #
#deny # message = Tato zpráva obsahuje virus ($malware_name) # demime = * # malware = */defer_ok #
-------------------------------------------------------------------
# Volání nástroje SpamAssassin pro získání hodnot $spam_score # a $spam_report. # V závislosti na klasifikaci obsahuje proměnná $acl_m9
hodnotu # „ham” nebo „spam”. # Pokud je zpráva klasifikována jako spam a proměnná $acl_m0 není # nastavena pro přijetí zprávy, je odmítnuta.
# warn
set acl_m9 = ham # Pokud se využívají individuální nastavení softwaru SpamAssassin pro # jednotlivé uživatele, odkomentujte následující
řádek a zakomentujte # „spam = mail“. # Předává se uživatelské jméno, které je součástí adresy příjemce, # tj. část před prvním výskytem
znaku „=“ nebo „@“, převedená na malá # písmena. Zpráva by díky předchozímu omezení již neměla mít více # příjemců. # spam = ${lc:
${extract{1}{=@}{$recipients}{$value}{mail}}} # ------------------------------------------------------------------spam = mail set acl_m9 = spam
control = fakereject logwrite = :reject: Odmítnutý spam (score $spam_score): $spam_report
# Přidání záhlaví X-Spam-Status: do zprávy.
#
warn
message
logwrite
= X-Spam-Status: \
${if eq {$acl_m9}{spam}{Yes}{No}} (score $spam_score)\
${if def:spam_report {: $spam_report}}
= :main: Klasifikováno jako $acl_m9 (score $spam_score)
# --- KONEC KONFIGURACE EXISCAN -# Akceptace zpr疱y. # accept
Slovník
Ve slovníku jsou uvedeny definice některých slov a termínů, použitých v rámci tohoto dokumentu.
Bayesův filtr
Filtr, který přiřazuje pravděpodobnost, že zpráva je spam, na základě obsahu slov (lépe řečeno na
základě výskytu slov nebo frází) z jednotlivých zpráv. Filtr je nejprve nutné vytrénovat tak, že se mu dají k dispozici zprávy
nevyžádané pošty a zprávy legitimní pošty. Filtr pak přidělí každému slovu (frázi) ve zprávách hodnocení s tím, jestli se dané
slovo nebo fráze vyskytuje v legitimní nebo nevyžádané poště. Slovo spolu se svým hodnocením je uloženo v Bayesově indexu.
Tyto filtry mohou zachytit takové příznaky nevyžádané pošty, které jsou programátory opomíjeny při vytváření filtrů založených
na seznamech klíčových slov. Bayesovy filtry jsou vždy specificky nastaveny pro jazyk, ve kterém se provádí trénink, a navíc se
nastavení může pro jednotlivé uži-vatele lišit. Proto jsou vhodné pro individuální filtrování zpráv jednotlivých uživatelů víc než
pro celoplošné filtrování zpráv v rámci celé domény.
Spameři však našli způsob, jak tyto filtry obejít tím, že do svých zpráv přidávají náhodná slova ze slovníku nebo celé části textu.
To snižuje pravděpodobnost, že filtr ohodnotí zprávu jako spam, a v dlouhodobějším měřítku degraduje kvalitu Bayesova filtru.
Více informací naleznete na adrese http://www.everything2.com/index.pl?node=Bayesian.
Collateral damage – zavlečené škody
Blokování legitimních odesílatelů díky záznamům v seznamech zakázaných položek systému DNS. Některé seznamy (například
seznam SPEWS) obvykle zařadí do seznamu celý adresní prostor poskytovatele připojení v případě, kdy mají správci seznamu
pocit, že poskytovatel nereaguje odpovídajícím způsobem na stížnosti, což má vliv na všechny jeho zákazníky.
Collateral spam – zavlečený spam
Automaticky generované zprávy, které jsou zasílány jako odezva na původní zprávu (obvykle nevyžádanou poštu nebo malware)
v případě, kdy je adresa odesílatele falešná. Typickými pří-klady zavlečeného spamu jsou falešná oznámení o viru nebo jiná
oznámení o stavu doručení.
Delivery status notification – oznámení o stavu doručení
Zpráva automaticky generovaná agentem přenosu zpráv nebo agentem doručení zpráv, která informuje odesílatele původní zprávy
o stavu doručení. Oznámení o stavu doručení může napří-klad informovat odesílatele původní zprávy o tom, že původní zprávu
nebylo možné doručit díky nějakým dočasným nebo trvalým problémům, anebo o tom, jak dlouho ještě budou případně další
pokusy o doručení pokračovat.
Domain Name System
Standard pro získávání informací o názvech domén v prostředí Internetu. Příklady takových infor-mací jsou například adresy IP
serverů (tzv. záznamy typu A), adresy poštovních serverů (záznamy typu MX), obecné informace o serverech (záznamy typu
SRV) nebo jiné textové informace (zá-znamy typu TXT). Systém DNS je distribuovaný a hierarchický. Každý název domény má
přiřazen jeden nebo více serverů služby DNS, které poskytují informace o této doméně – včetně delego-vání názvové služby pro
poddomény. Doménu nejvyšší úrovně „org“ spravuje registr The Public Internet Registry. Servery služby DNS delegují dotazy
pro doménu „tldp.org“ na specifické názvo-vé servery domény The Linux Documentation Project. Názvové servery této domény
pak mohou nebo nemusí delegovat dotazy na domény třetí úrovně (např. www.tldp.org).
Vyhledávání v systému DNS obvykle provádějí směrující názvové servery, například ty, které jsoupřiděleny poskytovatelem
připojení k Internetu.Oznámení o stavu doručení jsou zasílána s prázdnou adresou odesílatele.
Envelope recipient – adresa příjemce
Adresa příjemce, na kterou je zpráva doručena. Adresa je uvedena ve zprávě v průběhu transak-ce protokolu SMPT v příkazu
RCPT TO:. Tato adresa může být odlišná od adres uvedených v záhlaví „To:“ a „Cc:“ zprávy.
Envelope sender – adresa odesílatele
Adresa odesílatele, která je uvedena ve zprávě v průběhu transakce protokolu SMTP v příkazu MAIL FROM:. Tato adresa může
být odlišná od adresy uvedené v záhlaví „From:“ vlastní zprávy. Speciálním případem je oznámení o stavu doručení, u něhož je
adresa odesílatele prázdná. Tím se zabrání vzniku zacyklených zpráv a umožní se odlišení tohoto typu zpráv od ostatních zpráv.
False negative – falešná negativní detekce
Nevyžádaná pošta (spam, virus nebo malware), která je chybně klasifikovaná jako legitimní pošta, a tudíž nezablokovaná a
nefiltrovaná.
False positive – falešná pozitivní detekce
Legitimní pošta, která je chybně klasifikovaná jako spam, a tudíž zablokovaná a filtrovaná.
Fully Qualified Domain Name – úplný název domény
Úplný, globálně jedinečný internetový název domény, například www.yahoo.com. Úplný název domény většinou neodkazuje na
jediný hostitelský systém. Služby typu www obvykle odkazují na mnoho adres IP, aby bylo možné na jednotlivých serverech
provádět vyvažování zátěže. Primár-ní název hostitelského systému by měl být vždy jedinečný, například
p16.www.scd.yahoo.com. Úplný název domény vždy obsahuje znak tečka („.“). První část názvu před první tečkou je tzv. neúplný
název a není globálně jedinečný.
Joe Job
Spam, který vypadá tak, že pochází z platné adresy, obvykle pokus o získání informací nebo pokus o poškození vlastníka takto
podvržené adresy. Viz také http://www.everything2.com/ index.pl?node=Joe%20Job.
Mail Delivery Agent – agent doručení zpráv
Software, který je spuštěn na počítači, kde je umístěna poštovní schránka uživatele, a který zajišťuje doručení zpráv do schránky.
Doručení zprávy se provádí agentem přenosu zpráv, který slouží následně jako agent doručení zpráv. Mezi agenty doručení zpráv
patří například Delivery, Procmail, Cyrmaster nebo Cyrdeliver (ze sady nástrojů Cyrus IMAP).
Mail Exchanger – poštovní server
Server vyhrazený pro příjem a odesílání poštovních zpráv pro danou internetovou doménu. Zóna systému DNS pro danou
internetovou doménu obvykle obsahuje seznam úplných názvů systémů, které pracují jako poštovní servery pro danou doménu.
Každý takový poštovní server je identifi-kován záznamem typu MX a také svou prioritou v případě, kdy poštu pro doménu
obsluhuje více poštovních serverů. Server s nejnižší prioritou je považován za primární poštovní server pro danou doménu.
Mail Loop – zacyklení zpráv
Situace, kdy jedna automaticky generovaná zpráva způsobí vygenerování jiné zprávy, která spus-tí vygenerování další zprávy atd.
Příkladem může být například mailinglist, v němž jeden z uživa-telů má adresu vlastního mailinglistu. V takových případech se
většinou využívá záhlaví „X-Loop:“ a zprávy, které takové záhlaví obsahují, již nejsou zpracovávány.
Mail Transport Agent – agent přenosu zpráv
Software, který je spuštěn na poštovním serveru dané internetové domény a zasílá a přijímá zprá-vy z jiných hostitelských
systémů. Mezi agenty přenosu zpráv patří například Sendmail, Postfix, Exim nebo Smail.
Mail User Agent – klientský software
Software, který používá uživatel pro přístup, stahování, čtení a odesílání zpráv. Mezi klientský soft-ware patří například Microsoft
Outlook nebo Outlook Express, Apple Mail.app, Mozilla Thunder-bird nebo Ximian Evolution.
Mikropayment schemes – mikroplatební systémy
Odesílatel zprávy využije prostředky poštovního serveru pro vytvoření virtuální poštovní známky pro každého příjemce zprávy.
Obvykle se to realizuje vyřešením nějaké matematické úlohy, která vyžaduje velký počet paměťových operací, ale je relativně
nenáročná na výkon procesoru. Známka je přidána do záhlaví zprávy a příjemce může provést ověření známky jednodušší
dekódovací operací. Základní myšlenka tohoto systému je, že díky nutnosti použít poštovní známku pro kaž-dou adresu příjemce
by hromadné odesílání spamu tisícům uživatelů bylo poněkud výpočetně „náročné“.
Mezi mikroplatební systémy patří například:
Camram (viz http://www.camram.org/)
Penny Black Project firmy Microsoft. (http://research.microsoft.com/research/sv/ PennyBlack/)
Open Proxy – otevřený proxy systém
Proxy systém, který akceptuje připojení protokolu TCP/IP odkudkoliv a přesměruje je kamkoliv. Takové systémy jsou obvykle
zneužívány spamery, kteří je využívají pro zakrytí vlastní adresy IP a efektivnější distribuci nevyžádaných zpráv mezi mnoho
hostitelských systémů a sítí.
Open Relay – systém, který umožňuje přeposílání zpráv
Systém, který akceptuje poštovní zprávy od kohokoliv a přesměrovává je kamkoliv. V roce 1980 byl takřka každý poštovní server
typu open relay. Zprávy obvykle předtím, než byly doručeny pří-jemcům, procházely přes více hostitelských systémů. V
současnosti jsou legitimní zprávy od ode-sílatelů téměř výhradně zasílány odchozími agenty přenosu zpráv a doručovány
poštovním serve-rům domén příjemců. Servery Open Relay existují i v současnosti a jsou téměř výhradně zneuží-vány spamery
pro zakrytí vlastní identity a pro vyvažování zátěže při rozesílání miliónů zpráv v co největším objemu předtím, než seznamy
zakázaných položek systému DNS stihnou zaregistrovat všechny takové Open Relay servery.
Proxy
Počítač, který provádí úkoly v zastoupení někoho jiného. Může například směrovat požadavky protokolu HTTP nebo připojení
protokolu TCP/IP do nebo z Internetu. Velké organizace nebo někdy i celé země používají webové proxy pro filtrování odchozích
požadavků protokolu HTTP z vnitřních sítí. Tento proces může nebo nemusí být pro koncové uživatele transparentní.
Ratware
Software používaný spamery pro hromadné rozesílání nevyžádané pošty, který je navržen s cílem doručit co možná největší
objem zpráv ve velice krátkém čase. Většina softwaru tohoto typu obsa-huje pouze nejnutnější implementaci protokolu SMTP,
která umí doručit zprávy pouze v ideálním případě. Implementace zahrnuje poskytování falešných nebo nepřesných informací v
transakcích protokolu SMTP. Ratware nečeká na odezvy z poštovního serveru a odpojí se v případě, kdy neobdrží odezvu po pár
sekundách. Ratware nedodržuje normální mechanismus doručování v pří-padě dočasného selhání služby.
Relay – systém pro přeposílání zpráv
Počítač, který provádí přeposílání zpráv obvykle do nebo z Internetu. Příkladem může být například vyhrazený systém
poskytovatele, přes který zasílají odchozí zprávy všichni zákazníci poskytovatele.
Request for Comments – dokumenty RFC
Definice, která pochází z adresy http://www.rfc-editor.org/, říká: „Sada dokumentů RFC je sada technických a organizačních
poznámek na téma Internet. […] Poznámky v dokumentech RFC obsahují různé aspekty počítačových sítí, včetně protokolů,
procedur, programů a metod a jiných poznámek, názorů a také humoru.“
Dokumenty obsahují kromě jiného i popisy protokolů a formátů dat. O doručování zpráv pojednávají následující dokumenty:
RFC 2821 „Simple Mail Transfer Protocol“
RFC 2822 „Internet Message Format“
Spam Trap – spamová past
Adresa zpráv elektronické pošty, která je nastražena tak, aby ji mohli snadno získat roboti, kteří sbírají adresy v prostředí
Internetu. Obvykle se používají jako zdroj spamu pro seznamy zakáza-ných položek systému DNS nebo pro úložiště signatur
zpráv nevyžádané pošty. Zprávy zaslané na tuto adresu jsou v naprosté většině pouze spam nebo malware. Některé takové zprávy
však mohou být zavlečený spam, který obsahuje například oznámení o stavu doručení s podvrženými adresami odesílatele. Pokud
spamová past neobsahuje mechanismus, jak odfiltrovat takové zprá-vy, může být jako zdroj spamu nespolehlivá.
Zombie host – hostitelský systém – zombie
Hostitelský systém s připojením k Internetu infikovaný virem nebo červem, který rozesílá zprávy elektronické pošty. Takové
hostitelské systémy obvykle využívají operační systém Microsoft Win-dows a obvykle jsou to „domácí“ uživatelé. Vlastníci
těchto systémů obvykle nemají tušení o tom, že je systém infikovaný, a jejich poskytovatelé připojení k Internetu obvykle
nepodniknou nic pro jejich odpojení.
Naštěstí existují seznamy zakázaných položek systému DNS, jako je např. „dul.dnsbl.sorbs.net“, který obsahuje bloky adres
takových „domácích“ uživatelů. Tento seznam je vhodné využít pro odmítání příchozích zpráv. Legitimní zprávy od takových
uživatelů obvykle zasílají vyhrazené poštovní servery poskytovatelů.