Posílání pošty není složité ….

…. ale můžete to takové udělat.

To byla jedna z posledních slov Susan Bulloch, která měla první Jump Start přednášku na konferenci Admin 2006. A musím říci, že přednáška byla opravdu super, to pokud bych měl hodnotit jednou větou. Taková, ve které jsem se dozvěděl spoustu věcí, které jsem předtím buď nevěděl, nebo si nějak nezapamatoval. A jejich množství mě, upřímně řečeno, překvapilo. A ještě to celé prokládala vtípky, které občas byly opravdu dobré. A ještě jeden postřeh na začátek – lidé, kteří přišli do IBM z Lotusu, s tím zjevně pořád ještě nejsou úplně smíření. Což je trochu škoda, ale současně i neuvěřitelně zajímavé.

Tak co překvapilo, co jsem si rád zopakoval?

  • že pro spojení dvou LN serverů pro posílání pošty jsou potřeba dva dokumenty spojení – občas jsem někde viděl (a nikdy nepoužil) volbu Pull/Push, nicméně jsem netušil, že k ní musí být na protějším serveru dokument s volbou Push/Wait
  • že routing costs mohou narůst maximálně o jednu – tedy pokud máte jednu cestu, která stojí 1 a druhou, záložní, která stojí 10, tak k přepnutí na záložní nikdy nedojde. Záložní tak musí mít hodnotu 2, aby k přepnutí došlo, protože při přerušení cesty se náklady zvýší právě o jedna a nikdy víc
  • že když se posílá pošta mezi servery, tak se nejdřív spočte cesta s nejnižší cenou, poté, pokud je stejná cena, ta s nejmenším počtem hopů, pokud i to sedí tak se použije jméno serveru – to se jménem dříve v abecedě vyhrává
  • pokud někdo používá alternativní editor pošty, tak je to skvělé ve spojení s Outlookem, ale dopadá to opravdu špatně při příjmu v LN
  • že veškeré věci na nastavování, které spolu souvisí (a netýká se to jenom mailu) budou v Hannoveru sloučeny dohromady (a k tomu vtipně přidala, že pak tedy ta daná konfigurace bude mít 30 záložek, ale bude to na jednom místě)
  • že mailové schránky jsou menší, pokud se uživatelům nastaví, aby se to při odesílání každého mailu ptalo, zda ho chtějí uložit – hodněkrát si totiž uvědomí že to vlastně nepotřebují
  • že když pracuji v lokální poštovní schránce a mám nastavenou pravidelnou replikaci, tak se mi mail zreplikuje okamžitě po příchodu pošty na server. Toho jsem si sám několikrát všiml, ale nepřikládal tomu důležitost. Prý je to vlastnost, která přišla v 6.x.y, ale protože úplně nefungovala, tak ji nedali do dokumentace a pak už se na to nějak zapomnělo 🙂
  • že reply with internet style je skvělé na to, aby člověk viděl jak to přijde příjemci, pokud se zalámou řádky a mohl se na to připravit a email třeba trochu poupravit
  • že u volby Multilingual Internet Mail je nejlepší volbou UTF-8, protože se to nikdy neptá (ale občas to holt přijde jako rozsypaný čaj)
  • že pole pro nastavení internetové domény v dokumentu pracoviště skoro nikdo nepoužívá
  • že pokud je nastaveno vyhledávání příjemců na „Stop after first match“, tak se to zastaví při první shodě, která ale vůbec nemusí být v hlavní adresní knize
  • že by se na klientovi jako formát odchozí pošty mělo zapínat MIME, protože server potom nemá práci s konverzí mailu (a při konverzi dochází občas k tomu nepříjemnému zvětšování znaků)
  • že když uživatel zabloudí někam do hlubin nastavení (popravdě, ani já jsem v těch hlubinách ještě nikdy nebyl) tak se mu má říct „to je pro pokročilé uživatele, my to děláme jinak a lépe“. V Americe to prý na lidi zabírá
  • že emaily s vysokou prioritou (díky které se v inboxu zobrazí červený vykřičník) mohou být v některých zemích brány negativně, protože červená je špatná (osobně je beru negativně také, protože prioritu mailů si určuji já, nikoliv odesílatel). A také to, že kdyby email byl opravdu důležitý, tak by přeci odesílatel neměl čas na zaškrtávání této věci
  • že nastavení High Delivery Priority (tedy aby byly rychle doručeny, nikoliv aby zobrazovaly vykřičníky) jde na serveru zakázat (konfigurační dokument, RouterSMTP Advanced ControlsIgnore message priority) a hlavně že díky tomu dojde k odeslání všech mailů, které zrovna čekají na odeslání, nikoliv pouze toho jediného
  • že volba „Stamp message with a Please Reply By“ v možnostech doručení u emailu rovnou příjemci i vytvoří úkol v úkolech (což jsem nikdy netušil, ale finta je to skvělá – ještě kdyby se po odpovědi rovnou označil za vyřešený)
  • že by se minimálně měly používat dva mail.boxy, protože to nezatíží server a když se jeden poškodí tak to nevadí. A že další se mají přidat, pokud hodnota Show Stat Mail.box.* ukazuje pořád více jak 2% konfliktů přístupu (technote 1148438)
  • že v konfiguračním dokumentu je pole Smart host na „dejte tam svůj Exchange server a veškeré nedoručené spamy budou končit tam :))“
  • že se nemá nastavovat počet vláken pro přenos mailů, protože Domino ho počítá hodně dobře a člověk by tím mohl něco znefunkčnit
  • že mezi dvěmi doménami se přenášejí maily vždy pouze po jednom vlákně, pokud jich chce člověk víc, tak musí do notes.ini přidat RouterAllowConcurrentXFERToAll=1
  • že low priority maily se mají používat opatrně, pokud je firma přes více časových pásem (což mi osobně předtím vůbec nedošlo, že ten email díky tomu může klidně putovat několik dní – a přihlašte se vy, kterým to došlo :)))
  • že když se nepovede spojení se serverem, tak router čeká před dalším pokusem definovanou dobu (konfigurační dokumentRouterSMTP Advanced ControlsInitial transfer retry interval), před dalším pokusem její dvojnásobek a před každou další trojnásobek a to celé, dokud zprávě nevyprší time-out, který je standardně 24 hodin – poté se pošle nedoručenka. Pro změnu standardu se opět použije notes.ini – MailTimeout=počet dnů, případně MailTimoutMinutes, pokud je hodnota menší nebo rovna 1440 minutám
  • že pokud má člověk 20 – 30% výkonu CPU navíc, tak si může klidně zapnout Mail Tracking, jinak by to měl zapínat pouze v případě problémů a když něco hledá
  • že v konfiguračním dokumentu v poli Address lookup by měla být hodnota Fullname only, protože díky tomu nejde tak snadno odhadnout adresa uživatele (variant je výrazně méně)
  • že pokud je disclaimer přidán až na serveru, tak podepsané zprávy příjemci půjdou přečíst, ale nebudou podepsané a šifrované zprávy nepůjdou dešifrovat ani přečíst – člověk skoro přemýšlí, proč je tedy možnost disclaimer přidávat i k podepsaným a zašifrovaným zprávám
  • že volba Cluster failover v konfiguračním dokumentu nastavená na „for all transfers in this domain“ není většinou potřeba – což je zajímavé, ale nedozvěděli jsme se proč 🙁

A to bylo vše – celá ta smršť informací trvala tři hodiny a měla 130 slidů. Úctyhodný výkon, zvláště ta rychlost na konci 🙂 Teď si to jenom celé zapamatovat a něco si z toho vzít.

Leave a Reply