Stejně jako veškeré ostatní antispamové metody (a metody řízení přístupu), které tu byly a budou představeny, představují i „restrictions“ v Postfixu dvousečnou zbraň. Na jednu stranu pomáhají v odmítání nechtěné a nevyžádané pošty, ale stejně tak mohou zabránit v přijetí regulérního mailu – stačí ne zcela vhodně nastavený server. Vždy je třeba zvážit přínos versus náklady, kde přínosem je vliv na příjem a propouštění spamu a náklady představují podíl regulérních mailů, které jsou odmítnuty.

Restrictions

Jak název napovídá, restrictions jsou omezení různého typu a v různé fázi průběhu odesílání nebo příjmu pošty dle SMTP protokolu. Znalost tohoto protokolu, alespoň rámcově, je pro pochopení vítaná až nutná. Pokud SMTP protokol neznáte, přečtěte si první díl seriálu o poštovním serveru nebo samotné RFC 5321. Restrictions umožňují omezit množství propuštěného spamu využitím mezer v softwaru spammerů, resp. faktu, že tento software často nerespektuje příslušná RFC nebo jejich doporučení. Problémem je, jak je již naznačeno výše, že tato omezení mohou odmítnout i regulérní e-mail přicházející z ne zcela vhodně nakonfigurovaného poštovního serveru.

Následují proměnné definující jednotlivá omezení:

• smtpd_client_restrictions – omezení SMTP klienta

• smtpd_helo_restrictions – omezení vztažené k HELO/HELO příkazu

• smtpd_sender_restrictions – omezení dle původce e-mailu (příkaz MAIL FROM: v rámci SMTP relace)

• smtpd_recipient_restrictions – jediná povinná položka, omezení vztažená k RCPT TO:

• smtpd_data_restrictions – omezení vztažená k příkazu DATA

• smtpd_end_of_data_restrictions – omezení vztažená k příkazu ukončujícímu přenos dat

• smtpd_etrn_restrictions – omezení příkazu ETRN

Tyto proměnné obsahují seznam pravidel (oddělených čárkou). Některá pravidla jsou společná (např. check_policy_service, reject či permit), jiná jsou specifická pro daný typ omezení. Podrobný popis jednotlivých omezení a všech možných hodnot naleznete v dokumentaci Postfixu, tj. buď v online podobě, nebo pomocí příkazu:

man 5 postconf

Připomínám, že tato omezení se definují v /etc/postfix/main.cf. Aktuálně nastavená omezení si můžete nechat vypsat příkazem:

postconf | grep restrictions

Aby to nebylo tak jednoduché, existují ještě další proměnné vztažené k daným omezením. Kupříkladu, smtpd_helo_required řídí, zda je příkaz HELO (či EHLO) vyžadován, nebo jej klient nemusí posílat. Pravidla umístěná v proměnné smtpd_helo_restrictions pak definují, jakým podmínkám musí příkaz HELO vyhovět (byl-li v průběhu SMTP relace zadán). Těchto proměnných je celá řada (viz dokumentace).

Ještě než se dostanu k samotným příkladům, zmíním jednu důležitou související proměnnou, a sice smtpd_delay_reject, kterou doporučuji nastavit na „yes“:

smtpd_delay_reject = yes

Tato volba zajistí, že v případě nevyhovění některému z pravidel nedojde k okamžitému odmítnutí, ale vyčká se s odmítnutím až na fázi po zadání RCPT TO:. To má jednak výhodu v kompatibilitě s některými špatně napsanými klienty, ale mnohem podstatnější je skutečnost, že díky tomu bude moci server v případě odmítnutí zaznamenat odesílatele i příjemce zprávy (což se pak dozvíte z logu).

smtpd_helo_restrictions

Příklad pro smtpd_helo_restrictions, omezení vztažená k příkazu HELO/EHLO následuje:

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    permit

Seznam pravidel se prochází směrem od prvního k poslednímu, jak je obvyklé. První pravidlo, permit_mynetworks, propustí klienta z rozsahu definovaného v proměnné mynetworks, aniž by musel vyhovět kterémukoliv dalšímu pravidlu.

Pravidlo reject_invalid_helo_hostname odmítne klienta, pokud je jím použitá syntaxe hostname příkazu HELO/EHLO neplatná. Pravidlo reject_non_fqdn_helo_hostname pak dále požaduje, aby klient uvedl jako hostname plně kvalifikované doménové jméno, jak požaduje RFC.

Nezachytí-li se klient u některého z předchozích pravidel, dostane se na konec seznamu, kde je pravidlo permit, které ho pustí dál.

Rozhodnete-li se nasadit tato omezení, bývá dobré také požadovat, aby klient příkaz HELO/EHLO uváděl (to je realizováno na prvním řádku příkladu, pomocí proměnné smtpd_helo_required).

smtpd_sender_restrictions

Tato omezení se vztahují k příkazu MAIL FROM: v rámci SMTP relace. Pozor – pole From: může následovat i v hlavičce mailu, kde už jeho obsah nehraje (v rámci tohoto omezení) roli.

smtpd_sender_restrictions =
    permit_mynetworks,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit

Struktura je podobná jako v příkladě výše. Pravidlo reject_non_fqdn_sender odmítne odesílatele, který nemá plně kvalifikované doménové jméno, jak je požadováno v RFC. Pravidlo reject_unknown_sender_domain pak odmítne klienta, který v doménové části e-mailu použije doménu, která nemá definovaný A ani MX záznam nebo která má nekorektní MX záznam. V případě dočasné chyby DNS vrací chybový kód 450 (čímž instruuje klienta, aby zkusil doručit mail později).

smtpd_recipient_restrictions

Tato omezení se vztahují k příkazu RCPT TO: v rámci SMTP relace. Jako jediné ze všech omezení je povinné a jeho výchozí hodnota je tato:

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Klíčové je zde pravidlo reject_unauth_destination, které odmítá poštu pro všechny příjemce s výjimkou těch, pro které váš poštovní server představuje konečnou. Toto pravidlo tedy zajišťuje, že server neslouží jako open relay, který je hojně využíván spammery k přeposílání spamu. Vždy se ujistěte, že toto pravidlo ve své konfiguraci máte.

Příklad komplexnějšího nastavení by mohl vypadat takto:

smtpd_recipient_restrictions =
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   permit_mynetworks,
   reject_unauth_destination,
   check_sender_access
         hash:/etc/postfix/sender_access,
   reject_rbl_client my_blacklist.example.org,
   permit

Vezměme to pěkně popořadě. Pravidlo reject_unauth_pipelining odmítne klienta, který používá techniku zvanou pipelining, umožňující urychlit doručování většího množství e-mailů použitím více SMTP příkazů najednou. Tato technika vyžaduje, aby si klienti nejprve ověřili, je-li podporována. Spammeři často rovnou posílají řadu příkazů bez toho, aby prováděli ověření. A právě takového klienta Postfix v tomto případě odmítne.

Pravidlo reject_non_fqdn_recipient je díky předchozím příkladům už jasné (odmítne příjemce, který nepoužívá plně kvalifikované doménové jméno), stejně jako reject_unknown_recipient_domain (odmítne příjemce s neexistující doménou). Pravidla permit_mynetworks i reject_unauth_destination byla popsána výše.

Zbývají tedy dvě, check_sender_access a reject_rbl_client. První z nich prověří místní databázi povolených nebo zakázaných odesílatelů, zatímco reject_rbl_client umožňuje napojení na některý z DNS blacklistů. Více viz dále.

check_sender_access

Toto pravidlo vyžaduje jako parametr soubor s dodatečnými pravidly (v příkladu výše /etc/postfix/sender_access). Tento soubor může vypadat třeba takto:

hodny_odesilatel.tld   OK
spammer.tld            REJECT
zly.spammer.tld        REJECT You have been blacklisted.
zly@spammer.tld        REJECT
zloun@                 REJECT
spammer@               REJECT

Syntaxe by z tohoto příkladu měla být vcelku jasná. Lze specifikovat jak domény, tak jména (část před zavináčem). Tímto způsobem lze realizovat místní blacklist i whitelist, propuštění e-mailu zajistí OK, odmítnutí pak REJECT, přičemž REJECT můžete následovat zprávou, která se pak pošle jako součást chybové hlášky. Můžete tak například těm, kteří se na váš blacklist dostali, poskytnout nějakou metodu, jak se z něj nechat vyjmout.

Změny v souboru vyžadují vygenerování databáze, podobně jako v případě aliasů:

postmap /etc/postfix/sender_access

Existuje podobné pravidlo check_recipient_access, které umožňuje realizovat totéž na úrovni příjemců a pro každého příjemce (nebo skupinu příjemců) umí použít jinou politiku přístupu. Příklad využití naleznete zde.

reject_rbl_client a blacklisty

Blacklisty byly představeny v tomto seriálu již dříve, zopakuji tedy jen to nejdůležitější. Blacklist je služba, která sdružuje na základě nějaké politiky IP adresy nebo IP rozsahy a umožňuje poštovním serverům prostřednictvím specifických DNS dotazů zkontrolovat, zda se IP adresa SMTP klienta v této databázi vyskytuje, či nikoliv.

Blacklisty na této úrovni v Postfixu je možné využít pouze k odmítání pošty, což nebývá vždy ten nejlepší nápad. Řada správců poštovních serverů raději blacklisty zařazuje až do fáze kontroly antispamem (např. spamassassin), kde je příslušným e-mailům pouze zvýšeno skóre, ale nejsou natvrdo odmítány.

Úmyslně v příkladu výše neuvádím žádný známý blacklist – jednak nechci dělat reklamu zadarmo, a pak, místo slepého cut-and-paste, doporučuji blacklisty vybírat ručně, a to velmi pečlivě. Je nepříjemné, pokud zvolíte nějaký, který po správcích serverů, kteří se na blacklist třeba dostali omylem nebo ne vlastní chybou, vyžaduje poplatek za vyřazení z databáze. Stejně tak pečlivě prověřte, jaké IP adresy jsou na blacklist zařazovány, zda patří počítačům odesílajícím spam, nebo pouze majitelům IP adres specifických typů poskytovatelů (např. běžným ISP) – nejeden linuxový/unixový nadšenec má domácí poštovní server, a použitím takového blacklistu byste jej natvrdo odřízli.

Některé blacklisty mohou mít tak nastavená pravidla, že je lze považovat v podstatě za vyděrače (zařazují na blacklist kdekoho a za vyjmutí si nechají zaplatit).

Stejně tak je třeba dát si pozor na pravidla použití daného blacklistu, některé lze použít třeba pouze pro nekomerční účely a pouze pro určitý objem pošty.

Použití blacklistů v Postfixu je snadné, postačí daný server uvést jako parametr pravidla reject_rbl_client:

smtpd_recipient_restrictions =
     ...
     reject_rbl_client my_blacklist.example.org,
     permit

Je to asi naprosto jasné, ale pro úplnost dodám, že v tomto příkladu by se DNS dotazy vázaly na server my_blacklist.example.org.

Závěr

Restrictions umožňují definovat komplexní pravidla přístupu, mnohem komplexnější, než co zde bylo probráno. Kupříkladu, řídit přístup lze i podle obsahu hlaviček e-mailu, které lze prověřovat prostřednictvím regulárních výrazů, a na jejich základě poštu odmítat nebo přijímat. A to je jen špička ledovce. Berte tedy tento článek pouze jako úvod do tématu s tím, že další možnosti řízení přístupu se dozvíte, pokud nahlédnete do dokumentace k Postfixu. Dokumentace k Postfixu je dobře strukturována, je dostatečně podrobná, jasná a v online podobě i vhodně prolinkovaná.