Tartalomjegyzék

< E-mail szerver

Elektronikus levelezés

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:

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
1-1023 közismert portok Csak célportként használható
1024-49151 bejegyzett portok Cél és forrásportként is használható
49151-65535 egyéni portok Cél és forrásportként is használható

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 Dynamic Host Configuration Protocol - Dinamikus állomáskonfigurálási protokoll (ügyfél)
68 DHCP v4 kiszolgá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:

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 - E-mail 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:

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.

A fentiek alapján egy levél útja általánosan így írható le:

MUA
levelező kliens 		→ SMTP → MTA
levelezőszerver 		→ SMTP → MTA
levelezőszerver 		→ Inbox → POP3 → MUA
levelező kliens

A e-mail 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:

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 Maildir
a levelek
egyetlen fájlban 		ahány levél,
annyi fájl
Sok levél esetén nagyon lassú Sok levél esetén jó megoldás

Mbox

Mbox:

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 Funkció
cur Olvasott levelek
new Új levelek
tmp 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:

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:

E-mail

Az e-mailről

Az e-mailt az RFC 822 írja. Ennek továbbfejlesztett verziója az RFC 2822. 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 e-mail 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 e-mail részei

Egy e-mail 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 e-mailről add információkat.

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.

E-mail forrása

Az alábbi e-maileket egy mutt klienssel írtam helyi másik felhasználónak.

Másik levél UTF-8 kódolással:

E-mail forrás újra

A levelező kliens által gyártott plusz fejlécmezőkkel:

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

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 Levél
MAIL FROM:
RCPT TO: 		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 e-mail 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:

Az SMTP kapcsolatot egy telnet programmal mi is végezhetünk egy szerverrel. Kapcsolódjunk egy 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 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: <jozsi@zold.hu>
250 2.1.0 Ok
rcpt to: <kati@piros.hu>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>

Számok

A levelezés és a DNS szerver

A levelezőszerverek a DNS szerverektől kérdezik le, hova kell küldeni egy e-mailt. A DNS szerveren, ez az MX rekordban van tárolva.

POP3 kommunikáció

A POP3 protokoll a levelek letöltésére használható, kliens programból. A POP3 protokollt beszélő kliens programok, alapértelmezetten letöltik a leveleket a helyi gépre, a szerverről pedig törlik.

POP3 alaputasítások

POP3 teszt freemail-en 

telnet zold.and 110
Trying 192.168.10.1...
Connected to zold.and.
Escape character is '^]'.
+OK <24999.1259006863@zold.and>
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 1998
-2011 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 373283184] Ok
* 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-2013 13:22:19 +0200"
RFC822.SIZE 2895 ENVELOPE ("Mon,  8 Jul 2013 13:22:19 +0200 (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 "<20130708112219.7604D429E9@verem.zold.and>") 
BODY (("text" "plain" ("charset" "iso-8859-1") NIL NIL "8bit" 1023 22)
("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-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Spam detection software, running on the system "verem.zold.and", has
identified this incoming email 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 email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
   [...] 

Content analysis details:   (1002.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 1.2 TO_MALFORMED           To: has a malformed address
 0.2 FH_FROMEML_NOTLD       E-mail address doesn't have TLD (.com, etc.)
1000 GTUBE                  BODY: Generic Test for Unsolicited Bulk Email
 0.1 MISSING_MID            Missing Message-Id: header
 0.0 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 [192.168.5.5])
	by verem.zold.and (Postfix) with ESMTP id EA7AE429C6
	for <joska@verem.zold.and>; Mon,  8 Jul 2013 13:22:18 +0200 (CEST)
From: V
To: N
Subject: Teszt level

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*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:

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.

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 [192.168.5.10]
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:

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