Základní principy elektronické pošty (díl druhý)

V minulé části jsem nastínil, jak funguje elektronická pošta. Dnes se naopak budeme zabývat tím, jak elektronická pošta může nefungovat.

Jistě se vám již někdy stalo, že jste odeslali mail a po chvíli, či druhý den jste dostali podivnou zprávu, která byla obvykle kompletně v angličtině, obsahovala nějaká čísla, nepochopitelný text a jako odesílatel byl uveden někdo, komu jste nikdy nepsali, případně někdo, koho neznáte. V tu chvíli jste se stali spokojenými (nebo možná méně spokojenými) příjemci automaticky generované chybové hlášky. (Ještě to také mohl být spam, ale o tom zase jindy.) Pokusíme se podívat, jak takové zprávě porozumět.

Pro studijní účely si můžeme chyby rozdělit do dvou skupin, a to na chyby, které jste způsobili sami, a na chyby, které vznikly v průběhu doručování vinou nějaké nestandardní situace, jakou je třeba výpadek některého serveru.

V první skupině jsou v drtivé většině chyby způsobené chybně uvedenou adresou příjemce nebo odesílatele (tedy chybou vaší). Věnujte pozornost i druhé variantě, kterou zmiňuji (tedy adrese odesílatele). V dnešní době totiž již v rámci ochrany proti spamu bývá kontrolována adresa odesílatele buď na obecnou platnost, nebo na tzv. lokálnost. Mnoho poštovních serverů totiž doručí jedině zprávu, jejíž příjemce nebo odesílatel je serveru znám, tedy je lokálním uživatelem. Platnost adresy příjemce je samozřejmě nezbytná. Tady se nejčasněji chybuje v překlepech, buď běžným prohozením písmen nebo stisknutím třeba klávesy CTRL místo klávesy SHIFT. Znak vložený s klávesou CTRL nemusí být viditelný, ale je samozřejmě překážkou doručení. Některé poštovní programy dokáží vložit doprostřed poštovní adresy i znak generovaný klávesou ENTER. Další, poměrně zřídka se vyskytující, závada může být v tom, že v části adresy před zavináčem se obecně rozlišují velká a malá písmena. Pepa tedy není PEPA! Ale většinou bývá velikost písmen ignorována, záleží na úvaze a názoru správce cílového serveru.

Řešení všech těchto vad je celkem prosté. Stačí ověřit si, že jste zadali adresu správně, případně opakovat zaslání později pro případ, že by závada byla u příjemce. Samozřejmě je možné i to, že cílová adresa byla zrušena. Pak ovšem nezbývá, než abyste navázali spojení jinou cestou.

Druhý případ je nejčastěji zaviněn výpadkem některého spoje na Internetu, nebo ve vnitřní síti příjemce (či odesílatele). Další v pořadí je přeplněný disk příjemce nebo vyčerpání diskové kvóty konkrétního uživatele. To se stává především studentům, ale i klientům providerů, kteří omezují velikost schránek klientů, ale neomezují nijak velikost přijaté zprávy. Protože nemáte žádnou možnost ovlivnit, jak velkou zprávu vám někdo pošle, může se to snadno stát i vám. Obrana tady žádná není. Poslední běžný případ je chybné přesměrování zprávy. (Přesměrování zprávy znamená, že zprávy pro nějakého účastníka jsou doručovány na jinou adresu. Nastavuje jej buď účastník sám, nebo to za něj může udělat správce systému.) Pokud je nová cílová adresa chybně zapsána, zpráva se vám vrátí.

Pro řešení druhého případu si zprávy rozdělíme na další dvě skupiny, chybové hlášky a varování. Chybové hlášky obsahují téměř vždy někde v textu, nebo subjektu slůvko "error" nebo "returned mail". Varovné zprávy obsahují v textu slovo "warning" a dále obvykle nějaké poučení typu "You don�t need to send your message again". Na varovné hlášky skutečně není třeba reagovat, první přijde obvykle po čtyřech hodinách, po které se nepodařilo zprávu doručit, druhá po dni, třetí po třech dnech a pátý den se zpráva vrací (dále se již nedoručuje). Tyto hodnoty jsou typické, ale nejsou nijak uzákoněné, takže se můžete setkat jak s jinými odstupy, tak s úplným vypnutím generování těchto zpráv.

Chybové zprávy znamenají, že zpráva nebyla doručena a systém se o další doručování ani nebude pokoušet. Je na vás, co uděláte. Pokud jste přesvědčeni, že zpráva být doručena měla, je vhodné kontaktovat správce systému, na kterém k chybě došlo nebo správce cílového serveru a žádat je o radu či pomoc. RFC za tímto účelem definuje, že "každá registrovaná doména musí mít zřízeno konto postmaster za účelem správy pošty".

RFC 822
6.3.  RESERVED ADDRESS

          It often is necessary to send mail to a site, without  know-
     ing  any  of its valid addresses.  For example, there may be mail
     system dysfunctions, or a user may wish to find  out  a  person's
     correct address, at that site.

          This standard specifies a single, reserved  mailbox  address
     (local-part)  which  is  to  be valid at each site.  Mail sent to
     that address is to be routed to  a  person  responsible  for  the
     site's mail system or to a person with responsibility for general
     site operation.  The name of the reserved local-part address is:

                                Postmaster

     so that "Postmaster@domain" is required to be valid.

     Note:  This reserved local-part must be  matched  without  sensi-
            tivity to alphabetic case, so that "POSTMASTER", "postmas-
            ter", and even "poStmASteR" is to be accepted.

Teorie tedy praví, že pokud nahradíte jméno, na které nelze něco poslat slovem postmaster, a doménu ponecháte, měli byste se spojit s někým, kdo ví, co a jak, a pomůže vám. Prakticky to naráží na jednu chybu, všechny RFC dokumenty jsou nezávazné a spousta správců je stejně nečte. Navíc některé komerčně dodávané poštovní systémy (Microsoft Exchange) nemají toto konto od výrobce vůbec definováno a jejich správci buď o nutnosti toto konto dodefinovat nevědí, nebo se jim do toho ani nechce. Často se také setkáte s tím, že konto sice existuje, ale nikdo jej nečte. Takže toto není vždy ta úplně správná cesta, nic vám ale nebrání to pro začátek alespoň zkusit. A možná si to přečtou i zákazníci mající zakoupený webhosting a budou se dožadovat u providera nápravy. (Pokud totiž někdo má www adresu www.domena.cz, ale jako kontaktní adresu uvádí "nekdo@provider.cz", je neexistence postmastera téměř jistá.)

Pokud tato možnost selže, můžete se pokusit najít na danou osobu kontakt v nějaké adresářové službě, třeba http://lide.seznam.cz nebo http://www.bigfoot.com. Další rady nemám (a takové jako použít telefon nemá smysl psát).

V chybové zprávě budou řádky obsahující adresu, na kterou nebyla zpráva doručena, a v jejich těsném okolí se bude asi vyskytovat číselný kód složený ze tří číslic. Něco si o něm povíme, protože je velice podobný tomu, který se používá v protokolu http. Ono by bylo asi lepší říci, že ten v http je podobný poště (http prostě převzalo velice osvědčený systém). Tyto kódy jsou určeny především pro strojové zpracování, ale i nám mohou něco zajímavého povědět. Chybové zprávy jsou totiž velice variabilní, odrážejí náladu a třeba i smysl pro humor tvůrce. Proto jsou pro počítač nesrozumitelné a pro ty, kteří nevládnou právě dobře anglicky také. A tady právě nastupuje chybový kód. První číslice udává jakousi kategorii chyb:
1xx � v poště se nevyskytuje, udává, že předchozí příkaz byl přijat, ale očekává se další pokyn, aby se něco mohlo začít dít, případně se používá pro ladicí účely;

2xx � příkaz byl zpracován, může následovat další příkaz, vše proběhlo správně;

3xx � příkaz byl akceptován, ale nebude se hned zpracovávat, nevypadá to, že by něco bylo špatně;

4xx � příkaz nebyl přijat, systém není připraven jej zpracovat, ale jedná se o dočasný stav, pokud bude požadavek opakován později, bude stejný příkaz korektně zpracován;

5xx � příkaz nebyl a nikdy nebude přijat.

Asi jste pochopili, že chybové jsou až dvě poslední hlášky. Přesná hranice mezi nimi není, např. nedostatek místa na disku hlásí některé systémy jako chybu třídy 4, jiné jako 5.

Druhá číslice udává typ chyby:
x0x � syntaktická chyba, neznámý příkaz;

x1x � informace, nápověda;

x2x � chyba (stav) se vztahuje ke spojení;

x5x � chyba se vztahuje k funkci poštovního systému.

Třetí číslice dále zjemňuje chybu, ale není definována takto konkrétně. Na závěr vybírám několik nejdůležitějších stavových hlášek:

500 Syntax error, command unrecognized
(neznámý příkaz)

501 Syntax error in parameters or arguments
(neznámý parametr)

502 Command not implemented
(příkaz není implementován)

251 User not local; will forward to
(Pošta uživatele je přesměrována na jinou adresu, nejedná se o chybu, ale znamená to, že je nutné poštu posílat na novou adresu. Většina poštovních programů to udělá sama, a potom chybovou hlášku vůbec neobdržíte.)

450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
(např. došlo místo na disku)

550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
(Uživatel není znám, došlo místo v podání jiného systému, ale také třeba odešel disk.)

551 User not local; please try
(Uživatel není náš, zkuste jinou adresu, my se o doručení starat nebudeme. V tomto případě bude zpráva téměř jistě vrácena a budete se o ni muset postarat sami.)

452 Requested action not taken: insufficient system storage
552 Requested mail action aborted: exceeded storage allocation
(Opět varianty vyčerpání volného místa na disku.)

A ukázky chybových zpráv:

------- Failure Reasons  --------

User  not listed in public Name & Address Book
xxxxxxxx@dxxxxxxxxxk.com


------- Returned Message --------

Toto generuje Exchange. Jak vidíte, číselné kódy chybí. Kdo by se patlal s jejich implementací. (Toto neplatí pro dostatečně nové verze.) Chyba znamená neexistujícího uživatele.

Delivery has failed on the enclosed message for the following
reasons reported either by the mail delivery system on the mail
relay host or by the local TCP/IP transport module:

   550 
... User unknown

Your original mail message follows:
--------------------------------------------------------

The original message was received at Tue, 16 Mar 1999 22:37:29 +0100
from poli.feld.cvut.cz [147.32.193.233]

   ----- The following addresses had permanent fatal errors -----


   ----- Transcript of session follows -----
... while talking to lxxis.lxxis.cz.:
>>> RCPT To:
<<< 550 ... User unknown
(Tady je výňatek podstatné části komunikace s cílem.)
550 ... User unknown
(Tohle je definitivní závada po vyhodnocení předchozích řádek systémem.)

(Tady následuje část pro strojové zpracování.)
Final-Recipient: RFC822; xxxxx@loxxs.cz
Action: failed
Status: 2.0.0
Remote-MTA: DNS; lxxxs.lxxxs.cz
Diagnostic-Code: SMTP; 250 HAA01267 Message accepted for delivery
Last-Attempt-Date: Wed, 17 Mar 1999 08:35:00 +0100

Ukázka chyby doručení generovaná programem sendmail. Tato zpráva se nejvíce přibližuje standardu pro chybové hlášky a je dokonce i strojově zpracovatelná. Opět se jedná o chybu v adrese.

Message has spent too much time being processed at this host

fxxxzt.pxxt.cz unable to deliver mail to the following recipient(s):

petr.xxxxk@pxxxt.cz

The rejected message follows:

Altavista mail, opět malinko nestandardně a v zásadě nesrozumitelně. Jednalo se o zrušení konta danému uživateli, zatímco tohle vypadá spíše na nějakou ztrátu spojení.

Hi. This is the qmail-send program at email.seznam.cz.
I'm afraid I wasn't able to deliver your message to the following
addresses. This is a permanent error; I've given up. Sorry it didn't work
out.

:
This message is looping: it already has my Delivered-To line. (#5.4.6)

--- Below this line is a copy of the message.

Tohle nám vygeneroval qmail na seznamu, jedná se o chybné přesměrování pošty. Uživatel si do přesměrování uvedl vlastní adresu, takže se pošta zacyklila. Pozná se to podle slůvka "looping" které při této chybě hlásí snad všechny systémy.

The original message was received at Thu, 11 Mar 1999 11:21:42 +0100 (MET)
from max.feld.cvut.cz [147.32.192.36]

   ----- The following addresses had permanent fatal errors -----


   ----- Transcript of session follows -----
... Deferred: Connection timed out with mail.ixxxxxxxxxe.cz.
Message could not be delivered for 5 days Message will be deleted from
queue

Final-Recipient: RFC822; rxxxxxxl@mail.fxxxxxxxt.cz
Action: failed
Status: 4.4.7
Remote-MTA: DNS; mail.fixxxcz
Last-Attempt-Date: Sun, 21 Mar 1999 22:43:28 +0100

Tady opět sendmail, ale s jinou chybou. Tato zpráva byla vrácena po pěti dnech pro nedoručitelnost. Důvodem bylo, že se nepodařilo ani jednou udržet spojení s cílovým strojem, spojení k němu prochází příliš přetíženou části Internetu, nebo je cílový stroj chybně nakonfigurován. Nejpravděpodobnější ale je, že někdo posílal mnoha megabytový dopis na adresu, kam se nemohl připojit ani přes atp. Navíc je z diagnostické části vidět, že pošta byla přesměrována.

Ještě si zamoralizuji na téma velkých mailů. Elektronické pošta je určena pro přenos krátkých textových zpráv. Zasílání instalačních disket, obrázků a videoklipů je sice velice šikovné, protože od vás to odteče na server providera hned, cíl si to také (možná) stáhne z lokálního serveru bez problémů. Provider má jistě místa na discích spousty. Takže kde je něco škodlivého? Problém je v přenosu samém. Každý server umí standardně odesílat X dopisů najednou, např. 25. Ostatní musí čekat ve frontě, až na ně přijde řada. Odeslání velkého souboru, navíc tak neefektivní metodou jako je poštovní přenos (o tom blíže příště), může trvat desítky minut nebo i celé hodiny. Více takových souborů může zablokovat server tak, že jinak blesková pošta se opozdí o hodiny. Navíc je vysoká pravděpodobnost, že spojení takto dlouho trvající spadne a přenos bude muset začít znovu od začátku (a to i několikrát). A ve vůbec nejhorším případě, pokud příjemci dojde místo v poštovní schránce, přenos se bude pokoušet o opakování mnohokrát a mnohokrát. Proto se může stát, že správce, zcela oprávněně, smaže zprávu z fronty a ani o tom nedá odesílateli vědět. V některých systémech ani není nějak jednoduše možné zjistit, komu vlastně ten velký soubor patří (patřil). Stejně tak to otravuje příjemce, protože pokud je připojen třeba slabou linkou, má ji zablokovanou a ani nemá moc možností s tím něco dělat, protože najít toho, kdo vám tam tlačí něco velkého není snadné a kontaktovat ho může být zcela nemožné. Proto vřele nedoporučuji používat elektronickou poštu na něco takového, zvláště když pro tyto účely byly vynalezeny domovské stránky, FTP, scp a podobně. Soubor, který někomu chcete nabídnout, je tam možné zveřejnit a jemu zaslat jen adresu.

To by pro dnešek mohlo stačit. Příště se můžete těšit na popis toho, jak se posílá diakritika (proč je to tak složité, resp. proč je tak často nečitelná). Uvítám jakékoliv připomínky k tomuto textu a případně i náměty, co by vás zajímalo v dalších částech.

Dan Ohnesorg (dan@feld.cvut.cz) - 27.4.1999

Zaujal Vás tento článek? Chcete nám k němu něco sdělit? Neváhejte a sdělte nám svůj názor 

S O U V I S E J Í C Í   O D K A Z Y . . .

Základní principy elektronické pošty - 26.2.1999