Abeceda e-mail managementu

To je totiž příliš rozsáhlé téma zahrnující vše od volby desktopového klienta elektronické pošty až po konfiguraci serveru. Místo toho pomůže zkalibrovat vaše očekávání, identifikuje klíčové otázky e-mail managementu a naučí vás základy, které je dobré znát.

Jaké jsou hlavní mylné představy o odchozím e-mailu?

Ačkoli každý v podnikání závisí na e-mailu, nejde o spolehlivý doručovací mechanizmus. Nic ve specifikacích elektronické pošty nezaručuje, že bude zpráva doručena včas. A vlastně nemáte ani jistotu, že bude doručena vůbec.

Specifikace pro internetové protokoly schválené organizací Internet Engineering Task Force (IETF) jsou nazývány Request for Comment (RFC). Elektronická pošta se po internetu pohybuje téměř bezvýhradně prostřednictvím protokolu SMTP (Simple Mail Transport Protocol). SMTP přitom není nativně zabezpečený, garantovaný, stopovatelný ani certifikovaný.

Spoléhat se na doručení e-mailu není nejlepší nápad. Když nedojde na místo určení, je obvyklé obviňovat z toho síťové a e-mailové administrátory, jakoby neměli nic jiného na práci a schválně sabotovali vaše snahy. Specifikace e-mailu nevyžadují a ani nemohou vyžadovat a zaručit, že se zpráva objeví ve schránce adresáta pár nanosekund po odeslání (jak by si asi většina z nás přála). Nejde přitom o selhání specifikací, ale o potvrzení výzev, jimž musí čelit každá z fronty odesílaných zpráv. Přerušená optická vlákna, mrtvé mail servery, zauzlené směrovací smyčky (routing loops), šedé listiny (graylisty), zpoždění filtrů, blacklisty a další nadělení, jež mohou putující e-mail zdržet či zcela „zabít". Zpráva elektronické pošty, která na místo určení dorazí tři dny po odeslání, by tak nějak přesně odpovídala užitým specifikacím.

V rámci organizace můžete e-mail učinit vysoce dostupným, spolehlivým a auditovatelným - pokud tedy v putování k cíli hodláte investovat dostatek lidských a technických zdrojů. Žádná snaha a žádné vynaložené náklady vám ovšem nemohou zaručit, aby byl externí e-mail srovnatelný s tím podnikovým. To je částečně také záměrem. Některé funkce korporátních e-mailových systémů (jako jsou „out of office" upozornění, potvrzenky o přečtení nebo vyhledávání a verifikace adres) totiž doprovází obavy o jejich zneužití. Aby tedy internetový e-mail fungoval stejně jako ten korporátní, je třeba v případě nutnosti postupovat individuálně prostřednictvím speciálních dohod s konkrétními externími partnery. Všechny pokusy o zajištění vyšší spolehlivosti SMTP (například přidáním tzv. return receipt, tedy oznámení o přijetí adresátem) buďto ztroskotaly hned, nebo byly staženy kvůli jejich masivnímu zneužívání primárně notorickými spammery. Zapamatujte si tedy, že e-mail není garantovaný a vaši administrátoři elektronické pošty nejsou kouzelníky, aby to mohli změnit.

Několik krátkých doporučení:

Pokud zpráva nedospěje k zamýšlenému adresátovi, nejde vždy o selhání technologie. Odesílání e-mailu je jako vytáčení telefonního čísla - ani zde, pokud v adrese uděláte překlep, e-mail na zamýšlené místo zkrátka nedojde. Přečtěte si zprávy ze serveru, než se odhodláte ke stížnostem.

E-mail nikdy není zcela privátní. Pokud chcete jeho obsah udržet v naprosté tajnosti, nejprve zašifrujte soubor se zprávou a pak jej odešlete ve formě přílohy. E-mailový administrátor totiž může například procházet zprávy elektronické pošty ve frontě k odeslání, třeba ve snaze přijít na zdroj aktuálního problému na firemním serveru. Pokud je zpráva v plain textu, nebude zkrátka nikdy tajná.

Jaké jsou hlavní mylné představy o příchozím e-mailu?

Koncoví uživatelé jsou často zmateni z toho, že jim ve schránce přistane zpráva, ačkoli jejich jméno nefiguruje v políčku adresátů. Jedním z vysvětlení může být, že jsou udáni v kolonce pro slepou kopii (bcc). Ve skutečnosti nejsou viditelné adresy v „To:" a „Cc:" nutně ve vztahu s faktickým seznamem adresátů. E-mailoví klienti tam umísťují adresy příjemců pouze ze zvyku.

Jedinou věcí, na níž kvůli směrování pohledu serveru záleží, je „obálka" (envelope) e-mailu. Toto lze rozvést na jednoduchém příkladu: Vezměte si kus papíru a napište na něj jakékoli jméno (kupříkladu Šárka). Vložte poté papír do obálky, na níž napíšete jméno jiné (třeba Hana). Nezáleží na tom, co je v obálce, takováto zpráva dojde vždy k Hance - ve skutečnosti a analogicky také na internetu.

Toho často zneužívají spammeři, kteří do hlavičky e-mailu na pozici adresátů rozhodně nezapisují kompletní seznam recipientů. Stejně tak mají prospěch z toho, že lze poměrně jednoduše upravit i adresu odesílatele, která se bude zobrazovat u adresáta. Systém totiž nepovažuje za směrodatná data udaná v hlavičce e-mailu v políčku „od:" (from:), ale hledí pouze na parametr „mail from" (který lze také zfalšovat). Spammer tedy upraví jak políčko „od:", tak parametr „mail from" (do obou obyčejně vloží adresu dalších nic netušících obětí) a zpráva pak může vypadat zcela regulérně.

Další běžnou starostí uživatelů je, že dostávají oznámení o nedoručený zprávách, které vůbec neposlali. I zde je koncový uživatel postaven do role oběti. Tato aktivita je totiž téměř jistě výsledkem činnosti infikovaného počítače. Mnohé viry a další malwary generují e-maily (nezřídka jde o spam). Jedním ze způsobů maskování je pak zfalšování zpáteční adresy použitím e-mailu nevinné třetí strany. Pokud zpráva nedorazí na místo určení, je chybové hlášené zasláno na onu zfalšovanou adresu patřící klasickému uživateli.

Bohužel zde není způsob, jak by se proti tomuto falšování mohl uživatel či e-mailový administrátor bránit. Vzhledem ke způsobu, jakým jsou navrženy standardy přenosových protokolů pro elektronickou poštu, je vlastně nemožné mu předejít a jen zřídkakdy se podaří alespoň identifikovat jeho strůjce. Hlavička e-mailu o nedoručení zprávy a jeho obsah mohou posloužit jako vodítka, zde však záleží na systému, který generuje chybová hlášení (respektive na úplnosti těchto chybových hlášení).

Čím se řídit při výběru mail serveru a jak zvolit vhodné správce?

Úspěšný e-mailový systém vyžaduje důkladně vybalancované investice v technickém vybavení a lidské zdroje. Mnohé organizace se neobejdou ani bez outsourcování některých prvků. Důležité je zmínit, že neexistuje jediné „krabicové" řešení vyhovující každému.

IT oddělení se možná bude cítit lépe využívajíc proprietární software pro mission-critical aplikace (tou e-mail bezesporu je, jen si představte, kdyby ve vaší firmě nefungoval třeba 48 hodin). V této oblasti však naplno ve všech směrech prorazila také open source řešení. Chce-li váš administrátor používat open source mail server, pak vězte, že vysoký podíl vysoce kvalitních e-mailových systémů je postaven na unixových či linuxových OS a open source softwaru. Někteří administrátoři dokonce o proprietárních řešeních mluví v značně pejorativním smyslu, ale co člověk, to názor...

Celkem vzato však klíčovým rozhodnutím není ani tak volba softwaru pro mailový server, jako spíše výběr člověka, který jej bude spravovat. Až příliš často, a to platí hlavně pro segment SMB, není administrace e-mailu považována za klasickou práci na HPP. Místo toho je zodpovědnost za elektronickou poštu zkrátka delegována na někoho s „nějakými" technickými znalostmi. Kvalitní správa mail serveru však vyžaduje mnohem více pozornosti a expertizy, než se mnozí domnívají. Jde o ohromnou změnu oproti stavu před dvaceti lety, kdy byla administrace elektronické pošty relativně snadná a organizace se nemusely obávat spamů, virů a, což je rostoucím problémem, paradoxně také dopadu neodborných pokusů o ochranu před těmito hrozbami.

Obdobně jako může líný pracovník pošty způsobit v obálkách naprostý chaos, není vyloučeno, že vystresovaný administrátor nenapáchá škody v oblasti e-mailu. Aby elektronická pošta fungovala, jak má, musejí pracovat a být správně nastaveny také její komponenty - DNS, směrování na síti, otevřené porty na příchozím mail serveru... Administrátora proto vybírejte s rozmyslem a pokud se vám nevyplatí nasadit někoho z vlastních řad, správu e-mailu zkrátka outsourcujte.

Váš e-mailový administrátor by se měl a rozumět minimálně RFC 2821 (Simple Mail Transfer Protocol) a RFC 2822 (Internet Message Format), vyznat se v nich a živě se zajímat o problematiku ochrany proti spamu (například prostřednictvím účasti v dedikovaných diskuzích typu Spam-L). Adeptů na pozici správce elektronické pošty se tedy hned zpočátku zeptejte, co je RFC 2821. Pokud neví, nebudou pro tuhle práci těmi pravými.

Co internetové standardy?

Do kolonky příjemců ani do kopie nevpisujte příliš mnoho adresátů. Narušujete tím soukromí lidí, jejichž adresy byste takto zveřejnili. Někdy také moc dlouhý seznam adresátů dělá problémy e-mailovým klientům. Pokud vaši uživatelé často posílají zprávy mnoha adresátům, požádejte je, aby do kolonky příjemce zapsali vlastní adresu a ostatní umístili na slepou kopii (Bcc:). U některých e-mailových klientů bude IT oddělení nuceno udělat úpravy, aby byla kolonka pro slepou kopii k dispozici.

Rozhodněte, jaké množství osobní korespondence je přijatelné na pracovním účtu elektronické pošty. V určitých případech je na místě zvážit, zda uživatelům nepřikázat, aby svou osobní korespondenci vyřizovali přes osobní e-mailový účet, čímž byste rozhodně ulehčili svým správcům elektronické pošty. V tom případě je však třeba zajistit, aby uživatelé na své osobní účty mohli z práce přistupovat (jinak budou váš zákaz pravděpodobně ignorovat).

Nezacházejte s elektronickou poštou jako se systémem pro přenos souborů. Pokud si vaši uživatelé vyměňují velké soubory, měli byste na síti pro tento účel nastavit sdílené adresáře, zprovoznit FTP server, využívat on-line úschovny nebo se uchýlit k jinému, vhodnějšímu médiu. Nařiďte správci elektronické pošty, aby omezil (v rozumné míře například 10 -15Mb pro odchozí a 15-20Mb pro příchozí zprávy) maximální velikost příloh elektronické pošty. Pokud je to možné, nakonfigurujte e-mailové klienty, aby identifikovaly velikost zprávy před jejím odesláním.

Snažte se, aby uživatelé využívali plain text zprávy namísto HTML nebo rich textu. Mnozí pracovníci s radostí rozesílají barvité e-maily napsané různými fonty. Pravděpodobně se domnívají, že se pak jejich zprávy budou příjemcům lépe číst. To však bývá spíše výjimkou, navíc je zde problém technického rázu, neboť hrozí, že poštovní klient adresáta původní formátování zobrazí jinak, než bylo zamýšleno (občas do té míry, že je výsledek zcela nečitelný). Pokud je důležité zachovat layout a formátování, přiložte do e-mailu soubor ve formátu PDF. Využívání HTML namísto plain textu je pak kompromitující pro bezpečnost, neboť takový e-mail pak funguje jako webová stránka.