Dovecot: Vzdálený přístup ke schránkám

13. 11. 2009 | Lukáš Jelínek | Sítě | 35356×

Obsah

• Jak doručovat, řešení uživatelů
• Přímé doručování systémovým uživatelům
  • Konfigurace doručování
  • Nastavení úložiště
  • Nastavení přístupu
• Vzdálený přístup ke schránkám
  • Konfigurace programu Dovecot
• Virtuální uživatelé
• Spolupráce programů Postfix a Dovecot

Vzdálený přístup ke schránkám

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

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é

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

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).

       

Komentáře

[ET]

v dalsich clancich by mohlo byt jeste rozvinuto boj se spamem (spamassassin,...), automaticke odpovedi (yaa,..)

[petr_p]

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.

Není tu něco špatně? Slovo za rovnítkem definuje co? Formát nebo název souboru? Co umístění souboru? /var/spool/mail nebo domovský adresář?

[Heron]

Pokud je tam lomítko, tak se to bere jako adresář pro maildir.

Díky Lukovi za skvělý seriál. Kdy se dostaneš ke "vzdálenému" smtp? Zatím je odesílající klient puštěn díky adrese v $mynetworks (a příslušným permit pravidlem), jak zařídit, aby mohl odesílat odkudkoliv (po nějaké formě přihlášení)?

[Vantomas]

Priste. Jak je napsano na konci clanku

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).

[Luk]

Pokud je tam lomítko, tak se to bere jako adresář pro maildir.

Přesně tak. Asi jsem měl použít lepší formulaci, takhle to nemusí být dostatečně zřejmé.

[petr_p]

A cesta jak? Když je absolutní, tak to je adresář, kde se budou vytvářet mailboxy/maildiry pojmenované podle uživatelského jména, a když je relativní, tak se bere vzhledem k domovskému adresáři?

[Luk]

Jsou povoleny pouze relativní cesty (což má logiku, protože se zde vychází vždy z domovského adresáře). Co to udělá, pokud by tam někdo narval absolutní cestu, jsem nezkoušel, ale asi to bude řvát. Další možnost je, že se parametr vůbec nenadefinuje, pak to vytváří mailboxy/maildiry pojmenované podle uživatelského jména, a to v adresáři definovaném pomocí mail_spool_directory.

[gagod]

Rozumím tomu správně, že nic nepokazím když použiji zkrácený zápis (s smtp_delay_reject=yes):

smtpd_recipient_restrictions =
  permit_mynetworks,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  check_recipient_access hash:/etc/postfix/access,
  check_sender_access hash:/etc/postfix/access,
  reject_unauth_destination

Nebo má v článku prezentované řešení jiné výhody? Btw ten permit na konci je přidán jen z psychologického hlediska, je tak? Díky

[Luk]

Rozumím tomu správně, že nic nepokazím když použiji zkrácený zápis (s smtp_delay_reject=yes)

Ano, za předpokladu smtp_delay_reject=yes by se to mělo chovat stejně.

Nebo má v článku prezentované řešení jiné výhody?

Upřednostňuji rozdělení na jednotlivé části, je to podle mého názoru přehlednější a názornější.

Btw ten permit na konci je přidán jen z psychologického hlediska, je tak?

Ano, je tam proto, aby bylo na první pohled patrné, co nastane, pokud žádné pravidlo nevyhoví.

[Marek]

Proč není u článku odkaz na další díl seriálu (a na předchozí, první a poslední, tak jako u ostatních)?