Elektronikus levelezés

Átírás

1 2016/12/03 02:10 1/18 Elektronikus levelezés < szerver Elektronikus levelezés Szerző: Sallai András Copyright Sallai András, 2011, 2013, 2015 Licenc: GNU Free Documentation License 1.3 Web: Bevezetés A levelezés az Internet legfontosabb szolgáltatása. Többféle levelezőszerver megoldással találkozhatunk. Az Interneten sok-sok levelezőszerver fogadja a leveleinket és küldi át egy másik levelezőszervernek. Sokféle levelezőszerver szoftvert írtak mára. Az alábbiakban egy rövidebb felsorolást látunk. Levelezőszerverek a teljesség igénye nélkül: Postfix Exim Qmail Sendmail HMailServer (Nyílt forráskódú Windowsra) Novell GroupWise SMail Eudora Internet Mail Server Exchange Zimbra Hálózat ismétlés Az Interneten elfogadott, hogy a számítógépek szoftveres portjait három részre osztjuk. Ezek a közismert portok, a bejegyzett portok és az egyéni portok, az alábbi táblázat szerint: Port tartomány Leírás Cél/Forrás közismert portok Csak célportként használható bejegyzett portok Cél és forrásportként is használható egyéni portok Cél és forrásportként is használható SzitWiki -

2 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet A következő táblázat néhány közismert portot mutat be. Port Rövidítés Leírás 20 FTP adat File Trafnsfer Protocol - adatátvitelhez 21 FTP vezérlés File Transfer Protocol - kapcsolatfelvétel 23 TELNET TELetype NETwork - távgépíró hálózat 25 SMTP Simple Mail Transfer Protocol - Egyszerű levélszállító protokoll 53 DNS Domain Name System - Tartomány nevek rendszere 67 DHCP v4 ügyfél 68 DHCP v4 kiszolgáló Dynamic Host Configuration Protocol - Dinamikus állomáskonfigurálási protokoll (ügyfél) Dynamic Host Configuration Protocol - Dinamikus állomáskonfigurálási protokoll (kiszolgáló) 80 HTTP Hypertext Transfer Protocol - Hiperszöveg átviteli protokoll 110 POP3 Post Office Protocol - Postahivatal protokoll 123 SNTP Simple Network Time Protocol - Egyszerű hálózati időprotokoll (UDP) 137 NBNS NetBios Name Service - NetBIOS névszolgáltatás 143 IMAP4 Internet Message Access Protocol - Internetes levélhozzáférési protokoll 161 SNMP Simple Network Management Protocol - Egyszerű hálózatfelügyeleti protokoll 443 HTTPS Hypertext Transfer Protocol Secure - Biztonságos hiperszöveg átviteli protokoll 465 SMTPS Levelek fogadása SSL/TLS kapcsolaton keresztül 993 IMAPS Levelek kiszolgálása olvasásra SSL/TLS kapcsolaton keresztül 995 POP3S Levelek kiszolgálása letöltésre, olvasásra SSL/TLS kapcsolaton keresztül A levelezés egységei Egy levelező szerver a következő egységekből állhat: MTA - Mail Transfer Agent - továbbít Használják egy komplett levelezőszerverre is. MDA - Mail Delivery Agent - eloszt, átad LDA Local Delivery Agent - az MDA szinonímája MSA - Mail Submission Agent - fogad MS - Mail Storage - tárol Printed on 2016/12/03 02:10

3 2016/12/03 02:10 3/18 Elektronikus levelezés POP3 kiszolgáló IMAP kiszolgáló Mivel az első négy szolgáltatást egyetlen szoftver csomag szokta ellátni, ezért az egészet MTA néven szoktuk említeni. Ezek után egy egyszerűsített felosztás látható a következőkben: Szerver Ellátott funkciók Példa MTA továbbít, eloszt, átad, fogad, tárol Exim, Postfix POP3 kiszolgáló dovecot-pop3d IMAP kiszolgáló dovecot-imapd A levelező kliens: Kliens Leírás Példa MUA Mail User Agent - kliens Thunderbird A fenti szerverszolgáltatások közül az MDA és LDA szolgáltatások számára külön szoftverek is létrejöttek. Ezek valamivel több szolgáltatást nyújtanak mint az MTA-ba beépített MDA, illetve LDA. MDA, LDA programokra példa: maildrop procmail Dovecot LDA modulja A következő ábra szemléltei a levelezés két lehetséges módját. Vagy webfelületen olvasom a leveleket, vagy egy levelező klienst használok. Az ábrán minden szoftver nevén is van nevezve. A webszerver például az apache. A levél kiszolgáló a Dovecot, amely IMAP és POP3 protokollon is ki tud szolgálni. A következő ábra egy levél útját mutatja levelezőszervereken keresztül. SzitWiki -

4 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet A fentiek alapján egy levél útja általánosan így írható le: MUA levelező kliens SMTP MUA MTA levelezőszerver SMTP MTA Inbox POP3 levelezőszerver levelező kliens A protokolljai, portjai Emlékeztetőül nézzük meg két gép között egy kapcsolatot: Egy kapcsolat: Mindkét gép rendelkezik egy saját IP címmel. A kezdeményező gép nyit egy szoftveres portot 1023 felett. Átküldi a másik gépnek a csomagot, ami egy szerver. A szerveren fut a levelezést kiszolgáló folyamat és folyamatosan várja a kapcsolódást a 25-s porton. A csomagok tehát a másik gép 25-s portján érkeznek a célgépre. A levelezésnél használt szerveroldali portok az ismert portokhoz tartoznak. Mint azt egy fentebbi ábrán láttuk a kliens oldalon viszont egy regisztrált port nyílik meg a kapcsolatteremtés céljából. A levelezésnél használt szoftveres portok: 25 - SMTP - Levelek fogadására használjuk POP3 - Levelek olvasására alkalmas IMAP - Levelek olvasására alkalmas SMTPS - Levelek fogadása SSL/TLS kapcsolaton keresztül POP3S - Levelek kiszolgálása letöltésre, olvasásra SSL/TLS kapcsolaton keresztül IMAPS - Levelek kiszolgálása olvasásra SSL/TLS kapcsolaton keresztül Printed on 2016/12/03 02:10

5 2016/12/03 02:10 5/18 Elektronikus levelezés Láthatjuk, hogy háromféle protokoll létezik, az SMTP, a POP3 és az IMAP. Amennyiben azt szeretnék jelezni, hogy ezt a protokollt titkosított csatornán keresztül valósítjuk meg, egy S betűt írunk a protokoll végére. Így a három protokollhoz hat darab port létezik. Szerver és kliens szempontból a következő kapcsolatok jöhetnek létre: Kliens POP3 Szerver Kliens IMAP Szerver Kliens SMTP Szerver Szerver SMTP Szerver Szerverek között mindig SMTP kapcsolat jön létre. Amikor a felhasználó el akarja érni a leveleket akkor azt vagy POP3 vagy IMAP protokollon keresztül teszi. De ha levelet akar küldeni kliens programból, akkor SMTP protokollt használ a kliens program is. Ha webes felületen küldünk levelet, ne felejtsük el, hogy a levél tulajdonképpen a webszerveren jön létre, és csak helyben mozog az adott szerveren. Hogy használ-e SMTP protokollt az csak a webes megvalósítástól függ. Levéltárolás A levelezőszerverek a leveleket általában két módon tárolják, mailbox vagy Maildir formátumban. A mailbox tárolás esetén minden felhasználónak van egy állománya amelyben megtalálhatók a levelei. Maildir esetén minden levelet külön fájlban tárolunk. mailbox a levelek egyetlen fájlban ahány levél, annyi fájl Maildir Sok levél esetén nagyon lassú Sok levél esetén jó megoldás Mbox Mbox: SzitWiki -

6 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet Maildir A Maildir tárolás esetnén találunk egy Maildir nevű könyvtárat a felhasználó könyvtárában. A Maildir könyvtárban újabb három könyvtár van. Ezek a cur, new és a tmp. Könyvtár cur new tmp Olvasott levelek Új levelek Funkció Levélfogadáskor ide érkezik először Amikor éppen érkezik egy levél a tmp könyvtárba lesz tárolva. Amint letöltődött az egész levél átkerül a new könyvtárba. Amikor a felhasználó elolvassa a levelet, akkor átkerül a cur könyvtárba. Maildir: Printed on 2016/12/03 02:10

7 2016/12/03 02:10 7/18 Elektronikus levelezés Virtuális felhasználók, Maildirben: MUA A MUA a Mail User Agent szavakból alkotott betűszó. Egy levelező kliens programot értünk alatta. Néhány népszerűbb levelező program: Thunderbird Evolution SzitWiki -

8 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet Claws Mail Sylpheed Opera Mail The Bat! Pegasus Mail Microsoft Outlook Outlook Express Kmail Mutt - konzolos Alpine - konzolos Cone - konzolos Geary Az ről Az t az RFC 822 írja. Ennek továbbfejlesztett verziója az RFC Ezzel azonban csak a 7bites US-ASCII kódolású levelek készíthetők. A MIME (Multipurpose Internet Mail Extensions) lehetővé teszi levelek küldését más kódolással, képek, bináris, illetve minden nem szöveges anyag küldését (RFC 2045, 2046, 2047, 2048, 2049). A MIME egy népszerű megoldás lett bináris, illetve nem ASCII-7 szövegek tartalmának kódolására. A megoldást az Internet más alkalmazásai is átvették. Manapság a legtöbb MIME kódolással megy át az Interneten, mivel az SMTP protokoll azóta is csak 7bites US-ASCII átküldésére alkalmas. Az részei Egy két részből áll. A fejrész és a törzs. A törzs tartalmazza magát a levelet. A fejrész pedig az ről add információkat. Printed on 2016/12/03 02:10

9 2016/12/03 02:10 9/18 Elektronikus levelezés A fejrész minden egyes sorára, mint mezőre szokás hivatkozni. Egy mező egy névből, a hozzátartozó értékből, a kettő között (:) kettőspont szeparátorból áll. forrása Az alábbi eket egy mutt klienssel írtam helyi másik felhasználónak. From joska@meteor Sun Oct 27 14:37: Return-Path: <joska@meteor> X-Original-To: andras@meteor Delivered-To: andras@meteor Received: by meteor (Postfix, from userid 5001) id 395CD1E1741; Sun, 27 Oct :37: (CET) Date: Sun, 27 Oct :37: From: Teszt =?iso ?q?j=f3zsef?= <joska@meteor> To: andras@meteor Subject: teszt 001 Message-ID: < GA5180@meteor> MIME-Version: 1.0 Content-Type: text/plain; charset=iso Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/ ( ) Status: O Content-Length: 44 Lines: 6 SzitWiki -

10 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet Teszt levél 001 András Másik levél UTF-8 kódolással: From Sun Oct 27 14:43: Return-Path: X-Original-To: Delivered-To: Received: by meteor (Postfix, from userid 5001) id 91A7D1E1741; Sun, 27 Oct :43: (CET) Date: Sun, 27 Oct :43: From: Teszt =?iso ?q?j=f3zsef?= To: Subject: teszt 002 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/ ( ) Teszt 002 levél. Árvíztűrő tükörfúrógép. András forrás újra A levelező kliens által gyártott plusz fejlécmezőkkel: From - Fri Feb 24 09:06: X-Account-Key: account3 X-UIDL: fmx03.fre .hu X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-Path: <nagyjozsef@gmail.com> Delivered-To: kispeter@fre .hu Received: (qmail invoked from network); 24 Feb :06: Received: from (HELO fmx03.fre .hu) ( ) Printed on 2016/12/03 02:10

11 2016/12/03 02:10 11/18 Elektronikus levelezés by localhost with SMTP; 24 Feb :06: Received: by wibhq12 with SMTP id hq12so wib.35 for Fri, 24 Feb :06: (PST) Received-SPF: pass (google.com: domain of designates as permitted sender) client-ip= ; Authentication-Results: mr.google.com; spf=pass (google.com: domain of designates as permitted sender) dkim=pass Received: from mr.google.com ([ ]) by with SMTP id m84mr705279wei (num_hops = 1); Fri, 24 Feb :06: (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mcx38+lptaagytimh7dsf42rqhwokiccian7w2wpq7e=; b=ziruudghsyvzgachdo9xrthv110kwjayn54zxa7nim8ofzkcsxw/sorf8jj2eo6snu reda47a+5n5gykb0zsyuvx71iiuvejxhzkcfbe5btime8pptua4pmuo+ccubinrecant T5ofwK/AIxEZpAl2+xJMp9gMDUh879Wtbne84= Received: by with SMTP id m84mr577703wei ; Fri, 24 Feb :06: (PST) Return-Path: <nagyjozsef@gmail.com> Received: from [ ] (catv catv.broadband.hu. [ ]) by mx.google.com with ESMTPS id dr5sm wib (version=sslv3 cipher=other); Fri, 24 Feb :06: (PST) Message-ID: <4F @gmail.com> Date: Fri, 24 Feb :06: From: =?ISO ?Q?Nagy_Jozsef= <nagyjozsef@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/ Thunderbird/ MIME-Version: 1.0 To: kispeter@fre .hu Subject: tesz 001 Content-Type: text/plain; charset=iso ; format=flowed Content-Transfer-Encoding: 8bit X-Fre message scanned teszt Nagy Jozsef Ha ki kell deríteni, honnan jött egy levél, akkor ahhoz Received mezők használata ajánlott, a többi aránylag könnyen hamisítható. SzitWiki -

12 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet A fejrész talán legfontosabb része amely leírja kinek megy a levél. Ebből azonban kettő van. Ha nevén akarjuk nevezni akkor az egyik a RCPT TO mező, a másik a To mező. A levelezőszerverek a RCPT TO mező alapján irányítják a leveleket a To mezővel nem foglalkoznak. Viszont a To mező az emely meghatározza mi jelenjen meg a levél olvasójának. Ilyen fontos rész lehet még, hogy kitől jött a levél. Ebből is kettő van, a MAIL FROM és a From. A levelezőszerverek itt is csak az elsővel foglalkoznak, a második pedig az ami a felhasználók számára megjelenik. Látjuk, hogy ami a felhasználónak megjelenik az egészen más is lehet mint amit levelezőszerver figyelembe vesz. Persze így van ez a Csigapostán (hagyományos posta) is. Van egy boríték, az alapján kézbesítenek, és a levélben lehet egészen más címzett. Feladó/címzett Envelope sender/recipient Levélfejléc Boríték MAIL FROM: RCPT TO: Levél Return-Path: Delivered-To: Received-To: From: To: Subject: Így fordulhat elő, hogy megérkezik egy levél de To: mezőben nem is az én címem van. Ez persze természetes egy levelezőlistánál. SMTP kommunikáció Az envelope sender és recipient a levél mezői között nem is jelennek meg. Ezt csak az SMTP kommunikációban láthatjuk, ha látjuk. Az envelope sender és recipient, tulajdonképpen utasítások formájában van jelen az SMTP kommunikációban. Az SMTP két gép utasításokat (vagy kéréseket) fogalmaz meg. Például, köszön az egyik. Erre a másik megmondja ki ő, majd közli, hogy várja a további teendőket. Erre a kezdeményező, szól, hogy akkor most bemondja a feladót (MAIL FROM). Ha fogadó elfogadja, a küldő bemondja a címzettet, stb. Ezek az utasítások csak adott szabályok szerint, adott sorrendben történhetnek. A levelezőszerver rendszergazdája, növelheti a SMTP kommunikáció szigorát. Például megkövetelheti, hogy ha valaki beköszön, mondjon magáról egy valós létező domain nevet. Ha nem valósat mond, nem fogad el leveleket a levelező szerver. Ilyen és ehhez hasonló szigorításokat szoktak a rendszergazdák bevezetni a SPAM elleni védekezés részeként. SMTP alaputasítások: EHLO ki vagyok MAIL FROM Kitől van a levél RCPT TO Kinek szól a levél DATA Küldöm az adatokat Az SMTP kapcsolatot egy telnet programmal mi is végezhetünk egy szerverrel. Kapcsolódjunk egy Printed on 2016/12/03 02:10

13 2016/12/03 02:10 13/18 Elektronikus levelezés telnet programmal a saját levelezőszerverünkhöz. A levelezőszerver 25-ös porton fogadja a leveleket. Ezért a parancssorba a következőket írjuk: telnet localhost 25 A kommunikáció ehhez hasonlóan nézhet ki: 220 piros.hu ESMTP Postfix (Debian/GNU) ehlo zold.hu 250-piros.hu 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: <jozsi@zold.hu> Ok rcpt to: <kati@piros.hu> Ok data 354 End data with <CR><LF>.<CR><LF> Számok 250 Elfogadom az címet 4xx hibaüzenet, de a levelet ideiglenesen még elfogadjuk 5xx fatális hiba, a levelet eldobjuk POP3 kommunikáció POP3 alaputasítások USER felhasznalonev - felhasználónév PASS jelszó - Jelszó megadása STAT - levelek száma és összméret LIST - levelek sorszámmal és mérettel RETR Letöltés DELE Törlése POP3 teszt fre -en telnet zold.and 110 Trying Connected to zold.and. SzitWiki -

14 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet Escape character is '^]'. +OK user jozsi +OK pass titok +OK IMAP A levelek nem töltődnek le, a szerveren tárolódnak. Sok funkció, üzenetállapotok, stb. Rögtön el is köszönünk: a01 logout Egy valódi kapcsolat esetén sok más információ is érkezik: Trying ::1... Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THRE AD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready Copyright Double Precision, Inc. See COPYNG for distribution information. a01 logout Bejelentkezünk: a01 login joska titok a02 logout Mappák lekérdezése: a02 list "" "*" * LIST (\Unmarked \HasChildren) "." "INBOX" * LIST (\HasNoChildren) "." "INBOX.Trash" a02 OK LIST completed Az INBOX kiválasztása: a03 select inbox * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited * 1 EXISTS * 0 RECENT * OK [UIDVALIDITY ] Ok Printed on 2016/12/03 02:10

15 2016/12/03 02:10 15/18 Elektronikus levelezés * OK [MYRIGHTS "acdilrsw"] ACL a03 OK [READ-WRITE] Ok Üzenet lekérése: a04 fetch 1:* flags * 1 FETCH (FLAGS (\Seen)) a04 OK FETCH completed. a05 fetch 1 full * 1 FETCH (FLAGS (\Seen) INTERNALDATE "08-Jul :22: " RFC822.SIZE 2895 ENVELOPE ("Mon, 8 Jul :22: (CEST)" "Teszt level" ((NIL NIL "V" "verem.zold.and")) ((NIL NIL "V" "verem.zold.and")) ((NIL NIL "V" "verem.zold.and")) ((NIL NIL "N" "verem.zold.and")) NIL NIL NIL "< D429E9@verem.zold.and>") BODY (("text" "plain" ("charset" "iso ") NIL NIL "8bit" ) ("message" "rfc822" ("x-spam-type" "original") NIL "original message before SpamAssassin" "8bit" 290 (NIL "Teszt level" ((NIL NIL "V" "")) ((NIL NIL "V" "")) ((NIL NIL "V" "")) ((NIL NIL "N" "")) NIL NIL NIL NIL) ("text" "plain" NIL NIL NIL "8bit" 71 1) 8) "mixed")) a05 OK FETCH completed. a06 fetch 1 body[text] * 1 FETCH (BODY[TEXT] {1752} This is a multi-part message in MIME format =_51DAA0EB.EF3051D1 Content-Type: text/plain; charset=iso Content-Disposition: inline Content-Transfer-Encoding: 8bit Spam detection software, running on the system "verem.zold.and", has identified this incoming as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future . If you have any questions, for details. Content preview: XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST- *C.34X [...] Content analysis details: ( points, 5.0 required) pts rule name description ALL_TRUSTED Passed through trusted hosts only via SMTP 1.2 TO_MALFORMED To: has a malformed address 0.2 FH_FROMEML_NOTLD address doesn't have TLD (.com, etc.) 1000 GTUBE BODY: Generic Test for Unsolicited Bulk 0.1 MISSING_MID Missing Message-Id: header SzitWiki -

16 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet TVD_SPACE_RATIO TVD_SPACE_RATIO 1.4 MISSING_DATE Missing Date: header =_51DAA0EB.EF3051D1 Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: inline Content-Transfer-Encoding: 8bit Received: from meteor (meteor.zold.and [ ]) by verem.zold.and (Postfix) with ESMTP id EA7AE429C6 for Mon, 8 Jul :22: (CEST) From: V To: N Subject: Teszt level XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST- *C.34X =_51DAA0EB.EF3051D1-- ) a06 OK FETCH completed. Visszapattanó levél Bounce Visszapattanó levél, vagy angolosan bounce. Esetleg bounce message. A visszapattanó levelet a következő nevekkel is használjuk: Non-Delivery Report/Receipt (NDR) Delivery Status Notification (DSN) Non-Delivery Notification (NDN) Tulajdonképpen a feladónak szóló üzenet, amely a kézbesítés sikertelenségéről informálja. A levél több ok miatt is vissza pattanhat. Lehet gondja a címzettel, de lehet gondja a feladóval is. Problémás címzett esetén ilyen lehet ha címzett postaládája elérte a maximális méretet, vagy egyszerűen nem is létezik. Általában elmondhatjuk, hogy ha egy levelet átvettünk akkor arról gondoskodnunk kell. Ha nem vesszük át, akkor értesíteni kell a feladót. Ezen szabály alól kivételt szoktunk mostanság tenni a spam-ek és a vírusos levelek esetén. Az ilyen levelek önmagukban is nagy levélforgalmat generálnak. Ha én azt még vissza is küldöm, akkor sokszorozom a problémát. Printed on 2016/12/03 02:10

17 2016/12/03 02:10 17/18 Elektronikus levelezés A visszapattanó levelet a levelezőszerverek átírják. Saját From mezőt írnak, ami természetes. A feladó ilyenkor néha null, azaz <>. De gyakori a From: mezőben a MAILER-DAEMON. A visszapattanó üzenetben több üzenet is segít tájékozódni. A visszapattanást okozó szerver azonosítója, dátum, az ok, stb. A visszapattanó levélben az üzenet egy része vagy a teljes üzenet is szokott szerepelni. Példa részlet: Remote-MTA: dns; smtp.zold.and [ ] Diagnostic-Code: smtp; 550 No such user here Automatikus válasz Az automatikus válasz nem visszapattanó levél, mivel válaszoltunk a levélre. Automatikus válasz például az úgynevezett vacation, vagyis nyaralásról szóló tájékoztató. Az automatikus válaszokat a RFC 3834 tárgyalja. A levelező szerver vagy tudják ezt a szolgáltatást, vagy egy segédprogrammal megoldható. Általában a felhasználó számára, valamilyen módon, például webes felületen lehetővé tesszük a vacation beállíthatóságát. Függelék Postfix, Dovecot, Maildir ESMTP Az ESMTP protokoll az SMTP kiterjesztése, amelyet RFC 1869 ír le. Az ESMTP a következő többletet tudja: 8BITMIME 8 bites adatátvitel, RFC 6152 ATRN Azonosítás után a fogadó küldhet levelet (On-Demand Mail Relay), RFC 2645 AUTH SMTP azonosítással, RFC 4954 SzitWiki -

18 Last update: 2015/12/21 16:37 oktatas:linux: _szerver: _elmélet CHUNKING darabolás, RFC 3030 DSN Kézbesítési állapotok feljegyzése, RFC 3461 (Lásd a boríték változó visszatérési útját) ETRN Távoli várakozási sorban, TURN paranccsal kezelt levelek kiterjesztése, RFC 1985 HELP Hasznos információk szolgáltatása, RFC 821 PIPELINING Parancsok használata csővezetékben, RFC 2920 SIZE Üzenet méretének megadása, RFC 1870 STARTTLS Az átviteli réteg titkosítása, RFC 3207 (2002) SMTPUTF8 UTF-8 engedélyezése a mailbox nevében és a fejlécmezőkben., RFC 6531 LMTP Local Mail Transport Protocol DKIM A tartománynevünkhöz tartozó TXT rekordot állítunk be a DNS szerveren, amely egy nyilvános kulcsot tartalmaz. Minden kimenő levélhez hozzáadunk egy aláírást, amelyet a levél fogadója ellenőrizhet a DNS szerveren elhelyezett nyilvános kulcs alapján. Így a levelek fogadója meggyőződhet arról, hogy a levél valóban tőlünk származik. Ha valaki kap egy levelet, amely azt állítja magáról, hogy a mi tartományunkból jön, akkor csak meg kell néznie, hogy alá van-e írva. Ha alá van írva, akkor elfogadja, ha nem akkor valószínűleg nem tőlünk ment a levél. A DKIM szabványt az RFC 4871 írja le. Irodalom (Levelező szerverek) (Levelező szerverek összehasonlítása) (Evoluton Windowsra) (Evoluton Windowsra) From: - SzitWiki Permanent link: Last update: 2015/12/21 16:37 Printed on 2016/12/03 02:10