Stavíme poštovní server – 6 (virtuální uživatelé)

25. 11. 2009 | Lukáš Jelínek

Články - Stavíme poštovní server – 6 (virtuální uživatelé)  

U dedikovaných poštovních serverů nevyužívají uživatelé obvykle nic jiného než právě poštovní služby. Existuje samozřejmě možnost skloubit systémové (unixové) uživatele se schránkami v různých doménách, nicméně by bylo zbytečné, aby byly pro tyto účely v systému normální uživatelské účty. Proto se využívají tzv. virtuální uživatelé. Existuje řada způsobů, jak s nimi v poštovním prostředí pracovat.

Obsah

• O virtuálních uživatelích
• Konfigurace doručování
  • Základní konfigurace
  • Schránky a aliasy
• Konfigurace přístupu k poště
  • Hesla a autentizace
• Autentizace pro odesílání zpráv
  • Dovecot jako poskytovatel SASL
  • Ověřování uživatelů v Postfixu
• Uživatelé v databázi

O virtuálních uživatelích

Základní informace o smyslu a vlastnostech virtuálních uživatelů jste se mohli dočíst už v minulém dílu. Důležité je, že virtuální uživatelé existují nezávisle na těch systémových, mohou být vázáni k různým doménám (slouží-li server například v rámci hostingu), lze využívat řadu metod přístupu k datům o nich atd. To jsou všechno výhody, které výrazně usnadňují využití pro poštovní služby a někdy jsou přímo podmínkou fungování v dané situaci.

Jaké informace jsou tedy potřeba pro úspěšné fungování virtuálních uživatelů? Není toho mnoho:

• pro které domény se místně doručuje
• odkud brát informace o uživatelích a heslech
• jak uživatele ověřovat

U domén jde o to, že server přijme zvenčí zprávy jen pro domény, do kterých doručuje. Informace o těchto doménách musí nějakým způsobem získávat. Podobně potřebuje mít k dispozici i informace o uživatelích a heslech, a rovněž vědět, jakým způsobem uživatele ověřovat (autentizační metody, schémata hesel, ověřovací prostředek).

Konfigurace doručování

Jak tohle celé uchopit? Jako první je na řadě rozhodnutí, jak budou vůbec informace uloženy. To záleží na současné situaci (jaké technologie se např. ve firmě používají), k čemu bude server sloužit, jak často se bude něco měnit, zda bude potřeba měnit hesla apod. Nejjednodušší je uložení dat v obyčejných souborech, tedy v rámci konfigurace a dalších souborů.

Základní konfigurace

O doručování došlých zpráv se stará Postfix, proto potřebuje mít k dispozici informace o tom, do kterých domén má doručovat a kde se nachází úložiště toho kterého uživatele. Protože jde o virtuální uživatele, lze s klidem zapomenout na nějaké domovské adresáře a prostě si říct, že bude úložiště umístěno například v adresáři /var/mail/virtual.

V tomto adresáři budou adresáře jednotlivých domén a pod nimi adresáře uživatelů (v nich pak normální úložiště Maildir, případně mbox). Proto uživatel s adresou franta@moje.domena bude mít schránku na /var/mail/virtual/moje.domena/franta. Je to prosté. V konfiguraci to pak bude vypadat nějak takhle:

virtual_mailbox_domains = moje.domena jina.domena dalsi.domena
virtual_mailbox_base = /var/mail/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_minimum_uid = 100
virtual_uid_maps = static:100
virtual_gid_maps = static:100

Parametr virtual_mailbox_domains přímo definuje, pro které domény bude Postfix doručovat. V seznamu nesmí být doména uvedená v mydestination (parametr mydestination zde lze v konfiguraci klidně vynechat, použije se výchozí hodnota). virtual_mailbox_base je ono místo, pod kterým bude úložiště schránek. Další dva parametry říkají, kde se nachází tabulka schránek, resp. aliasů (viz dále).

Seznam domén lze místo virtual_mailbox_domains samozřejmě definovat i někde venku (třeba v hešové tabulce, takže se pak cesta k ní uvede zde), ovšem obvykle to v takto jednoduchém případě není potřeba. Případně lze parametr dokonce vynechat, použije se pak automaticky to, co je obsaženo ve virtual_mailbox_maps – není to ale dobrý nápad, protože někdy mohou být v doméně definovány pouze aliasy a žádné schránky, pak by samozřejmě doručování nefungovalo.

Zbývající tři parametry se týkají uživatele a skupiny. Služba virtual, která se stará o doručování virtuálním uživatelům, si totiž zjišťuje, pod jakým uživatelem a skupinou provede doručení do konkrétní schránky. Lze doručovat pod různými uživateli, nicméně v tomto případě bude uživatel jediný, konkrétně s UID=100 (může to být třeba uživatel nazvaný vmail; nesmí být totožný s uživatelem, pod nímž běží Postfix, tedy typicky uživatelem postfix). Totéž se týká i skupiny. Parametr virtual_minimum_uid říká, jakou minimální hodnotu musí zjištěný identifikátor mít (zde má pouze formální význam, protože je hodnota nadefinována natvrdo).

Pozor na to, aby měl adresář úložiště správně nastavena práva. Vlastník a skupina by měly být nastaveny na správné hodnoty (podle konfigurace uvedené výše), jakýkoli přístup pro jiné uživatele by měl být zakázán (tj. maska adresáře nejlépe 0700, případně 0750).

Schránky a aliasy

Dále je potřeba vytvořit zmíněný seznam e-mailových schránek, tedy soubor /etc/postfix/vmailbox. Ten bude obsahovat vždy dvojici adresy a cesty, kde se schránka nachází. Tady je příklad takového souboru (na počtu mezer nebo tabulátorů oddělujících hodnoty dvojice nezáleží):

franta@moje.domena     moje.domena/franta/
tereza@moje.domena     moje.domena/tereza/
postmaster@moje.domena moje.domena/postmaster/

petr@jina.domena       jina.domena/petr/

Z příkladu je snad všechno zřejmé. Důležité je, aby cesta končila lomítkem, protože to signalizuje, že jde o schránku typu Maildir. Pokud by se nepoužilo, Postfix by to chápal jako mbox. Cesty jsou relativní vzhledem k virtual_mailbox_base, tedy pod /var/mail/virtual.

Dalším souborem bude /etc/postfix/virtual, tedy tabulka aliasů. Vypadá podobně jako tabulka schránek, jen místo cesty je tam cílová adresa:

abuse@moje.domena         postmaster@moje.domena
root@moje.domena          franta@moje.domena

postmaster@jina.domena    postmaster@moje.domena
abuse@jina.domena         postmaster@jina.domena

postmaster@dalsi.domena   postmaster@moje.domena
abuse@dalsi.domena        postmaster@dalsi.domena

Všimněte si dvou věcí. Především toho, že jeden alias může směřovat na jiný alias – tedy zde například abuse@jina.domena směřuje na postmaster@jina.domena, což je alias schránky postmaster@moje.domena. Takhle to jde řetězit skoro nekonečně (v praxi do limitu nastaveného parametrem virtual_alias_recursion_limit, v současné době je výchozí hodnota 1000). Druhá důležitá věc je, že je zde definován alias pro uživatele root (využívají se virtuální aliasy, nikoli lokální).

Adresa s uživatelem postmaster musí být definována v každé doméně – je to striktní požadavek RFC 2821 (stejně tak i draftu RFC 5321) a navíc standardní cesta, jak kontaktovat správce serveru. Nezáleží na tom, zda je adresa implementována jako schránka nebo alias k jiné schránce, ale zprávy by měl někdo pravidelně číst. Adresa postmaster musí být funkční i jako lokální (to se zajistí tak, že je správně nakonfigurována schránka postmaster pro doménu definovanou parametrem myorigin – podobně se postupuje i pro uživatele root). RFC 2142 definuje také adresu abuse, určenou k oznamování zneužití služby – měla by být definována pro nejvyšší doménu využívanou určitým subjektem (v praxi typicky doména 2. úrovně), ale v praxi se adresa skutečně využívá zřídka. V různých RFC najdete i další speciální adresy spjaté s jinými službami.

Netřeba dodávat, že oba textové soubory je třeba převést na hešové tabulky příkazem postmap. Celý soubor konfigurace pro Postfix tedy nyní vypadá takto (včetně omezení přístupu v podobě z minulého dílu):

myhostname = postak.moje.domena
myorigin = $mydomain

biff = no
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

virtual_mailbox_domains = moje.domena jina.domena dalsi.domena
virtual_mailbox_base = /var/mail/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_minimum_uid = 100
virtual_uid_maps = static:100
virtual_gid_maps = static:100

Konfigurace přístupu k poště

Nyní je tedy situace taková, že Postfix správně doručuje do schránek, nelze se k nim však zatím dostat. Je proto potřeba nakonfigurovat také program Dovecot. I ten bude nyní plně založen na informacích uložených v souborech, je to ale o něco složitější – je totiž potřeba pracovat také s hesly.

Hesla a autentizace

Při práce s hesly (resp. s autentizací obecně) se používají dva důležité termíny: autentizační mechanismus a schéma hesel. Oba spolu souvisejí. Autentizační mechanismus je vlastně protokol, podle něhož se provádí ověření uživatele, kdežto schéma hesel je způsob, jakým jsou hesla uložena. Jde o to, že na tom, jaké schéma se pro uložení hesel použije, závisí množina použitelných autentizačních mechanismů. Základním pravidlem je, že pokud je heslo uloženo v otevřeném tvaru (schéma PLAIN), lze ho využít pro všechny mechanismy. Naopak pro mechanismus PLAIN (heslo se posílá v otevřeném tvaru) lze využít libovolné schéma uložení hesel. Ostatní případy jsou specifické a většina vzájemných kombinací není z principu možná.

V minulém dílu seriálu si můžete všimnout, že v situaci, kdy lze heslo pouze ověřit (tedy ne přímo získat), jsou autentizační možnosti omezené a lze použít pouze metody PLAIN a LOGIN, tedy ty, kdy se posílá heslo v otevřeném tvaru. To je však v kombinaci s nešifrovaným přenosem nebezpečné, proto je výhodnější mít hesla raději uložena v otevřeném tvaru a pro autentizaci využívat různé bezpečnější mechanismy (s možností nabídnout jich více najednou).

Nyní už je tedy jasné, že budou hesla uložena tak, jak jsou. Proto je potřeba zvlášť pečlivě nastavit přístupová práva k souboru s hesly (viz dále). Soubor může být umístěn například v /etc/dovecot/passwd, proto se v konfiguračním souboru dovecot.conf nastaví toto:

passdb passwd-file {
  args = scheme=plain username_format=%u /etc/dovecot/passwd
}

Tento fragment říká, že se jako databáze hesel použije soubor typu passwd-file (soubor „jako passwd“), schéma uložení je PLAIN, uživatelská jména jsou uvedena včetně domény (%u) a soubor je umístěn na dané cestě. Podobnou sekci je třeba přidat i pro databázi uživatelů:

userdb passwd-file {
  args = username_format=%u /etc/dovecot/passwd
}

K souboru s hesly smí mít přístup jen uživatel, pod nímž poběží program provádějící autentizaci. Tímto uživatelem nesmí být root, uživatel dovecot ani uživatel určený pro přístup ke zprávám (např. vmail). Vhodným řešením je založit speciálního uživatele, například dovecot-auth, a toho oprávnit k přístupu k datům. Tento uživatel se pak nastaví v konfiguraci (viz dále).

Ještě je potřeba dodefinovat, kde má Dovecot hledat schránky a pod jakým uživatelem a skupinou ke zprávám přistupovat (podobně jako v případě Postfixu). Protože Postfix používá jediného uživatele a skupinu, bude nastavení úplně stejné. Tady jsou konfigurační pravidla:

mail_location = maildir:/var/mail/virtual/%d/%n
first_valid_uid = 100
last_valid_uid = 100
first_valid_gid = 100
last_valid_gid = 100

Cesta ke schránce se bude tvořit automaticky z uživatelského jména včetně domény (uživatelé se budou přihlašovat celou e-mailovou adresou), to se rozloží na své složky a použije v cestě. Jediným platným identifikátorem pro uživatele i skupinu je 100, tedy například onen uživatel vmail. Nyní už zbývá jen vytvořit soubor s uživatelskými jmény a hesly.

franta@moje.domena:{plain}nejakeheslo:100:100:::
tereza@moje.domena:{plain}jineheslo:100:100:::
postmaster@moje.domena:{plain}dalsiheslo:100:100:::
petr@jina.domena:{plain}jestejineheslo:100:100:::

Každý řádek obsahuje přihlašovací jméno uživatele (tedy jeho adresu), heslo včetně schématu, UID a GID. Soubor může obsahovat ještě další údaje, například o tom, ze kterých adres je uživateli povolen přístup. Podrobnosti najdete v dokumentaci pro Dovecot. Pokud chcete použít heslo s jiným schématem než PLAIN, můžete využít nástroj dovecotpw, který dokáže generovat hesla ve formátu podle schématu (např. CRAM-MD5 nebo CRYPT).

To už je v podstatě vše, co je potřeba je zdárnému fungování přístupu ke schránkám. Tady je celý konfigurační soubor pohromadě (včetně základních nastavení z minulého dílu):

protocols = imap pop3

ssl = no
disable_plaintext_auth = no

mail_location = maildir:/var/mail/virtual/%d/%n
   first_valid_uid = 100
last_valid_uid = 100
first_valid_gid = 100
last_valid_gid = 100

protocol imap {
  imap_client_workarounds = outlook-idle
}

protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
  pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
}

auth default {
  mechanisms = plain login cram-md5 digest-md5 ntlm

  passdb passwd-file {
    args = scheme=plain username_format=%u /etc/dovecot/passwd
  }

  userdb passwd-file {
    args = username_format=%u /etc/dovecot/passwd
  }

  user = dovecot-auth
}

V sekci auth default si všimněte, že oproti minulému dílu přibyly další autentizační mechanismy (CRAM-MD5, DIGEST-MD5 a NTLM; je to množina těch nejčastěji používaných). Lze je bez problémů používat, vzhledem k tomu, jak jsou uložena hesla. Na konci sekce je pak vidět přiřazení uživatele dovecot-auth pro přístup k heslům.

Autentizace pro odesílání zpráv

Popsané řešení vyhovuje v situaci, kdy je poštovní server součástí sítě, ze které k němu uživatelé přistupují, a lze tedy rozlišovat oprávněnost odesílání „ven“ podle síťových adres. Jenže často je server někde na Internetu a přístup je potřeba k němu mít odkudkoliv (a současně nedovolit jeho zneužití k rozesílání spamu) – to je třeba typický případ pošty u hostingových služeb. Pak je potřeba zavést ověřování totožnosti uživatelů, kteří chtějí něco poslat mimo daný server.

Zapnutí kontroly je v zásadě velmi triviální (viz dále), problém ovšem nastává s tím, odkud čerpat data k ověřování. Byl by nesmysl mít dvě samostatné databáze, jednu pro Dovecot a druhou pro Postfix, když by v obou byly totožné údaje a každá změna by se musela promítnout do obou databází.

Naštěstí to tak být nemusí. Pro ověřování uživatelů se totiž využívá technologie SASL (podle RFC 4422). A Dovecot umí vystupovat jako poskytovatel služeb SASL, takže se jeho databáze využije i pro účely Postfixu. Oba programy se ale musí správně nakonfigurovat.

Protože poskytování SASL funguje podle modelu klient/server, musí pro fungování autentizace v Postfixu běžet i Dovecot. Pokud nepoběží, nebude možné přes Postfix odesílat zprávy, protože uživatel nepůjde ověřit.

Dovecot jako poskytovatel SASL

Dovecot poskytuje autentizační služby prostřednictvím lokálního (unixového) socketu. Ten musí být umístěn tam, kam Postfix vidí (i pokud služba běží v prostředí chroot), a musí mít správně nastavena práva. Může to vypadat přibližně takto:

auth default {

  …

  socket listen {
    client {
      path = /var/spool/postfix/private/auth
      mode = 0660
      user = postfix
      group = postfix
    }
  }
}

Místo oněch tří teček je původní obsah sekce auth default. Parametr path je cesta uvnitř pracovního prostoru programu Postfix, vlastník i skupina souboru bude postfix (pod tímto uživatelem Postfix obvykle běží) a oprávnění bude nastaveno na čtení a zápis pro uživatele i skupinu. To je ze strany programu Dovecot vše, po startu s tímto nastavením bude poskytovat na uvedeném socketu autentizační služby.

Ověřování uživatelů v Postfixu

Zbývá nastavit ještě druhou stranu, tedy program Postfix. První je na řadě to, aby program vůbec využíval autentizační služby. Tady je sada konfiguračních parametrů, které se přidají k aktuální konfiguraci v main.cf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes

smtpd_sasl_type říká, jaký typ poskytovatele SASL se bude používat (výchozí je cyrus). V parametru smtpd_sasl_path je obsažena cesta k socketu pro komunikaci (počítá se zde relativně k bázovému adresáři Postfixu; tato hodnota je vhodná i pro prostředí chroot, které se obvykle používá). Využití autentizace je samozřejmě potřeba také zapnout pomocí smtpd_sasl_auth_enable. Poslední nastavení (broken_sasl_auth_clients) se týká podpory „rozbitých“ klientů (např. starší verze programů Microsoft Outlook Express nebo Microsoft Exchange), které vyžadují nestandardní deklaraci autentizačních metod (zapnutí této volby nevypne standardní deklaraci, pouze přidá ještě tu nestandardní).

Nyní je však ještě potřeba upravit pravidla pro restrikce přístupu tak, aby bylo doručení do místních schránek povoleno odkudkoliv, zatímco odesílání ven jen autentizovaným uživatelům (plus samozřejmě odesílání z vlastní sítě, kterou lze – při umístění serveru volně na Internetu – nastavit na lokální adresy).

smtpd_recipient_restrictions =
  permit_mynetworks,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  check_recipient_access hash:/etc/postfix/access,
  permit_sasl_authenticated,
  reject_unauth_destination,
  permit

Rozdíl je v přidání pravidla permit_sasl_authenticated, které říká, že pokud byl uživatel ověřen pomocí SASL, je mu povoleno odeslání libovolnému příjemci (tedy samozřejmě za předpokladu, že nebyl příjemce odmítnut některým z předchozích pravidel). Na ostatní odesílající klienty se bude vztahovat pravidlo další, tedy reject_unauth_destination, proto budou smět posílat poštu jen adresám, pro které tento server doručuje (viz minulý díl).

Uživatelé v databázi

Téměř každý, kdo si vyzkouší popsané řešení založené na souborových seznamech uživatelů, aliasů atd., brzy narazí na limity takového řešení. Spravovat soubory je nepohodlné, musí to dělat vždy administrátor (lze si představit nějaké nástroje pracující nad těmito soubory, ale to je drbání se levou nohou za pravým uchem), při některých operacích se musí sahat hned na čtyři místa.

Proto je pro i jen trochu větší poštovní server (tedy skoro každý) mnohem výhodnější použít nějaké lepší řešení. Jedním z nich jen využít některou z podporovaných databází. Jak takovou databázi navrhnout, jaké informace do ní dát a jak k ní připojit Postfix a Dovecot, to bude předmětem příštího dílu.

Seriál Stavíme poštovní server (dílů: 17)

První díl: Stavíme poštovní server – 1 (Postfix), poslední díl: Stavíme poštovní server – 17 (optimalizace výkonu).
Předchozí díl: Stavíme poštovní server – 5 (doručování, vzdálený přístup)
Následující díl: Stavíme poštovní server – 7 (uživatelé v databázi)

Diskuse k tomuto článku

[ubuntak]

Sleduju tento serial od pocatku a opet super. Jen tak dal. Uz se tesim na pokracovani.

[vladky]

Suhlasim, je to super serial a vzdy sa neviem dockat dalsieho dielu. Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.

[Luk]

Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.

Ano, ale ještě to bohužel chvilku potrvá.

[Honza]

Toto řešení již bylo kdysi popsáno (v Poštovní server s virtuálními účty trochu jinak). Doufám, že se dočkáme i řešení přes LDAP

[Zdeněk Burda]

Něco jako tohle? - namátkou vybraná konfigurace na nějakém nepoužívaném serveru, mělo by to fungovat, ale není to asi zrovna optimální

dovecot-ldap.conf:

hosts = localhost
dn = cn=ldapproxy,dc=domain,dc=tld
dnpass = tajneheslo
auth_bind = yes
auth_bind_userdn = uid=%u,ou=users,o=%d,o=hosting,dc=domain,dc=tld
ldap_version = 3
base = o=hosting,dc=domain,dc=tld
scope = subtree
user_attrs = mailMessageStore=home,mailQuotaSize=quota=maildir:storage
user_filter = (&(objectClass=posixAccount)(objectClass=qmailUser)(mail=%u)(employeeType=mail)(description=active))
pass_attrs = mail=user
pass_filter = (&(objectClass=posixAccount)(objectClass=qmailUser)(mail=%u)(employeeType=mail)(description=active))
user_global_uid = 1011
user_global_gid = 1011

+ nastavení postfixu ve stylu:

domains_server_host = localhost
domains_search_base = o=hosting,dc=domain,dc=tld
domains_query_filter = (&(o=%s)(objectClass=organization)(description=active))
domains_result_attribute = o
domains_scope = one
domains_cache = no
domains_bind = yes
domains_bind_dn = cn=ldapproxy,dc=domain,dc=tld
domains_bind_pw = tajneheslo
domains_version = 3

aliases_server_host = localhost
aliases_search_base = o=hosting,dc=domain,dc=tld
aliases_query_filter = (&(objectClass=qmailUser)(mail=%s)(description=active)(employeeType=mail))
aliases_result_attribute = mailForwardingAddress
aliases_scope = sub
aliases_cache = no
aliases_bind = yes
aliases_bind_dn = cn=ldapproxy,dc=domain,dc=tld
aliases_bind_pw = tajneheslo
aliases_version = 3

accounts_server_host = localhost
accounts_search_base = o=hosting,dc=domain,dc=tld
accounts_query_filter = (&(objectClass=qmailUser)(mail=%s)(description=active)(employeeType=mail))
accounts_result_attribute = mailMessageStore
accounts_result_format  =  %s/Maildir/
accounts_scope = sub
accounts_cache = no
accounts_bind = yes
accounts_bind_dn = cn=ldapproxy,dc=domain,dc=tld
accounts_bind_pw = tajneheslo
accounts_version = 3

alternate_server_host = localhost
alternate_search_base = o=hosting,dc=domain,dc=tld
alternate_query_filter = (&(objectClass=qmailUser)(mailAlternateAddress=%s)(description=active)(employeeType=mail))
alternate_result_attribute = mailMessageStore
alternate_result_format  =  %s/Maildir/
alternate_scope = sub
alternate_cache = no
alternate_bind = yes
alternate_bind_dn = cn=ldapproxy,dc=domain,dc=tld
alternate_bind_pw = tajneheslo
alternate_version = 3

dovecot_destination_recipient_limit = 1
virtual_transport = dovecot

[Honza]

Možná, netušil jsem, že konfigurace je tak dlouhá. Vyzkouším! Přiznám se, že LDAP není můj šálek čaje...

[Luk]

Jak na to tak zběžně koukám, tak by to mohlo fungovat. Článek o využití LDAPu samozřejmě bude (přespříště ).

[Luk]

Koukl jsem na to znovu a dal to souvislosti s tím, co jsem zjistil v dokumentaci. Přinejmenším pro Dovecot by to zcela jistě nešlo použít (tedy pro verze 1.2 a 1.1), je to konfigurák pro 1.0 a některé parametry jsou již v novějších verzích jiné (a ty staré už to neumí). Postfix je na tom se zpětnou kompatibilitou lépe (přece jen Dovecot 1.0 byl ještě dost neustálený, kdežto Postfix už je tu s námi dlouho), ale ruku do ohně bych za funkčnost nedal.

[pele]

Jaky je duvod k tomu, ze virtualni domena nesmi byt stejna jako mydestinations? Daji se pak kombinovat lokalni a virtualni ucty pro stejnou domenu?

Jinak super clanek, diky za nej.

[Filip Jirsák]

Je to právě proto, že "lokální" a "virtuální" domény se obsluhují jiným způsobem, řeší to v rámci Postfixu jiná služba. Takže v mydestinations definujete lokální domény a ve virtualdomains definujete virtuální domény. Kombinovat to můžete třeba pomocí aliasů. Důležité je pochopit ten základní princip, ono se to totiž ani moc netýká domén, jako účtů - lokální domény jsou určeny pro systémové účty, pošta se doručuje do "systémového" adresáře pro poštu konkrétního systémového uživatele. Virtuální domény jsou určeny pro virtuální (nesystémové) účty, doručování musí být explicitně nakonfigurováno (je nutné říci, jak z virtuálního účtu získat informace o úložišti e-mailů).

[pele]

Diky, muj problem byl v mydestination, jestlize je tato promenna prazdana vse je ok. A posta chodi i na virtualni ucty.

[faha]

Ulozeni informaci v prostych/hash souborech ma samozdrejme i svuj duvod, krome samozdrejme na prvni pohled horsi udrzovatelnosti (coz lze odbourat pomoci nekoli skriptu), ale prinaseji vyssi vykon zpracovani zprav.

Ono je sice moc pekne reseni(i na pohled  napr.pro zakaznika) drzet informace o uctech v relacni DB (a to vcetne anti spam/vir reseni, forwardu ...), ale uvedovme si jak je tento proces narocny na DB, prichod jednoho emailu spousti pomerne narocnou proceduru a co teprve v pripade zpracovani i nejakou tu dekadu vetsiho poctu (1ky,10ky, 100ky tisic ), db permanentne pretizena, uzamykani tabulek ... apod. co horsi se muze stat nez, ze to DB nevydrzi a sesype se... problem

Videl jsem reseni prave na rozsahlych hash-mapach, ktere navic dokazalo rozlozit zatez na vice serveru, informace se skutecne udrzovaly v DB, nikoliv vsak informace nutne pro sluzby, ale info ze ktereho se generovali hash-mapy

Vyhoda byla v jiz zminene rychlosti, nezavislost na DB (i kdyz se DB zhroutila nic se nedelo, pouze clovek neni schopen pridat/upravit/smazat uzivatel,ale system jede dal), nastroje zajistujici tento chod meli samozdrejme web rozhrani, za kterym sedela "opice".

Takze bych nezatracoval textove soubory.

[Luk]

Ulozeni informaci v prostych/hash souborech ma samozdrejme i svuj duvod, krome samozdrejme na prvni pohled horsi udrzovatelnosti (coz lze odbourat pomoci nekoli skriptu), ale prinaseji vyssi vykon zpracovani zprav.

Vyšší výkon přinášet nemusejí, zejména pokud se často mění.

Ono je sice moc pekne reseni(i na pohled napr.pro zakaznika) drzet informace o uctech v relacni DB (a to vcetne anti spam/vir reseni, forwardu ...), ale uvedovme si jak je tento proces narocny na DB, prichod jednoho emailu spousti pomerne narocnou proceduru a co teprve v pripade zpracovani i nejakou tu dekadu vetsiho poctu (1ky,10ky, 100ky tisic ), db permanentne pretizena, uzamykani tabulek ... apod. co horsi se muze stat nez, ze to DB nevydrzi a sesype se... problem

Problém to je, pokud se to špatně navrhne a/nebo realizuje. Databází může být více exemplářů (replikují se z jednoho zdroje) na samostatných strojích, ještě s on-line zálohováním (replikací) do geograficky vzdálené lokality. Například. Když něco uhnije, jede se dál. Problém s přetížením vzniká typicky při špatném návrhu DB.

Videl jsem reseni prave na rozsahlych hash-mapach, ktere navic dokazalo rozlozit zatez na vice serveru, informace se skutecne udrzovaly v DB, nikoliv vsak informace nutne pro sluzby, ale info ze ktereho se generovali hash-mapy

Jenže pokud se tam dějí změny, musí se to pořád všechno přegenerovávat znovu. I kvůli drobnosti, kdy se v DB updatuje jeden atribut v jediném řádku, se tady musí generovat celý obrovský soubor.

Takze bych nezatracoval textove soubory.

Soubory nezatracuji, je vidím jejich místo tam, kde je málo dat a hlavně se málo mění. Pro uložení více dat vidím jako lepší řešení použít databázi.