Ako funguje e-mail

23. 6. 2004 | Rastislav Stanik | Sítě | 22360×

E-mail (rovnako ako mnoho iných funkcií počítača) môžete používať aj bez toho abyste vedeli, ako to vnútri funguje. Ale vedieť viace je lepšie, nie?

• Úvod
• Posielanie pošty
  • SMTP server
• Prijímanie pošty
  • Local
  • POP
  • IMAP
• Čo nájdeme v mailovej správe
  • Hlavička
  • Telo

---

Úvod

Medzi najpopulárnejšie spôsoby komunikácie, ktoré nám priniesol internet, je e-mail. Tento dokument popisuje princípy toho, ako e-mail funguje.

Posielanie pošty

Keď posielate e-mailovú správu môžete, vynechať telo správy. Môžete vynechať aj vyplnenie kolonky Predmet (Subject:), ale ak chcete, aby správa niekam odišla, musíte vyplniť položku Adresát (To:). Cesta e-mailu začína práve tu. Adresa môže vyzerať rôzne. Môže pozostávať len z mena (napr. rastos), môže špecifikovať meno užívateľa a meno počítača (napr. rastos@server), meno počítača môže byť aj úplné (napr. rastos@server.example.org). Najbežnejšou formou však je meno a doména (napr. rastos@example.org). Túto adresu teda zadáme do programu na písanie e-mailov. Aby tento program vedel, kam správu poslať, má dve možnosti:

1. Odovzdať telo správy spolu so všetkými potrebnými údajmi inému programu. Napríklad mnohé unixové programy na písanie e-mailu samotné odoslanie správy prenechajú interaktívnemu módu programu sendmail. Ten potom použije postup popísaný v nasledujúcom bode.
2. Protokolom SMTP odovzdať takzvanému odchodziemu serveru (angl. outgoing server). Týmto serverom je zvyčajne SMTP server poskytovateľa pripojenia na internet. Správca väčších lokálnych sietí (napr. vo firmách, alebo školských sieťach) môže zriadiť vlastný SMTP server.

SMTP server

SMTP server je server, ktorý v závislosti na druhu adresy môže urobiť jednu z nasledujúcich vecí:

• Ak je adresát správy špecifikovaný len menom, pokúsi sa správu doručiť lokálnemu užívateľovi s týmto menom.
• Ak adresa obsahuje aj meno počítača, pokúsi sa správu poslať SMTP serveru na špecifikovanom počítači.
• Ak adresa obsahuje doménu, musí SMTP server odovzdať ďalej. Čo to presne znamená, záleží na jeho konfigurácii a môže to byť jedna z nasledujúcich vecí:
  • Jednoducho odovzdá správu inému SMTP serveru.
  • Pokúsi sa správu doručiť sám. Ak sa mu to nepodarí, odovzdá ju inému STMP serveru v nádeji, že ten bude úspešnejší. Tento druhý SMTP server sa v angličtine nazýva smart host.

Veta Pokúsi sa správu doručiť sám je krátka, ale skrýva sa za ňou mnoho. SMTP server sa spojí s DNS serverom, aby si od neho vypýtal takzvaný MX záznam pre danú doménu. MX je z anglického slova Mail eXchanger, teda stroj, ktorý je zodpovedný za vymieňanie e-mailu pre danú doménu. DNS server vracia teda IP adresu tohto stroja. DNS server môže mať takýchto záznamov viacero - ukazujúcich na rôzne IP adresy. V takom prípade sa jednotlivé záznamy líšia takzvanou prioritou. Je to celé kladné číslo, ktoré hovorí o tom, ktorý zo záznamov má vyššiu prednosť. Nižšie číslo znamená vyššiu prioritu. Ako vyzerajú tieto MX záznamy si môžeme pozrieť pomocou programu nslookup, na novších systémoch programom host či dig:

$ host -t mx rastos.org rastos.org mail is handled by 20 mx.smtp.cz. rastos.org mail is handled by 10 in.smtp.cz. $ dig MX +short=yes rastos.org 20 mx.smtp.cz. 10 in.smtp.cz. $ nslookup > set type=mx > rastos.org Server: 192.168.1.102 Address: 192.168.1.102#53 Non-authoritative answer: rastos.org mail exchanger = 20 mx.smtp.cz. rastos.org mail exchanger = 10 in.smtp.cz.

Keď už máme adresu poštového servera, môžeme si vyskúšať, čo vlastne robí náš e-mailový klient, keď mu odovzdáva našu správu cez SMTP:

> telnet in.smtp.cz 25 Trying 81.95.97.116... Connected to in.smtp.cz. Escape character is '^]'. 220 in.smtp.cz ESMTP ehlo yahoo.com 250-in.smtp.cz 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-PIPELINING 250-STARTTLS 250 8BITMIME mail from: smith@yahoo.com 250 ok rcpt to: testaccount@rastos.org 250 ok data 354 go ahead Subject: citat Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge . 250 ok 1086177079 qp 12124 quit 221 in.smtp.cz Connection closed by foreign host.

Ako vidíte, server označil odosielateľa aj príjemcu správy za ok. Odosielateľ nie je ok, ak jeho doména má existujúci MX záznam. Príjemca je ok, ak daný server je skutocne mail exchanger pre doménu príjemcu. SMTP server môže tiež zo sieťového spojenia zistiť, z akej IP adresy mu správa prichádza, a porovnať to s tým, čo tvrdí odosielateľ.

Server, ktorý nerobí tieto kontroly, sa označuje termínom open relay. Takýto stroj je pokladom pre odosielateľov spamu, ktorí často falšujú adresu odosielateľa. Mnohé (no žiaľ nie všetky), takéto servery sú zaznamenané v zozname, ako je napríklad ORDB (Open Relay Database). Keďže e-mail môže prechádzať cez viacero SMTP serverov, môžu v rámci protispamových opatrení jednotlivé servery tiež kontrolovať, či SMTP server, od ktorého preberajú správu, nie je zaznamenaný v zozname ORDB.

Prijímanie pošty

Local

V čase, keď si e-mail ešte len razil cestu na výslnie, sa najčastejšie pošta preberala z lokálnej e-mailovej schránky. Je to vlastne súbor, do ktorého e-mailový server ukladá prichádzajúce správy jednu za druhou. Tento súbor sa spravidla nachádza v adresári /var/spool/mail (na niektorých systémoch /usr/spool/mail alebo /usr/lib/mail). Program na čítanie e-mailu, označovaný ako mailer (alebo aj Mail User Agent - MUA), číta tento súbor a umožňuje jednotlivé správy zobraziť a spracovať. To samozrejme môže fungovať vtedy, keď mailer beží na tom istom počítači, na ktorom sa nachádza e-mailová schránka. Čo už dnes nie je tak časté.

POP

Najčastejší spôsob prístupu k e-mailovej schránke je asi sieťovým protokolom POP (Post Office Protocol). Je to pomerne jednoduchý protokol, ktorým si mailer preberá správy z poštového servera. Znamená to teda, že správa od odosielateľa dorazí na server a tam zostáva až do okamihu, kedy si ju odtiaľ nevyzdvihnete. Pri prevzatí správy z POP servera sa zvyčajne správa na serveri zmaže a zostáva teda len na klientovi. Komunikáciu POP protokolom možno jednoducho nasimulovať napríklad takto:

> telnet pop3.hosting.cz 110 Trying 81.95.97.117... Connected to pop3.hosting.cz. Escape character is '^]'. +OK <29567.1086177339@pop3.smtp.cz> user testaccount@rastos.org +OK pass m0jehe5sl0 +OK list +OK 1 656 . retr 1 +OK Return-Path: <smith@yahoo.com> Delivered-To: testaccount@rastos.org Received: (qmail 12323 invoked from network); 2 Jun 2004 11:54:37 -0000 Received: from unknown (HELO in.smtp.cz) (81.95.97.116) by master.smtp.cz with DES-CBC3-SHA encrypted SMTP; 2 Jun 2004 11:54:37 -0000 Received: (qmail 15491 invoked from network); 2 Jun 2004 11:51:19 -0000 Received: from unknown (HELO yahoo.com) (213.15.194.19) by in.smtp.cz with SMTP; 2 Jun 2004 11:51:03 -0000 Subject: citat Message-ID: <20040602115437.12323.qmail@master.smtp.cz> Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge . dele 1 +OK quit +OK Connection closed by foreign host.

Príkazy posielané klientom rozšifrujete asi ľahko: user a pass sa postarajú o našu autentifikáciu. list vypíše, koľko správ je v schránke a ako sú dlhé. retr požiada o výpis správy, dele správu zmaže a quit ukončí spojenie.

Protokol POP nie je šifrovaný, takže heslo je prenášané v čistom texte. Tento nedostatok môže pomôcť odstrániť zabalenie POP protokolu do šifrovacieho protokolu SSL - to ale musí prirodzene podporovať ako server, tak aj klient.

IMAP

IMAP protokol sa trocha podobá protokolu POP. Tiež je to protokol, ktorý umožňuje e-mailovému klientovi pristupovať k správam na serveri. Hlavný rozdiel je v tom, že správy zostávajú na serveri. Nepresúvajú sa na lokálny disk. Znamená to teda, že e-mailový klient len sprostredkováva pohľad na schránku sídliacu na serveri. Zmenou klienta či počítača, za ktorým sedíte, sa nič nedeje. Stála vidíte tie isté správy, označenie prečítaných správa sa nemení, zostáva štruktúra priečinkov a tak ďalej. Uľahčuje to tiež systém zálohovania, pretože sa nemusia zálohovať schránky jednotlivých užívateľov roztrúsené po všetkých pracovných staniciach.

Komunikácia protokolom IMAP je trocha zložitejšia. Tu je stručná ukážka:

> telnet pop3.hosting.cz 143 Trying 81.95.97.117... Connected to pop3.hosting.cz. Escape character is '^]'. * OK Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. See COPYING for distribution information. a001 login testaccount@rastos.org m0jehe5l0 a001 OK LOGIN Ok. a002 select inbox * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited * 1 EXISTS * 1 RECENT * OK [UIDVALIDITY 1082124563] Ok a002 OK [READ-WRITE] Ok a003 fetch 1:1 full * 1 FETCH (FLAGS (\Recent) INTERNALDATE "02-Jun-2004 14:00:32 +0200" RFC822.SIZE 669 ENVELOPE (NIL "citat" NIL NIL NIL NIL NIL NIL NIL "<20040602120031.21486.qmail@master.smtp.cz>") BODY ("text" "plain" NIL NIL NIL "8bit" 134 2)) a003 OK FETCH completed. a004 fetch 1:1 body[TEXT] * 1 FETCH (BODY[TEXT] {134} Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge ) * 1 FETCH (FLAGS (\Seen \Recent)) a004 OK FETCH completed. a005 store 1:1 +FLAGS (\Deleted) * 1 FETCH (FLAGS (\Seen \Deleted \Recent)) a006 OK STORE completed. a006 expunge * 1 EXPUNGE * 0 EXISTS * 0 RECENT a006 OK EXPUNGE completed a007 logout * BYE Courier-IMAP server shutting down a007 OK LOGOUT completed Connection closed by foreign host.

Väčšina príkazov začína unikátnym identifkátorom (ja som pre jednoduchosť použil identifkátory začínajúce s a00). Príkaz select zvolí priečinok, ktorého sa budú týkať ďalšie príkazy. fetch môže vrátiť rôzne časti správy. V našom prípade to bola najprv hlavička a potom telo. Protokol IMAP ponúka tiež rozsiahlu sadu príkazov pre nastavovanie príznakov správ (videná, zmazaná, odpovedaná, atď.) a príkazov na prácu s priečinkami (vytvoriť, zmazať, premenovať, atď.).

Podobne ako pri protokole POP, komunikácia klienta so serverom nemusí byť šifrovaná.

Čo nájdeme v mailovej správe

Každá e-mailová správa sa skladá z hlavičky a tela. Oddelené sú prázdnym riadkom.

Hlavička

Hlavička (angl. header) obsahuje niekoľko druhov informácií. Ich význam určujú kľúčové slová na začiatku riadku nasledované dvojbodkov:

To:

e-mailová adresa príjemcu

Cc:

e-mailové adresy ľudí, ktorí dostanú kópiu správy (z anglického Carbon Copy)

Bcc:

e-mailové adresy ľudí, ktorí dostnú kópiu správy, ale normálni príjemcovia sa o tom nedozvedia (z anglického Blind Carbon Copy)

From:

e-mailová adresa

Subject:

Predmet, titulok správy.

Date:

Dátum a čas odoslania.

Received:

Jedno Received: pre každý server, cez ktorý správa prechádzala. Dá sa tu dozvedieť meno servera, doba, kedy server správu spracovával, akým protokolom správu dostal, unikátny identifkátor správy a pre koho je správa určená. Každý server zopakuje Received: riadky, ktoré už v správe sú a pridá svoj. Tento údaj teda umožňuje určiť trasu, po ktorej správa putovala - až k jej zdroju. Preto sa napríklad rozosielatelia SPAMu, či vírusy túto časť snažia falšovať. Niektoré anti-spamové riešenia sú založené na tom, že overujú platnosť týchto informácií.

Message-ID:

Unikátny identifikátor správy umožňujúci napríklad radenie správ do tzv. vlákien.

Reply-To:

Komu pôjde odpoveď, keď príjemca odpovie na túto správu.

Content-Type:

Správy obsahujúce prílohy v tejto položke nesú informáciu od druhu prílohy (video, zvuk, binárny súbor, archív, html, ...) a tiež reťazec, podľa ktorého sa dá určiť, kde príloha začína a končí (tzv. boundary).

X*

Existujú mnohé položky začínajúce písmenom X. Norma hovorí, že e-mailové programy môžu takéto položky ignorovať. Používajú sa preto napr. pre informácie špecifické pre istý druh e-mailového programu, pre mail-listy a podobne.

Telo

Telo e-mailovej správy tvorí užívateľ a preto by sa mohlo zdať, že v ňom môže byť čokoľvek. Ale tak ako aj v iných oblastiach nášho života, aj pre telo správy platia isté pravidlá. Spomeniem aspoň niekoľko z nich:

• Pamätajte, že obsah prenášaných e-mailov nie je chránený pred nepovolanými očami. Ak potrebujete prenášať dôverné informácie, potrebujete asi e-mailový program podporujúci šifrovanie.
• Keď odpovedáte na e-mail, môžete citovať pôvodnú správu. Citujte to, čo príjemcoví pripomenie tému diskusie, ale necitujte zbytočne veľa.
• Než začnete písať odpoveď, overte si, že ste medzi príjemcami správy (kolonka To:) a nie len medzi tými, ktorí dostali len kópiu správy (kolonka Cc: alebo Bcc:).
• Neposielajte správu zbytočne ľuďom, ktorí ju nepotrebujú. Napríklad otázka poslaná skupine nemá byt zodpovedaná e-mailom celej skupine, ale len tomu, kto otázku položil.
• Odpoveď na e-mail môže prísť s oneskorením. Ak nemôžete čakať, použite telefón.
• Predmet (Subject:) správy by mal byť dostatočne výstižný. Ľudia si e-maily archivujú. Keď sa pozriem do archívu spred dvoch rokov a nájdem správu s predmetom: pomoc - moc mi to nepovie.
• Pokiaľ si nie ste istí, že všetci, komu sa správa môže dostať do rúk, ju dokážu pohodlne prečítať, vyhnite sa všetkému, čo môže robiť problémy. To môže znamenať diakritiku, HTML formatované správy a podobne.
• Neposielajte nevyžiadanú poštu. Nešírte neoverené a nepravdivé poplašné správy. Nešírte reťazové a pyramídové e-maily.
• Pre prenos väčšieho množstva dát e-mail nie je vhodný. Dokáže to, ale príjemcovi to môže spôsobiť problémy. Niektoré servery obmedzujú veľkosť správy, ktorú sú ochotní spracovať.

Okrem týchto pravidiel, ktoré onedlho oslávia 10. výročie vzniku, pridám ešte zopár rád vhodných v súčasnosti. V poslednej dobe sa na internete šíri nemálo vírusov práve pomocou mailu. Veľká časť z nich sa spolieha na neopatrnosť užívateľov. Preto buďte opatrní; neotvárajte pripojené súbory od neznámych odosielateľov. Vírusy tiež často využívajú chyby v programoch na čítanie e-mailov. Voľte preto dobre.

       

Komentáře

[Tomáš]

Bude nějaké pokračování, kde popíšete tvar souboru s poštou (mailbox: /var/spool/mail/*), připojení příloh--Mime vs. UUENCODE/UUDECODE. Jak vysekat přílohy, když poštovní server něco udělá špatně?

[rastos]

Zatial nemam v plane popisovat tieto veci, ale je pravda, ze by sa to sem hodilo - ako advanced topic.

Strucne: mailbox vo /var/spool/mail/*: Odporucam pustit 'mail' a ulozit jednu spravu do suboru:

$ mail
mailx version nail 10.7 3/19/04.  Type ? for help.
"/var/spool/mail/rastos": 1 message 1 new
>N  1 john@yahoo.com    Wed Jun 23 08:17  20/721   test
? s /tmp/msg
"/tmp/msg" [New file] 21/730
? x

Potom sa pozries na /tmp/msg - taketo subory su v mailboxe nacvakane jeden za druhym.

Mime: hlavicka obsahuje nieco taketo:

Content-type: multipart/alternative;
boundary="Boundary_(ID_PjqrZVpDzzEjacVh9b/vqg)"

Jednotlive attachmenty su podtom oddelene riadkami, na ktorych je:

--Boundary_(ID_PjqrZVpDzzEjacVh9b/vqg)

uuencode/decode - pozriet si manualovu stranku, urobit si uuencode na lubovolny subor a pozriet si prve dva a posledny riadok vystupu.

[Jiří Svoboda]

Na vysekani priloh pouzivam ripmime.

[rastos]

Neviem ci ripmime je sucastou tvojej distribucie, ale Slackware ma napr. mimencode/mimedecode v baliku 'metamail'. Ak sprava nie je poskodena, tak dostat z nej ten attachment zvycajne nie je problem.

[Jiří Svoboda]

Ano, mas samozrejme pravdu, ale mam dojem, ze mimencode/mimedecode potrebuje poslat na stdin jen vlastni encodovana data. 'ripmime' spustim treba na cely mbox file a do adresare mi to vysype vsechny prilohy ze vsech mailu (se spravnymi jmeny souboru).

[Tomáš Šimek]

Hezký článek, děkuji za přikaz retr u POP3, jedna z věcí co mi chyběla do úspěšného low-level testování.

Odesílání SMTP se mi zdá popsáno poněkud zmatečně >Ak adresa obsahuje doménu, musí SMTP server odovzdať ďalej. >* Jednoducho odovzdá správu inému SMTP serveru.

Tohle je ten smarthost jak je napsáno dole, používá se na menších podsítích, není např veřejná IP, nebo reverzní DNS (chytrý pošťák příjemce odmítne převzít mail z takového serveru)

>* Pokúsi sa správu doručiť sám. Ak sa mu to nepodarí, odovzdá ju inému STMP....(smarthost).

Tak tohle jsem ještě neslyšel (SMTP fair doručování+smarthost dohromady), pokud se mu to nepodaří (na 99% spam) je to důvod k odmítnutí mailu, at si klient skusí záložní server (MX s nižší prioritou.

V článku mi chybí zmíňení způsobu odmítnutí (realtime, bounce (chybový) mail zpět)

[nemo]

Prominte, muzete mi to upresnit. Asi jsem to nepochopil. Kdy odmitne kdo prevzit mail z jakeho serveru?

Adresa obsahuje domenu, takze SMTP server odevzda mail dalsimu SMTP serveru - smarthostu(?). Proc by smarthost takovy mail odmital? Protoze ten SMTP server co mu mail predal nema verejnou IP adress?

Potom by nemela smysl nasledujici situace: domaci sit s vlastnim postovnim serverem pripojena pres dialup. Takovy domaci SMTP server by nemel verejnou IP adresu a vsechny Internetove SMTP servery (pro nej smarthosti) by od nej maily odmitaly.

Pochopil jsem to dobre? Jsem lama, takze diky za vysvetleni.

[platYpus]

Vetsinou je to udelano tak, ze (na domacim SMTP-serveru) mas nastaven jako "smarthost" SMTP-server sveho providera.

Ten pochopitelne v DNS je, a tudiz se s nim ostatni SMTP-servery (ktere overuji pres reverzni DNS) bavit budou.

To jestli je to spravne je diskutabilni, nicmene je to tak.

BTW: terminem "smarthost" se oznacuje _prave_jeden_ server (viz. vyse), na ktery smeruji veskere tvoje odchozi maily a on uz se postara o jejich dalsi smerovani (slouzi jako relay).

[nemo]

Clanek se mi libil, jen mam jeste par otazek.

* Jednoducho odovzdá správu inému SMTP serveru.
* Pokúsi sa správu doručiť sám. Ak sa mu to nepodarí, odovzdá ju inému STMP serveru v nádeji, že ten bude úspešnejší. Tento druhý SMTP server sa v angličtine nazýva smart host.

Podle ceho se rozhodne co bude delat? Nebo to dela poporade, zkusi dorucit a kdyz neuspeje preda dal?

Pokud SMTP server dostane od DNS serveru vic MX zaznamu s ruznou prioritou, zkousi v pripade neuspechu poslat mail podle zaznamu s nizsi a nizsi prioritou, nebo kdyz se mu to jednou nepovede, tak se na to vykasle? Je to dane, nebo to zavisi na konkretnim nastaveni toho SMTP serveru?

Smarthost je kazdy SMTP server, kteremu jiny SMTP server preda mail k doruceni? Zavisi tedy na pohledu nebo je smarthost definovan jinak?

Kdyz postovni server predava mail jinemu postovnimu serveru k doruceni, predava mu jej SMTP protokolem, nebo si mail servery predavaji maily jinym zpusobem?

Diky.

[rastos]

Zda sa, ze s tym smart-hostom som zabrusil do temy, kde nie som dostatocne fundovany . Preto budem vdacny, ak ti, co sa na to citia (Tomáš Šimek?) ma uvedu na pravu mieru.

Osobne sa domnievam, ze ak SMTP server nedokaze dorucit spravu, posle ju smart-hostovi. Nedokazat to moze napr. z dovodu timeoutov pri rezolovani DNS a podobne. Dokumentacia sendmail-u napr. hovori, ze smart-host mozno definovat ako host, ktory dokaze spracovat e-mail, ktory sa niekde na ceste musi prenasat napr. cez uucp. Nas server to nevie, ale vieme o niekom, kto to vie - proste je smart - chytrejsi ako nas server.

Co sa tyka spravania pri viacerych MX - myslim, ze to zavisi na druhu problemu, ktory ma nas server s dorucovanim. RFC hovori: "if host is not available" - ak nie je dostupny. Povedal by som, ze 'no route to host' ci 'connection timeout' by mali viest k pouzitiu dalsieho MX v poradi.

Este k prvej otazke: SMTP server moze byt nakonfigurovany ako 'forwarder' - vtedy, vseto co dostane posle tomu 'forwarduje'. Moze byt ale nakonfigurovany ako plnohodnotny server a vtedy sa pokusa dorucit spravu sam.

[Jiří Svoboda]

"SMTP server moze byt nakonfigurovany ako 'forwarder' - vtedy, vseto co dostane posle tomu 'forwarduje'." - ano, a prave tomu stroji, na ktery se to vsechno forwarduje, se z pohledu forwardera rika smarthost... (IMHO)

[Tomáš Šimek]

SMTP servery (já používám EXIM) se pokud přijmou poštu (z internetu, od uživatele) většinou řídí správcem definovanýmy pravidly (samotnému přijetí může předcházet opět řada kontrol (syntaxe hlaviček, existence revezního MX DNS odesílajícího serveru, koukání se do různých blacklistů, spojení se s odesílajícím serverem a pomocí SMTP VRFY příkazu ověření existence odesílatele))

U většiny tyto pravidla vypadají asi takhle :

1) je cílová doména jedna z mojich ?

1.1) Podívej se do /etc/aliases, jestli najdeš uživatele, začni procházet pravidla znova s pŕepsanou adresou

1.2) Existuje ten uživatel a má ~/.procmailrc ? -> předej procmailu

1.3) Existuje ten uživatel ? -> zapiš mu mail do /var/spool/mail/uzivatel

1.4) Selži, chybou 550 pokud ješte můžeš (nepřijmul si tělo a neodpověděl 250 OK), jinak budeš muset poslat bounce mail

2) je cílová doména jedna z těch pro které děláš záložní server ?, jestli ano, odešli

3) cílová adresa je úplně cizí, je IP odesílatele v databázi strojů pro které děláš relay/smarthost ?, jestli ano, odešli

4) selži SMTP chybou (teď nevim, jestli taky 550), není rozhodně třeba bounce mail protože, chyba je u odesílatele a ne u nás a nebudeme net zatěžovat bounce reakcemi na stovky spamů

odeslání:

(Sem už se dostanou pouze maily co dou pryč do internetu, naše už jsme zpracovali). Podívej se do DNS na MX cílové domény.

Navaž spojení se serverem co má nejnižší MX a pošli mu to.

V případě že převezme (SMTP 250), přestává to být naše starost.

V případě že odpoví 550, víme že uživatel neexistuje, nebo jiný permanentní důvod (server má např. zprávu za spam) a my pošleme zpátky bounce mail (mail už jsme od odesílajícího převzali, tudíž nemůžeme zpátky odpovědět 550, a je naše starost poslat bounce mail.

V případě že odpoví něco ve stylu temporary error, nebo se s ním vůbec nespojíme, zkusíme celé odesílání zopakovat dalšímu serveru (s menší prioritou)

Pokud ani jeden server nebyl schopen pŕijmout, ani natvrdo odmítnout, uložíme a zkoušíme několik dní

Potom pošleme zpátky bounce mail a zahodíme

Pokud jsme někde v lokální síti s privátní adresou, nemáme reverzní MX (slušné servery nevemou poštu od někoho kdo nemá revezní MX), nakonfigurujeme odesílání přez SMARTHOST (nekoukáme do DNS, ale všechno strčíme rovnou smarthostu, chyby neočekáváme). Je samořejmé źe smarthost je normální SMTP, který naší adresu ma v databázi adres, pro které dělá relay viz výše)

Tak tohle je zjednodušené schéma jak pracuje SMTP server, většina standardních konfigurací se takhle chová. Body co jsem poslal jsou v praxi trochu složitější. Navíc já byh dnes např. nevyžil bez antispamu, antiviru, blokátoru pŕíloh (když má někdo 800 spamů+virů do domény denně :(). Tyhle anti* kontroly se většinou realizujou standardně pomocí SMTP přeposílání (ano ten náš smarthost), takže pravidla bobtnají

Uff trochu sem se rozepsal, při uvážení trendu zkracování, by to vydalo na článek :)

[jiri]

Díky. Tohle je opravdu moc pěkně napsáno!

[petr_p]

Pekny clanek, akorat tu chybi vysvetleni, ze SMTP a mail jsou dve oddelene veci. SMTP je protokol k obecnemu predavani textovych zprav, takze ho jejich obsah -- mail (tzn. hlavicky a telo) vubec nezajima. Chybi vysvetleni pojmu obalkova adresa, coz je ten smerodatny udaj, podle ktereho se pozna adresat a odesilatel.

[Michal Kubeček]

Ono je tam těch nepřesností mnohem víc. Spíš mám podezření, že autor nikdy neviděl RFC 2821 a 2822 (o 2045-2049 nemluvě) a to, co zde prezentuje, jsou pouze odpozorované empirické poznatky.

[h7]

Ahoj, chystam se napsat aplikaci ,co bude pravidelne prochazet maildiry a starsi maily bude hazet do databaze (prilohy necham na disku v urcenem adresari). Jeste nevim v cem to budu delat.... php ,bash nebo perl. Ted resim problem ,jak z mailu (v maildir formatu) vysekat telo a prilohu. Rad bych tez ukladal text mailu v plain textu (tzn: pokud je mail v html tak to bude potreba prevest do plainu,ale jak nejsnaze?) Budu rad,kdyz hodite nejake postrehy zkusenosti,typy a tak. Pekny den hanz!

[David Jež]

Zdravim,
kombinace mess822 a ripmime by ti mohla hodne pomoct
-djz

[io]

Velmi dobre napsano, i kdyz jsem (jak se ted troufale oznacim) starej windowsak tak mi to hodne dalo :) jen jsem si nedokazal pokecat se SMTP serverem ... musim jich zkusit vic, ten nas mi nechce napovidat pres HELP :)