• Szerző: Sallai András
• Copyright © Sallai András, 2011, 2013, 2015, 2020
• Licenc: GNU Free Documentation License 1.3
• Web: https://szit.hu

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

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:

A következő táblázat néhány közismert portot mutat be.

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
• 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:

A levelező kliens:

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.

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

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
• 110 - POP3 - Levelek olvasására alkalmas
• 143 - IMAP - Levelek olvasására alkalmas
• 465 - SMTPS - Levelek fogadása SSL/TLS kapcsolaton keresztül
• 995 - POP3S - Levelek kiszolgálása letöltésre, olvasásra SSL/TLS kapcsolaton keresztül
• 993 - IMAPS - Levelek kiszolgálása olvasásra SSL/TLS kapcsolaton keresztül

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:

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.

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.

Mbox:

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.

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:

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
• Claws Mail
• Sylpheed
• Opera Mail
• The Bat!
• Pegasus Mail
• Microsoft Outlook
• Outlook Express
• Kmail
• Mutt - konzolos
• Alpine - konzolos
• Cone - konzolos
• Geary

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.

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.

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

From joska@meteor  Sun Oct 27 14:37:19 2013
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 2013 14:37:19 +0100 (CET)
Date: Sun, 27 Oct 2013 14:37:19 +0100
From: Teszt =?iso-8859-1?Q?J=F3zsef?= <joska@meteor>
To: andras@meteor
Subject: teszt 001
Message-ID: <20131027133719.GA5180@meteor>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.21 (2010-09-15)
Status: O
Content-Length: 44
Lines: 6
 
Teszt levél 001
 
András
 
---
http://szit.hu

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

From joska@meteor  Sun Oct 27 14:43:34 2013
Return-Path: <joska@meteor>
X-Original-To: andras@meteor
Delivered-To: andras@meteor
Received: by meteor (Postfix, from userid 5001)
	id 91A7D1E1741; Sun, 27 Oct 2013 14:43:34 +0100 (CET)
Date: Sun, 27 Oct 2013 14:43:34 +0100
From: Teszt =?iso-8859-1?Q?J=F3zsef?= <joska@meteor>
To: andras@meteor
Subject: teszt 002
Message-ID: <20131027134334.GA5402@meteor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.21 (2010-09-15)
 
Teszt 002 levél.
 
Árvíztűrő tükörfúrógép.
 
András
---
http://szit.hu

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

From - Fri Feb 24 09:06:44 2012
X-Account-Key: account3
X-UIDL: 1330070807.83976.fmx03.freemail.hu
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Return-Path: <nagyjozsef@gmail.com>
Delivered-To: kispeter@freemail.hu
Received: (qmail 83917 invoked from network); 24 Feb 2012 09:06:46 +0100
Received: from 127.0.0.1 (HELO fmx03.freemail.hu) (209.85.212.176)
  by localhost with SMTP; 24 Feb 2012 09:06:46 +0100
Received: by wibhq12 with SMTP id hq12so1783514wib.35
        for <kispeter@freemail.hu>; Fri, 24 Feb 2012 00:06:46 -0800 (PST)
Received-SPF: pass (google.com: domain of nagyjozsef@gmail.com designates 10.216.131.234 as permitted sender) client-ip=10.216.131.234;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of nagyjozsef@gmail.com designates 10.216.131.234 as permitted sender) 
        smtp.mail=nagyjozsef@gmail.com; dkim=pass header.i=nagyjozsef@gmail.com
Received: from mr.google.com ([10.216.131.234])
        by 10.216.131.234 with SMTP id m84mr705279wei.24.1330070806022 (num_hops = 1);
        Fri, 24 Feb 2012 00:06:46 -0800 (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 10.216.131.234 with SMTP id m84mr577703wei.24.1330070805954;
        Fri, 24 Feb 2012 00:06:45 -0800 (PST)
Return-Path: <nagyjozsef@gmail.com>
Received: from [192.168.16.20] (catv-178-48-52-12.catv.broadband.hu. [178.48.52.12])
        by mx.google.com with ESMTPS id dr5sm5030563wib.0.2012.02.24.00.06.44
        (version=SSLv3 cipher=OTHER);
        Fri, 24 Feb 2012 00:06:44 -0800 (PST)
Message-ID: <4F474509.1010004@gmail.com>
Date: Fri, 24 Feb 2012 09:06:33 +0100
From: =?ISO-8859-2?Q?Nagy_Jozsef= <nagyjozsef@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: kispeter@freemail.hu
Subject: tesz 001
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-Freemail: message scanned
 
teszt 001
 
-- 
Nagy Jozsef
http://szit.hu

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.

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

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 (lehet HELO is)
• 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 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>

• 250 Elfogadom az e-mail címet
• 4xx hibaüzenet, de a levelet ideiglenesen még elfogadjuk
• 5xx fatális hiba, a levelet eldobjuk

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.

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

• 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 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

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

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

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.

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
• 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

Local Mail Transport Protocol

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.

• http://www.faqs.org/rfcs/rfc2822.html
• http://weblabor.hu/cikkek/emailekfelepiteselepesrollepesre
• http://en.wikipedia.org/wiki/List_of_mail_servers (Levelező szerverek)
• http://en.wikipedia.org/wiki/Comparison_of_mail_servers (Levelező szerverek összehasonlítása)
• http://evolution-win32.sourceforge.net/ (Evoluton Windowsra)
• http://www.go-evolution.org/Windows (Evoluton Windowsra)