Portál AbcLinuxu, 26. dubna 2024 15:27
Stavíme poštovní server – 5 (doručování, vzdálený přístup)
Články
-
Stavíme poštovní server – 5 (doručování, vzdálený přístup)
Poštovní server obvykle nejen odesílá zprávy někam jinam, nýbrž je také přijímá k doručení do schránek. Existuje řada způsobů, jak lze schránky a doručování do nich řešit. Schránky musí být také samozřejmě přístupné pro uživatele.
Obsah
Jak doručovat, řešení uživatelů
link
Přijme-li poštovní server zprávu, rozhoduje se, co s ní udělá. Pokud je zpráva
doručitelná, musí být správně doručena. Řešení z minulých dvou dílů předávala
veškeré takové zprávy jinam. Ovšem často je potřeba doručovat tzv. místně, tedy
uživatelům, kteří mají své schránky přímo na daném serveru.
Možností, jak to dělat, existuje celá řada. Obecně můžeme rozlišovat tyto
roviny:
- zda doručuje přímo server (Postfix), nebo jiný program
- zda jde o systémové, nebo virtuální uživatele
- kde se nachází úložiště
- jakým způsobem jsou zprávy uloženy
Jednotlivé roviny spolu samozřejmě souvisejí, nicméně do určité míry jsou nezávislé. V první řadě jde o to, zda se o finální doručení stará přímo Postfix, nebo zda se využije nějaký program pro místní doručování. Pokud doručuje Postfix, je to celé jednodušší, spotřebuje to méně výkonu, nicméně protože Postfix nemá tuto činnost až tolik v popisu práce, nedá se proces doručování příliš ovlivňovat. Naopak využití doručovacího programu (agenta) je náročnější na konfiguraci a spotřebuje výkon navíc, na druhou stranu lze zprávy filtrovat, třídit, jemně definovat kvóty apod.
Další rozlišení je mezi systémovými (unixovými) a virtuálními uživateli. Systémový uživatel je takový, který má svůj uživatelský účet zjistitelný přes systémovou databázi (podle nastavení NSS). Typicky jde o uživatele, který se může do systému běžně přihlašovat a pracovat v něm. Naopak virtuální uživatel existuje pouze v poštovním serveru. Řešení se systémovými uživateli se využívá v případě, kdy uživatelé využívají i další služby systému a současně poštovní server obsluhuje jen jednu doménu. Virtuální uživatelé se naopak hodí na dedikované poštovní servery obsluhující větší počet domén.
Úložiště zpráv se může nacházet obecně kdekoliv, jak fyzicky, tak logicky. Fyzicky bývá buď přímo na daném stroji (běžný disk nebo RAID), anebo na jiném stroji (souborový server, NAS apod.). Z hlediska logického záleží na způsobu uložení zpráv (viz dále), ale pokud jde o souborové řešení, pak mohou být zprávy uloženy buď pod domovskými adresáři uživatelů (pokud jde o systémové uživatele), nebo v adresářovém stromě na vyhrazeném místě (např. /var/mail).
Zprávy lze ukládat různými způsoby. Je samozřejmě vždy potřeba přizpůsobit volbu schopnostem programů, které k nim přistupují (zde Postfix a Dovecot). Další kritéria jsou robustnost řešení, výkon, případně možnost přebrat bez dalších úprav již existující úložiště. Některé programy používají různá databázová řešení (obvykle nekompatibilní s jinými programy), často se používá také Maildir (každá zpráva je soubor v adresáři) a mbox (všechny zprávy v jednom souboru).
Přímé doručování systémovým uživatelům
link
První řešení bude situace, při které je na serveru určitý počet místních uživatelů, kterým bude Postfix doručovat zprávy do jejich schránek umístěných pod jejich domovskými adresáři. Uživatelé budou ke schránkám přistupovat jen lokálně, čili nebude potřeba zprovozňovat vzdálený přístup přes protokoly POP3 a IMAP. Odesílání zpráv do vnějšího světa bude fungovat tak jako minule.
Konfigurace doručování
link
Doručování místním uživatelům ovlivňuje několik konfiguračních hodnot. Důležité jsou hlavně parametry local_transport (jeho nastavením bylo v minulém díle zakázáno lokální doručování) a local_recipient_maps. První stačí nechat na výchozí hodnotě (což je local:$myhostname, tedy lokální doručovací proces na tomto stroji; je samozřejmě potřeba, aby byl zapnutý v souboru master.cf). I v druhém případě si lze vystačit s výchozí hodnotou, ovšem nebude od věci se na ni podívat trochu podrobněji.
Parametr local_recipient_maps definuje datové zdroje (tabulky), podle kterých se doručuje místním uživatelům. Výchozí hodnota je proxy:unix:passwd.byname $alias_maps. To znamená, že se nejdřív zkusí databáze unixových uživatelů a potom (při neúspěchu) se prověří ještě aliasy podle aktuálního nastavení (viz dále). Jak si můžete všimnout, využívá se datový zdroj proxy, přes který se teprve přistupuje k databázi uživatelů. Proč tomu tak je? Důvody jsou dva: výkonový (eliminace případných vícenásobných připojení ke stejnému zdroji podle nastavení NSS) a bezpečnostní (není třeba, aby měla služba local přístup k databázi uživatelů). Přístup zajistí služba proxymap.
Ve výchozím nastavení local_recipient_maps jsou obsaženy i aliasy. Obecně není potřeba je používat, ovšem protože specifikace v RFC vyžaduje existenci některých adres (např. postmaster@doména…; je to dobré i z funkčních důvodů) a bývá zbytečné pro ně vyhrazovat samostatné schránky, aliasy se hodí. Dávají se obvykle do hešové tabulky umístěné v /etc/aliases – obsah může vypadat například takto:
mailer-daemon: root
postmaster: root
hostmaster: root
nobody: root
security: root
abuse: root
Po vytvoření nebo úpravě (po instalaci distribuce mívá obvykle smysluplný obsah podobný výše uvedenému) souboru je potřeba ještě spustit na soubor příkaz postalias /etc/aliases, aby se tabulka vygenerovala. Také se musí nastavit, kde má Postfix aliasy hledat:
alias_maps = hash:/etc/aliases
Výchozí hodnota obvykle obsahuje tuto tabulku, nicméně obvykle tam bývá ještě přístup k NIS, který se obyčejně nevyužívá, proto je zbytečné ho nechávat zapnutý. Místo příkazu postmap lze využít také newaliases (bez udávání cesty), ale musí se správně nastavit parametr alias_database:
alias_database = hash:/etc/aliases
Hodnota local_recipient_maps slouží pouze ke zjišťování, zda určitá adresa existuje. Proto nezáleží na pořadí jednotlivých zdrojů dat. S aliasy pracuje služba local při doručování zpráv a vyhodnocuje je vždy dříve než poštovní schránky (proto vytvoření aliasu „zastíní“ příslušnou schránku).
Nastavení úložiště
link
Nyní už je nastaveno, jak se budou zprávy doručovat, ještě ale není jasné kam. Protože se má doručovat do schránek pod domovským adresářem, je potřeba to v konfiguraci nastavit. Tady jsou dva příklady:
home_mailbox = Mailbox
home_mailbox = Maildir/
Jak je z názvů patrné, v prvním případě se nastaví doručování do souboru formátu mbox s názvem Mailbox, ve druhém případě to bude formát Maildir a adresář nazvaný taktéž Maildir. Kdy použít tu či onu metodu? Záleží hlavně na tom, jaké programy (poštovní klienty) budou ke zprávám přistupovat. Každý způsob má jinak své výhody a nevýhody. mbox (všechny zprávy v jednom souboru) je obvykle rychlejší, ale při odstraňování zpráv zůstává prázdné místo a soubor se musí „zkompaktňovat“, aby nezabíral zbytečně moc prostoru. Maildir (každá zpráva je samostatný soubor) je robustnější, ale na některých souborových systémech je při velkém množství zpráv pomalý.
V případě formátu Maildir je zatím řeč jen o tomto formátu, ne o jeho rozšířeních (jako používá např. Dovecot), která pomocí indexace umožňují výrazně zrychlit práci i na souborových systémech bez indexů nad adresáři.
V obou případech, tedy jak pro mbox, tak i Maildir, doručuje Postfix s právy toho uživatele, kterému schránka patří. Je to jednoduché a pohodlné, nicméně z pohledu bezpečnosti to samozřejmě znamená, že musí služba local běžet s právy roota mimo prostředí chroot.
Nastavení přístupu
link
K plné funkčnosti zbývá ještě nastavit přístup pro doručování zvnějšku. Aby server nebyl otevřený pro rozesílání spamu, musí zůstat v platnosti omezení definovaná minule (tedy přístup jen z určených sítí), ovšem současně je potřeba umožnit doručování do místních schránek odkudkoliv (není-li to zakázáno v blacklistu).
V čem tedy tkví podstata změny konfigurace? Pokud si vzpomínáte na parametr reject_unauth_destination, tak to je přesně on. Ten totiž odmítne doručení kamkoliv mimo cíle, které obsluhuje tento server. Konfigurace kontroly pro SMTP příkaz RCPT TO se tedy změní takto (zjednodušená verze – plná přijde vzápětí):
smtpd_recipient_restrictions =
permit_mynetworks,
check_recipient_access hash:/etc/postfix/access,
reject_unauth_destination,
permit
Takto napsané pravidlo nejprve povolí doručení odkudkoli z vlastních sítí, pak provede kontrolu oproti blacklistu (protože může být někdy dobré některé místní schránky udělat opravdu jen „místní“, tedy bez doručování ze světa), potom odmítne veškeré „neautorizované“ cíle (tj. všechny adresy, které neobsluhuje tento server) a propustí všechno ostatní.
Podobně je potřeba oproti minulému dílu upravit i další pravidla řízení přístupu, aby vše fungovalo tak, jak je třeba. Tady je celý výsledný konfigurační soubor se všemi pravidly:
myhostname = postak.moje.domena
myorigin = $mydomain
mydestination = $mydomain, localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
home_mailbox = Maildir/
biff = yes
delay_warning_time = 4h
mynetworks = 127.0.0.0/8
smtpd_client_restrictions =
permit_mynetworks,
check_sender_access hash:/etc/postfix/access,
permit
smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
check_sender_access hash:/etc/postfix/access,
permit
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_recipient_access hash:/etc/postfix/access,
reject_unauth_destination,
permit
smtpd_error_sleep_time = 30
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
disable_vrfy_command = yes
Co je jinak oproti minulému dílu? Všimněte si například parametru mydestination. Ten říká, pro jaké všechny adresy bude server cílový. V tomto případě to budou adresy v definované doméně (mydomain) a adresy v „doméně“ localhost. Dále přibyly parametry pro aliasy (alias_*) a pro schránky (home_mailbox). V pravidlech pro kontrolu klientů se využívá blacklist, pravidla pro kontrolu odesílatele se proměnila tak, že propustí vše kromě formálně nevyhovujících adres a adres z blacklistu. Pravidla pro cílové adresy jsou upravena pro odmítání zpráv z vnějšku, kdy příjemce není „místní“. Všimněte si také parametru disable_vrfy_command, který zakazuje SMTP příkaz VRFY (tím si může spammer zjišťovat existenci schránek, aniž by se do nich pokusil doručit – tak by se mohl vyhnout odmítnutí za překročení limitu chyb).
Ještě je důležité dodat, že při přístupu z vlastních sítí (zde pouze lokální adresy) je přístup vždy ihned povolen, bez dalších kontrol. Tyto kontroly jsou totiž obvykle zbytečné, navíc nevadí (a leckdy se to naopak hodí), že jsou propuštěny i adresy bez uvedení domény.
Obsah
Vzdálený přístup ke schránkám
link
Popsané řešení umožňuje doručování do schránek uživatelů, nicméně jediný možný přístup ke zprávám je prostřednictvím programů spouštěných přímo na stejném stroji (případě i odjinud, pokud by byla schránka dostupná třeba přes sshfs), navíc jen takových, které tento způsob podporují. Ovšem s tím se lze málokdy spokojit – standardem je přístup vzdálený, pomocí některého z protokolů k tomu určených.
Protože Postfix tyto věci vůbec neřeší, je na čase pustit k práci také druhý ze zde popisovaných programů – Dovecot. Z hlediska základní kooperace s Postfixem není potřeba nic zvlášť řešit, zejména pokud se jako úložiště používá Maildir (pro mbox by se muselo ohlídat zamykání, aby se programy o soubor schránky nepraly).
Konfigurace programu Dovecot
link
Následující text a konfigurace bude odpovídat verzi 1.2. Pro starší verze to může vypadat mírně jinak, přestože základní věci se skoro neliší. Každopádně je dobré se při použití dřívějších verzí podívat do dokumentace a případné odlišnosti promítnout do nastavení. Konfigurační soubor programu Dovecot se standardně nachází na cestě /etc/dovecot/dovecot.conf.
V první řadě je potřeba zapnout podporu protokolů POP3 a IMAP (musí být samozřejmě nainstalováno vše potřebné – někde je samostatně jádro programu a jednotlivé protokoly, viz třetí díl seriálu). Šifrované verze (protokoly imaps a pop3s; běží na samostatných portech) zůstanou vypnuty, protože vyžadují správně nakonfigurovanou technologii SSL.
protocols = imap pop3
Nejenže se nezapnou protokoly imaps a pop3s na zvláštních portech, ale je potřeba vypnout i SSL/TLS jako celek, protože Dovecot podporuje rozšíření STARTTLS, s jehož pomocí lze TLS zapnout v rámci relace na běžném portu. Současně bude potřeba udělat bezpečnostní ústupek a povolit autentizaci heslem v otevřeném tvaru (viz dále).
ssl = no
disable_plaintext_auth = no
Dovecot z bezpečnostních důvodů standardně zakazuje autentizaci heslem v otevřeném tvaru odjinud než z bezpečných adres (běžně jen z místního stroje). Heslo v otevřeném tvaru není problém při použití šifrování, proto se v takovém případě povoluje. Tady jde ovšem o jiný případ – i když se šifrování používat nebude, je heslo v otevřeném tvaru nezbytné. Důvodem je, že pokud se využívá běžná systémové databáze hesel, nelze používat metody, které pro svoji funkci vyžadují heslo v otevřeném tvaru (CRAM-MD5, DIGEST-MD5, NTLM atd.). Takové řešení není bezpečné, zejména používá-li se při přístupu přes Internet. Nejčistším řešením je využít TLS, které je ovšem potřeba správně nakonfigurovat (což není tak úplně triviální a je potřeba si připravit certifikát a klíč). Jinou možností je mít heslo uloženo v otevřeném tvaru, což ale nelze použít s normální systémovou (unixovou) databází.
Z obecných konfiguračních parametrů zbývá již jen jeden. Je to typ a umístění úložiště zpráv. Tady je to jednoduché, používá se úložiště typu Maildir a schránka je adresář Maildir pod domovským adresářem uživatele.
mail_location = maildir:~/Maildir
Nyní přicházejí na řadu sekce pro jednotlivé protokoly a pro autentizaci. Pro protokol IMAP je žádoucí nastavit toto:
protocol imap {
imap_client_workarounds = outlook-idle
}
Parametr zapne obcházení chyby implementace protokolu IMAP v programu Microsoft Outlook. Pokud se Outlook zcela jistě používat nebude, není potřeba toto zapínat. Naopak při použití jiných klientů (typicky hodně starých) by se zapnuly jiné podobné volby. Pro protokol POP3 se nastaví tyto hodnoty:
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
}
První parametr říká, jaký formát budou mít unikátní identifikátory zpráv. Pokud se vytváří nové úložiště, je v podstatě jedno, jak se budou identifikátory generovat. Jedno to ovšem není, přebírá-li se existující úložiště, nad kterým běžel nějaký jiný POP3 server. Určitý problém může být také s klienty (např. Microsoft Outlook 2003) nepodporujícími některé formáty. Uvedený formát odpovídá tomu, který používá program UW ipop3d a je doporučen autorem programu Dovecot. Druhý parametr zapíná podporu pro obcházení chyb některých klientů (podobně jako u protokolu IMAP).
Teď už zbývá jen nastavit autentizaci. Dovecot rozlišuje dva druhy autentizačních dotazů: na hesla a na uživatele. Ne každý informační zdroj lze použít pro obojí. Například na hesla se pro systémové uživatele standardně používá PAM (nelze použít jako databázi uživatelů), k dotazům na uživatele zase databáze passwd (tedy standardně NSS). Tady je příslušná konfigurační sekce:
auth default {
mechanisms = plain login
passdb pam {
args = dovecot
}
userdb passwd {
}
user = root
}
Parametr mechanisms udává povolené autentizační mechanismy. Zde jsou uvedeny pouze dva, vzhledem k tomu, jak jsou ověřována hesla (PAM může pouze ověřit, zda je získané heslo správné, ale nemůže ho jako takové získat). Podsekce passdb definuje přístup k databázi hesel, zde s použitím PAM. Jako argument (args) zde figuruje název služby v rámci PAM (viz dále). Dále je tu prázdná podsekce s databází uživatelů (i když tam nic není, nelze ji vynechat – říká, jak se budou uživatelé ověřovat) a nakonec uživatel, pod kterým poběží autentizační proces (musí mít přístup k heslům, čili v tomto případě to bude root).
Před spuštěním programu Dovecot je potřeba ještě ověřit, zda má PAM nakonfigurovánu službu dovecot. Při instalace programu z balíčku to obvykle bývá v pořádku, nicméně pokud soubor (typicky /etc/pam.d/dovecot) chybí, je potřeba ho tam přidat a standardně bude mít tento obsah (může vypadat mírně jinak, např. jako inkludování společných souborů, podle řešení v konkrétní distribuci):
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
To je vše a po spuštění programu Dovecot s touto konfigurací by měl POP3 i IMAP přístup ke schránkám fungovat bezproblémově. Ovšem pozor – uživateli root Dovecot nepovolí přístup ke schránce. Je to logické, zejména v kontextu nešifrovaných hesel běhajících po síti. Proto je obecně lepší, když root vůbec svoji schránku nepoužívá. Prostě se pro tyto účely využívá běžný uživatel, přičemž pošta adresovaná uživateli root se pomocí aliasu přesměruje tomuto uživateli – do souboru /etc/aliases se na konec přidá pravidlo jako je toto:
root: uzivatel
Virtuální uživatelé
link
I když řešení se schránkami běžných uživatelů v systému je jednoduché a v řadě případů dobře použitelné, hlavně u dedikovaných poštovních serverů je vhodnější (a často v podstatě nezbytné) použít tzv. virtuální uživatele, kteří nemají své uživatelské účty v systému jako celku. Použití virtuálních uživatelů má celou řadu výhod:
- lze zcela oddělit poštovní služby od jiného využívání počítače
- lze pracovat s poštou většího počtu domén (s různými uživateli v každé z nich)
- lze mít bezpečně uložena hesla v otevřeném tvaru (nepoužívají se mimo poštu)
- databáze uživatelů a hesel lze spravovat zcela samostatně
- o přístupová práva se stará poštovní server (výhoda u sdílených schránek apod.)
Programy lze samozřejmě nastavit i tak, aby fungovaly současně pro systémové i virtuální uživatele, i když je to většinou zbytečné. Jako úložiště pro schránky virtuálních uživatelů se samozřejmě nepoužívají žádné domovské adresáře. Úložiště je centrální (typicky pod /var/mail), může být i fyzicky oddělené od poštovního serveru. Oddělit pak snadno lze i doručování zpráv a přístup k nim.
Spolupráce programů Postfix a Dovecot
link
Teoretický úvod o virtuálních uživatelích byl předstupněm toho, co přijde příště. Oba programy (Postfix a Dovecot) vytvoří silnou dvojici, která bude těsně spolupracovat – a to tak, že Postfix využije služeb programu Dovecot. Cílem bude ověřování virtuálních uživatelů, a to jak pro účely doručování (tedy jestli uživatel vůbec existuje), tak pro ověření pro odesílání zpráv (často je žádoucí mít možnost právo uživatele odesílat poštu ověřit i jinak než pouze podle síťových adres).
Související články
Další články z této rubriky
Diskuse k tomuto článku
13.11.2009 08:59
ET
Re: Stavíme poštovní server – 5 (doručování, vzdálený přístup)
13.11.2009 10:01
petr_p | skóre: 59
| blog:
pb
home_mailbox
21.11.2009 19:35
gagod | skóre: 2
Re: Stavíme poštovní server – 5 (doručování, vzdálený přístup)
16.2.2010 16:51
Marek
Re: Stavíme poštovní server – 5 (doručování, vzdálený přístup)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
13.11.2009 11:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
13.11.2009 12:58
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora