Seznam Serveru s popisem:

TECH:Konvertor

Z VOLNYpedie

Konvertor je aplikační server na adrese conv.vol.cz, postavený na metadatad a balíku metadatad-services-converter.

Slouží ke konverzi dokumentů z jednoho formátu do druhého, např. Word do HTML. Výstupem
konvertoru může být i více souborů, např. HTML soubor a z něj linkované obrázky. Využívá se především
ve webmailu pro zobrazování náhledů nestandardních typů příloh.

Přehled
Na conv.vol.cz jsou nainstalovány balíky metadatad a metadatad-services-converter, které jsou vyvíjeny na area51 ve /var/www. Log všech operací je na serveru v /var/log/metadatad.log. Dočasné adresáře jsou
vytvářeny a automaticky po čase odstrańovány v /var/metadatad/tmp.
Přenos dat probíhá standardním metadatad protokolem. Je tedy možno využívat persistentní spojení i
efektivní chunkované předávání vstupu a výstupu, nikde tedy nejsou potenciálně velmi velké soubory
ukládány celé naráz do paměti. Služba konvertor není autentizována per-uživatel, využívá se jen globálního
hesla pro přístup k metadatad serveru.

Klient na server posílá tyto parts:

1. XML meta informace, obsahující parametry daného konvertoru
2. binárně vstupní soubor

Server posílá klientovi:

1. XML meta informace
2. binárně první výstupní soubor
3. binárně druhý výstupní soubor

Součástí výstupních XML informací jsou i názvy zasílaných souborů. Klientská třída je využije při ukládání
výstupních souborů do adresáře. Služba konvertoru se stará o několik důležitých věcí:

• Uklízí po sobě dočasné adresáře.
• Má spolehlivě řešený timeout v případě, že se spouštěný command line nástroj zasekne.

Implementace řeší pomocí process group i spolehlivé ukončení (SIGKILL) všech podprocesů
spuštěných tímto nástrojem. Timeout je implicitně 60 sekund, lze ho u všech konvertorů při jejich
volání změnit pomocí parametru max_runtime.

Klientské aplikace

PHP

• /var/www/classes/MetadataConverter.inc na area51 - detailní popis a ukázku využití najdete přímo v ní

Perl

• třída MetaClient?.pm z mailutil, funkční ukázku použití a command line tester naleznete v metadatad-services-converter/test na area51

Dostupné konvertory

PdfToHtml

Konvertuje PDF do obrázku vložených v HTML stránkch. Přijímá parametr max_pages, který určuje, kolik
maximálně stránek má být zkonvertováno, což je důležité z hlediska nepřetížení stroje.
Využívá port COL/pdf2html, který modifikuje program z http://freshmeat.net/redir/pdf2html/7693/url_tgz
/pdf2html
TODO: Nejslabší konvertor, konvertuje skutečně do obrázků, není tedy možné výsledný text označit a
kopírovat atd. Bylo by vhodné ho v budoucnu nahradit nějakým konvertorem, který by text konvertoval
skutečně na text a grafické prvky by byly přiloženy jako obrázky, podobně jako funguje WordToHtml?.

WordToHtml
Konvertuje MS Word soubor do jednoho HTML dokumentu s případnými vloženými obrázky.
Využívá port textproc/wv. http://wvware.sourceforge.net/

ExcelToHtml
Využívá port textproc/xlhtml. http://chicago.sourceforge.net/xlhtml/

FoToPdf
Využívá port /usr/ports/textproc/fop, aktuálně verzi 0.93 rozšířenou o podporu českých fontů

TnefToHtml
Testování funkčnosti
Funkčnost je testována přihlášením na konto aa_volmejltest. Zde ve složce DORUČENÉ dejte vyhledat
zprávu s předmětem "test priloh". V ní najdete všechny v současnosti podporované typy příloh - klikněte u
nich na náhled.

TECH:MailSystem

Příjem pošty, datové uložiště, služby backendu (POP3, filterd, metadatad)

• Backendy
  • Backend datové uložiště - MD5 struktura, adresáře uživatelů, indexy, uložení zpráv a složek
  • Backend administrace - postupy, upgrade, instalace, přesun schránek, NFS, hardware, disková pole, výkon
• Relay servery - přijímající, cílové SMTP servery
• Filterd - LMTP démon pro ukládání a filtrování příchozích zpráv
• MetadatadServicesMail - metadatad služby pro práci s backend datovým uložištěm
• POP3 - reseni POP3 pristupu k mailboxum uzivatelu
• Kvóty - omezení na velikost mailboxu, jak se s nimi pracuje, kdy se nastavují
• Antivirus
• Antispam
  • SpamAssassin - Open Source nástroj pro detekci spamu
  • FuzzyOCR - OCR plugin pro SpamAssassin? pro detekci obrázkových spamů
• Mailutil - Perl knihovna modulů, využívaná ve filterd, metadatad a jinde
• Mailindex - Perl knihovna zajišťující práci s Maildiry a SQLITE indexy
• ContentSwitch - systém pro rozdělení uživatelských homedirů na jednotlivé backendy dle MD5 prefixů
• Filtry - funkce, způsob uložení, implementace
• Úschovna - datový prostor pro uživatelské soubory v jejich homediru

Web rozhraní, obecnější témata

• Webmail
  • Webová aplikace - vývoj - konfigurace, popis kódu, požadavky na verzi a extenze PHP
  • Webová aplikace - administrace - postupy při změnách, práce s CVS, nahazování na ostré,
• administrace, logy
• Práce a propojení s Omnisem
• Frontend MySQL databáze
• Uživatelská nastavení
• Archivace
• Uživatelský log přístupů přes POP3 a web
• Superkoš - složka Supertrash, obnovování smazaných zpráv
• Odpad - složka Junk (ODPAD), automaticky promazávaná složka pro ukládání spamu a virů
• WAP rozhraní
• Aliasy - extra adresy v jiných doménach
• Vyhledávání v obsahu mailboxu
• Zabezpečení a autentizace - práce s hesly, změna hesla
• Znaková sada - práce s kódováním a diakritikou, UTF8
• Odesílání a komponování zpráv - HTML editor, vkládané hlavičky, formát
• Přilohy - náhledy Word, Excel, PDF, práce s konvertorem
• Administrační rozhraní - jeho funkce, jak co funguje
• Reklama - ve webové aplikaci, patičky, zpracování statistik direct mailů ve filterd
• Testování - testovací scénáře

TECH:Metadatad

metadatad (Metadata Daemon) je server pro předávání různých údajů proprietárním protokolem. Server je napsaný v Perlu a má modulární architekturu. Samotný server řeší jen transport po síti, o zpracování obsahu požadavků se starají pluginy služeb (services). Nasazení metadatad ve VOLNÉM je dvojí, jako součást mailového systému, a pro konverze formátů dokumentů.

Protokol
Server naslouchá tradičně na portu 26666. Při příchozím spojení spawnuje nový child proces. V jednom spojení lze obsloužit více požadavků, server podporuje persistentní spojení. Požadavky i odpovědi jsou předávány ve formě jednoduchých XML dokumentů.
Službám, které vyžadují práci nad daty zákazníka (emailové schránky), je předána autorizace ve formě páru username a heslo. Aby nebylo nutno ověřovat uživatele při každém požadavku, metadatad umožňuje autorizaci následných požadavků pomocí páru username a session_id. Sessions jsou ukládány na straně metadatad serveru do SQLite databáze.
První čtyři bajty požadavku udávají verzi metadatad protokolu. Následující čtyři bajty udávají počet částí v požadavku. První část (part) je vždy XML s požadavkem, mohou následovat nepovinně části s binárními daty, např. soubory příloh atd. Následují čtyři bajty udávají velikost obsahu části, hned po nich následuje tělo části.
Po přijetí požadavku od klienta se nejdříve ověřuje heslo, nastavené globálně pro celý server v jeho konfiguraci (request/auth/metadatad_password). Následně je přečteno jméno požadované služby (request/service). V konfiguraci serveru je ověřeno, že požadavek přichází z povoleného IP rozsahu pro danou službu. Následně je vykonáno volání služby.

Ukázka XML požadavku (request):

Výsledek volání je předán zpět klientu jako XML response dokument. Ten má pevnou strukturu, obsahující status (OK, ERROR), číslo chyby, případně chybový text, a element data, který obsahuje XML dokument generovaný volanou službou.
Ukázka:

Metadatad má speciální funkčnost redirekce, která umožňuje přesměrovat klienta na jiný metadatad server (běžící na jiném stroji). Klient se po obdržení příslušného kódu spojí s novým serveru a zopakuje požadavek - obdoba HTTP redirektu. Dále metadatad umožňuje fungovat jako metadata proxy - předávat všechny požadavky na jiný metadatad server. Tyto funkce v běžném provozu ve VOLNÉM nepoužíváme.

Klient
K dispozici je klientská knihovna pro Perl a PHP.

Služby

• MetadatadServicesMail
• Konvertor dokumentů

TECH:MS:Antispam

Antispam je využíván pro kontrolu příchozí pošty, u zákazníků i zaměstnanců. Kontrola příchozí pošty je na mail system backendech realizována ve Filterd. Antispam je využíván i v RT.

Implementace - KAS
Jako hlavní antispam využíváme Kaspersky Antispam (http://www.kaspersky.com/linux_antispam) ,komerční closed source produkt, verzi pro FreeBSD. Ten implementuje Milter rozhraní pomocí démona kas-milter. Přes toto rozhraní s ním pak komunikuje filterd na backendech pro příchozí poštu. Spamová databáze KAS je aktualizována automaticky z cronu několikrát denně.
Implementace - SpamAssassin?
Jako dodatečný antispam je na colmailu využíván SpamAssassin? (SA). Ten testuje zprávy, které KAS označil jako čisté. SA nabízí oproti KAS navíc především detekci obrázkových spamů prostřednictvím pluginu FuzzyOCR.

Nastavení
Antispam je ve filterd zapínán pomocí filtrů, buď uživatelských nebo globálních. Volba citlivosti analýzy není u KAS možná.
Antispamová opatření na relay
Kromě hlavní antispamové detekce na backendech využíváme i kontroly na přijímacích relays - zde se provádí kontrola existence reverzního DNS záznamu právě připojeného SMTP serveru. Tuto kontrolu je možné vypnout v Nastavení web-aplikace v Antivirus&Antispam zvolením Úroveň antispamu =>Standardní.

Spouštění a administrace
KAS je instalován jako FreeBSD package kas-isp.

Kasmilter loguje do adresáře /usr/local/ap-mailfilter3/log.

TECH:MS:Antivirus

Antivirus je využíván pro kontrolu příchozí a v některých případech i odchozí pošty, u zákazníků i zaměstnanců. Kontrola příchozí pošty je realizována ve Filterd. Kontrola odchozí pošty je prováděna na webmailech při odesílání zprávy (pouze profibox) a také na odchozí SMTP relay pro odesílanou poštu zaměstnanců.

Implementace
Využíváme Kaspersky Antivirus (http://www.kaspersky.com/kav6) , komerční closed source produkt, verzi pro FreeBSD. Ten implementuje Milter rozhraní pomocí démona kavmilter. Přes toto rozhraní s ním pak komunikuje filterd na backendech pro příchozí poštu, skript milter.pl z mailutil na web rozhraní a Sendmail na odesílací relay pro poštu zaměstnanců. Virová databáze je aktualizována automaticky z cronu několikrát denně.
Nastavení
Antivirus je ve filterd zapínán pomocí filtrů, buď uživatelských nebo globálních. Na colmailu si zaměstnanec nemůže změnit defaultní antivirus filtr, nastavovaný oddělením sysadmin. Uživatel má možnost nechat si posílat upozornění při zachycení viru.

Spouštění a administrace
KAV je instalován jako FreeBSD package COL-kav4milter-freebsd.

Kavmilter loguje do maillogu.

TECH:MS:FileStore

Úschovna poskytuje uživatelům webmail rozhraní možnost uložit na backend serverech své soubory a snadno je odesílat jako přilohy zpráv nebo pomocí odkazu na speciální stahovací stránku.

Využití, implementace ve web rozhraní

• Uživatelé mohou do úschovny ukládat soubory těmito způsoby:
  • Přímý upload souboru z prohlížeče (www/filestore.php).
  • Uložit do úschovny přílohu některé zprávy (www/view.php).
• Soubory v úschovně je možné využívat takto:
  • Jako odkládací prostor - soubor přímo stáhnout (www/filestore.php).
  • Připojovat soubory k odesílaným zprávám přímo jako attachment (www/compose.php) - toto je vhodné např. pokud uživatel odesílá častěji svůj životopis atp.
  • Připojovat soubory k odesílaným zprávám formou odkazu. To je vhodné v případě, že soubor by byl jako attachment příliš velký. Do odesílané zprávy je umístěn odkaz (www/compose.php), který příjemce odkáže na stránku, kde po zadání (náhodně vygenerovaného) hesla může soubor stáhnout (www/fsdown.php), aniž by sám měl konto v mailsystemu.

• Úschovna prozatím nepodporuje rozdělování uložených souborů do podadresářů. Uživateli je její obsah prezentován jako jeden dlouhý seznam názvů souborů, setříděný dle abecedy.
• Maximální velikost jednotlivých souborů není omezená.
• Ke každému souboru je možné uložit poznámku, která je uložená ve webmaildb, tabulka FileStore?, sloupec "memo".
• Na backendu jsou uloženy pouze samotné obsahy souborů, veškerá metadata (název souboru, velikosti, poznámky) jsou uložena ve webmaildb (tabulka FileStore).
• Výpis obsahu úschovny je vytvářen bez komunikace s backendem, pouze z obsahu tabulky FileStore?.
• V konfiguraci webmailu se úschovny týkají volby:
  • FILESTORE_ACTIVE - globalne zapina funkce souvisejici s uschovnou. Pokud je FALSE, uzivatel je presmerovavan na stranku s hlasenim o docasne nedostupnosti uschovny.
  • FILESTORE_HOST - určuje hostname v odkazu vkládaném do odesílaných zpráv při posílání souboru přes odkaz (mail.volny.cz).

Kapacita úschovny
Kapacita úschovny je omezená per-uživatel, její max. velikost je pro jednotlivá konta uložena v Omnisu. Webová aplikace ji načítá z Radiusu pomocí testlibradc výstupní hodnoty "storage = XXX", kde XXX je integer hodnota v MB (inc/UserManager.inc-getExtraInfoRadius()). Ve webové aplikaci je s touto hodnotou dále pracováno přes $this->_uc"EX_FILESTORE", kde je uložena v kB (inc/AppPage.inc-processExtraInfo()). Vynucování tohoto omezení je prováděno pouze na webu (www/filestore.php), nikoliv na backendu.

Statistika využívání a zaplnění
Úschovna byla zprovozněna 1.7.2004, celkové množství dat narůstá rychlostí cca. 3 GB / měsíc (Oct 2006). Každou noc je na stroji portal2.vol.cz z crontab spouštěn skript:

Tento skript odesílá do konference application-reports-l v(e) col.cz statistiku využití, jejiž celkový trend se příliš nemění. V říjnu 2006 vypadala takto:

Stahování přes odkaz s využitím hesla
Pokud uživatel chce poslat soubor z úschovny odkazem, vygeneruje se do odesílané zprávy takovýto text:

Toto heslo je automaticky generováno ke každému souboru v okamžiku prvotního uložení do úschovny a nelze poté již změnit. K jeho generování je užita funkce String.inc-niceRandomPassword(), která se snaží generovat dobře čitelná hesla vhodnou kombinací souhlásek a samohlásek. Adresát po obdržení zprávy otevře tento odkaz a dostane se na stránku www/fsdown.php, kde zadá toto heslo a může si daný soubor stáhnout.

Implementace na backendu, omezení
Obsah úschovny je na backendu uložen v homedirech jednotlivých uživatelů v adresáři "filestore". V tomto adresáři jsou soubory uloženy jako 32 znaků dlouhé unikátní identifikátory odpovídající sloupci "md5" z tabulky FileStore? ve webmaildb. Tím odpadají problémy s ukládáním potenciální diakritiky ve skutečných názvech souborů.

• Jako PHP klient pro přístup k obsahu úschovny slouží třídy:

• Na straně metadatad-services pro úschovnu žádné speciální služby nejsou. Využívají se univerzální

• V konfiguraci metadatad-services se úschovny týkají volby:

, ve kterých musí být zahrnuto:

Adresář "filestore" se v homediru uživatele vytváří při prvním nahrání souboru do úschovny, v rámci služby putfile.pm, která je z tohoto důvodu volána s parametrem "mkdir=1". Služba putfile.pm je implementována tak, aby uložení nahrávaného souboru do cílového adresáře bylo atomické. Obsah je zapisován do dočasného souboru, poté je voláno rename().

TECH:MS:Filterd

Filterd (filtering daemon) je v Perlu napsaný server, který od SMTP relays přijímá příchozí poštu prostřednictvím protokolu LMTP (http://www.faqs.org/rfcs/rfc2033.html) , filtruje ji dle uživatelských filtrů a ukládá ji do schránky uživatele. Součástí filtrování je antivirová a antispamová kontrola. LMTP je podobný SMTP, avšak je navržen pro efektivnější lokální doručování, především je vracen oddělený stavový kód pro každé doručení zprávy jednomu příjemci.

Spouštění a běh

Vývojový kód filterd je udržován na area51 v /var/www/webmail2-filterd a v app sekci CVS. Z tohoto kódu je vytvářen FreeBSD port COL-filterd, který je pak spolu se stable release filterd udržován v sysadmin sekci CVS, odkud je instalován na backend servery.
Filterd instaluje svůj rc skript:

Volba "info" pošle démonu SIGHUP, do logu jsou pak vypsány různé stavové informace.

Logování je řešeno pomocí syslog, konfigurační nastavení SYSLOG_FACILITY. Logování je v
/etc/syslog.conf nastaveno do souboru /var/log/filterd.log, který se každý den rotuje.

Na serveru se démon instaluje do /usr/local/filterd.

Rozvržení kódu
Filterd využívá třídy z mailutil, především common.pm, Filters.pm, Message.pm, MailSender?.pm,
MailDSN.pm, MailQueue?.pm a Milter.pm. Klíčové soubory jsou:

• filterd
  • spouštěcí soubor démona, načítá moduly a konfiguraci, naslouchá na socketu a předává jednotlivá klientská spojení ke zpracování třídě ClientConnection?.pm. Po každém accept() následuje fork() - každé klientské spojení tedy běží ve svém vlastním procesu.
• inc/ClientConnection.pm
  • zpracovává jedno klienstké spojení, k čemuž využívá třídu FilterdLMTP.pm, které předává své vlastní metody jako callback handlery pro jednotlivé LMTP příkazy. Klient může v jednom spojení poslat více zpráv a jedna zpráva může mít i více envelope-to příjemců, kterým je nutné zprávu doručit. Pro každého příjemce je iniciováno jedno doručení, které je realizováno v třídě MessageDelivery?.pm.
• inc/FilterdLMTP.pm
  • zpracovává LTMP protokol a řeší i předávání jednotlivých hlaviček a řádků zprávy, načítaných po příkazu DATA, do instance třídy Message.pm, která reprezentuje právě doručovanou zprávu. Tato třída je potomkem třídy
    Net

    Server

    Mail

    ESMTP

    ze CPAN balíku

    Net

    Server::Mail
    (http://search.cpan.org/~rsoliv/Net-Server-Mail-0.13/) .
• inc/MessageDelivery.pm
  • zpracovává jedno doručení zprávy jednomu příjemci.
• inc/Filter.pm
  • rodičovská třída všech filtrů, poskytuje k nim jednotné rozhraní a obsahuje společné metody, využívané více filtry, jako např. přeposlaní právě zpracovávané zprávy, zpracování přes milter, odesílání nově generovaných zpráv (notifikace...) atd. Jednotlivé implementace filtrů jsou např. inc/FilterAntispam.pm, inc/FilterNotify.pm atd.
• inc/Recipient.pm
  • poskytuje jednotné rozhraní k funkcionalitě týkající se přijemce zprávy, např. získání cest k homediru a maildiru atp.
• inc/Util.pm
  • obsahuje sdílené class methods

Zpracování zprávy
Zpráva je reprezentována mailutil třídou Message.pm. Tato třída je instanciována v ClientConnection->processMailFrom() pro každou novou zprávu. V této chvíli v ní ještě nejsou hlavičky ani tělo zprávy. V ClientConnection->processRcptTo() probíhá kontrola všech envelope-to příjemců zprávy, zda je pro ně aktivní doručovaní, zda mají homedir. Hlavičky a tělo zprávy jsou instanci třídy Message.pm předávány postupně v filterdLMTP->process() při zpracování LMTP příkazu DATA. Message.pm transparentně tělo zprávy udržuje v paměti nebo na disku. Max. velikost těla udržovaného v paměti se nastavuje volbou MESSAGE_MAX_STORE_IN_MEMORY (nyní 64 kb). Po načtení celého těla je instance Message.pm připravena k použití při doručování jednotlivým příjemcům.

Toto doručövání probíhá v metodě MessageDelivery?.pm->process(), která je vyvoláná jednou pro každého příjemce a je jí vždy předána instance Message.pm, která je pak dostupná jako $self->{msg}. Tato instance zůstává stejná pro všechny příjemce, pouze se v ní v rámci doručování jednotlivým příjemcům doplňují či jinak modifikují hlavičky. Je zajištěno, že při každém volání metody process() jsou tyto změny hlaviček anulovány a instance je tedy u každého příjemce ve stejném stavu, v jakém byla vytvořena po příkazu DATA (viz. volání $self->{msg}->headerStoreCopy() a $self->{msg}->headerStoreUse() v process()).

Doručová?í probíhá tak, že jsou postupně vyvolávány různé operace, jako kontrola kvóty, kontrola uživatelského blacklistu a zpracování jednotlivých filtrů. Každá tato operace vrací buď MessageDeliveryFINISH_DELIVERY. Před vrácením FINISH_DELIVERY musí daná operace vždy nastavit stavový SMTP köd, který bude předán klientovi, voláním discardMessage() nastaví kód SMTP_OK a zpráva tak bude zahozena nebo přímo setSMTPDeliveryReturnCode(), pokud dojde k nějaké chybě, kterou je třeba speciálně ošetřit a zpravit o ní klienta. Pokud dojde k jakékoliv nepředpokládané chybě, stačí vyvolat výjimku pomocí $self->exception()

interně volá die(). Pokud je zachycena výjimka, je klientu vždy vrácen kód SMTP_TEMPFAIL.

Pokud je zpráva uložena do složky na disk, děje se tak vždy prostřednictvím MessageDelivery->saveMessage(), která je volána buď z FilterMove?.pm nebo z MessageDelivery->process() po projití všech filtrů.

Zpracování filtrů
Jednotlivé filtry jsou načteny, otestovány na validitu dle data a ACTIVE, seřazeny a instanciovány v objekty v MessageDelivery->prepareFilters(). Řazení filtrů a další detaily jsou popsány v článku věnovaném filtrům. Zpracovávány jsou postupně v processFilters() tak, že je volána metoda Filter->process(), která dále vyvolává metodu run() jednotlivých filtrů. Jednotlivým filtrům jsou prostednictvím rodičovské třídy
Filter.pm dostupné především metody:

• getMessage()
  • vrací odkaz na instanci doručované Message.pm
• getMsgEnvelopeFrom() / getMsgEnvelopeTo()
  • vrací envelope-from a envelope-to
• getMsgSize()
  • velikost zprávy (nemusí být přesné, odpovídá stavu před modifikacemi hlaviček)
• discardMessage()
  • nastaví SMTP stavový kód na zahození zprávy
• setSaveFolder()
  • změní cílovou složku
• saveMessage()
  • uloží zprávu do nastavené cílové složky, pak je nutný konec doručování
• getIsVirus() / setIsVirus / getIsSpam() / setIsSpam()
  • označuje zprávu jako virus/spam
• addToDeliveryLog()
  • přidá záznam do delivery_log, respektuje nastavení getIsSpam() a getIsVirus()
• getMessageMeta() / setMessageMeta()
  • vytvoří pojmenovanou proměnnou, která je persistentní mezi jednotlivými příjemci. Využíváno pro kešování výsledků antispamové a antivirus kontroly a pro kešování rozparsovaného těla zprávy v objektu
    MIME::Parser
• getConnectionMeta() / setConnectionMeta()
  • vytvoří pojmenovanou proměnnou, která je persistentní po celou dobu životnosti jednoho klientského spojení, tzn. i pro více zpráv. Využíváno pro udržövání instance MailSender?.pm s otevřeným SMTP spojením pro přeposílání a odesílání zpráv (notifikací atd.)
• sendNewMessage()
  • využívá persistentní instanci MailSender?.pm k odesílání nově vytvořených zpráv
• resendMessage()
  • slouží k přeposílání aktuální zprávy (forward, copy, antispam/antivirus forward)
• runMilter()
  • prožene zprávu milterem, spojení na milter je při selhání zkoušeno vícekrát

Neexistující homedir či Maildir
Pokud existuje homedir, předpokládá se, že vždy existuje i Maildir. Pokud není namountována maildir struktura, což se rozpoznává podle existence prvního md5 adresáře, vrací se TEMPFAIL.

Pokud homedir neexistuje, a problém je permission denied, vrací se TEMPFAIL. V případě jiného problému se testuje, zda se má aktivovat noHomedir doručovací mód, či rovnou vrátit chybu SMTP_NOUSER.

NoHomedir? mód se zapíná:

• Pokud plus-extenze username (aa_volmejltest+xdeliver@volny.cz) je rovna hodnote cfg option ALWAYS_TRY_DELIVERY_EXT ("xdeliver").
• Pokud envelope-from je zahrnut v cfg poli @ALWAYS_TRY_DELIVERY_FROM.

V případě aktivního noHomedir módu:

• ignorují se Autoreply filtry
• ignoruje se kvóta
• pokud není aktivni force-delivery mód, je vrácena chyba SMTP_NO_LOCAL_DELIVERY při pokusu uložit zprávu na disk do složky. Forwardy stále fungují, jelikož při nich k uložení nedochází.

Force-delivery mód
Pokud force-delivery mód aktivní je, vytvoří se neexistující homedir i Maildir (bez systémových složek webmailu) a implicitní kvóta (DEFAULT_QUOTA_SIZE), a zpráva se uloží. Force-delivery se zapíná globálně pomocí FORCE_DELIVERY_ALWAYS nebo pro jednotlivé zprávy zahrnutím speciální hlavičky
X-Vol-Force-Delivery?.

Tato hlavička musí obsahovat hex_md5 kód vytvořený z řetězce, který vznikne tak, že spojíme obsah
hlavičky Date (bez newline) a připojíme k němu bez oddělovače řetězec s hodnotou cfg option
FORCE_DELIVERY_CODE.

NO_RECEIVE
Dále, pokud existuje homedir a v něm je soubor NO_RECEIVE, vrací se pří pokusu o uložení zprávy do složky chyba SMTP_DEACTIVATED. Forwardy stále fungují.

Fronta odesílaných zpráv
Filterd odesílá přes SMTP relay vygenerované zprávy (notifikace, autoreply) a přeposílané zprávy (kopie,forward). Pokud odeslání některé z těchto zpráv selže jako PERMFAIL, je vygenerován chybák. Pokud ale selže jako TEMPFAIL, pak je zpráva uložena do fronty odesílaných zpráv. Tato fronta je implementována třidou MailQueue?.pm z mailutil a na disku je v /var/filterd/queue. Pravidelně je z crontabu procházena mailutil skriptem run_mail_queue.pl. Tento skript projde celou frontu a pokusí se zprávy odeslat. Vytváří přitom log /var/log/run_mail_queue.log.

Příprava nové release - portu

• Zvýšit verzi v VERSION.
• Doplnit záznam do ChangeLog?.
• V COL-filterd/Makefile změnit Last Update a PORTVERSION.
• Vytvořit port a distfile a přenést ho na devel1 - na area51 spustit:

• Dále na devel1 spustit jako root:

TECH:MS:FuzzyOCR

FuzzyOCR je plugin pro SpamAssassin?, který rozpoznává text v obrázkových přílohách emailů a dokáže tak detekovat obrázkový spam. Homepage tohoto projektu je zde (http://fuzzyocr.own-hero.net/) . Využíváme ho ve spojení s GNU OCR programem gocr (http://jocr.sourceforge.net/) . Alternativní program ocrad (http://www.gnu.org/software/ocrad/ocrad.html) rozpoznává text znatelně hůře a obrázky se musí před zpracováním konvertovat.

Instalace
Ve freebsd existuje port /usr/ports/mail/p5-FuzzyOcr, který ale nevyužíváme. Tento port totiž instaluje gocr defaultně, bez volby WITHOUT_X11=1, kterou potřebujeme kvůli tomu, aby na systém nebyla instalována celá Xka.

Místo toho využíváme náš port COL-SA-FuzzyOCR vyvíjený na area51 v /var/www/fuzzyocr. Ten dále instaluje náš port COL/gocr, který vyvinul Páv, aktivoval v něm neinstalování X11 a dokumentace a zrušil závislost na latexu. Instaluje se také port COL/libungif, který instaluje graphics/libungif bez X11.

Při instalaci je dále třeba dát pozor na to, co instaluje ImageMagick? jako své závislosti. Při první instalaci ImageMagick? se systém dotáže na instalační volby, je třeba potlačit podporu X11.

Port COL-SA-FuzzyOCR instaluje do /usr/local/etc/mail/spamassassin tyto soubory:

• FuzzyOcr.cf
• FuzzyOcr.pm
• FuzzyOcr.words

Po instalaci portu COL-SA-FuzzyOCR je třeba restartovat spamd. Ihned poté by měl plugin začít být využívaný. Je třeba zkontrolovat jeho log (viz konfigurace níže).

Konfigurace
FuzzyOcr?.cf
Plugin se nastavuje v FuzzyOcr?.cf. Nejdůležitější volby jsou:

Pro regulaci náročnosti a kvality detekce je důležitá volba focr_scansets. Ta má implicitně nastavení:

Toto způsobí, že každý obrázek bude programem gocr proskenován třikrát, vždy s jiným nastavením ovlivňujícím skenování. Takto lze najít nejvíce slov. Pokud by to bylo příliš náročné na prostředky systému, lze využít toto základní nastavení:

FuzzyOcr?.words

V FuzzyOcr?.words je seznam slov, která budou v obrázcích vyhledávána. Pro označení jako spam musí být nalezeno více slov.

TECH:MS:Mailindex

Mailindex je knihovna Perl modulů a skriptů využívaných v uložišti a indexech mailsystemu VOLNÝ. Vznikla oddělením z mailutil proto, aby balík mailutil nebyl závislý na sqlite. Její třídy tvoří základ metadatad.
Vývojový kód je udržován na area51 v /var/www/mailindex a v app CVS. Stable verze je ve formě FreeBSD portu COL-mailindex udržována v sysadmin CVS, odkud je přenášena na backend stroje. Na serveru se knihovna instaluje do /usr/local/mailindex.
Moduly

• Index.pm
  • implementuje indexy jednotlivých složek v Maildiru, urychlující načítání obsahu složky s ohledem na řazení.
• Maildir.pm
  • zakládání Maildirů a složek v nich, stahttps://intranet.col.cz/mediawiki/index.php?title=TECH:MS:Mailindex&action=edittistiky zaplnění a počtu zpráv.
• MaildirFilename.pm
  • vytváření filenames pro zprávy dle Maildir standardu.
• MaildirQuota.pm
  • implementuje Maildir kvóty, jejich testování, přepočítávání i změny

Skripty

• files-deindex.pl
  • odstraňuje z filenames zpráv v zadaném Maildir/cur adresáří flag "I", čímž je vynuceno přeindexování při příštím otevření indexu.
• mailindex.pl
  • kontroluje integritu a aktuálnost Maildir folder indexu a dokáže je rekonstruovat

XS - Perl moduly psané jako extenze v jazyce C
MailXS.xs
implementuje v jazyce C některé operace, které by v Perlu byly příliš pomalé. Jde o aktualizace sqlite
indexů, zjišťování zaplnění Maildirů, na diakritiku necitlivé vyhledávání v indexech.

TECH:MS:Mailutil

Mailutil je knihovna Perl modulů a skriptů využívaných v mailsystemu VOLNÝ. Její třídy tvoří základ filterd i metadatad.
Vývojový kód je udržován na area51 v /var/www/mailutil a v app CVS. Stable verze je ve formě FreeBSD portu COL-mailutil udržována v sysadmin CVS, odkud je přenášena na backend stroje. Na serveru se knihovna instaluje do /usr/local/mailutil.

Moduly - práce se zprávami

• Logger.pm
  • univerzální logovací třída, podporuje logování do souboru i přes syslog (http://en.wikipedia.org/wiki/Syslog)
• MailDSN.pm
  • vytváření Delivery Status Notification zpráv (chybáků) dle RFC1894 (http://www.faqs.org/rfcs/rfc1894.html)
• MailQueue.pm
  • univerzální fronta pro ukládání zpráv, které je nutné ještě nějak zpracovat nebo odeslat. Ukládá se i envelope-from a envelope-to. Podpora lockování.
• MailSender.pm
  • SMTP/LMTP klient pro odesílání zpráv přes persistentní SMTP/LMTP spojení.
• Message.pm
  • objektová reprezentace zprávy, umožňující snadnou editaci hlaviček. Tělo je optimálně a transparentně uloženo dle své velikosti buďto v paměti nebo v dočasném souboru na disku.
• Sendmail.pm
  • odesílání zpráv pomocí command line utility sendmail. Kvalitní ošetření chyb.

Moduly - ostatní

• Addrlist.pm
  • slouží k práci se seznamem emailových adres a domén, uloženém v textovém souboru ve formátu jedna adresa na řádek. Takovýto seznam je využíván např. pro uložení blacklistu v homediru uživatele. Je dostupná i metoda pro otestování adresy proti celému načtenému seznamu adres/domén.
• CourierUID.pm
  • slouží k práci se souborem courierimapuiddb, vytvářeným Courier IMAP serverem (http://www.courier-mta.org/imap/) v Maildiru pro přiřazování unikátních UID jednotlivým soborům se zprávami. Již se aktivně nevyužívá.
• Exception.pm
  • implementuje objekt Perl výjimek, vyvolávaných pomocí die(). Tyto výjimky mají - narozdíl od běžného die() řetězce - v sobě podporu chybového číselného kódu a vytváření výpisu stacktrace. Používá se v metadatad pro přesné rozlišení jednotlivých druhů chyb a předání přislušného číselného kódu chyby klientovi.
• Filters.pm
  • parsuje a načítá soubor filter.xml, ve kterém jsou uloženy uživatelské filtry v homediru uživatele. Podporuje modifikace, rušení a přidávání filtrů a následné uložení do nového XML souboru. Převádí tyto XML filtry na hashref reprezentace, se kterými dále pracuje filterd a metadatad.
• ImapUtf7.pm
  • převod řetězců z/do kódování IMAP-UTF7 dle RFC2060 (http://www.faqs.org/rfcs/rfc2060.html) . Toto kódování se využívá pro názvy složek v Maildiru.
• MetaClient.pm
  • klient a implementace metadatad protokolu. Některé jeho funkce jsou využívány i na straně serveru v metadatad.
• MetaError.pm
  • obsahuje konstanty používáne v metadatad protokolu pro číselnou indikaci chybových stavů ve spojení s Exception.pm.
• Milter.pm
  • implementace milter klienta. Milter je protokol pro filtrování zpráv prostřednictvím serveru, naslouchajícího na socketu. Využíváno pro antivirus a antispam.
• NfsWalker.pm
  • automatizovaný procházeč Maildir struktury. Pro každý homedir uživatele vyvolá zadanou callback funkci a předá ji cestu k tomuto adresáři jako parametr.
• Radius.pm
  • rozhraní ke command line nástroji testlibradc z balíku COL-radclient, který zprostředkovává komunikaci s Radius serverem pro autentizaci uživatelů.
• TempMaker.pm
  • třída pro spolehlivé a jednotné vytváření dočasných souborů a adresářů. Poskytuje i automatické odmazání těchto souborů určitou dobu od posledního přístupu.
• common.pm
  • směsice krátkých jednoúčelových funkcí

Skripty

• cswitch.pl
  • parsuje Content-Switch? soubor a vrací pro zadaného uživatele hostname příslušného backend serveru.
• disk_io_benchmark.pl
  • benchmark pro výkonnost disků při simulaci zátěže mail system backendů
• filterconv.pl
  • konvertor filtr ze staré mailconf md5 struktury do nového filter.xml v homediru uživatele.
• filtercount.pl
  • prochází Maildir strukturu a vypisuje pro jednotlivé uživatele počet filtrů a adres v blacklistu
• filtergrep.pl
  • prochází Maildir strukturu a vypisuje filtry, které odpovídají zadaným kritériím
• findusers.pl
  • projde namountovanou část Maildir struktury a vypíše všechna username, která v ní mají homedir.
• make-courierdb.pl
  • vytváří Courier-IMAP (http://www.courier-mta.org/imap/) courierimapuiddb soubor z obsahu Maildir složky. Již se nevyužívá.
• message_size_distribution.pl
  • vytváří tabulku statistik rozložení velikosti doručovaných zpráv dle filterd.log.
• metaclient.pl
  • command line klient metadatad protokolu. (využívá MetaClient?.pm)
• metaloadtest.pl
  • test pro zátěžový test metadatad.
• milter.pl
  • command line klient Milter protokolu. (využívá Milter.pm)
• movemd5.pl
  • přesouvač md5 svazků přes NFS.
• run_mail_queue.pl
  • prochází MailQueue?.pm frontu.

TECH:MS:MetadatadServicesMail

Balík metadatad-services-mail obsahuje kolekci Metadatad služeb, zajišťujících komunikaci webového rozhraní s fyzickým úložištěm schránek v mail systému VOLNÝ.

Přihlášení

• login
  • Provede autorizaci uživatele VOLNÝ proti Radius serveru. Po úspěšném ověření vytvoří session (pro účely metadatad komunikace) a jeho ID vrátí klientovi. V případě prvního přihlášení uživatele do systému vytvoří v úložišti fyzickou schránku (homedir a maildir), uloží do ní hodnotu quoty získanou z Radiusu a vytvoří zamykací soubor pro POP3 přístup.
• createmailbox
  • Vytvoří schránku uživatele (homedir a maildir), obdobně jako služba login. Na rozdíl od ní tato služba nevyžaduje autorizaci uživatele.
• disablemailbox
  • Znepřístupní schránku uživatele (přejmenuje homedir se sufixem .disabled.čas).
• islocked
  • Vrátí příznak zámku homediru. Ve webmailu se nepoužívá.
• lock
  • Zamkne homedir. Ve webmailu se nepoužívá.
• unlock
  • Odemkne homedir. Ve webmailu se nepoužívá.

Práce s maildirem

• deletemessage
  • Vymaže fyzicky zprávu z maildiru uživatele, vymaže ji z mailindexu a upraví quotu uživatele. Může pracovat nad více zprávami zároveň.
• createfolder
  • Vytvoří podsložku v maildiru uživatele.
• deletefolder
  • Vymaže podsložku.
• deleteattach
  • Vymaže přílohu z emailu uloženého v maildiru uživatele.
• detachrfc822
  • Extrahuje přeposlaný přiložený email z jiného emailu a uloží ho do složky jako samostatný email.
• folderstats
  • Vrátí statistiky jedné nebo více složek z maildiru. Reportované parametry jsou: počet zpráv, velikost v bajtech, a počet nepřečtených zpráv. Pracuje s fyzickým obsahem schránky.
• folderview
  • Výpis obsahu složky (schránky). Umožňuje stránkování v rozsáhlých složkách, vyhledávání nad libovolnou položkou a třídění podle libovolné položky. Používá mailindex kvůli rychlosti. Vrací následující údaje o každém reportovaném emailu: UID, datum odeslání, datum doručení, velikost, příznak přítomnosti přílohy, příznak přečtení, hlavičky From, To, Subject, Message ID, References a In Reply To.
• getflags
  • Vrátí stavy následujících příznaků zprávy z mailindexu: přečtena, označena, indexována.
• getmsgheader
  • Odešle raw hlavičky emailu jako binární část (part) po metadata protokolu.
• getmsgoverview
  • Vrátí podstatné hlavičky a strukturu emailu (informace o přílohách etc). Volitelně vrátí první (textovou) část emailu (prefetch). Volitelně označí zprávu jako přečtenou (mark_seen).
• getmsgpart
  • Rozparsuje email a vrátí požadovanou část (textovou část, HTML část, přílohu...). Ponechává krátkodobou parse cache - adresář s dekódovanými částmi zprávy a přílohami.
• getmsgsource
  • Odešle celý raw soubor s emailovou zprávou jako binární část (part) po metadata protokolu.
• listfolders
  • Vrátí seznam jmen podsložek.
• mailboxstats
  • Vrátí statistiky celé schránky (všech složek): počet zpráv, počet nepřečtených zpráv, velikost v bajtech. Pracuje s fyzickými soubory.
• movemessage
  • Přesune jednu nebo více zpráv mezi složkami, a upraví quotu uživatele pokud došlo k přesunu z/do speciální složky Supertrash.
• purgefolder
  • Vyprázdní složku tím, že jí vymaže a znovu založí.
• recalcmaildirsize
  • Přepočítá quotu uživatele na základě inspekce fyzických souborů.
• renamefolder
  • Přejmenuje složku.
• setflags
  • Nastaví příznaky v mailindexu pro jednu nebo více zpráv.
• setquota
  • Změní quotu uživatele.
• storemessage
  • Uloží do maildiru emailovou zprávu a zapíše jí do mailindexu. Používá se pro ukládání odeslané pošty a draftů z webmailu.

Manipulace homediru

• addblock
  • Zablokuje doručování pošty z emailové adresy pro daného uživatele tím, že jí zapíše do blacklist souboru v homediru uživatele.
• deleteblock
  • Vymaže blokování doručování pošty z dané emailové adresy.
• addfilter
  • Přidá do homediru uživatele filtr příchozích zpráv.
• deletefilter
  • Vymaže filtr.
• getfilter
  • Vrátí obsahy filtrů podle FIDů.
• modifyfilter
  • Změní obsah filtru.
• getquota
  • Vrátí hodnotu quoty.
• getquotausage
  • Vrátí aktuální využití quoty.

Úschovna

• putfile
  • Nahraje soubor do úschovny uživatele. Úschovna je v podadresáři filestore v homediru a nezapočítává se do quoty. Jeho obsazenost je sledována a kontrolována v databázi webmailu.
• getfile
  • Vrátí obsah souboru z úschovny uživatele (např. za účelem downloadu do prohlížeče).
• deletefile
  • Vymaže soubor z úschovny uživatele.

Různé

• makearchive
  • Vytvoří z emailů z daného časového rozmezí v dané složce archiv ve formě mbox souboru nebo zip archívu. Výsledný soubor uloží do podsložky archive v homediru a vrátí název tohoto souboru.
• metaview
  • Vylistuje metadata v dané složce. Nepoužívá se — určeno výhradně k debuggingu.

TECH:MS:Overview

Mail systém se skládá z aplikací a serverů, které dohromady zajišťují příjem, filtrování, antispam a antivirus, uložení, zpřístupnění a další práci s VOLNÝ, Profibox i interní COL elektronickou poštou. Nejvyužívanější rozhraní pro přístup jsou Webmail a POP3.

Základní rozdělení dle funkce

Příjem a zpracování příchozí pošty

• Relays - oddělené Postfix (http://www.postfix.org/) SMTP (http://www.faqs.org/rfcs/rfc2821.html) servery pro příjem pošty, komunikují přes LMTP (http://www.faqs.org/rfcs/rfc2033.html) s filterd na backendech
• Filterd - server, běžící na backendech, poskytuje LMTP rozhraní pro ukládání pošty, zajišťuje i filtrování, notifikace, přeposílání
• Kaspersky (http://www.kaspersky.com/) Antispam a antivirus přístupný z filterd přes Milter rozhraní
• SpamAssassin (http://spamassassin.apache.org/) antispam, jako dodatečný antispam přístupný z filterd přes Milter rozhraní

Zpřístupnění pošty

• Metadatad - základní backend aplikační server, zpřístupňuje obsah schránek a je využíván pro všechny operace nad schránkou (mazání, ukládání uživateli vytvořených zpráv, práce s filtry)
• Webmail rozhraní - komunikuje s metadatad na jednotlivých backendech a zpřístuňuje poštu přes WWW (HTTP) a WAP (pro mobilní telefony), běží na vlastních serverech
• POP3 - upravený POP3 server z distribuce qmail, běžící na backendech, pro vnější svět zpřístupněný pomocí POP3 proxy Popular (http://www.remote.org/jochen/mail/popular/)

Další subsystémy

• MySQL databáze webmaildb2 - slouží k uložení dat specifických pro web rozhraní (adresáře,nastavení rozhraní)

Související systémy

• RADIUS servery - poskytují autentizaci a základní informace o uživatelských kontech
• OMNIS - firemní IS, obsahuje rozšířené informace o uživ. kontech - web rozhraní k němu přistupuje přes SSL-GATE běžící na serveru das

Hostnames, kde co je

"X" značí určité číslo, počet serverů se často mění.
Příjem pošty

• relayX.volny.cz - přijímací SMTP relays pro @volny.cz poštu

Backendy

• mX.volny.cz - backendy pro @volny.cz

POP3 proxy a aliasy

• pop3.volny.cz - DNS round robin alias pro pX.volny.cz
• pX.volny.cz - jednotlivé POP3 proxy pro @volny.cz

Web rozhraní a ostatní

• mail.volny.cz (http://mail.volny.cz) - web rozhraní, DNS round robin alias pro
• www1-3-.mail.volny.cz
• www1-3-mail.volny.cz - web rozhraní pro @volny.cz a @vol.cz
• webmaildb2.hide.vol.cz - MySQL databáze pro web rozhraní
• mail.area51.hide.vol.cz (http://mail.area51.hide.vol.cz/) - testovací developerská instalace web rozhraní VOLNÝmailu

Rozdělení na domény a backendy

Existují v podstatě tři mail systémy, které používají stejný software, ale starají se o různé mailové domény,
mají jiné servery, jiná hostnames a především jiná datová uložiště, přístupná přes vlastní backendy. Jedná se
o tyto tři základní systémy:

• @vol.cz (plus profibox.cz)
• @volny.cz (plus uživatelem definované aliasy)
• @firma.volny.cz (dříve @telekomaustria.cz, @col.cz a @jet2web.cz)

Data jednotlivých mail systémů jsou v podobě uživatelských adresářů a Maildirů rozdělena na různé backendy. Rozdělování se provádí pomocí systému ContentSwitch? dle md5 prefixů získaných z uživatelských jmen. Základních prefixů je celkem 256 a tyto jsou pak rozděleny na jednotlivé backendy. Na jednom backendu bývá v případě @volny.cz systému cca. 20 prefixů. Každý backend stroj má své vlastní diskové pole, na kterém jsou uloženy uživatelské adresáře příslušející dle ContentSwitch? prefixů na daný backend.

Zdrojové kódy

• Zdrojové kódy web rozhraní (PHP) jsou vyvíjeny na area51 v /var/www/webmail2.
• Zdrojové kódy backendu (Perl) jsou vyvíjeny také na area51:
  • /var/www/webmail2-filterd
  • /var/www/webmail2-popular
  • /var/www/webmail2-metadatad-services-mail
  • /var/www/mailutil
  • /var/www/metadatad
  • /var/www/metadatad-services-converter

Zdrojové kódy jsou odsud nahrávány do firemního CVS, konkrétně do src/app, kde jsou i pomocí tagů označené jednotlivé releases. V případě backendů oddělení sysadmin ukládá jednotlivé stabilní releases i do své sekce CVS a vytváří z nich porty, které jsou distribuovány na cílové stroje.

TECH:MS:POP3

Uvod

Nize popsany system POP3 pristupu do mailovych schranek nasich uzivatelu je pouzit pro mailove systemy VOL, VOLNY a COL. Text popisuje konkretne systemy VOL a VOLNY. V mailovem systemu COL funguje vse na stejnych principech, ale cely system bezi na dedikovanem stroji (colmail.vol.cz), ktery je jak POP3 proxy (vserv), tak zaroven POP3 serverem (backend). Speciality COL systemu jsou popsany v samostatne kapitole.

Architektura a popis systemu

Obrazek nize znazornuje architekturu systemu POP3 pristupu k uzivatelskym mailovym schrankam v systemu VOL/VOLNY. (Obrazek je prevzaty z dokumetace POPular (http://www.remote.org/jochen/mail/popular/doc/html/popular.html) )

POP3 pristup k uzivatelskym mailboxum je v systemu VOL/VOLNY zajisten systemem, ktery ma dve vrstvy. Prvni vrstvu tvori POP3 proxy, ktera primo komunikuje s koncovym uzivatelem. Druhou vrstvou je POP3 server (tzv. backend), ktery ma fyzicky pristup k uzivatelskym mailboxum a komunikuje s POP3 proxy.

Jako POP3 proxy provozujeme aplikaci POPular (http://www.remote.org/jochen/mail/popular/) . Jako POP3 server provozujeme Qmail POP3 server (http://cr.yp.to/qmail.html) . Uzivatel se ze sveho klienta pripojuje na servery p1.volny.cz, nebo p2.volny.cz na port 110. Pripojuje se prostrednictvim domenovych jmen pro tento ucel zrizenych, ktere smeruji na konkretni IP adresy, IP aliasy zminenych serveru. Jedna se o domenova jmena pop3.volny.cz, pop3.vol.cz a pop.vol.cz. pop3.volny.cz je round-robin. Kazda IP v tomto round-robinu ma sve jedinecne domenove jmeno pro administrativni ucely. Jsou to pop3-1.volny.cz a pop3-2.volny.cz.

To, na ktery realny server prostrednictvim vyse zminenych aliasu pristupujeme, je mozno zjistit z uvitaciho
banneru POP3 serveru (resp. POP3 proxy), ve kterem udaj p1 nebo p2 identifikuje realny server.

NA portu 110 posloucha POP3 proxy, ktera podle toho, na ktery IP alias se klient pripojuje (coz identifikuje tzv. namespace) a podle uzivatelem zadaneho jmena (USER) a hesla (PASS) urci backend server (server, kde bezi POP3 server Qmail a kde jsou fyzicky ulozeny mailboxy), na kterem je umisten mailbox daneho uzivatele. Namespace vyuzivame k provozu POP3 proxy pro ruzne mailove systemy (VOL/VOLNY) na sdilenem serveru. Po identifikaci backend serveru se POP3 proxy chova jako bezny klient POP3 a spoji se s backend serverem (mailnfs servery). Zasle mu jmeno a heslo a po uspesne autentizaci zacne jiz jen predavat data, bez jakekoliv interpretace, mezi uzivatelem (klientem) a backend serverem (POP3 serverem). K autentizaci tedy dochazi na backend serveru.

POP3 proxy identifikuje backend server pomoci externiho modulu "Contentswitch PDM" (PDM = POPular Database Module) , ktery je vlastni tvorbou COL (by Tomas Styblo) a ktery neprovadi vlastni autentizaci, nybrz pouze onu identifikaci backend serveru. Identifikace probiha na zaklade namespace a prvniho byte z md5-ky uzivatelskeho jmena.

Qmail POP3

Jako POP3 server pouzivame vyse zmineny Qmail (http://cr.yp.to/qmail.html) . Program je upraveny nasim patchem, ktery predevsim zajistuje autentizaci prostrednictvim radius klienta a spravnou identifikaci Maildiru uzivatele ve file systemu, kde vyuzivame tzv. MD5 strukturu. Zdrojaky jsou udrzovany v CVSku na cvs.hide.vol.cz v src/sys/qmail (qmail) a src/sys/maildirtools (checkpassword). Qmail POP3 server spoustime prostrednictvim inetd(8) (http://www.freebsd.org/cgi/man.cgi?query=inetd) . Je tedy potreba nastavit spousteni inetd(8) (http://www.freebsd.org/cgi/man.cgi?query=inetd) po nastartovani stroje, coz se provede v /etc/rc.conf a vytvorit spravny zaznam v etc/inetd.conf.

/etc/rc.conf:

/etc/inetd.conf:

POPular POP3 proxy

Jako POP3 proxy provozujeme POPular POP3 proxy (http://www.remote.org/jochen/mail/popular/) (/usr/ports/mail/popular). Podle autora jde o aplikaci urcenou pro velke mailove systemy se statisici uzivateli. Aplikace obsahuje krome POP3 proxy i POP3 server, ktery my v soucasne dobe nevyuzivame. POPular zvlada krome prosteho POP3 i POP3s a POP3 via TLS.

POP3 proxy, kterou vyuzivame v nasem systemu, predstavuje program pproxy(1) (http://www.remote.org /jochen/mail/popular/doc/html/man-pproxy.html) . Pproxy bezi pod uzivatelem pop a posloucha na portu 110. Aby mohla poslouchat na privilegovanem portu, spousti se pred startem pproxy program ringd(1) (http://www.remote.org/jochen/mail/popular/doc/html/man-ringd.html) , ktery bezi pod rootem a jedinou jeho ulohou je na vyzadani alokovat privilegovany port a "predat" ho zadateli, kterym je v nasem pripade pproxy.

POPular pproxy identifikuje na zaklade IP adresy, na kterou klient pristupuje, a uzivatelskeho jmena, presne receno na zaklade prvniho byte z md5 vypocitane z uzivatelskeho jmena, backend server (POP3 server), na kterem ma uzivatel fyzicky umisten Maildir. K indentifikaci dochazi v autentizacni fazi POP3 spojeni klienta s pproxy. Autentizacni faze u pproxy v nasem pripade znamena pouze zminovanou identifikaci backendserveru.

Pproxy nezajistuje autentizaci uzivatele. Po uspesne identifikaci backend serveru otevre pproxy POP3 spojeni na backend POP3 server a v autentizacni fazi POP3 pouzije uzivatelske jmeno a heslo, ktere ziskala od autentizacniho modulu. Na backend serveru dojde k autentizaci uzivatele a pokud je tato autentizace uspesna, zacne pproxy jiz jen predavat data od klienta na backend server a opacne bez jakekoliv jejich interpretace. V pripade, ze je backend server nedostupny se pproxy chova tak, ze klientovi "predstira" prazdny mailbox. Mimo to se muze backend server v konfiguraci pproxy nachazet v nekolika stavech (konfiguruje administrator):

• online - backend server je oznacen jako aktivni, pproxy se bude snazit na nej pripojit, pokud bude vysledkem identifikace backend serveru
• offline - backend server je oznacen jako neaktivni, pproxy nebude zkouset spojeni na dany backend server a rovnou po prikazu PASS oznami "-ERR temporarily unavailable"
• fake - backend server je oznacen jako nekativni, pproxy bude uzivateli predstirat prazdny mailbox

POPular POP3 proxy ma zpracovanou pomerne slusnou dokumentaci (http://www.remote.org/jochen/mail/popular/doc/html/popular.html) .

Konfigurace pproxy

Pproxy se konfiguruje pomoci programu pcontrol(1) (http://www.remote.org/jochen/mail/popular/doc/html/man-pcontrol.html) , jehoz prostrednictvim se zasilaji prikazy bezici pproxy. Po nastartovani bezi pproxy s minimalni defaultni konfiguraci (napr. neposloucha na zadnem portu) a je potreba ji nakonfigurovat za behu. Po startu pproxy se to resi volanim pcontrol(1) (http://www.remote.org/jochen/mail/popular/doc/html /man-pcontrol.html) a ulozenou konfiguraci (sled prikazu pro pcontrol) ze startovaciho rc skriptu. To znamena, ze s pproxy pracujeme v nasem pripade v drtive vetsine tak, jak jsme zvykli, tedy upravou konfigurace (rc skriptu) a restartem pproxy. Pproxy se startuje z /usr/local/etc/rc.d. Pred spustenim pproxy je potreba spustit ringd.

Konfigurace je ulozena v /usr/local/etc/popular/pproxy.rc: (nize jde o ukazku, aktualni konfigurace je lokalne na danem serveru)

Stejne jako backend se muze v konfiguraci pproxy vyskytovat v nekolika stavech i tzv. "virtual server". Virtualni server je v podstate konkretni instance POP3 proxy serveru poslouchajici na konkretnim interface a konkretnim portu. Umoznuje napr. podle IP adresy, na kterou prisel pozadavek volit ruzny 'namespace', coz vyuzivame pro provoz POP3 serveru pro ruzne nase mailove systemy na sdilenem serveru (VOL/VOLNY). Virtualni server se muze vyskytovat v techto stavech (konfiguruje spravce):

• online - virtualni server je aktivni, pproxy posloucha na danem portu
• offline - virtualni server je neaktivni, pproxy neposloucha na danem portu
• fake - virtualni server je aktivni, ale pproxy predstira klientum prazdny mailbox
• disabled - virtualni server ativni, ale pproxy okamzite po spojeni klienta na dany port ukonci spojeni s hlasenim 'bannererr', ktere jekonfigurovatelne (viz vyse)

Jelikoz ve fazi autentizace muze klient pouzit krome prikazu USER a PASS i prikaz CAPA, pokud ho server podporuje je tento prikaz implementovan i v pproxy. Capabilities (schopnosti), ktere se maji po zadani prikazu CAPA vypsat jsou v nasem systemu ulozeny v souboru /usr/local/etc/popular/capa/VOLNY a pproxy se toto sdeli prikazem "set capadir
/usr/local/etc/popular/capa" a "capa load VOLNY".
/usr/local/etc/popular/capa/VOLNY:

TLS/SSL podpora

POPpular nam umoznuje nabizet uzivatelum TLS/SSL POP3. SSL podporu predstavuje "virtual server" s protokolem POP3s (port 995), TLS podporu pak "virtual server" pro bezny POP3 se zapnutou volbou "starttls". TLS muze byt v tomto pripade bud vynucene (force) nebo volitelne (optional).

Certifikaty jsou ulozene pro kazdy "virtual server" zvlast v samostatnem souboru v adresari /usr/local/etc/popular/tls, ktery je nastaven volbou tlsdir (set tlsdir /usr/local/etc/popular/tls). Soubor se musi jmenovat stejne jako "virtual server" plus pripona .pem, napr. pop3-vol.pem a obsahuje jak samotny certifikat, resp. certifikaty (cely retez duvery, serazeno od naseho certifikatu ke korenovemu), tak privatni klic. Prava pro cteni souboru smi mit tedy jen uzivatel, pod kterym bezi 'pproxy' (v nasem pripade uzivatel 'pop').

Moznost zadat vice nez jeden certifikat do 'pem' souboru pro dany virtualni server a implementovat tak tzv, zprostredkovatele (retez duvery od nas az ke korenovemu certifikatu) byla do POPularu pridana nasim vlastnim patchem (by Pav) a od te doby instalujeme nas 'COL-popular' port namisto bezneho portu 'popular'. Kompletni popis konfigurace pproxy naleznete v dokumentaci k POPular POP3 serveru POPular POP3 serveru (http://www.remote.org/jochen/mail/popular/doc/html/conf-pproxy.html) .

Contentswitch PDM

Autentizacni faze je resena externim modulem libpdm_contentswitch.so (PDM - POPular Database Modul), ktery je vlastni tvorbou COL (by Tomas Styblo). Modul se nachazi v adresari /usr/local/lib/popular/. Modul obdrzi od pproxy mimo jineho uzivatelske jmeno, heslo, namespace. Z uzivatelskeho jmena vypocte MD5 a na zaklade prvniho byte MD5, namespace a sve konfigurace, ktera prvni byte MD5 mapuje na backend server, identifikuje backend server. Modul pote vrati pproxy mimo jineho uzivatelske jmeno, heslo a backend server (resp. ID backend serveru). Pro identifikaci backend serveru modul vyuziva prave jeden konfiguracni soubor pro kazdy namespace, jehoz jmeno prijima jako svuj parametr. Konfiguracni soubor mapuje prvni byte md5 na ID backend serveru.

Napr. /usr/local/etc/content-switch-volny.conf:

NOTE: Na prave strane tabulky content-switch-volny.conf je skutecne ID backend serveru, ktery je nakonfigurovan v pproxy (viz konfigurace pproxy nize). Nejedna se o DNS nazev stroje, prestoze v nasem pripade je ID zvoleno shodne s DNS zaznamem. Neni tedy mozne do content-switch-volny.conf zadat na pravou stranu neco jineho, nez je konfigurovano v pproxy. (Napr. tedy nelze doplnit tecku za ID backendu: m9.volny.cz.)

Jako dalsi nepovinny parametr prijima modul content-switch-volny.conf klicove slovo embedip. V pripade, ze je tento parametr predan, vraci modul pproxy uzivatelske jmeno ve tvaru username/client_ip, coz nam umoznuje na backend serveru (POP3 serveru) logovat i IP skutecneho klienta a ne jen IP POP3 proxy. Qmail, ktery bezi na backend serveru obsahuje COL patch, ktery username ve vyse zminenem formatu zpracuje odpovidajicim zpusobem. Qmail s COL patchem automaticky rozlisuje mezi beznym formatem username a formatem s client_ip na zaklade existence lomitka v username (v username pro COL sluzby neni lomitko povoleny znak).

Oba parametry jsou predavany pro kazdy namespace, ktery chceme pouzivat. Konfiguracni radka modulu z rc konfigurace pproxy vypada takto:

pcontrol - runtime konfigurace

Pproxy je mozne konfigurovat za behu. Slouzi k tomu program pcontrol(1) (http://www.remote.org/jochen/mail/popular/doc/html/man-pcontrol.html) , ktery via socket file komunikuje s pproxy. Kompletni popis naleznete v dokumentaci k POPular POP3 serveru (http://www.remote.org/jochen/mail/popular/doc/html/conf-pproxy.html) .

Program pcontrol je potreba spoustet pod uzivatelem, pod kterym bezi pproxy. V nasem pripade jde o uzivatele 'pop'. Po spusteni se dostanete do prostredi konzole progrmau pcontrol a muzete zadavat jednotlive prikazy pro konfiguraci pproxy. Ve vetsine pripadu asi nebude v nasem prostredi potreba provadet konfiguraci za behu. Vystacime si vetsinou s upravou souboru /usr/local/etc/popular/pproxy.rc a naslednym stop/start pproxy.

Existuje vsak jeden pripad, u ktereho je vhodne provest konfiguraci za behu namisto upravy ulozene "startovaci" konfigurace. Jde o zmenu stavu backend serveru pripadne zmenu stavu virtualniho serveru.

Rozhodneme-li se z nejakeho duvodu, ze konkretni backend server uvedeme do stavu "offline" nebo "fake" (pote treba do "online") je zbytecne (jde-li o kratkodobou zalezistost) upravovat ulozenou konfiguraci a stop/start pproxy. Staci via pcontrol prislusnym prikazem stav zmenit za behu.

Pro jednodussi praci s pcontrol je na serverech s pproxy nainstalovan COL port COL-popular-tools-1.0, ktery v soucasne dobe obsahuje dva jednoduche shell wrapper-y programu pcontrol. Prvni je prikaz su-pcontrol, ktery je ciste wrapper pcontrol a tudiz jako paramatr prijima komandy, ktere jsou pouzitelne v pcontrol konzoli a prinasi navic tedy to, ze se nemusite su-ckovat na uzivatele 'pop' a historii prikazu.

Druhym je prikaz backend-state, ktery, pokud je mu jako parametr zadano pouze ID backend serveru, zobrazi jeho state, resp. zobrazi jeho komplet konfiguraci a v pripade, ze za ID backend serveru nasleduje dalsi parametr, nastavi state backend serveru podle zadaneho parametru. Drtiva vetsina syntax kontroly je ponechana na samotnem programu pcontrol.

Priklady:

Logovani

Pproxy loguje do souboru /var/log/popular/pproxy, ringd loguje do /var/log/popular/ringd. Logovani je dobre popsane v dokumentaci POPular POP3 serveru v kapitole 7.Logfiles (http://www.remote.org/jochen/mail/popular/doc/html/log.html) . Kazda zprava do logu ma sve jedinecne ID (4 citiferne hexa cislo), ktere je mozno vyhledat v manualove strance popular-log(7), kde byva podrobneji vysvetlena.

Reseni problemu

Vypadek jednoho z proxy serveru
Pri vypadku jednoho z proxy serveru p12.volny.cz, je mozne "prehodit" IP alias z postizeneho serveru na bezici stroj. Na bezicim serveru je nutne nakonfigurovat dalsi vitrulani server pro tento IP alias. Konfigurace je predpripravena v /usr/local/etc/popular/pproxy.rc:

Firewall neni potreba upravovat. Pravidla PF jsou napsana tak, aby pristup POP3 byl povolen pro pridany IP alias automaticky. Presto je samozrejme potreba overit, ze po pridani IP aliasu vse funguje jak ma.

TECH:MS:SpamAssassin

SpamAssassin? (SA) je program pro detekci spamu, využívaný v antispamovém systému našeho mail systému a v RT. Jeho homepage je zde (http://spamassassin.apache.org/) .

Démoni spamd a spamass-milter

Filterd SpamAssassin? využívá prostřednictvím démonu spamd, který se dodává s SA a zajišťuje persistentní běh SA bez nutnosti neustále spouštět perl interpret a načítat SA knihovny. Démon spamd komunikuje se svými klienty (např. dodávaný spamc pro příkazovou řádku) pomocí vlastního protokolu. Filterd ale potřebuje ke komunikaci Milter protokol, proto využíváme i démon spamass-milter. Tento démon poskytuje jakousi protokolovou proxy mezi spamd a Milter klienty.

Spouštění a administrace

SA se instaluje z FreeBSD portu mail/p5-Mail-SpamAssassin. Milter rozhraní spamass-milter se instaluje z portu mail/spamass-milter. Spamd se spouští takto:

K dispozici je ale i samostatný command line nástroj, vhodný na testování. Výslednou upravenou zprávu vypíše na STDOUT:

Konfigurace

Základní konfigurační soubor naší instalace je v /usr/local/etc/mail/spamassassin/local.cf. Zde se nastavuje mimo jiné:

• use_razor2
  • zapnutí Razor
• use_dcc
  • zapnutí dcc
• skip_rbl_checks
  • vypnutí RBL kontrol
• use_auto_whitelist
  • automatický whitelist v homediru uživatele - u nás musí být vždy vypnuté
• bayes_auto_learn
  • učící se systém, funguje pouze per-uživatel - u nás vždy vypnuté
• rbl_timeout, razor_timeout
  • timeouty, vhodné relativně nízké, cca. 10 sekund
• whitelist_from
  • whitelist adresy oddělené mezerou
• required_score
  • nastavuje práh, při jakém score je mail považován za spam - u nás na mail system backendech se nevyužívá, jelikož porovnání vráceného score probíhá přímo ve filterd oproti jeho konfigurační volbě ADDITIONAL_SA_SCORE.
• report_safe, rewrite_header atd.
  • nastavuje modifikace zprávy - na mail system backendech nemá efekt, protože všechny modifikace dělá přímo filterd.

Kontrola funkčnosti

• Razor: grep RAZOR /var/log/maillog
• DCC: grep DCC /var/log/maillog
• FuzzyOCR: grep FUZZY_OCR /var/log/maillog

TECH:MS:Supertrash

Superkoš je funkce, která má obdobný účel jako Trashcan ve Windows - smazané zprávy nejsou skutečně smazány z disku, nýbrž jen přesunuty do systémové složky "Supertrash".

Automatické promazávání

• Složka je pozdě v noci pravidelně automaticky promazávána skriptem, který běží přímo na backend serverech. Jedná se o skript /home/system/mail/process-maildirs/process-maildirs (udržují admini), který načítá modul cleanjunk.pm vyvíjený aplikátory na area51 /var/www/webmail2/scripts/cleanjunk
• Interval promazávání je nastaven tak, že smazány jsou všechny zprávy starší než jeden den. Tato hodnota je nastavena v process-maildirs skriptu při inicializaci modulu cleanjunk. Stáří zprávy se určuje pomocí ctime atributu souboru. Je nutné užívat ctime, nikoliv mtime, protože ctime se mění i při přesunu zprávy mezi dvěma adresáři pomocí rename(), což potřebujeme, protože tak je implementováno přesouvání zpráv.

Implementace na webu

• Uživatel tuto složku ve webmail rozhraní nevidí mezi ostatními složkami - toto je implementováno na straně web aplikace, nikoliv v metadatad-services zabývajících se výpisem složek. Toto skrývání je implementováno v inc/AppPage.inc-listFolders().
• Přístup do této složky a obnovení ("undelete") zpráv v ní je možné v Nastavení->Superkoš. Zprávy jsou vždy obnoveny do složky INBOX, bez ohledu na to, z které složky byly původně smazány.
• Na straně web aplikace při mazání je superkoš implementován v www/list.php-multiDelete(). Superkoš mají aktivní všichni uživatelé, tudíž veškeré mazání prováděné ve webmail rozhraní je nyní ve skutečnosti přesouváním (services/movemessage.pm).

Implementace na backendu

• Ve složce Supertrash je vždy plně kontrolována aktuálnost indexu, není zde spoléháno na index add/remove systém (mailutil/Index.pm-useIndexMarkSystem()) - z toho důvodu, aby bylo možné složku libovolně promazávat jednoduchým skriptem.
• Složka je v konfguraci filterd i metadatad-services uvedena v direktivě @NO_QUOTA_FOLDERS, tato direktiva je využívána v services/movemessage.pm, services/deletemessage.pm a mailutil/Maildir.pm (funkce pro přepočítání kvóty a getStatsRecursive).

Ostatní

• Neplést se složkou Junk (na webu "ODPAD"), která slouží k ukládání doručených spamů a virů.
• Neplést se složkou Trash (na webu "ODSTRANĚNÉ"), která slouží jako koš, do kterého uživatel přesouvá zprávy vědomě.
• Obsah této složky se nezapočítává do kvóty.

TECH:MS:Testing

• prihlasit se na konto aa_volmejltest/pazzwdaa
• zkusit Napsat zpravu s pripojenou prilohou, nechat ji ulozit do Odeslane, kontrola ulozeni, kontrola zda spravne dosla
• otevrit slozku Dorucene
• otevrit slozku ěščřžýáíé - kontrola slozek s diakritikou v nazvu
• presunout dve libovolne zpravy z Dorucene do ěščřžýáíé, a zpatky
• vyhledavani - zadat ve slozce Dorucene do hledani vlevo "priloh" - objevi se dve zpravy, jedna z nich bude pouzita pro test nahledu
• test nahledu - otevrit zpravu "test prependu test priloh" - a zkusit:
• nahled PDF
• nahled Excel - vsimat si spravne diakritiky
• nahled Word - vsimat si spravne diakritiky
• uschovna - oznacit soubor Less_Mess?.png, kliknout na Odeslat - vzit vygenerovanou URL pro stazeni a zadat ji do jineho okna a zkusit stahnout soubor
• uschovna - zkusit upload nejakeho souboru - testuje diskovy prostor
• Nastroje - Prizpusobeni schranky - Aliasy - testuje spojeni s Omnisem
• Nastroje - Rozsirene filtry - testuje prenos filtru z backendu
• kontrola pravopisu - Napsat zpravu - zadat "test matkah" - kliknout na "CZ" - slovo matkah by melo byt oznacene jako chybne
• vlevo manu dole - kliknout na Sprava slozek - mel by se vypsat seznam
• test HTML editoru - jen Firefox/IE - Napsat zpravu - Vytvořit zprávu v HTML editoru - napsat nejaky formatovany text, odeslat, zkontrolovat (testuje i funkcnost lynxu pro konverze do plain textu)
• Nastroje - Zaznam pristupu - POP3 rozhrani
• test regexpu - Nastroje - Rozsirene filtry - Popis a online test regulárních výrazů - zadat ukazkove retezce a testnout
• WAP - pres telefon na wap.mail.volny.cz

TECH:MS:TODO

TODO seznam dlouhodobějších úkolů při vývoji MailSystému?. Některé mohou být pouze potenciálními návrhy. Jedná se o poslední kroky, které je třeba realizovat, aby se náš mail systém vyrovnal konkurencí.

Rozdělení mailutil na mailutil a mailindex

V lednu bychom meli rozdelit dosavadni port mailutil na:

• mailutil
• mailindex

To proto, ze v mailutil je spousta univerzalnich perl trid, ktery uz se vyuzivaji na dasu, na konvertoru, na dispotu.
Jenze diky pritomnosti indexu se tim na ty stroje zbytecne zanasi sqlite, pcre a MailXS ceckove perl moduly, ktere je nutne kompilovat. Idealni bude to oddelit.

Přechod z Maildiru na efektivnější uložiště

Jedná se o nahrazení Maildir struktury efektivnějším uložištěm zpráv:

• disková struktura by měla být navržena tak, aby v jednom adresáři nebyly při velké schránce desítky tisíc zprav - proto je místo Maildiru lepší struktura podobná té využité v DMS.
• pro velmi časté funkce mazání a přesouvání zpráv není efektivní mít složky jako různé sub-Maildiry na disku, lepší je *mít informaci o složce uloženou jenom jako tag u zprávy v indexu
• každá zpráva by měla mít neomezené množství tagů, které by byly uloženy v indexu, nikoliv ve filename
• filename zprávy by mělo být pouze číselné, mělo by odpovídat ID zprávy a nemělo by se nikdy měnit - z důvodu efektivity jeho nacházení.
• pro efektivní vyhledávání zpráv pomocí fulltextu je třeba mít jeden index, ve kterém budou zprávy ze všech složek naráz - složky budou u zpráv uloženy jako číselné ID, které bude ve druhé tabulce mapováno na název v utf-8
• názvy složek nebude nutné složitě kódovat do imap-utf7
• současný kód pro doručování zpráv, operace nad zprávami a nad kvótou je komplikovaný právě kvůli tomu, že je nutné zacházet s Maildir strukturou. Nová strukura by byla výrazně jednodušší a spolehlivější. Nejvíc bugů souviselo s nutností obcházet vlastnosti Maildirů.
• kvóta by se měla dynamicky zjišťovat pouze z indexu, kde by byly uloženy i velikosti zpráv. Kvóta by tak vždy byla 100% aktuální a nebylo by třeba žádné složité přepočítávání. Při uložení zprávy do indexu už by nebylo třeba nijak aktualizovat kvótu, podobně je to s mazáním zpráv.
• tento systém by umožnil zbavit se céčkového mailutil modulu MailXS, protože vše by šlo dělat efektivně přímo z perlu.
• kvóta bude vždy 100% aktuální a nebude nikdy rozsynchronizována se skutečným stavem obsazení
• mazání (přesouvání) je teď velmi pomalé, protože je nutné transakčně bezpečně data z jednoho indexu vyjmout a do jiného vložit - v novém uložišti bude stačit jedním dotazem změnit hodnotu pole folder v jedné tabulce

Nahrazení by mělo proběhnout tak, aby jedna verze filterd i metadatad dokázala detekovat typ uložiště a pracovat s oběma typy. Tím by bylo možné převádět do nového formátu schránky postupně dle potřeby nebo např. dle toho, zda si uživatel zakoupí pomocí SMS 2 GB schránku. Pro realizaci bude třeba upravit i qmail-pop3d, což je ovšem snadné.
Frontend a metadatad protokol mail služeb nebude třeba měnit vůbec.

Rozpis realizace (cca. dva měsíce)

• 1 týden - nová mailutil třída MailStore?.pm, která zajistí abstraktní interface pro operace s indexem a s uložištěm a detekci typu uložení a zvolení implementace níže.
• 1 týden - MailStoreMaildir?.pm - implementace rozhraní MailStore? zajišťující práci se současnými Maildiry a indexy.
• 1 týden - MailStoreNew?.pm - implementace rozhraní MailStore? zajišťující práci s novým indexem a novým uložištěm.
• 1 týden - upravit filterd pro práci s MailStore? + testy
• 1 týden - upravit metadatad pro práci s MailStore? + testy
  • zde zejména archivace, přesouvání, mazání, vytváření složek, ukládání
• 2 týdny - úprava POP pro detekci typu uložiště a práci s novým uložištěm
• 1 týden - testy a testovací nahození

Fulltextové indexy

Tento bod má smysl realizovat až poté, co bude Maildir nahrazen efektivnější strukturou uložiště, tedy až bude pro všechny složky existovat jen jeden index. Jde o vytvoření systému pro snadné fulltextové vyhledávání ve zprávách, které by dokázalo vyhledané zprávy i řadit dle nějakého kritéria relevance. Vyhledávat se budou klíčová slova. Ta budou do fulltext indexu umisťována s různě nastavenou váhou relevance z těchto dekodovaných údajů ve zprávě:

• Subject
• From
• To

V této fázi jde o zeefektivnění současného vyhledávání v těchto polích, které je realizováno jako sekvenční průchod celého indexu, což bude u více zpráv v jedné složce pomalé. Jde také o realizaci postupně rozšiřitelného systému pro fulltext vyhledávání obecně. V další fázi lze do indexu zahrnovat i slova z textové části těla zprávy, ale výrazně tím naroste prostor zabraný indexem a také bude nutné parsovat a dekodovat celé zprávy. Je otázka, zda má takové vyhledávání pro uživatele význam.

Při realizaci by se měl využít modul DBIx-TextIndex (http://search.cpan.org/~dkoch/DBIx-TextIndex-0.25/) , jehož jsem spoluautor. Tento dokáže pro uložení dat fulltext indexu využít jakoukoliv DBI kompatiiblní databázi, tedy i nyní použivaný sqlite (http://sqlite.org/) . Využívá klasický inverted matrix postup, kdy slova z dokumentů se stanou klíči indexu, ukazujícími na seznam odpovídajících dokumentů spolu s vahou relevance daných výskytů.

Bude třeba ještě promyslet udržování fulltext indexu.

Postup realizace (jen první fáze, bez indexace těl zpráv):

• 2 týdny - doplnění funkcionality do mailutil Index.pm
• 1 týden - implementace na straně metadatad-services + testy
• 1 týden - změny v protokolu a webrozhraní ohledně řazení dle relevance

AJAX web rozhraní

Jde o zrychlení odezvy při práci s web rozhraním. Místo genenrování nové stránky ze šablon a její znovunačítání a vykreslování prohlížečem se pouze ze serveru na pozadí stáhnou data, která Javascript využije pro změnu určitých prvků zobrazené stránky.

Google mail je takhle udělaný celý, jako jediný webmail. Nevýhodou je nutnost mít speciální verzi pro starší prohlížeče a zajistit detekci. V současnosti AJAX podporují: Explorer, Firefox, Konqueror, Opera.

Určitě není vhodné dělat v AJAX (http://en.wikipedia.org/wiki/Ajax_(programming)) vše komplet jako
jednu stránku-Javascript aplikaci. Takto to má udělané Google. To je zbytečně pracné a nepraktické. My
bychom měli udělat AJAX verzi pouze u těchto provázaných nejpoužívanějšch stránek/funkcí, mezi kterými
uživatel při běžné práci neustále přechází a tudíž mu to skutečně urychlí práci:

• list.php - zobrazení obsahu složky
• view.php - zobrazení zprávy
• compose.php - vytvoření nové zprávy
• compose.php - kontrola pravopisu

Nicméně je třeba pamatovat na to, že zpracování šablon na serveru téměř žádný čas nezabírá a odezva z pohledu uživatele vždy bude limitována především rychlostí odezvy backendu/metadatad. Využity by byly Widget moduly AJAX framework Jaxter, který připravuji.

Rozpis realizace

• 1 týden - server-side skript, vracející ve formátu JSON (http://en.wikipedia.org/wiki/JavaScript_Object_Notation) data, která si vyžádá Javascript na straně klienta. Také bude zajišťovat zpracování dat odesílané zprávy a kontroly pravopisu.
• 4 týdny - AJAX widgety implementující:
  • list - výpis obsahu složky, listování mezi zprávami, mazání, přesouvání...
  • view - zobrazení zprávy, nahoře kontext seznam okolních zpráv, jako to má třeba outlook + možnost zvětšit na celé okno.
  • compose - formulář pro tvorbu zprávy, zde lze pomocí AJAX udělat i různé malé doplňky,např. automatické doplňování adres příjemců ihned poté, co uživatel napíše první písmena.
  • compose - kontrola pravopisu
• 2 týdny - dát to vše dohromady, cross-browser testy atd..

Velká kapacita schránek

Současná poskytovaná kapacita 20 MB je zcela nedostatečná, konkurence nabízí gigabajt i více. Kapacitu budeme rozšiřovat na minimálně 250 MB. Je nutné provést upgrade HW a dokoupit disková pole, o což se stará oddělení sysadmin.
Mail systém je v rámci omezení daných Maildir strukturou navržen pro optimální výkon i pří hodně velkém počtu zpráv ve složce. Dobrá odezva běžné práce a snesitelná odezva vyhledávání by měla být zajištěna ještě při cca. 10 000 zprávách ve složce. Pro více zpráv již bude nutné změnit strukturu uložiště na efektivnější formát.

Ostatní

Předělat alias-forwardy uložené v Omnisu na FORWARD filtry. Na colmailu už to tak je. O tohle se stará Vlasta.
Průběžně dopisovat dokumentaci ve wiki.

TECH:MS:WebAppAdmin

Switchnutí aplikace z area51 na ostré

• BASEDIR je /var/www/webmail2. Vše by mělo být prováděno pod běžným uživatelem ve skupině webmast.
• Dokončit rozpracované věci na area51 v BASEDIR, otestovat, nezapomenout potlačit debug výpisy.
• Zvýšit číslo VERSION v inc/config.inc a v BASEDIR spustit:

• Počkat, než se překompilují šablony a vše se přenese do /disk/web-src
• Minutová pauza, aby měl websrc démon čas vše aktualizovat na všech strojích
• Na všech web strojích spustit jako root:

• Počkat, až se vše přenese z /home/r-web-src-sh do /var/www. Stisknout ENTER.

RELAY.VOLNY servery

Stroje

• relay1.volny.cz
• relay2.volny.cz
• relay3.volny.cz

Sluzby

VOLNYMAIL
Servery ze skupiny relay.volny.cz jsou mailservery (MTA) urcene pro prichozi postu mailove sluzby VOLNYMAIL (volny.cz, volna.cz, ufoni.cz, mizera.cz, machr.cz, voleji.cz, soukroma.cz, firemni.cz, napismi.cz, genius.cz).

Jako MTA pouzivame Postfix (http://www.postfix.org/) . Mailsever postu prijima, provede zakladni kontroly (vcetne zakladnich antispam restrikci), pripadne forwardy (nejsou-li via filtry na mailovych backendech) a preda po LMTP zpravu dale na mailovy backend server m0-9.volny.cz.

Dusledky vypadku

VOLNYMAIL

Pri vypadku nektereho ze serveru skupiny relay.volny.cz nebude dany server prijimat postu a ta bud zustane ve fronte mailserveru, ktery se snazi na nas server postu odeslat a odesilajici mailserver bude zkouset odeslat postu pozdeji nebo bude dorucena na jiny server ze skupiny relay.volny.cz, pokud to odesilajici mailserver na jiny nas serveru odeslat zkusi. V praxi odesilajici mailserver skutecne vetsinou zkusi dalsi mailserver (servery relay123.volny.cz jsou v DNS uvedeny v "round-robinu" mx.volny.cz, ktery je uvaden v MX zaznamech prislusnych domen systemu VOLNYMAIL)

Implementace

Hardware

• relay1.volny.cz - 4U server: P4 3 GHz, 2 GB RAM
• relay2.volny.cz - 4U server: P4 3 GHz, 2 GB RAM
• relay3.volny.cz - 4U server: P4 3 GHz, 2 GB RAM

Operacni system
Na serverech je pouzit operacni system FreeBSD:

• relay1.volny.cz: FreeBSD 6.4-RELEASE-p8
• relay2.volny.cz: FreeBSD 6.4-RELEASE-p8
• relay3.volny.cz: FreeBSD 6.4-RELEASE-p8

Baliky:

• COL-logr
• COL-setup
• portupgrade
• pkg_cutleaves

Manualne upravene soubory:

• /etc/fstab
• /etc/mail/aliases
• /etc/make.conf
• /etc/pf.conf
• /etc/rc.conf
• /etc/resolv.conf
• /etc/sysctl.conf
• /tmp (odkaz na var/tmp)
• /usr/local/etc/check-daemons.conf
• /usr/local/etc/ports.cvsup
• /usr/local/etc/ports.local.cvsup

VOLNYMAIL

Baliky:

• COL-mailstats-postfix
• COL-trigger-1.3
• p5-Digest-MD5
• postfix
• scponly-4.8

Manualne upravene soubory:

• /usr/local/etc/content-switch-volny.conf
• /usr/local/etc/size_queue_check.conf
• /usr/local/etc/trigger.cf
• /usr/local/etc/postfix/access_client_nores
• /usr/local/etc/postfix/access_local
• /usr/local/etc/postfix/access_sender_blacklist
• /usr/local/etc/postfix/access_sender_nores
• /usr/local/etc/postfix/body_checks
• /usr/local/etc/postfix/genius_aliases
• /usr/local/etc/postfix/header_checks
• /usr/local/etc/postfix/main.cf
• /usr/local/etc/postfix/master.cf
• /usr/local/etc/postfix/transport_global
• /usr/local/etc/postfix/transport_local
• /usr/local/etc/postfix/virtual_global
• /usr/local/etc/postfix/virtual_local

Generovane soubory (konfigurace):

• /usr/local/etc/postfix/access_gen_blacklist
• /usr/local/etc/postfix/access_recipient_nores
• /usr/local/etc/postfix/transport_users
• /usr/local/etc/postfix/users
• /usr/local/etc/postfix/virtual

• IP aliasy - kazdy ze stroju skupiny relay.volny.cz ma svou primarni IP adresu, ktera ma jmeno relay123.volny.cz, na ktere je stroj pristupny pro spravu via SSH a dale IP alias(y), na kterych provozujeme dane sluzby MTA. IP aliasy jsou IP adresy, ktere uvadime v prislusnych MX zaznamech domen na strojich ze skupiny relay.volny.cz prijimanych. Na primarnich IP adresach neni sluzba MTA (Postfix) dosazitelna.

Aktualne:

• relay1.volny.cz
  • primarni IP: 212.20.96.185 (relay1.volny.cz)
  • IP aliasy: 212.20.96.186 (mx1.volny.cz)
• relay2.volny.cz
  • primarni IP: 212.20.96.179 (relay2.volny.cz)
  • IP aliasy: 212.20.96.180 (mx2.volny.cz)
• relay3.volny.cz
  • primarni IP: 212.20.96.183 (relay3.volny.cz)
  • IP aliasy: 212.20.96.182 (mx3.volny.cz)

Dale existuje toto DNS jmeno:

• mx.volny.cz -> 212.20.96.186 (mx1.volny.cz), 212.20.96.180 (mx2.volny.cz), 212.20.96.182 (mx3.volny.cz) - round-robin IP aliasu vyuzivany u sluzby VOLNYMAIL jako jmeno do MX zaznamu prislusnych domen.

Jako MTA je pouzit Postfix (http://www.postfix.org/)

• Domena volny.cz a dalsi domeny (volna.cz, ufoni.cz, mizera.cz, machr.cz, voleji.cz, soukroma.cz, firemni.cz, napismi.cz, genius.cz) jsou via MX zaznam smerovany na DNS jmeno mx.volny.cz, coz je round-robin nekolika IP adres pouzitych jako IP aliasy na strojich skupiny relay.volny.cz (viz vyse).
• Domena volny.cz a dalsi domeny jsou konfigurovany jako relay-ovane domeny (volba relay_domains v main.cf) a na urovni konkretnich kompletnich e-mail adres je posta smerovana via LMTP na mailove backend servery (skupina stroju m.volny.cz) (tabulka transport_users). Muzou existovat mailove aliasy v domene volny.cz, ktere jsou konfigurovany via sluzbu Postixu virtual (tabulka virtual_aliases).
• Vyjimkou je domena "genius.cz", ktera je konfigurovana jako mydestination a pres lokalni aliasy (/usr/local/etc/postfix/genius_aliases) jsou pak jednotlive konkretni e-mail adresy smerovany na e-mail adresu v domene "volny.cz". *Konfigurace je prevazne automaticky generovana, viz kapitola "Generovana konfigurace".

Konfigurace se nachazi v /usr/local/etc/postfix/
Bezna konfigurace Postfixe:

• vse je v main.cf a v master.cf (s upravama v master.cf velmi opatrne, s upravama v main.cf vsak take velmi opatrne)

• V master.cf si definujeme nove "transport-y" lmtp0-9. Jednak pak lepe funguje cahce-ovani otevrenych spojeni, protoze pro kazdou destinaci existuje vlastni transport a za druhe to umoznuje nastavovat ruzne limity pro tyto transporty oddelene (napr.: lmtp1_destination_concurrency_limit, apod.).

Upravene soubory (Postfix):

• access_client_nores, access_client_nores.db - tabulka IP klientu, na ktere se neuplatnuji nektere Postfix restrikce pouzite jako cast naseho AS (antispam) reseni (reject_unknown_client, reject_rbl_client). Primarnim cilem je whitelistovat "cesky internet", tj. IP adresy pridelene CZ. Soubor je udrzovan lokalne rucne.
• access_gen_blacklist, access_gen_blacklist.db - tabulka IP/e-mail adres/domen, ktera slouzi jako blacklist. Soubor je udrzovan rucne na stroji intranet.vol.cz a odtud distribuovan na nase mailservery.
• access_recipient_nores, access_recipient_nores.db - tabulka e-mail adres prijemcu, pro ktere se neuplatnuji nektere Postfix restrikce pouzite jako cast naseho AS reseni (reject_unknown_client,reject_rbl_client). Soubor je generovan z MySQL DB na webmaildb2.hide.vol.cz a odtud je distribuovan na skupinu stroju relay.volny.cz. Cilem je umoznit uzivatelum volitelne "vypnout" vyse zminene Postfix restrikce pro postu jim urcenou. Uzivatele toto nastavuji pres Webmail rozhrani.
• access_sender_blacklist, access_sender_blacklist.db - tabulka e-mail adres odesilatelu, ktera slouzi jako blacklist uplatnujici se prave na adresy odesilatelu. Soubor je udrzovan lokalne rucne.
• access_sender_nores, access_sender_nores.db - tabulka e-mail adres odesilatelu, pro ktere se neuplatnuji nektere Postfix restrikce pouzite jako cast naseho AS reseni (reject_unknown_client,reject_rbl_client). Soubor je udrzovan lokalne rucne.
• body_checks - tabulka, ktera slouzi k detekci urciteho retezce/vzorku v tele mailu a urcuje jak pri pozitivni detekci reagovat. Soubor je udrzovan lokalne rucne. U nas slouzi predevsim k blokaci SPAMu, VIRu, apod.
• header_checks - tabulka, ktera slouzi k detekci urciteho retezce/vzorku v hlavicce mailu a urcuje jak pri pozitivni detekci reagovat. Soubor je udrzovan lokalne rucne. U nas slouzi predevsim k blokaci SPAMu, VIRu, apod.
• main.cf - jeden z hlavnich konfiguracnich souboru Postfix-e
• master.cf - jeden z hlavnich konfiguracnich souboru Postfix-e
• transport_global, transport_global.db - transport tabulka Postfixe obsahujici z naseho phledu zakladni nastaveni. Soubor je udrzovan lokalne rucne. Rozdeleni do nekolika tabulek transport_* je predevsim z duvodu prehlednosti a predchazeni konfiguracnim chybam.
• transport_local, transport_local.db - transport tabulka Postfixe, kterou vyuzivame pro lokalni nastaveni umoznujici testovani, docasna reseni, apod. Soubor je udrzovan lokalne rucne. Rozdeleni do nekolika tabul transport_* je predevsim z duvodu prehlednosti a predchazeni konfiguracnim chybam.
• transport_users, transport_users.db - transport tabulka Postfixe, ktera obsahuje zaznamy o konkretnich kompletnich adresach v domene volny.cz. Zaznamy zajistuji smerovani posty pro konkretni e-mail adresu via LMTP protokol na prislusny mailovy backend server (m0-9.volny.cz). Tabulka je generovana z databaze (dbas); vice viz kapitola "Generovana konfigurace".
• users - je pomocny seznam existujicich e-mail adres v domene volny.cz, ktery slouzi jako predloha pro generovani konfigurace postfixe (pro generovani tabulky transport_users). Tento soubor neni primo vyuzivan jako konfigurace Postfixe. Jeho format je LHS<tab>RHS, kde LHS je e-mail adresa a RHS je klicove slovo, ktere jiz dnes nema zadny vyznam a cela tabulka se tedy dnes vyuziva jen jako seznam existujicich e-mail adres. Soubor je generovan z databaze (dbas); vice viz kapitola "Generovana konfigurace".
• virtual, virtual.db - tabulka virtual Postfixe, ktera obsahuje zaznamy o mail aliasech v domene volny.cz a implementuje tak mailove aliasy u sluzby VOLNYMAIL a zaroven forwardy uzivatelu. Mailove aliasy vyuzivame "interne", ne pro zakazniky. Dale tato tabulka implementuje aliasy v dalsich domenach (volna.cz, ufoni.cz, mizera.cz, machr.cz, voleji.cz, soukroma.cz, firemni.cz, napismi.cz,genius.cz), ktere si nastavuji sami uzivatele sluzby VOLNYMAIL. Tabulka je generovana z databaze (dbas); vice viz kapitola "Generovana konfigurace".
• virtual_global, virtual_global.db - tabulka virtual Postfixe, ktera obsahuje zakladni nastaveni aliasu. Soubor je udrzovan lokalne rucne. Aktualne neobsahuje zadnou konfiguraci a existuje z duvodu dodrzeni konzistence v cleneni konfigurace na "globalni", "lokalni" a "ostatni" (napr. generovanou). Rozdeleni do nekolika tabul virtual_* je predevsim z duvodu prehlednosti a predchazeni konfiguracnim chybam.
• virtual_local, virtual_local.db - tabulka virtual Postfixe, kterou vyuzivame pro lokalni nastaveni umoznujici testovani, docasna reseni, apod. Soubor je udrzovan lokalne rucne. Rozdeleni do nekolika tabul virtual_* je predevsim z duvodu prehlednosti a predchazeni konfiguracnim chybam.

Generovana konfigurace

Nektere soubory, ktere jsou soucasti konfigurace Postfixe jsou generovane z databaze, tj. distribuovane ze stroje dbas.hide.vol.cz, dale ze stroje webmaildb2.hide.vol.cz, ze stroje intranet.vol.cz a ze stroje svn.hide.vol.cz. Pro automaticke spusteni rekonfigurace po nakopirovani noveho souboru z DB (dbas.hide.vol.cz) je vyuzivan bud skript trigger (COL/trigger) nebo pravidelne spousteni z Cronu.

• transport_users - z DB seznam existujicich adres. Distribuovany soubor ma format tabulky, kdy na leve strane je konkretni existujici e-mail adresa predstavujici fyzicky mailbox ve VOLNYMAIL systemu a na prave strane je jedno zklicovych slov "STANDARD" nebo "MAILSCAN". Prava strana nema jiz dnes zadny vyznam. Ze seznamu se generuje skriptem /home/system/postfix/postfix_transport_users.reload tabulka transport_users pro Postfix. Podstatne je, ze je ke kazde adrese urcen mailovy backend server na zaklade spocitani md5 uzivatelskeho jmena (cast pred

zavinacem) a porovnanni s prevodni tabulkou /usr/local/etc/content-switch-volny.conf.

• Pozn.: reload konfigurace podporuje tzv. "patch-e", tj. z DB se vygeneruje jen to, kde doslo ke zmene. Problem soucasneho reseni je, ze pri pouziti patche se zmenami upravi pouze vlastni db soubor Postfixe transport_users.db, nikoliv jeho textova predloha transport_users. virtual_aliases - z DB seznam mailovych aliasu. Distribuovany soubor ma format tabulky, kdy na

• virtual_aliases - z DB seznam mailovych aliasu. Distribuovany soubor ma format tabulky, kdy na leve strane je konkretni existujici e-mail adresa v domene systemu VOLMAIL a na prave strane jakakoliv jina adresa nebo adresy, na ktere ma byt posta smerovana. Reload zajistuje skript /home/system/postfix/postfix_virtual_aliases.reload.
  • Pozn.: reload konfigurace podporuje tzv. "patch-e", tj. z DB se vygeneruje jen to, kde doslo ke zmene. Problem soucasneho reseni je, ze pri pouziti patche se zmenami upravi pouze vlastni db soubor Postfixe virtual_aliases.db, nikoliv jeho textova predloha virtual_aliases.

• access_gen_blacklist - rucne spravovany blacklist na stroji intranet.vol.cz. Ze stroje intranet.vol.cz je distribuovan pravidelne na nekolik nasich mailserveru (dle konfigurace distribucniho skriptu na intranet.vol.cz). Reload zajistuje skript /home/system/postfix/postfix_access.reload.

• access_recipient_nores - distribuovano ze stroje webmaildb2.hide.vol.cz. Seznam uzivatelskych jmen na leve strane a jedno z klicovych slov "DISABLED" nebo "LOW" na strane druhe. Klicova slova pro na maji v soucasne dobe stejny vyznam. Na zaklade teto predlohy je skriptem /home/system/postfix /postfix_access_recipient_nores.reload vygenerovana tabulka pro Postfix access_recipient_nores,ktera slouzi jako whitelist pro nektere pouzivane restrikce v konfiguraci Postfixe.

• content-switch-volny.conf - rucne udrzovany soubor na stroji svn.hide.vol.cz, ze ktereho je v pripade potreby rucnim spustenim distribucniho skriptu kopirovan na urcene stroje, vcetne stroju skupiny relay.vol.cz. Zde je reloadovan skriptem /home/system/content-switch.reload.

Trigger /usr/local/etc/trigger.conf:

Návody

Přeplnění deferred front na relayích
Často indikuje nějaký problém na backendech. Skript show_backends vypíše, pro kterých backend je ve frontě nejvíc mailů:

Postfix DOC

• man 5 postconf
• man 1 postconf
• /usr/local/share/doc/postfix/
• http://www.postfix.org

Prace s mailovou frontou

• prohlizeni mailove fronty

• statistika prijemcu/odesilatelu v mailove fronte: qshape <mail_fronty> (podle domeny prijemce), qshape -s <mail_fronty>(podle domeny odesilatele)

• prohledavani mailove fronty: cd /var/spool/postfix; grep -R <neco> deferred/

• promazani mailove fronty (OPATRNE !!!) : cd /var/spool/postfix; grep -R <neco> deferred/ | awk

'{print $3}' | cut -f3 -d"/" | postsuper -d -

• dohledani souboru s mailem v Postfix mail fronte podle MSGID z vypisu fronty nebo z logu: cd

/var/spool/postfix; find . -name <MSG_ID>

• zobrazeni mailu z fronty (soubory v Postfix fronte jsou binarni): postcat

<cesta_k_souboru_s_mailem> | less