Dotaz: Limity mailserveru

[jan.rok]

Dobrý den,

rád bych znal názory zkušenějších na následující situaci:

Pár let provozuju na Ubuntu Serveru 18.04 LTS Postfix+Dovecot+antivir+antispam pro 30 uživatelů. Jako IMAP klient je používán Outlook 2016/19. Nyní je v systému asi 800 tisíc mailů, celkem asi 250 GB dat. Server je DELL s Xeon s 16 GB a dvěma 1 TB disky v HW RAID1, používám ext4. Server provoz zvládá bez problémů (jak co do vytížení CPU i RAM).

Uživatelé si však stěžují, že práce v Outlooku je pomalá. Přičítám to tomu, že program pracuje s velkým objemem dat, která musí Outlook zpracovat (uživatelé mají mailboxy o velikosti třeba i 20-30 GB, extrém je 90 GB). Synchronizace dat mezi serverem a PC taky chvilu trvá.

Můj návrh na řešení je použití webmailu, kde by "zamrzání" hrozit nemělo. Je nějaké jiné technické řešení, které použít. Jsem bohužel limitován jak výkonem serveru (na nový není a myslím, že ani to není potřeba), tak i organizační stránkou věci, kdy se uživatelé nechtějí velkých objemů pošty vzdát. Spíš se zde ptám proto, zda není nějaký problém ve zvoleném řešení (jiná distribuce, jiný souborový systém, nějaké zásadní opomenutí v nastavení). Procházel jsem logy na serveru, ale nic zvláštního jsem nenašel. RAID je taky ok.

Díky za názor. JR

Odpovědi

[MP]

Jakym zpusobem jsou maily ulozene? Jestli maildir, maji uzivatele obrovska mnozstvi souboru per slozka?

Jake jsou IOPS serveru pri synchronizaci atd? Ty disky jsou HDD ci SSD?

Kolik CPU ma server k dispozici? Jaky je vliv antispam/antiviru na zatez?

[jan.rok]

Ano, maildir - co mail, to soubor.

Disky jsou HDD SAS 10000 otáček. CPU je jeden, ale vliv antispamu/antiviru je minimální. Výkon málokdy přeleze 10 %. IOPS jsem neměřil, zkusím se na to podívat. Je to na gigabitové síti.

[jan.rok]

~$ iostat
Linux 4.15.0-112-generic (mail)         09/09/2020      _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.85    0.14    0.54    3.58    0.00   93.89

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
loop0             0.00         0.00         0.00          5          0
sda              73.23      3012.43       246.52 4064397131  332601025
sdb              48.16      2223.81       246.51 3000385967  332600245
md126           110.30      2341.62       246.77 3159341944  332941581
sdc               1.01         8.37       534.95   11298685  721755008

[Jendа]

Já teda tohle nikdy neviděl, ale jestli "tps" je počet seeků za sekundu, tak 50 je na rotační disk už docela vysoká zátěž, a 110 na celý RAID je taky asi dost.

Hnijou ti procesy poštovního serveru ve stavu "D"? Je tvůj imap server multithreadový, resp. prostě aby to umělo posílat do disku víc požadavků současně? (jádro/radič/disk si je pomocí NCQ přeskupí a bude to rychlejší)

Terové SSD stojí pár korun, nechceš upgradovat?

[R]

1TB a 10K nejako nesedi dokopy. Pokial viem, tak 10K a 15K disky sa nerobia v "desktopovych" velkostiach (napr. 1 TB), ale v "serverovych" - napr. 900GB, 1.2TB.

Dalej tvrdis, ze tam mas HW RAID - co je potom md126?

Mam server, kde je asi 2 TB mailov (500 kont). Je tam 10ks 600GB 15K diskov v HW RAID1 (PERC H730 s 1GB cache), server ma 32GB RAM (28GB z nej Linux pouziva ako cache). Tiez pouzivam ext4 a maildir, Debian, Postfix, Dovecot, Spamassassin, Clamav, SOLR, Horde.

Najvacsi mailbox ma takmer 80 GB, v Inboxe ma 90 tisic mailov. Nepocul som, ze by sa niekto stazoval na vykon. Bezi to asi 3 roky.

[Robert Kupka]

U mna 2 virtualne CPU jadra (Xeon 2.6 GHz), 4GB RAM, ext4 na RAID1 diskoch (klasicke 7200ot), kazda zlozka je jeden adresar, kazdy email je 1 subor. SW je Postfix + cyrus-imapd, Amavisd, Clamd+Spamassassin. Mam uzivatelov aj s 10000 mailami v schranke. Momentalne 674 Uzivatelov..., nestazuje sa nikto, okrem uzivatelov Outlook 2016/2019. Myslim, ze problem je prave v Outlooku. Posledny dobry Outlook ako IMAP klient bol outlook 2007. Od 2013 vyssie je to dost zlé. Mam nasadeny aj Webmail Squirrelmail na PHP 5.3, a Roundcube na PHP 7. Roundcube hodne zrychlil po prechode z PHP 5.3 na PHP 7. Pracuje sa s nim daleko rychlejsie, ako s Outlookom.

V kazdom pripade.... RAM na servri pomoze prave v cachovani inode struktur, 16GB je podla mna bohate dost.

[jan.rok]

Já mám extrémního 1 uživatele s 212 000 maily ve schránce. Je to jeden ze stěžovatelů. Zvláštní ale je to, že pokud se připojí zvenčí přes VPN, tak v Outlooku tento problém nemá. Z toho mi vyplývá, že problém bude asi někde ve vnitřní LAN, nějaký vadný switch nebo tak.

[Max]

A nebo se z venčí připojuje, když není peak na serveru? Tzn. večerní hodiny apod. To by pak ukazovalo, že nestíhají disky na serveru.
Zdar Max

[Max]

Mají klienti SSD disky v počítačích? Protože kombinace Win(obzvláště Win10) + Outlook s tak velkými mailboxy je pro rotačák smrt, tzn., že slabé místo by v takovém případě bylo minimálně na klientech.
Zdar Max

[jan.rok]

Je to tak půl na půl, ale stěžují si z obou skupin.

[Peter Golis]

A sťažujú si aj po dokončení replikácie pošty na lokál (cache) a následnému ukončeniu indexácie emailov?

[jan.rok]

Ano, i potom. Typicky při přechodu z doručené do odeslané pošty Outlook jakoby zamrzá.

[j]

Hele odpoved je primitivne trivialni... zrus ten utlouk. Ten s maily pracovat neumi vubec, a jeste hur na imapu.

Potiz je totiz v tom, ze zcela bez ohledu na to jak (tzn i kdybys mel exchange) si utlouk vsechny maily nasosa do lokalniho velesouboru (na exch se to da omezit a prestanou ti fungovat jiny veci), a jakmile to prekroci nejakych 20G, tak se z toho zesere.

Ten HW bez potizi a s prstem v nose musi zvladat tisice klientu.

Otestuj trebas em klienta, nebo tb oba imapem budou fungovat mnohem lip. Webmail neni na kazdodeni praci idealni reseni.

---

Dete s tim guuglem dopice!

[Max]

Není pravda, jsi asi tak o 13 let zaspal dobu. Limit 20GB na pst soubor byl kdysi kdysi dávno (Outlook 2007 a starší). Navíc ten limit nebyl hardcoded a šel zvětšit přes registry. Dnes navíc outlooky pst nepoužívají pro produkční data (jen pro archivní), pro produkční používají ost file a ten má základní base na 50GB a není problém i více. Ofiko info viz How to configure the size limit for both (.pst) and (.ost) files in Outlook.

U nás v jobu jedeme běžně 30GB i více a no problemo.
S imapem existují problémy v případě, že uživatel vytváří mega moc podsložek. To pak má outlook problém syncovat a i pracovat v tom. Ofiko limit od MS je max 500 složek. Máme lidi, co mají 1200 podsložek a ještě fungují, ale přes MAPI, nikoli imap. Když je imap a trochu více podsložek, outlook jde do kolen. Pokud má outlook doručenou, odeslanou, spam a tři další složky, tak s imapem problém nemívá.
Zdar Max

[Heron]

má základní base na 50GB

Ofiko limit od MS je max 500 složek.

Jako ... WTF? Kdo navrhuje datové struktury s takto divnými limity? Jako normální úložiště mají limity něco jako 2^64 * velikost bloku, tj dané použitými datovými typy, které dávají smysl. Ale 50GB? 500 složek? What?

Pokud má outlook doručenou, odeslanou, spam a tři další složky, tak s imapem problém nemívá.

Super. 6 složek musí stačit každému.

[Max]

Takhle, MS limit je větší, ale nad 500ks MS varuje, že může výkon klesat.
Těch 50GB je jen umělý sw limit, který jde změnit. Důvod takto nastaveného limitu neznám, možná tím chtějí uživatele varovat, aby po sobě uklízeli a nedošlo k výkonnostním problémům.
Pokud jde o imap, tak vím, že 30 podsložek může být problém, občas nějaká zmizne z odebírání a člověk jí musí znovu přidat, nebo se blbě syncuje atd. Prostě nic světoborného. Když jede člověk základ a pár podsložek, je to ok. Tak jsem to aspoň vypozoroval u větších mailboxů.
Zdar Max

[j]

Jasne, zaspal sem dobu tak, ze s tim, zjevne narozdil od tebe, jsem nucen denne delat.

Prave tragickej vykon utlouka sme resili tak, ze sme omezili lokalni cache. Coz ale vede k tomu, ze se lidi na sekundarnich mboxech ke starsim mailum NEDOSTANOU. Jednoduse proto, ze tam neni ten debilni link "dalsi ze serveru". A je to vlastnost (jak jinak) utlouka cca od verze 2k13.

Sekundarni duvod byl pak samo ten, ze je fakt uzasny, kdyz na kazdym stroji ma kazdej uzivatel svych 50GB, takze v ramci firmy maily jednoho uzivatele zabiraj klidne 500GB. Vubec nej je tohle na TSku, kam se prihlasuje cela firma. To aby clovek poridil extra pole jen kvuli tomu.

Utlouk s imapem fungovat neumi zcela libovolnym zpusobem jakej si kdo (ne)dokaze predstavit.

Utlouk totiz NEUMI mailovat VUBEC a to ani s exchange. Moh bych na to tema napsat tlustou knizku, ale jen tak pro tu rit, zrus mailbox a zaloz trebas skupinu se stejnou adresou (nebo opacne, to je fuk). A ses v pici, protoze cely firme bude utlouk tvrdit, ze ten mail neexistuje. Protoze ti curaci z M$ neposilaj mail na mailovou adresu, ale na nejaky uuid, ktery si utlouk ulozi. Takze prijemnou zabavu s obihanim vsech uzivatelu a resenim.

Nebo ... chmm co trebas vic mailboxu ze kterych user muze odesilat? Cekal bys, ze se odeslanej mail flakne do toho, ze kteryho byl odeslanej? No tak to bys nesmel bejt u M$ a pouzivat utlouk.

---

Dete s tim guuglem dopice

[Max]

Asi bude primární problém v adminovi ve firmě, kde pracuješ. Já spravuji cca 600 uživatelů s Outlookem. Většina jede proti Exchange a nemálo lidí má více mailboxů v jednom outlook profilu a není problém, chová se to regulérně (Outlook 2010SP1 a vyšší), jen to nastavení není z pohledu admina Exchange moc user friendly (dělá se přes powershell, takže klikací admini mají problém).
Pokud jde o TS, tak tam u outlooků nemáme nastavenou lokální cache, takže s místem opravdu problém není a s výkonem také ne.
Pokud jde o Exchange, tak teď jsme asi na 3TB? Už nevím. Ale máme tak málo kvůli tomu, že na uživatele trochu tlačíme, aby si uklízeli, nebo vytvářeli lokální pst archivy (pro některé je to jednodušší, než lézt do archivačního systému). Máme totiž emailový archivační systémy (GFI Archiver i MailStore, aktuálně je v archivu přes 55 mega mailů), takže se snažíme, aby v produkci bylo co nejméně dat. Nikdo tedy o emaily nepřijde a vždy jde v klidu dohledat cokoli. Lidí s velkým mailboxem je ale i přes to hodně. 200k mailů v jednom mailboxu nebývá problém. Největší mailbox má přes 2mega mailů (používá se jen přes webmail).

Pak spravuji ještě další systém, KerioConnect, kde uživatelé vyžadují Outlook, takže do něj je potřeba connector. Celkově je to méně výkonné řešení než Exchange+Outlook, ale po přechodu na ssd u uživatelů problém také není (kerio connector má lokální fdb). A tito uživatelé mají divný způsob práce, třeba 20 lidí má ve svém outlook profilu svůj mailbox + 10 dalších společných. A každý společný mailbox má 5-50GB velikost. A no problemo, resp. jediný problém je, když by měl mít někdo přístup jak do Exchange, tak do Keria, tam musí být jeden účet přes imap a druhý nativně. Pokud se použíje pro exchange mapi a pro kerio connector (emulace mapi), chová se to pak neregulérně.

Problém u vás tedy bude asi někde u nějakého admina.
Zdar Max

[j]

Jinak receno, zase zvanis zcela z cesty.

S vypnutou cache prestanou totiz fungovat zase jiny veci. Coz bys vedel, kdybys o tom neco vedel.

"že na uživatele trochu tlačíme, aby si uklízeli, nebo vytvářeli lokální pst archivy"

Jo, to je dalsi zuzo funcionalita, uz si to zkousel nejak centralne nastavit? Ono to nejde ze? Teda nijak normalne, ze? A dokonce ti to vynada (se divim ze JEN vynada) ze ten archiv teda jako rozhodne nemas davat na sitovej disk, ze?

Ale jo, muzes pouzivat archivaci na exchange ... to prece archivovat umi, ze? Jen si k tomu musis koupit opice v enterprise verzi, aby ten archiv byl videt z utlouka.

Mimochodem, on se exch da nastavovat nejak jinak nez z PS? Ze sem si nestacil vsimnout. Teda ... "da". Fakt miluju hlasky na tema ze objekt je jinyho nez ocekavanyho typu. Tam kde v tuxovi napisu pajpu na pul radky tak abych psal kilometrovou konverzi mailovy adresy aby byl spokojenej.

Jup a abych nezapomel, protoze ses ucite ten nelepsi admin na planete, tak ocekavam reseni (a jo, umim si poradit a usery sem to naucil, ale schvalne nebudu psat jak)

https://office365.uservoice.com/forums/264636-general/suggestions/19243423-cached-exchange-mode-restore-the-ability-to-view

---

Dete s tim guuglem dopice!

[Max]

Hele, ty jsi tu jedinej, kdo tu brečí, že má problémy. Když ti napíšu, že všechny tebou popsaný problémy jsme vyřešili/nemáme a no problemo, tak ty mi tu budeš tvrdit, že ne.
Navíc nevím, odkud bereš, že by uživatelé měli mít pst na síťovém disku. Ani nevím, proč by je tam mít měli. Jasně jsem napsal, že používáme archivační systémy, takže pst fakt neřešíme.
Archiv v podání Exchange je jen trapná alternativa pro pst, není to žádná alternativa pro archivační systémy jako je GFI MailArchiver nebo MailStore apod. Zkus si dostudovat, co jsou to archivační systémy a jaké mají fce, pak pochopíš, o co jde .
Jak už jsem napsal, sdílíme více mailboxů a uživatelé opravdu nemají problém s tím, že když odpoví, tak se ta odpověď uloží do jiného mailboxu. To fakt ne. Problém je ve vašem adminovi, jak už jsem napsal, protože vám zjevně nastavuje delegaci, která se takto chová. My delegace nepoužíváme, jsou nedostatečné, používáme sdílení celých mailboxů.
Jinak nikdo tady netvrdí, že jsem nějakej super admin, já jen tvrdím, že váš admin má nějaké zjevné nedostatky.
Pokud jde o ten link, tak ten mně fakt netrápí, protože jak už jsem psal, my nepoužíváme delegace, ale sdílíme celé mailboxy. To znamená, že uživatel má v outlook profilu oba mailboxy plnohodnotně připojené (podpora začala být od Outlooku 2010 SP1), do obou se samozřejmě ověřuje pod svým/stejným uživatelem. Funguje to ok a není problém s ničím. Takto některé týmy operují se společnou schránkou a všichni vidí doručenou i odeslanou a nikdo nemá problém.
Zdar Max

[Heron]

Já si k vám někdy musím zajet na exkursi. Už ty technologie ani nestačím počítat. Komerční panoptikum.

Máme totiž emailový archivační systémy (GFI Archiver i MailStore, aktuálně je v archivu přes 55 mega mailů), takže se snažíme, aby v produkci bylo co nejméně dat.

Něco podobného jsem elegantně vyřešil levnou zadní. Dovecot jen jako IMAP, emaily ukládat do mdbox (to k vůli razantnímu snížení počtu souborů) a zfs dataset s kompresí gzip-9. Jednoduché, funkční, zdarma. Na disku to zabírá minimum místa (až bude zstd, bude veseleji).

Uživatel má připojen tento archiv a tam si snadno může přeházet emaily. Dokonce tam může mít víc než 6 složek.

[Max]

Já u tebe byl relativně nedávno, škoda, že vždy jen projíždím bez volného času :-/.
Jinak ano, jde to samozřejmě řešit imap serverem s read only přístupem. Já toto řešení nevybíral a ani nenasazoval, i když to nasazování přecijen nakonec na mně padlo (kolega to nakonec nedal a řešil jsem s tím jen samé problémy). Dalo by se říci, že to řešení nenávidím, ale teď už aspoň funguje :). Nejvtipnější je, že změnili licenční politiku, takže když přestaneš platit, tak se ten sw zabejčí a nepustí tě k mailům :D. Jo a sice podporuje firebird databáze, ale jen pro malé nasazení, jinak vyžaduje MSSQL, docela další pálka :).
MailStore mi přijde lepší, podle mně je tam lepší vývoj, lepší licenční politiky, lepší porpojení s outlookem a s firebird db si vystačí a s výkonem nemá problém, aspoň to tak vypadá.
Jinak to samozřejmě nabízí různé možnosti indexace, správu ACL, řešení smazaných uživatelů, web ksicht, rozšíření do outlooku, reporting (analýzu mailů, trasování kdo kolik co a jak posílá atd.). Reálně hafec blbostí, které člověk reálně nepotřebuje :D.
Zdar Max

[Heron]

Nejvtipnější je, že změnili licenční politiku, takže když přestaneš platit, tak se ten sw zabejčí a nepustí tě k mailům :D. Jo a sice podporuje firebird databáze, ale jen pro malé nasazení, jinak vyžaduje MSSQL, docela další pálka :).

Není nad to si platit své vězení, bachaře a kata.

Reálně hafec blbostí, které člověk reálně nepotřebuje :D.

Ano, to lze říct o libovolném komerčním řešení a pochopil jsem to už dávno. To vždycky kolega přijel z nějaké nalejvárny (někdy se tomu říká snídaně, někdy konference, někdy "přátelské" posezení ve sklípku) a potom tvrdil, jak to nutně musíme nasadit. Nakonec vyšlo najevo, že nic z toho není potřeba a všechno co potřeba je už nabízí OSS.

[Madmucho]

Zkusil bych ponížit velikost souborů v jedné složce mám svou zkušenost že pokud je ve složce např inbox neroztřízeno nad 20 000 emailů už to má vliv na chod a synchronizaci(TB,Otlouk, i mobil), zkuste jim udělat foldery třeba per rok, jestli u těch problémových uživatelů nebude znát zlepšení.

[MMMMMMMMM]

Zkusil bych potunit ext4, pokud ještě není provedeno. ;) https://www.howtoforge.com/reducing-disk-io-by-mounting-partitions-with-noatime

[R]

To je dobra poznamka. noatime povazujem za samozrejmost - mam to nastavene na vsetkych Linuxoch - serveroch, desktopoch aj notebookoch.

[jan.rok]

Parametr noatime tam není, je tam relatime.

Celou diskusi sleduju se zájmem a mezitím jsem si jednotlivé Outlooky obešel a taky uživatele důkladně vyzpovídal.

Přes webmail nemá problém nikdo. Kromě dvou případů (zrovna zde jsou desítky tisíc mailů) nedělá problémy ani přecházení mezi složkami v Outlooku. Drtivá většina si ale stěžuje na pomalé/zamrzající/zcela nefunkční vyhledávání v mailech. Na to nějaké doporučené řešení existuje (obnova indexování apod.) Předpokládám ale, že to už se netýká serveru, ale je to věcí stanice.

K názorům "opustit Outlook": V jiných sítích s ním problémy nemám (ať už běží proti linuxovému řešení, proti Keriu nebo Exchange). Uživatelé mají i desítky podsložek. Jiná věc je, že někde se třeba rozhodli používat Thunderbird, ale ani tam problém není.

V mnou popisovanému problému došlo tak nějak "najednou" - dlouho byl klid, i když množství mailů bylo velké, ale teprve v poslední době začali uživatelé naříkat.

Primárně jsem chtěl dotazem ověřit, že taková množství pošty server může zvládnout. Protože jak už to bývá: když něco nefunguje, je to na adminovi "co jsi nám to sem dodal...".

[Petr Šobáň]

Pokud se to začalo dít najednou tak co se změnilo na serveru?

Nějaká aktualizace něčeho?

Pak taky může být chyba v HW co smart HDD poví není tam něco špatně, a co ten RAID zda tam nemůže být nějaká brzda.

Jinak další problém může být propustnost sítě, nezměnil se nějaký síťový prvek, nebo vadný nějaký kabel a síť chybuje?

[Max]

Outlook využívá k indexování Windows Search, který se mění s updatama Windows. Byly doby, kdy se hodně často rozbíjel. A to buď tak, že nevyhledával, nebo Windows Search zamrzal / vytěžoval CPU na 100%, nebo se vygeneroval 20GB index file, se kterým pak měl problém atd.
Na jednom dotyčném počítači doporučuji nejdříve zkusit totální clear indexeru (hloupý script, využívám externí nástroj SetACL pro převzetí oprávnění části registrů kvůli jejich smazání), outlook je před spuštěním nutné ukončit:

# create temp directory and copy tools to change perm in registry
mkdir C:\temp-scripts
C:\WINDOWS\system32\xcopy \\share\SetACL\64bit\SetACL.exe C:\temp-scripts\ /Y

# stop indexer and disable to prevent run again
Get-Service WSearch| Set-Service -StartupType Disabled
net stop "WSearch"

# Delete indexer database
del C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb

# Change perm for admins
c:
cd C:\temp-scripts
.\setacl.exe -on "HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\WorkingSetRules" -ot reg -rec yes -actn setowner -ownr "n:Administrators"
.\setacl.exe -on "HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\WorkingSetRules" -ot reg -rec yes -actn ace -ace "n:Administrators;p:full"

# Delete keys
reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\WorkingSetRules" /f

# Allow and run wsearch again
# Get-Service WSearch| Set-Service -StartupType AutomaticDelayedStart
Get-Service WSearch| Set-Service -StartupType Automatic
net start "WSearch"

# clear scripts
cd c:\
del C:\temp-scripts\SetACL.exe
rmdir C:\temp-scripts

Jinak můj názor na Outlook je takový, že jeho html editor je parádní, Thunderbird se v tomto ohledu nechytá. Také mi přijde, že UI má lepší latence oproti Thunderbirdu. Jinými slovy, z hlediska uživatelských fcí a přívětivosti k uživateli je Outlook na velmi dobré úrovni. Co tam pokulhává jsou občasné problémy s indexováním a ta né moc ideální podpora pro imap (problém se syncem stovek podsložek apod.). Jinak pro caldav/cardav už existuje OSS doplněk, takže toho s ním lze dost pokrýt.
Zdar Max

Nechápu, k čemu je v mailu potřeba nějaké html. Leda tak jako podpora šíření virů.

[Max]

Ke stylování emailu. Pro mně osobně je také přehlednější, když v rozsáhlém textu něco zvýrazním. Lidé pak běžně používají inline přílohy (vložené obrázky mezi textem) a různé zvýrazňování. Pak se také všichni snaží, aby jejich podpis vypadal dobře a bylo v něm i logo firmy atd.
Já v tom nijak velký problém nevidím.
Zdar Max

Názory se patrně různí. Ale co já znám, tak lidi neovládají formátování ani v programech (*)Office, které denně používají k vytváření nějakých rádoby líbivých textů, za které jsou placeni. Natož pak v poštovním programu, který je pouhým transportním prvkem.

[jan.rok]

Díky za nasměrování, na pondělní večer je naplánovaná údržba, kdy chci vytvořit všude nové indexy a ten skript se víc než hodí.

Osobně bych také považoval poštovní program pouze za transportní nástroj, ale uživatelé to vidí jinak a Outlook je pro ně tak nějak přívětivější.