Jak je to s maily

joe - "...že funguje jak ty SMS"

Vyvedu Vás z omylu, ani SMS nemusí být spolehlivé. Je to teda už pár let, kdy jsem se snažil pomocí SMS uklidnit přítelkyni, že se mi nic vážnéhoho nestalo (měl jsem určitý problém a ona byla pracovně v nedaleké cizině). Na její opakované vyděšené dotazy jsem během 1/2 hodiny odeslal 4 uklidňující SMS. Všechny normálně odešly. Když přišel další dotaz proč neodpovídám, tak jsem jí zavolal a vysvětlil všechno "ústně". Všechny odeslané SMS došly zároveň až druhý den.

"A nechtělo by s tím něco dělat, reklamovat, chtít slevu, je to bordel."

Jakou slevu ? Vy za maily na Seznamu něco platíte?

Tak. tak.

Dnes to většinou chodí přímo.

To je svatá pravda, nejvíc to záleží na tom článku za displejeM/klávesnicí

@mesg To není pravda!

Tak to není ani v případě, kdy jako kanonýr doručuješ přímo na MX server příjemnce.

vibe2: Ty a ostaní co tvrdí, že e-maily a SMS nejsou okamžité asi nemáte s tím příliš zkušenosti a nevíte jak to funguje. Já když např. v bance zadám a odešlu platbu tak často mi do minuty nebo několika málo minut příjde e-mail s informací, že peníze byly odeslané. Stejně tak mi do několika sekund chodí z banky SMS s kodem pro přihlášení do IB nebo potvrzení platby atp.. Samozřejmě se občas stane, že vlivem nějaké chyby to příjde i za delší dobu nebo nepříjde vůbec, ale nestává se to běžně. Pokud tu chceš psát nějaké moudra tak by sis to mohl ověřit jak to je ve skutečnosti a nepsat tu pouze tvoje dojmy.

@2222 a ty jsi spravoval kolik mailserverů?

Já jich spravoval jen několik, ale myslím, že do toho, jak opravdu fungují, vidím poněkud líp, než jen na základě dojmů z pár rychle doručených mailů od banky.

gilhad: Nechtěl bych mít schránku na serveru který by jsi spravoval ty. Pokud jsi to opravdu dělal tak asi tak, že jsi tam ty e-maily asi záměrně zpomaloval. Žijeme ve 21 stoleti a roce 2023 kdy internet a servery už dávno pracuhjí docela rychle než jak tomu bylo např. před 20 léty. Ono není třeba spravovat servery a stačí trochu sledovat jak rychle dokážou chodit e-maily nejen z banky ale i s odpověďmi od různých lidí, úřadů, firem atp..

@2222: Na "mých" serverech maily běžně chodily v řádu sekund (právě proto, že teď už jsou počítače i linky rychlé). Ale ta technologie je prostě postavená tak, že se nedoručuje "okamžitě", ale počítá se s tím, že ke zdržení principiálně technologicky dochází (že to technologické zdržení může být (a bývá) tak krátké, že ho uživatel ani nepostřehne, je jiná pohádka) a protokol s tím od začátku počítá. Ale podle okolností to zdržení klidně můžou být i hodiny a dny a je to tak v pořádku. Dokonce se může stát, že k doručení opakovaně nedojde vůbec a opět s tím protokol počítá. Prostě to není navržené pro okamžité přenosy.

Že jsem běžně poslal email kolegovi ve vedlejší místnosti, zvednul se, šel za ním a když jsem otevřel dveře, tak mi rovnou začal odpovídat na první otázky z toho emailu, na tom principu fungování nemění absolutně nic.

A jenom k měřítkům - teď zrovna řeším, že něco nejde dělat okamžitě, takže se tam musí zavést protokol, který počítá s dávkovým doručováním, nepředvídatelnýma pauzama a dokáže se postarat o správné blokování zdrojů, aby příjemce, ani odesilatel, nemuseli čekat, když se něco nestíhá.

Zrovna v tomhle případě jde o to, že nemůžu zaručit správnou real-time reakci do 0.000 000 25s (ano, mluvíme o 4MHz ) a tak nastupuje dávkové zpracování, které je schopné fungovat i s libovolně dlouhýma lagama (a testuju to s lagama v řádu jednotlivých sekund a fungovalo by to i s lagama denníma, nebo ročníma, jen by to nebylo vůbec praktické). Ono to nakonec v praxi vyjde, že to jak odesilatel, tak příjemce pojedou buď plnou maximální rychlostí, nebo nebo jen o kousek pod ní, ale ano, v principu mi to stejně nezaručuje "okamžité" předání, ale jen "odložené".

A samozřejmě tady nejde o email, ale ten princip je naprosto stejný. (A ten, kdo na to zvenku kouká lidskýma očima a "prostě to pozoruje a má to celkem přesně odzkoušené" o tom, jestli to je "okamžité", nebo "odložené" a "nevyžaduje okamžitou odpověď", ten o tom ví houby.)

.

Takže uživatelé "mých" serverů byli naopak náramně spokojení, ale na vlastnostech používaných protokolů a technologií to nemění nic.

Dovolím si přidat svoji zkušenost. Píšete tady o pojmech okamžité, online, dávkové zpracování. Pracoval jsem dlouhá léta v autorizačním centru platebních karet. Servery dostávají požadavky, ty řadí do fronty a zpracovávají tak, jak stíhají. 360 dní v roce to běží tak, že požadavek zpracují okamžitě. Platíte v obchodě kartou, okamžitě dostanete odpověď, že platba je schválena. Ale je pár dní nebo hodin, kdy to tak není. Typický příklad je zlatá neděle před vánoci v době 13:00-17:00, v obchodech jedou všechny pokladny, požadavků je třeba 1000x více než běžně, platíte kartou, po 3 minutách dostanete požadavek na PIN, po dalších 3 minutách platba schválená. Lidi u pokladen nadávají. Přitom vše běží stále online. Samozřejmě by se dal postavit server, který by to stihnul rychleji, ale nikomu se nevyplatí taková investice, která by 360 dní nebyla téměř vůbec využitá a prodražila by poplatky za platby.

gilhad: Pokud podle tebe "zdržení klidně můžou být i hodiny a dny a je to tak v pořádku." tak to nevím co bych si o tobě měl myslet, ale nic dobrého mne nenapadá. K něčemu takovému dochází např. zde na této poradně, ale to je tím, že e-maily s upozorněním na novou odpověď tu zdejší admin z nějakých nekalých důvodů záměrně zdržuje a odesílá je s tak velkým zpožděním.

@2222 Třeba by sis o mě mohl pomyslet, že kromě snahy ty emaly doručit co nejrychleji, pokud to zrovna jde, mám i snahu dodržovat platné standardy (např. RFC 5321) a nezahazuju emaily zbytečně při prvním zaškobrtnutí.

.

4.5.4.1. Sending Strategy

The general model for an SMTP client is one or more processes that periodically attempt to transmit outgoing mail. In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information.

The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. It MAY be appropriate to set a shorter maximum number of retries for non- delivery notifications and equivalent error messages than for standard messages. The parameters to the retry algorithm MUST be configurable.

A client SHOULD keep a list of hosts it cannot reach and corresponding connection timeouts, rather than just retrying queued mail items.

Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours.

...

gilhad: Nějaké tebou předhazované standardy mne nezajímají. Pro mne je hlavní především realita tak jak to ve skutečnosti většinou je.

Jinými slovy - email je technologie, která říká "je hezké doručovat co nejdřív, ale když to nejde, tak je lepší to doručit o pár dní později, než vůbec".

Taky jsou technologie, které to vidí zcela opačně, jako třeba "jestli jsi nezvládnul dodat data do 0.000 000 25 sec, tak jsi TOTÁLNĚ SELHAL a NEZKOUŠEJ TO ZNOVU, jinak to zaručeně rozbiješ ještě víc".

---

Jak výše píše @petrm , tak v reálném světě je potřeba počítat s reálnýma podmínkama a s tím, že věci nejsou ideální.

Chápu, že tohle běžní uživatelé neřeší, když se stránka nenačte, tak ji reloadnou, když se počítač sekne, tak ho restartujou a když pak naběhne, tak je vlastně všechno v pořádku. A když ne, tak "se to rozbilo" a volají helpdesk (ale stejně netuší, co a jak jim tam uvnitř funguje a proč).

Když mám ale pod palcem stovky počítačů po celé republice a okolí, mnohé za nejrůznějšíma NATama a jinýma úkazama a u každého z nich mám soustavný monitoring, so se s ním děje, tak ten pohled na spolehlivost sítě (a techniky vůbec) mám naprosto jiný - že se problémy dějou průběžně furt je v těch logách prostě vidět.

Že jsem to nastavil tak, aby se to z problémů samo vzpamatovávalo a uživatel nemusel nic řešit (a jaké všechny protokoly a jaké všechny mechanizmy jsem na to použil) je jiná záležitost.

A že výsledek je ten, že když u jednoho zákazníka zednící z důvodu rekonstrukce budovy prostě vytáhli běžící počítač ze zásuvky, tak jsem to byl já, kdo o tom zákazníkovi řekl. A když to po měsíci zrekonstruovali a ten počítač zase zastrčili do zásuvky, tak naběhnul a začal okamžitě správně pracovat. A já to měl během necelé minuty v databázi a všech přehledech. A že si ten počítač sám stáhnul všechno, co se za ten měsíc změnilo, a přešel na nový režim bez sebemenšího zaškobrtnutí je taky moje práce (protože jsem to postavil na technologii, co sice běžně plánovala na milisekundy, ale zvládala i několikaleté výpadky a uměla updatovat za pochodu). A zákazník se to opět dozvěděl od nás, jeho zaměstnanci to nahlásili až druhý den.

@2222 "realita tak jak to je" je, že když to jde dobře, tak je email doručen velmi rychle, ale když jsou po cestě problémy (a problémy se v realitě prostě vyskytují), tak je email doručen později a pokud jde o problémy delšího ražení, tak to může být i o několik dnů.

A že aby to aspoň nějak fungovalo, tak tyhle standardy dodržují prakticky všichni hráči (už proto, že většina z nich používá nástroje psané právě podle těchto standardů).

Že tomu jakožto uživatel nerozumíš a jen máš nějaké dojmy z toho, jak rychle ti odpoví nějací člověci je jenom tvůj problém.

A zda bys chtěl mít maily na "mých" serverech záleží na tom, zda bys chtěl dostávat emaily tak rychle, jak je to jen možné a zároveň v případě nějaké poruchy pokud možno o žádné nepřijít.

Pokud ano, tak bys u mě byl spokojený.

Protože právě pomocí podobných standardů se řeší, aby protistrana ty emaly vůbec byla ochotna přijmout, nebo přeposlat a taky to, že i když někde vylítnou pojistky, spadne síť, pako blbě nakonfiguruje NAT a půl podniku je bez připojení, kopáči překopnou datový kabel ... tak ti stejně ty emaily nakonec nějak dojdou.

(Jo, všechno tohle se v realitě stalo v té síti - a většina vícekrát a se vším si to poradilo)

gilhad: Už jsi docela dost trapný s těmi tvými vědeckými teoriemi a vychvalováním sám sebe. Mluví se, že samochvála smrdí, ale ta tvoje smrdí docela dost hodně. Ano nic není tak ideální aby se nemohlo občas pokazit nebo nějak chybovat. Podle několika % poruchovosti ale nemůžeš hodnotit celek, že je to tak běžné všude a vždy za všech okolnosti. Vůbec nebereš a přímo odmítáš realitu která je nejlepším a nejspolehlivějším ukazatelem jak co spolehlivě funguje. Bereš v úvahu úpouze tvoji zmatenou teorií a vše ostatní odmítáš. Mohl by ses už konečně nad tím alespoň trochu zamyslet.

Zdržení se může stát kdekoliv z jakýchkoliv důvodů. Ale to jak to píšete nemá žádný smysl. Prozkoumejte hlavičky těch mejlů a najděte si kde to viselo. Setkával jsem se kdysi například s tím, že měl problémy odesílatelův Outlook. V dnešné době by měly mejly putovat nejkratší cestou od serveru odesílatele k serveru příjemce. Ovšem v situaci kdy je cílový server například přetížen, může dojít k odmítnutí a pokus o doručení se ale neopakuje ihned ale až po několika hodinách.

Mám schránky na seznam.cz a centrum.cz, ale děje se mi to jenom na seznamu.

Ne. Je to univerzální vlastnost. Doba je různá i mezi stejnými adresami. Nejhorší je gmail.com. Často vrátí zprávu adresátovi a ten ji někdy dostane do spamu. Když si toho nevšimne, je problém na světě. Důležité věci je lepší vyřídit telefonicky a potvrdit datovou schránkou.