Stavíme poštovní server – 1 (Postfix)

12. 10. 2009 | Lukáš Jelínek | Sítě | 41798×

E-mailové řešení pro firmu nebo třeba neziskové sdružení, ale i rozjezd hostingových služeb, jejichž součástí elektronická pošta bývá – to jsou případy, kdy potřebujeme „postavit“ poštovní server nebo sadu serverů. Možnosti výběru jsou velké, a to i pokud zůstaneme jen u svobodného softwaru. Jako základní stavební kameny si lze zvolit například Postfix a Dovecot (případně v kombinaci s dalšími programy). Právě řešením postaveným na těchto dvou programech bude věnován tento seriál.

Obsah

• Proč právě…?
• Postfix a jeho historie
  • Historie programu Postfix
  • Proč používat Postfix
• Architektura poštovního systému Postfix
  • Průchod zpráv systémem Postfix
  • Další moduly programu Postfix
  • Informační zdroje programu Postfix
• To je všechno?

Proč právě…?

Proč si jako základ poštovního systému zvolit právě programy Postfix a Dovecot? Odpověď není až tak úplně jednoduchá, přesněji řečeno důvody jsou různé a většinou se jich uplatní hned několik najednou. Jsou samozřejmě případy, kdy bude vhodnější použít jiné programy, ale zmíněné dva bezproblémově vyhoví v široké škále situací, se kterými se setkáváme.

Vzhledem k té obsáhlosti zdůvodnění jsem se rozhodl zahájit seriál dvěma články, které budou věnovány obecnému popisu obou programů (tedy v tomto článku to bude Postfix, v příštím Dovecot) a představení důvodů, proč jsou tak vhodnými kandidáty pro nasazení na poštovních serverech.

Postfix a jeho historie

Postfix je poštovní server (Mail Transfer Agent, MTA), který plní základní úkoly při přenosu zpráv elektronické pošty. Mezi takové úkoly patří přebírání od klientů a od jiných poštovních serverů, směrování, předávání jiným serverům a doručování do schránek (jeho hlavním protokolem je SMTP, resp. ESMTP). Nestará se o přístup k poště (přes protokoly POP3 a IMAP4, ani přes webové rozhraní apod.), o ochranu proti spamu a virům (kromě využití „vhodného nastavení“, o kterém bude řeč v dalších dílech seriálu) ani o filtraci, třídění zpráv, automatické odpovídání a další „pokročilé“ funkce.

Že Postfix postrádá mnoho z funkcí, bez kterých si moderní poštovní server nelze představit, není vůbec na závadu. Lze ho totiž velmi snadno doplnit jinými programy, které tyto úkoly zastanou, a přitom není Postfix zbytečně zesložiťován a nafukován v případech, kdy takové funkce potřeba nejsou.

Historie programu Postfix

Program Postfix začal vyvíjet Wietse Zweitze Venema v IBM Thomas J. Watson Research Center ve druhé polovině 90. let. 14. prosince 1998 zveřejnila firma IBM tiskovou zprávu, kterou ohlásila vydání produktu Secure Mailer, což nebylo nic jiného, než program nazvaný též Postfix. Již před tímto oficiálním aktem byla k dispozici betaverze programu, tehdy pracovně nazvaného VMailer.

Cílem od samého počátku bylo nahradit dosud dominantní program Sendmail (který tehdy trpěl bezpečnostními chybami a byl obtížně konfigurovatelný) něčím mnohem bezpečnějším, robustnějším a snadněji spravovatelným. Na rozdíl od v zásadě monolitického Sendmailu byl VMailer/Postfix od počátku navržen jako silně modulární. Postfix je poskytován pod licencí IBM Public License (svobodná licence nekompatibilní s GNU GPL).

Přestože měl Wietse Venema původně v plánu po dokončení programu tento předat jiným lidem k další údržbě (aby se mohl věnovat jiným projektům), dodnes zůstává hlavním vývojářem a nové verze Postfixu stále vznikají poměrně rychlým tempem. Například nyní je aktuální řada 2.6.x (verze 2.6.0 byla vydána 12. 5. 2009), předchozí řada 2.5.x byla odstartována vydáním verze 2.5.0 dne 24. 1. 2008, již se připravuje řada 2.7.x. Aktuálně jsou (kromě řady 2.6.x) udržovány také řady 2.3.x, 2.4.x a 2.5.x.

Proč používat Postfix

Před podrobnějším rozvedením jednotlivých důvodů (včetně nezbytného technického pozadí) bude nejlepší uvést všechny tyto důvody pohromadě:

• flexibilita
• škálovatelnost
• funkční bohatost
• snadná konfigurace a správa
• robustnost, stabilita, bezpečnost
• nízké systémové nároky

Postfix je flexibilní. Lze ho v prakticky neomezené míře přizpůsobovat konkrétním potřebám. Může sloužit jako pouhý jednoduchý odesílací nástroj pro linuxový stroj, ale také jako server pro velkou firmu (s přenosem mnoha zpráv za sekundu) nebo pro hostingové řešení (tedy mnoho schránek na velkém počtu domén atd.). Data pro svou práci může získávat ze široké škály různých zdrojů. Se zprávami může nakládat mnoha způsoby.

Postfix je škálovatelný. Pro svůj běh si vystačí s omezeným prostředím, ale je-li třeba (a je-li správně nastaven), může stejně tak využít i možnosti poskytované mnohaprocesorovým strojem s velkou pamětí a rychlými síťovými rozhraními.

Postfix je funkčně bohatý. Přestože řadu úkolů poštovního serveru vůbec neřeší (třeba komplexní antispamovou filtraci), ve své funkční doméně toho nabízí opravdu hodně. Týká se to způsobu směrování, doručování a předávání zpráv, možností autentizace a autorizace, formálních kontrol zpráv a relací, komunikace s pomocnými programy atd.

Postfix je snadno spravovatelný a konfigurovatelný. Konfigurační soubor je složen z jednoduchých pravidel typu parametr=hodnota, není potřeba znát žádnou speciální syntaxi, všechno je dobře zdokumentováno. Pokud něco nefunguje nebo se chová anomálně, Postfix to dá srozumitelným způsobem vědět do logu.

Postfix je stabilní, robustní a bezpečný. Modulární koncepce znamená, že problémy jedné komponenty neohrožují funkci ostatních komponent. Havaruje-li některá komponenta, je restartována, ale s ohledem na zátěž systému. Bezpečnost je zajišťována hned několika způsoby – minimalitou práv, důslednou separací práv mezi moduly, možností zcela izolovat většinu modulů pomocí chroot, definicí různých omezení v konfiguraci a dalšími pomocnými metodami.

Postfix má nízké systémové nároky. Běží jen ty komponenty, které se skutečně používají. Nevyužívají se žádné paměťově náročné knihovny ani žravé algoritmy. Náročnost lze ještě dále snížit vhodnou konfigurací.

Architektura poštovního systému Postfix

Postfix je složen z hlavního modulu nazvaného master a z výkonných modulů, realizujících konkrétní úkoly. Modul master (v závislosti na své konfiguraci) výkonné moduly spouští a kontroluje jejich funkci. V případě, že nějaký modul neočekávaně skončí, master ho restartuje. Pokud jsou ale s nějakým modulem nadále problémy, čeká se po stanovenou dobu (výchozí hodnota je 1 minuta), aby nebyl systém zbytečně zatěžován neúspěšnými starty.

Lze určit, kolik instancí (procesů) kterého modulu smí maximálně běžet, jak dlouho má služba čekat na příchozí spojení před svým ukončením, jak často má master probouzet určitý modul atd. Těmito parametry lze ovlivňovat spotřebu prostředků (a na druhou stranu i rychlost odezvy a průchodnost) v závislosti na konkrétních potřebách a možnostech. Tak lze například seškrtit spotřebu tam, kde není potřeba vysoký výkon, a naopak poskytnout dostatečné možnosti na silném stroji a při velkých nárocích na výkon.

Modul master může spravovat i komponenty, které nejsou součástí programu Postfix. Typicky se může jednat třeba o situaci, kdy finální doručení do schránky provádí nějaký doručovací agent (třeba z programu Dovecot, bude popsán v příštím dílu seriálu). Dále může také stejná komponenta vystupovat ve více rolích, tedy master s ní nakládá různým způsobem (toto zase využíváme například při externí antispamové filtraci).

Součástí systému jsou samozřejmě také nástroje pro jeho ovládání. Přímo v balíku jsou k dispozici jednoduché konzolové utility, ale Postfix lze ovládat i jinými programy – ať už přímo, nebo nepřímo (přes zmíněné utility).

Průchod zpráv systémem Postfix

Cesta zpráv celým systémem může být poměrně komplikovaná. Bez dostatečného poznání, jaký úkol má na této cestě který modul, se však Postfix špatně konfiguruje. Ve velmi obecné rovině to ukazuje následující obrázek:

Zpráva se může do systému dostat několika cestami. Nejčastěji bude přijata přes síťovou SMTP relaci (případně přes QMQP, ale to je hodně vzácná věc), u lokálně odesílaných zpráv (od běžných poštovních klientů, ale třeba i od systémových programů nebo od PHP skriptů) také přes rozhraní „sendmail“ (příkaz se syntaxí odpovídající stejnojmennému programu, byť zde tuto funkcionalitu zajišťuje Postfix). Při síťovém příjmu zprávu přijímá modul smtpd (zajišťuje komunikaci na serverovém socketu).

Na vstupu zprávu zpracuje modul cleanup, který se postará o opravu a doplnění hlaviček, případně provede expanzi cílových obálkových adres (může využít služeb modulu trivial-rewrite) a vloží zprávu do fronty příchozích zpráv (incoming). Poté notifikuje správce fronty (qmgr), že je ve frontě nová zpráva.

Správce si udržuje „aktivní frontu“, což je jakési okno do skutečných front (příchozích a odložených zpráv) – tyto zprávy zkouší předávat dál. Pokud se mu to podaří, zpráva se odebere z fronty. Nepodaří-li se to, zpráva se umístí do fronty deferred (odložené zprávy), pokud tam dosud nebyla, a po nějaké době se opět aktivuje pro další doručovací pokus.

Další osud zprávy může být velmi rozličný. Starají se o něj doručovací agenty, konkrétně moduly smtp, lmtp, local, virtual nebo pipe. Modul smtp je SMTP klient, předává tedy zprávu nějakému dalšímu SMTP serveru – tím může být cílový server, relay server nebo třeba nějaký filtrační mechanismus. Totéž platí i pro modul lmtp, jehož protokol LMTP se však používá poměrně zřídka. Modul local doručuje místním příjemcům (uživatelům počítače), modul virtual pak virtuálním příjemcům (typická funkce pro poštovní hosting). A konečně pipe předává zprávy spouštěnému externímu programu.

Speciálními případy doručovacích agentů jsou moduly discard a error. Ty totiž ve skutečnosti nikam dál nedoručují. Modul discard zprávu prostě zahodí, error ji vrátí s dočasnou chybou retry nebo trvalou chybou error. Takové chování těchto speciálních agentů se využívá v situacích, kdy nelze z nějakého důvodu zprávu někam normálně doručit.

Další moduly programu Postfix

Kromě uvedených modulů se nakládání se zprávami a dalších činností poštovního serveru Postfix účastní ještě další moduly. Následující seznam bude jen heslovitý, protože na detailní popis jednotlivých modulů nastane pravý čas později.

• trivial-rewrite – jednoduchá kontrola a vyhodnocení adres (s využitím tabulek transportů a relokací)
• bounce – generování zpráv o (ne)doručení zprávy (včetně zpráv o dočasném nedoručení)
• flush – udržuje informace o zprávách podle cílů (urychluje vyžádané doručení, např. pomocí ETRN)
• proxymap – služba pro společný přístup k mapovacím tabulkám
• scache – sdílená cache odchozích spojení
• showq – poskytování informací o frontě zpráv
• spawn – spouštění externích programů (obdoba inetd)
• tlsmgr – správa generátoru pseudonáhodných čísel a TLS klíčů
• verify – kontrola zpráv ještě před jejich přijetím
• anvil – udržování statistik o počtu a četnosti připojení (pro zabránění zahlcení serveru)

Přítomnost jednotlivých modulů v běžícím serveru a jejich interakce s jinými moduly závisí na konfiguraci serveru. Například modul tlsmgr se spouští jen v případě, že se používá TLS komunikace. Většina modulů může běžet s minimálními právy (a v prostředí chroot), takže lze omezit potenciální bezpečnostní rizika, která by z nich pramenila.

Informační zdroje programu Postfix

Postfix může využívat celou škálu informačních zdrojů (tabulek). Co si pod tímto obecným pojmem představit? Z pohledu významu třeba seznamy doručovaných domén, mapování adres na schránky, aliasy, blacklisty a whitelisty, autentizační informace apod. Jednotlivým modulům stačí mít k dispozici potřebné informace a nezáleží na tom, odkud a jak se získají. Z pohledu člověka, který rozhoduje o způsobu nasazení a správy serveru, to však samozřejmě důležité je.

Proto Postfix podporuje řadu různých metod, jak potřebné informace získávat. Lze tak na jednu stranu velmi rychle zprovoznit jednoduchý server, ale současně také mít možnost pracovat s externími databázemi různého typu. Toto jsou obecně podporované metody:

• hash – hešové tabulky (typicky předem vytvářené z textových souborů)
• btree – vyvážené stromy (dtto)
• cdb, dbm, sdbm – jednoduché databáze uvedených typů
• regexp, pcre – regulární výrazy (POSIXové, resp. perlové)
• tcp – dotazování pomocí jednoduchého protokolu nad TCP
• cidr – tabulky ve formátu CIDR (Classless Inter-Domain Routing)
• ldap – dotazování protokolem LDAP
• environ – využití proměnných prostředí
• nis, nisplus – databáze NIS, resp. NIS+
• static – pevně definované hodnoty
• netinfo – databáze Netinfo (známá např. ze systémů Mac OS X)
• mysql – databáze MySQL
• pqsql – databáze PostgreSQL
• unix – standardní unixová databáze uživatelů
• proxy – využití modulu proxymap (vždy se kombinuje s jinou metodou přístupu, ke které se přes proxy přistupuje)

Ne vždy jsou všechny metody k dispozici (vyžadují zakompilování do serveru a často také podporu v systému, např. u databází), navíc ne vždy lze každou z nich použít, též samozřejmě různé metody jsou vhodné v různých případech. Například metodu unix nelze použít k ničemu jinému, než je ověřování uživatelů. Proměnné prostředí nebo statické hodnoty se zase hodí jen pro skutečně primitivní informace.

V každém případě tato široká škála poskytuje dostatek možností, jak si server maximálně přizpůsobit „k obrazu svému“, tedy pro určité použití. Komu by přece něco scházelo, existují implementace dalších metod, případně si lze vytvořit něco vlastního (ať už přímo přes příslušné API nebo třeba pomocí dotazování přes TCP). Jinak pro ověřování uživatelů Postfix podporuje standardizovanou metodu SASL, což lze s výhodou využít například při jeho spolupráci s programem Dovecot, ale i v jiných případech.

To je všechno?

Zatím ano. Toto byl jen takový velice letmý průlet tím, co Postfix všechno umí. Výčty modulů a metod jsou tu jen pro ilustraci šíře záběru tohoto programu. Mnohem zajímavější to ale bude, až se ukáže v praxi. To bude ale až přespříště, protože příště se stručně představí jeho společník: program Dovecot. Bez přístupu k poště by poštovní server rozhodně nebyl plnohodnotný. A Dovecot toho má skutečně dost co nabídnout, ve vzájemném porovnání je Postfixu zcela rovnocenným soupeřem.

       

Komentáře

[misace]

Super, tohle už tady dlouho nebylo. Myslím, že by bylo vynikající, kdyby v připravovaném návodou bylo ověřování přes LDAP.

[Luk]

LDAP bude.

[kvas]

a urcite by sa hodilo aj riesenie s virtualnymi uctami a domenami ulozenymi v databaze (napr: postgres, mysql)

[Antonín Kolísek]

Tohle není příliš efektivní řešení. My to tak v práci máme, ale při počtu cca 500 schránek a více člověk pozná, že databáze není ideální řešení. Daleko lepší (i když asi na konfiguraci pracnější) je LDAP.

[Vskutečnosti Saýc]

I pro desitky az stovky virtuanich domen, kde v kazde jsou dva tri mailboxy?

[Raduz]

Různá zadání žádají různá řešení. Ale ja také zastávám názor, že LDAP je lepší než samostatná databáze někde bokem. LDAP je obvykle hlavní zdroj informací o uživatelích a účtech, tak proč se zatěžovat správou nějaké další samostatné databáze, a potažmo serveru, když to můžu mít všechno na jednom místě, spravované jednou sadou nástrojů.

[Vskutečnosti Saýc]

Jasne, nesnazim se vas presvedcit ze je LDAP spatny napad, jen jsem zvedavy jak to funguje. Dobastlit si spravu virtualnich domen, mailboxu a aliasu nad mysql nebo postgre je docela snadne, jde to snadno i u ldapu (nebo je neco hotoveho?) a co virtualni domeny?

[Raduz]

Osobně jsem na svém serveru nešel až do důsledku, abych dělal v LDAP úplně všechno, hlavně proto, že nepotřebuju např. hromady aliasů, a mám jen několik statických virtuálních domén, takže tyhle věci jsem udělal natvrdo v texťácích (ale taky by to skrz LDAP šlo). Hlavně mám v LDAP uživatele, které Postfix při příjmu mailu dohledá, a pokud je najde, tak si z náležitých atributů vytáhne a poskládá cestu do jejich maildiru, a mail do něj uloží. Něco podobného pak dělá Courier IMAP.

Takže když vytvářím hromadně síťové uživatelské účty, stačí mi u každého uživatele pouze správně vyplněný atribut "mail", který v sobě nese mailovou adresu, a atribut "mailMessageStore", který v sobě nese úplnou cestu k maildiru na mail serveru (ten je pro Courier, Postfix ho při správném nastavení nepotřebuje, vystačí jen s mailovou adresou), a dál se nemusím o nic starat. K tomu vytvářím skriptem na serveru rovnou i ty maildiry, ale není to nutné - pokud Postfix při ověřovaní adresy zjistí že je uživatel platný, vytvoří mu maildir při prvním doručeném mailu automaticky.

[xkucf03]

Ona je hlavně otázka, jestli ten LDAP už máme nebo ne. Já mám naopak většinu věcí v DB, takže jsem i uživatele poštovního serveru a aliasy dal do DB. Věřím, že dobře vyladěná DB (indexy, datový model, správná volba DBMS) je výkonově srovnatelná se stejně dobře vyladěným LDAPem (možná i lepší). Jestli jste někdo dělal na tohle testy, tak sem s tím

Pokud naopak už LDAP máme a je to naše primární úložiště uživatelů, tak je asi celkem jasnou volbou. Rychlost dotazování není zdaleka jediným kritériem, ani není nejdůležitějším – projeví se až při vysokých objemech mailů (ale stejně víc výkonu sežere antivirus a antispam, pokud jsou).

[Kvakor]

Ano, zavádět LDAP jen kvůli Postfixu je zbytečnost, protože databáze je úzké hrdlo až při opravdu velkých objemech pošty nebo při DDoS útocích (ale ty dokáže omezit i samotný Postfix přes modul anvil). Navíc se dá databáze použít i pro jiné věci než samotné uživatelské účty a aliasy, například pro whitelisty, greylist a blacklisty.

[hwsoft]

V cem SQL nevyhovuje? Tech 500 schranek fakt neni moc, aby to bylo na zatizeni videt i SPAM "utoku"

[Antonín Kolísek]

1/ Kdyz se k tomu pripocte i webmail a dalsi dodelavky, tak je to docela dost spojeni s databazi (musel jsem zvetsit maximalni pocet spojeni na 500), nicmene o zatez nejde..ale spis o prakticnost.

2/ Daleko vetsi problem byl, kdyz jsme chteli po nejake dobe data centralizovat (mit nejakou hlavni db). Nacitani z mysql jsme museli recit ruzne pres externi nastroje. LDAP se mi jevi jako daleko lepsi reseni protoze s tim umi pracovat asi i vice aplikaci.

Proste kdyz jsme to rozjizdeli zdalo se mysql jako vhodne reseni. Pominu-li malickosti jako ze Postfix v RHEL podporuje pouze PostgreSQL, maildrop tam vubec neni... takze se plno veci muselo kompilovat rucne, ale to je otazka volby distribuce. Dnes to mame vyborne zajete a odladene s mnozstvim vychytavek a vylepseni, takze se uz nevyplati prechod k LDAPu.

[SAL]

My pouzivame postfix+dovecot a ucty mame riesene v mysql cez libnss_mysql. Okolo 10000 uctov na jednom servri a nepocitujeme ziaden problem (asi 2000 zamestnancov a zvysok studenti).

[Luk]

Záleží, o jak velký server jde, jak se to bude spravovat atd. Databáze zvládne hodně (těch 500 schránek je vcelku směšný počet - pokud je ta databáze správně navržena, nemá s tím problém), ale u větších serverů je opravdu lepší LDAP.

[Andrej]

LDAP je optimalizovany na caste citanie a zriedkavy zapis. Mat na tom zaveseny vytazeny mailserver mi nepride ako dobry napad.

[Raduz]

A můžu vědět proč? Vždyť ten mail server přesně tohle dělá - často z LDAP čte, ale nic do něj nezapisuje.

[Ripper]

Osobně si myslím, že je LDAP dobré řešení pro podnikový server tak v řádu stovek uživatelů, kde na něm budou provozovány i třeba nějaké místní profily a tak podobně. Pro mail server typu hosting s vícero doménami a vícero adminy je lepší nějaká ta SQL, která bez problémů zvládne velký počet uživatelů. Manipulace a podobně je potom efektivnější.

[Jakub Lucký]

nebo se chová abnomálně

[Luk]

Ne, anomálně (anomálie=odchylka). Abnormálně je IMHO spíš "nad normálem", anomálně se mi zdá vhodnější.

[Jakub Lucký]

ah... Jo, to určitě.. já v těch nočních hodinách totiž místo anomálně anormálně, což je tak trošku paskvil... Anomálně nebo abnormálně je OK

[dad]

kdysi davno mel grumpa na eurowiki cely takovy navod. Hledal jsem to, asi tu wiki zrusili. Nevim jestli tam byl postfix a nebo exim, ale dovecot tam byl v kazdem pripade. Takze bude tento serial doufam dobra nahrada. Zjistuji, ze je relativne malo navodu pro kombinaci exim+cyrus-imapd ve srovnani s postfixem+nejaky-imapd. Nevi nekdo proc? Je exim tak hrozny?

[Zdenek]

Nevim jestli je hrozny, ale posledni verze je 2 roky stara. Tudiz ho povazuji za mrtvy a pri mem vyberu vyhral prave postfix.

[pasmen]

Myslím, že Exim hrozný není. Tedy alespoň "nová" verze, která už je modulární. Mám doma knížku od O'Reillyho o Postfixu, a na začátku ve srovnání MTA se dokonce píše, že Postfix a Exim vychází +/- na stejno. Jen je Postfix řekl bych provařenější, existuje proto pro něj mnohem více návodů a co je důležitější, více těch drobných prográmku, které zaručí kompletní funkčnost. Většina z nich na volbě MTA samozřejmě nezávisí, ale některé ano (např. můj oblíbený postgrey).

[Michal Kopecny]

Ja mam Exim4 vylozene rad ;)

m.

[Ondrej 'SanTiago' Zajicek]

> Zjistuji, ze je relativne malo navodu pro kombinaci exim+cyrus-imapd ve srovnani s postfixem+nejaky-imapd. Nevi nekdo proc?

Mozna proto, ze exim ma vynikajici dokumentaci, narozdil od postfixe, kde me dokumentace prijde jako nekompletni snuska nesouvisejicich souboru, a tak neni treba tolik jinych navodu.

[vencour]

Dík za článek. Nedávno jsem taky hledal, našel jsem http://flurdy.com/docs/postfix/.

[Vskutečnosti Saýc]

To nevim jak moc bude pouzitelne -- sice ta maji vyvesene docela nove datum posledni aktualizace, ale amavis je uz roky mrtvy projekt.

[vencour]

Fajn, dík za zhonocení. I takováhle konfrontace myšlenek mi přijde užitečná. Přesto ... RC ke stažení jsou, poslední z června 2009, fakt je mrtvý?

[Luk]

fakt je mrtvý?

Není, Jakub si zřejmě popletl původní amavis a nový amavisd-new. A z toho června je nejen RC, ale (z 25.6.) i ostrá verze 2.6.4.

[Vskutečnosti Saýc]

Eh, jo.

Sorry :)

[Luk]

amavis je uz roky mrtvy projekt

Amavis ano, amavisd-new ne. Navíc amavisd-new bohužel nemá srovnatelnou náhradu (nejlépe takovou, která by nebyla v Perlu).

[Vskutečnosti Saýc]

Existuje sagator (ktery je teda napsany v pythonu). Ale nabizi se otazka, jestli to necemu vadi, pokud kolem lita spamassassin.

[Luk]

Perl ani Python nemám příliš v oblibě (a nejhorší je, když běží oba najednou). Jsou žravé a pomalé. Optimální by bylo mít tyto věci (jako amavis nebo SA) napsané v C nebo C++, ale chápu, že se do toho nikomu nechce.

[Ondrej 'SanTiago' Zajicek]

Existuje dspam, jako antispamovy filtr napsany v C.

[Luk]

Kdysi jsem ho testoval, neměl jsem s ním moc dobré zkušenosti. I když je to tedy pár let zpátky, takže je možné, že se zlepšil.

[ntw]

Hledám náhradu za současný zastaralý mailserver postavený na qmail + vpopmail + mysql + courier_imap, na kterém provozuji asi 450 domén s 2500 schránkami. Jsem zvědavý, jestli mně tento seriál pomůže.

[Andrej]

Postfix se mi nikdy příliš nepozdával. Používám Courier-MTA, protože je mnohem flexibilnější. Záležitosti jako podpora pro IMAP nebo POP3 jsou pro něj samozřejmostí. Není třeba hledat žádný další program. A co je nejdůležitější: ESMTP, IMAP i POP3 mají společnou správu přihlašovacích údajů a uživatelských účtů. Tohle Postfix jednoduše neumí.

[Luk]

Záležitosti jako podpora pro IMAP nebo POP3 jsou pro něj samozřejmostí. Není třeba hledat žádný další program.

Ano, pro někoho, kdo chce mít vše v jednom. Někdo chce mít ale řešení složené z komponent, které mu lépe vyhovují - tak si vybere něco jiného.

A co je nejdůležitější: ESMTP, IMAP i POP3 mají společnou správu přihlašovacích údajů a uživatelských účtů. Tohle Postfix jednoduše neumí.

Neumí, protože neumí IMAP a POP3. Když se ale dá dohromady například Postfix a Dovecot, je společná správa samozřejmostí (protože Postfix využívá SASL z Dovecotu).

[brabitom]

Zajimavej serial, a protoze zrovna resim postovni server, tak se mi to hodi

Mimochodem, tady je taky zajimavy clanek o vytvoreni postovniho serveru, s ucty v MySQL: http://www.zdenda.com/mailserver-postfix-imap-maildrop-mysql Nepouziva se tam sice Dovecot, ale kombinace Courier-IMAP a Courier-Maildrop, navic je uz nejaky ten rok stary, ale je to hodne zajimave pocteni.