Po zjištění z minulého dílu jsme se v Triton IT rozhodli nasadit vlastní mail server. Z běžně používaných řešení je ale pouze Microsoft Exchange Server dostupný jako kompetní balík všeho, co je potřeba. MS Exchange Server samozřejmě představuje nemalou investici a funguje jen na zařízeních s operačním systémem Windows Server. Vzhledem k našim požadavkům na nízkou cenu nezbývá, než ho přeskočit a podívat se na celé téma podrobněji.

Pro úspěšný běh vlastního mail serveru na internetu je potřeba jen následující tři kusy software:

• MTA: Mail Transfer Agent vyměňuje emaily po internetu. Funguje jako server i klient nad protokolem SMTP. Příkladem MTA jsou programy sendmail, postfix a exim4. V podstatě má jen dva úkoly:
  • jako klient se připojí k jinému MTA a doručí mu email.
  • jako server čeká, až mu někdo (např. jiný MTA) doručí email. Pak se rozhodne, jestli ho někam uloží, nebo ho jde poslat dál.
• MDA: Mail Delivery Agent umožňuje uživatelům stahovat emaily ze serveru. Konkrétně povoluje klientským programům (MUA) se připojit prostřednictvím protokolů IMAP nebo POP3 ke schránkám uživatelů. Teoreticky také může schránky a uživatele spravovat, to je něco, co ale umí i někteří MTA a obecně není jasně dáno, kdo to má mít starost.
• MUA: Mail User Agent je program, s kterým pracuje uživatel. MUA má zpravidla hezké grafické rozhraní s přehledem emailů ve schránce, ukládá si kontakty, umožňuje snadno přikládat přílohy, atd. Mezi MUA patří MS Outlook, Thunderbird, ale i GMail.com a Seznam.cz.

Když si oddělíme databázi našich uživatelů a samotné úložiště schránek, jde to celé nakreslit asi takto:

Při návrhu se největším úskalím ukázalo být vyzvedávání emailů pomocí MUA z MDA. Přestože komunikace přes protokoly POP3 a IMAP je naprosto přímočará a jasně definovaná, některé MUA se rozhodly zavést si vlastní dodatečná pravidla k formátu uživatelských jmen a šifrování. Konkrétně:

• MS Outlook nefunguje, dokuď nemá uživatelská jména pro komunikaci s MDA jen v alfanumerickém tvaru, tj. bez symbolu @ (nelze použít email jako přihlašovací jméno).
• GMail protestuje, pokud TLS komunikace není realizována pomocí certifikátu od některé z mezinárodních certifikačních autorit. Certifikát od Let's encrypt v době našeho testování (2016) bohužel nebyl podporován.

Finální řešení

Po dlouhém výzkumu metodou pokus-omyl jsme došli k následujícímu rozvržení:

• MTA = postfix
• MDA = dovecot
• MUA = co má kdo rád, za mě jednoznačně GMail
• Schránka = složka na serveru, kompletně v režii postfix a dovecot
• Databáze emailových účtů = MySQL databáze

Tím jsme dosáhli následujících nákladů:

• 110 Kč / měsíc ... Virtuální server, na kterém už stejně provozujeme weby
• 259 Kč / rok ... Certum Commercial SSL certifikát
• 130 Kč / rok / doména ... Náklady na CZ doménu placené registrátorovi

Jakých výhod jsme tímto řešením dosáhli?

• Libovolný počet domén, schránek, aliasů bez poplatků navíc.
• Možnost napojit oblíbenou schránku na webu nebo program úplně podle vlastní preference zaměstnance.
• Při používání GMailu dále:
  • Snadné spojení více firemních i soukromých schránek do jediného účtu
  • Automatické ukládání kontaktů a jejich sdílení do Android zařízení
• Téměř bezúdržbový běh
• Při použítí POP3 k vyzvedávání schránky - téměř nulové nároky místo při zálohování, zodpovědnost za uložené emaily lze přesunout na jinou (i placenou) službu.

V příštím díle se podíváme na běžné problémy, se kterými se setkáte po nasazení vlastního mail serveru. A že jich není málo.

Naše cesta k nasazení Cassandry byla poměrně rychlá: šli jsme rovnou do produkce a problémy se učili řešit až za běhu. Za rok, co ji provozujeme, jsme potkali už téměř všechny běžné scénáře:

• přeplnění tombstone
• oživení tombstone kvuli nespuštění repair do konce gc_grace_period
• nekontrolovatelné spínání stop-the-world garbage collection
• neopravitelné rozpojení tabulky mezi datacentry
• smazání části databáze špatně napsanou čistící funkcí a následná obnova ze snapshotu ...

Poslední dobou jsem ale zaznamenal plynulý nárůst zátěže na serverech s Cassandrou. Nárůst, který jsem si nedovedl vysvětlit.

Nejdříve jsem jej chtěl přisuzovat zvyšujícímu se objemu přenosu. Přece jen každý měsíc přidáváme nové stroje na těžbu a zpracování dat, logicky by se měla zvednout i zátěž na databázi. Svědomitě jsem proto pravidelně pouštěl repair, hlídal četnost GC a dodržoval postupy, které jsme našli v literatuře. A právě tady byl problém.

Bohužel jsme šáhli po stejných zdrojích jako Maki Watanabe. Důvod nárustu se ukázal být úplně prostý - nodetool repair implicitně nespouští tzv. major compaction. Právě nodetool compact jsem přestal manuálně spouštět ve chvíli, kdy jsem se naučil používat nodetool repair.

Repair není tak efektivní v odstraňování tombstone a my často zapisujeme, mažeme a provádíme změny struktury naší databáze. To také vedlo k vyšší zátěži.

Všechno špatné je ale k něčemu dobré, máme poučení, že nemáme číst zastaralou literaturu. Známe teď také další problémový scénář :)

Včera jsem navštívil veletrh For Arch. Moje první kroky vedly k velkému stánku našeho milovaného klienta. Opět jsem si s nimi příjemně popovídal, pořešil několik pracovních záležitostí a občerstvil se u jejich baru :)

Potom jsem si procházel zbytek veletrhu. S WebMedeou jsem si připadal tak trochu jako terminátor s infravizí. Proč? Stačilo zadat název od libovolného stánku do mobilu a hned jsem ve WebMedea viděl, kde se firma propaguje, do jakého propagačního kanálu investuje a zhruba kolik, kde jsou její slabá místa a prostor pro zlepšení.

Zastavil jsem se u několika stánků, s majiteli si chvíli pokecal a dozvěděl se řadu zajímavých informací. Tak například automatických kotlích na štěpku nebo luxusních vířivých vanách. Odcházel jsem s dobrou náladou a pár zajímavými vizitkami.

Jako jedna z prvních věcí, které jsme řešili při zakládání Triton IT, byla schopnost odesílat a přijímat emaily na vlastních doménách. Malicherný problém, který lze většinou vyřešit v ceně domény nebo hostingu. U Tritonu se ale problém ukázal být mnohem větší. Naše definice pohodlného ovládání se také postupně vyvíjela, neboť že vám něco není pohodlné většinou zjistíte až po vyzkoušení. Po mnoha pokusech a změnách jsme zakotvili na následujících požadavcích:

• Co nejnižší cena.
• Libovolný počet schránek a domén bez zvýšení nákladů na provoz.
• Možnost používat libovolného klienta podle preference zaměstnance -  tj. Gmail, Seznam, MS Outlook, Thunderbird (pro PGP šifrování), atd.
• Vytváření aliasů (emailových adres, které jsou jen přezdívkou pro jednu nebo více dalších adres).
• Sdílení kontaktů mezi emailovým klientem a telefonem.

Externí řešení k dispozici

Protože jsme se hned nechtěli pouštět do budování vlastního serveru, hledali jsme nejprve externí řešení. V následující tabulce je seznam toho, co jsme buď vyzkoušeli, nebo to zvažovali:

V uvedených cenách nejsou náklady na doménu, které jsou různé podle prodejce. Ceny naposled aktualizovány 2016.

Účtování za každou doménu a nízká flexibilita aliasů pro nás byly kamenem úrazu. Nezbývalo nám nic jiného než postavit alespoň částečně vlastní řešení, a na to se podíváme příště.

Odladit produktový feed u zákazníka, který ho nasazuje poprvé, dá zabrat. Když je k nasazení změn nutno zákazníka pokaždé kontaktovat, nebo dokonce předat hlášení třetí straně, může se odladění feedu tak, aby ho Google Merchant Center přijal, natáhnout až na týdny. Vy ale potřebujete feed funkční ihned a produktovou kampaň spuštěnou ideálně včera.

V Triton IT jsme řešili právě takový problém. Popisky produktů načtené z e-shopu obsahovaly znaky neplatné v kódování UTF-8. Google se proto jednoduše rozhodl, že zahodí celý zbytek feedu po výskytu takového znaku.

K vyřešení podobného problému ale úplně stačí mít po ruce vlastní hosting s podporou CGI - např. PHP. Soubor s následujícím kódem jsme nasadili na náš web, a můžeme tak feedy automaticky čistit od nežádoucích znaků:

<?php

if (!isset($_GET['f']) || $_GET['f'] == null) {
  header('Content-Type: text/plain');
  echo 'No feed provided';
  exit(1);
}

$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $_GET['f']);
curl_setopt ($ch, CURLOPT_HEADER, 0);
ob_start();
curl_exec ($ch);
curl_close ($ch);
$xml = ob_get_contents();
ob_end_clean();

header('Content-Type: text/xml');
echo preg_replace('/[\x00-\x1F\x7F]/u', '', $xml);
exit(0);

Původní odkaz v Merchant Centru jsme jednoduše nahradili odkazem na náš vlastní web: www.domena.cz/?f=url_na_puvodni_feed a vše hned fungovalo.

Méně výkonné hostingy mohou mít problém s feedy o mnoha produktech, i ten náš ale zvládá zpracovat feedy do 1000 položek pod 1s. Vzhledem k frekvenci stahování jedenkrát denně to nepředstavuje žádnou zátěž.