abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:00 | Nová verze

Oficiálně bylo vydáno Ubuntu 18.04 LTS s kódovým názvem Bionic Beaver. Tato verze s prodlouženou podporou bude podporována 5 let, tj. do dubna 2023. Přehled novinek a také odkazy na oficiální deriváty v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 23:00 | Nová verze

Po osmi letech od prvního commitu byla vydána verze 1.0 webového frameworku Flask (Wikipedie) napsaného v Pythonu. Přehled novinek v oznámení o vydání. Instalovat lze z PyPI. Odstraněna byla podpora Pythonu 2.6 a 3.3.

Ladislav Hagara | Komentářů: 0
včera 16:22 | Zajímavý článek

Nadace Raspberry Pi vydala devětašedesáté číslo (pdf) anglicky psaného časopisu MagPi věnovanému Raspberry Pi a projektům postaveným na tomto jednodeskovém počítači a šesté číslo (pdf) časopisu pro kutily HackSpace věnovanému navíc 3D tisku, pájení, řezání nebo i elektronice a IoT.

Ladislav Hagara | Komentářů: 0
včera 14:11 | Komunita

Byl zveřejněn seznam 44 osob přijatých do programu Outreachy od 14. května do 14. srpna 2018. Cílem programu Outreachy je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny.

Ladislav Hagara | Komentářů: 12
včera 11:44 | Nová verze

Glen MacArthur vydal verzi 2018.4.2 na Debianu založené linuxové distribuce optimalizované pro tvůrce audio a video obsahu AV Linux (Wikipedie). Podrobnosti v oznámení o vydání a v stotřicetistránkovém manuálu (pdf).

Ladislav Hagara | Komentářů: 1
25.4. 23:33 | Nová verze

Byla vydána nová stabilní verze 1.15 (1.15.1147.36) webového prohlížeče Vivaldi (Wikipedie). Z novinek lze zdůraznit možnost nastavení vlastního pozadí okna, přístup k záložkám z hlavního menu, lepší ovládatelnost v režimu celé obrazovky nebo vyřešení problémů se zvukem v HTML5. Nejnovější Vivaldi je postaveno na Chromiu 65.0.3325.183.

Ladislav Hagara | Komentářů: 0
25.4. 17:22 | Nová verze

Node.js Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 10.0.0 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). Verze 10 se v říjnu stane novou aktivní LTS verzí. Podpora je plánována do dubna 2021.

Ladislav Hagara | Komentářů: 0
25.4. 15:33 | Nová verze

Neal Cardwell ze společnosti Google oznámil zveřejnění verze 2.0 nástroje pro testování síťového stacku packetdrill. Jde o souhrnné vydání změn z interního vývoje od roku 2013.

Michal Kubeček | Komentářů: 0
25.4. 13:22 | Zajímavý software

Microsoft na svém blogu oznámil, že správce knihoven pro C++ Vcpkg (VC++ Packaging Tool) lze nově používat také na Linuxu a macOS. Aktuálně je pro Linux k dispozici více než 350 knihoven [reddit].

Ladislav Hagara | Komentářů: 1
25.4. 12:44 | Komunita

Byly zveřejněny exploity na Nintendo Switch a platformu Tegra X1: Fusée Gelée a ShofEL2. Jejich zneužití nelze zabránit softwarovou aktualizací. Na druhou stranu exploity umožní na Nintendo Switch snadno a rychle nainstalovat Linux, viz. ukázka na YouTube. Jenom je potřeba sáhnout na hardware.

Ladislav Hagara | Komentářů: 0
Používáte na serverech port knocking?
 (3%)
 (7%)
 (47%)
 (26%)
 (18%)
Celkem 388 hlasů
 Komentářů: 29, poslední 5.4. 12:25
    Rozcestník

    Ako funguje e-mail

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

    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

    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 (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.

           

    Hodnocení: 44 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    23.6.2004 07:57 Tomáš | skóre: 30 | blog: Tomik
    Rozbalit Rozbalit vše Pěkný úvod
    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ě?
    23.6.2004 08:36 rastos | skóre: 61 | blog: rastos
    Rozbalit Rozbalit vše Re: Pěkný úvod
    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 avatar 23.6.2004 09:47 Jiří Svoboda | skóre: 37 | blog: cat /dev/mind | Prostějov
    Rozbalit Rozbalit vše Re: Pěkný úvod
    Na vysekani priloh pouzivam ripmime.
    23.6.2004 11:10 rastos | skóre: 61 | blog: rastos
    Rozbalit Rozbalit vše Re: Pěkný úvod
    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 avatar 23.6.2004 11:28 Jiří Svoboda | skóre: 37 | blog: cat /dev/mind | Prostějov
    Rozbalit Rozbalit vše Re: Pěkný úvod
    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).
    23.6.2004 08:11 Tomáš Šimek
    Rozbalit Rozbalit vše SMTP Odesílání
    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)
    23.6.2004 09:39 nemo
    Rozbalit Rozbalit vše Re: SMTP Odesílání
    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.
    23.6.2004 13:12 platYpus
    Rozbalit Rozbalit vše Re: SMTP Odesílání
    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).
    23.6.2004 09:53 nemo
    Rozbalit Rozbalit vše SMTP & MX & smarthost
    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.
    23.6.2004 11:11 rastos | skóre: 61 | blog: rastos
    Rozbalit Rozbalit vše Re: SMTP & MX & smarthost
    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 avatar 23.6.2004 11:32 Jiří Svoboda | skóre: 37 | blog: cat /dev/mind | Prostějov
    Rozbalit Rozbalit vše Re: SMTP & MX & smarthost
    "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)
    23.6.2004 12:30 Tomáš Šimek
    Rozbalit Rozbalit vše Re: SMTP & MX & smarthost
    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 :)
    1.7.2004 13:00 jiri
    Rozbalit Rozbalit vše Re: SMTP & MX & smarthost
    Díky. Tohle je opravdu moc pěkně napsáno!
    23.6.2004 12:54 petr_p
    Rozbalit Rozbalit vše SMTP neni jen elektronicka posta
    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.
    6.7.2004 22:15 Michal Kubeček
    Rozbalit Rozbalit vše Re: SMTP neni jen elektronicka posta
    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.
    23.6.2004 13:04 h7
    Rozbalit Rozbalit vše rozsekani mailu
    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!
    25.6.2004 12:06 David Jež | skóre: 42 | blog: -djz | Brno
    Rozbalit Rozbalit vše Re: rozsekani mailu
    Zdravim,
    kombinace mess822 a ripmime by ti mohla hodne pomoct :-)
    -djz
    "Yield to temptation; it may not pass your way again." -- R. A. Heinlein
    2.7.2004 14:46 io
    Rozbalit Rozbalit vše velmi pekne
    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 :)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.