Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
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:
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).
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ů.
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).
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
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.
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:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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.
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 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.
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).
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
25.11.2009 17:03
vladky | skóre: 19
25.11.2009 20:36
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.Ano, ale ještě to bohužel chvilku potrvá.
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
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
25.11.2009 20:35
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
).
29.11.2009 22:48
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
25.11.2009 16:58
pele | skóre: 28
| blog: Bleabr
| UH
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ů).
27.11.2009 08:25
pele | skóre: 28
| blog: Bleabr
| UH
mydestination, jestlize je tato promenna prazdana vse je ok. A posta chodi i na virtualni ucty.
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.
29.11.2009 23:04
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
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... problemProblé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-mapyJenž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.